Fait partie de notre série Performance & Scalability
Lire le guide completOptimisation des performances PostgreSQL pour Odoo : réglage, indexation et surveillance
Une instance PostgreSQL correctement réglée peut améliorer les temps de réponse d'Odoo de 2 à 5 fois par rapport aux paramètres par défaut. La plupart des problèmes de performances d'Odoo remontent à la configuration de la base de données - les paramètres PostgreSQL par défaut sont conçus pour une utilisation minimale des ressources, et non pour alimenter un système ERP multi-utilisateurs.
Points clés à retenir
- Les paramètres PostgreSQL par défaut utilisent uniquement 128 Mo de tampons partagés -- la production Odoo a besoin de 25 % de RAM
- Les index manquants sur les colonnes fréquemment interrogées entraînent des analyses complètes des tables et un chargement lent des pages.
- Le regroupement de connexions avec PgBouncer réduit la surcharge de connexion à la base de données de 80 %
- VACUUM et ANALYZE réguliers évitent le gonflement des tables et maintiennent les plans de requête optimaux
Réglage de la configuration PostgreSQL
Paramètres de mémoire
Modifiez postgresql.conf avec les paramètres appropriés à votre matériel. Pour un serveur avec 16 Go de RAM, définissez shared_buffers sur 4 Go (25 % de la RAM totale), effective_cache_size sur 12 Go (75 % de la RAM totale), work_mem sur 64 Mo par opération, maintenance_work_mem sur 1 Go et wal_buffers sur 64 Mo.
Pour la planification des requêtes, définissez random_page_cost sur 1,1 pour le stockage SSD (la valeur par défaut 4,0 suppose un disque dur), effective_io_concurrency sur 200 pour les SSD et default_statistics_target sur 200 pour des plans de requête plus précis.
Consignes de dimensionnement :
| RAM du serveur | shared_buffers | effective_cache_size | travail_mem |
|---|---|---|---|
| 4 Go | 1 Go | 3 Go | 16 Mo |
| 8 Go | 2 Go | 6 Go | 32 Mo |
| 16 Go | 4 Go | 12 Go | 64 Mo |
| 32 Go | 8 Go | 24 Go | 128 Mo |
| 64 Go | 16 Go | 48 Go | 256 Mo |
Paramètres de connexion
Définissez max_connections sur au moins les travailleurs Odoo x 2 plus le tampon. Avec 4 travailleurs et 2 threads cron, vous avez besoin d'au moins 12 connexions. Ajoutez des connexions pour les outils d'administration, la surveillance et les tâches en arrière-plan. Une valeur de 200 offre une hauteur libre confortable.
Stratégies d'indexation pour Odoo
Identification des index manquants
Activez la journalisation lente des requêtes en définissant log_min_duration_statement sur 500 ms. Analysez ensuite le journal des requêtes lentes pour identifier les analyses de table complètes.
Index Odoo communs
Odoo crée automatiquement des index sur les clés primaires et les clés étrangères. Ajoutez des index sur les colonnes fréquemment filtrées telles que sale_order(state), account_move(state), stock_move(state), account_move(date) et sale_order(date_order).
Les index multi-colonnes améliorent les combinaisons de filtres courantes : account_move_line(account_id, date) et stock_quant(product_id, location_id).
Pour les tables avec des colonnes d'état, les index partiels sur les enregistrements actifs sont plus efficaces : indexez uniquement les lignes où l'état n'est pas annulé ou terminé.
Analyse des requêtes avec EXPLAIN ANALYZE
Exécutez EXPLAIN (ANALYZE, BUFFERS) sur des requêtes lentes pour comprendre les plans d'exécution. Recherchez :
- Seq Scan : analyse complète de la table indiquant un index manquant
- Nested Loop : peut être coûteux avec de grands ensembles de résultats
- Tri : les tris en mémoire dépassant work_mem se déversent sur le disque
- Tampons de lecture partagés : des valeurs élevées signifient que les données ne sont pas mises en cache
Les tueurs de performances courants :
- Index manquants sur les colonnes de la clause WHERE
- Grandes clauses IN générées par Odoo ORM
- Champs calculés stockés déclenchant un recalcul lors des écritures
- Requêtes de rapport complexes joignant plus de 5 tables
VIDE et Entretien
PostgreSQL MVCC crée des tuples morts lorsque les lignes sont mises à jour ou supprimées. VACUUM récupère cet espace et met à jour les statistiques.
Configurez l'autovacuum pour les charges de travail Odoo : activez l'autovacuum avec 3 travailleurs maximum, une sieste de 60 secondes, un facteur d'échelle de vide de 0,05 et analysez le facteur d'échelle de 0,02. Pour les tables à écriture élevée (account_move_line, stock_move, mail_message), définissez des paramètres par table plus agressifs.
Surveillez le gonflement des tables en vérifiant la taille totale des relations et le nombre de tuples morts. Utilisez VACUUM FULL uniquement en cas de ballonnement extrême (plus de 50 % d'espace mort) et uniquement pendant les fenêtres de maintenance car il verrouille la table.
Regroupement de connexions avec PgBouncer
PgBouncer se situe entre Odoo et PostgreSQL, regroupant les connexions pour réduire les frais généraux. Utilisez le mode pool de transactions pour Odoo, qui libère les connexions entre les transactions. Définissez default_pool_size sur 40 et max_client_conn sur 200. Pointez Odoo vers le port PgBouncer au lieu de PostgreSQL directement.
Surveillance
Métriques essentielles
- Connexions actives : doivent rester bien en dessous de max_connections
- Taux de réussite du cache : doit être supérieur à 99 %
- Taux de transaction : référence et surveillance des anomalies
- Nombre de requêtes lent : requêtes dépassant votre seuil
- Délai de réplication : si vous utilisez des réplicas en lecture
- Utilisation du disque : taux de croissance de la taille de la base de données
- Table bloat : ratio de tuples morts par table
Utilisez l'extension pg_stat_statements pour suivre les performances des requêtes au fil du temps. Il enregistre le nombre d'exécutions, la durée totale, la durée moyenne et les lignes renvoyées pour chaque modèle de requête distinct.
Questions fréquemment posées
Q : Comment savoir si PostgreSQL est le goulot d'étranglement ?
Activez la journalisation lente des requêtes et vérifiez les journaux de performances Odoo. Si la plupart des requêtes lentes correspondent à des requêtes lentes, le réglage sera utile. Si les requêtes sont rapides mais qu'Odoo est lent, le goulot d'étranglement réside dans le code de l'application ou le réseau.
Q : Dois-je utiliser des répliques PostgreSQL pour Odoo ?
Les réplicas en lecture déchargent les requêtes de reporting de la base de données principale. Odoo ne prend pas en charge nativement le fractionnement lecture/écriture, donc la configuration personnalisée achemine les requêtes en lecture seule vers les réplicas. Ceci est principalement utile pour les très grands déploiements.
Q : Quelle version de PostgreSQL dois-je utiliser avec Odoo ?
Utilisez la dernière version stable prise en charge par votre version Odoo. Les versions plus récentes incluent des améliorations de l'optimiseur de requêtes et de meilleures performances de vide. PostgreSQL 16 ou 17 sont recommandés pour les versions actuelles d'Odoo.
Q : Dans quelle mesure un réglage approprié est-il réellement utile ?
D'après notre expérience, le passage des paramètres par défaut à une configuration optimisée améliore généralement les temps de chargement moyens des pages de 40 à 60 % et réduit la fréquence des requêtes lentes de 80 à 90 %. L’amélioration est spectaculaire et immédiate.
Quelle est la prochaine étape
Le réglage PostgreSQL est l’optimisation ayant le plus grand impact sur les performances d’Odoo. Commencez par les paramètres de mémoire et l’indexation – ces deux changements à eux seuls réduisent souvent les temps de réponse de moitié.
Contactez ECOSIRE pour obtenir de l'aide sur l'optimisation de la base de données, ou explorez nos services d'assistance Odoo pour une gestion continue des performances.
Publié par ECOSIRE – aider les entreprises à évoluer grâce à des solutions logicielles d'entreprise.
Rédigé par
ECOSIRE TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
ECOSIRE
Transformez votre entreprise avec Odoo ERP
Implémentation, personnalisation et assistance expertes d'Odoo pour rationaliser vos opérations.
Articles connexes
Comment ajouter un bouton personnalisé à une vue de formulaire Odoo (2026)
Ajoutez des boutons d'action personnalisés aux vues de formulaire Odoo 19 : méthode d'action Python, héritage des vues, visibilité conditionnelle, boîtes de dialogue de confirmation. Testé en production.
Comment ajouter un champ personnalisé dans Odoo sans Studio (2026)
Ajoutez des champs personnalisés via le module personnalisé dans Odoo 19 : héritage de modèle, extension de vue, champs calculés, décisions magasin/non-magasin. Code d'abord, contrôle de version.
Comment ajouter un rapport personnalisé dans Odoo à l'aide d'une mise en page externe
Créez un rapport PDF de marque dans Odoo 19 à l'aide de web.external_layout : modèle QWeb, format papier, liaison d'action. Avec logo imprimé + remplacements de pied de page.
Plus de Performance & Scalability
Odoo 19 RH : Matrice de compétences, Plans de carrière, Cycles de performance
Mise à niveau Odoo 19 RH : matrice de compétences natives, planification de parcours professionnel, cycles d'évaluation de performances, grille de 9 cases, planification de succession, intégration SIRH.
Benchmarks de performances Odoo 19 : numéros de réglage PostgreSQL 17
Benchmarks de performances Odoo 19 dans le monde réel : vitesse du client Web, débit ORM, paramètres de réglage PG17, regroupement de connexions, nombre de travailleurs, seuils de mise à l'échelle.
Optimisation des coûts OpenClaw et efficacité des jetons à grande échelle
Optimisation du coût des jetons OpenClaw : mise en cache des invites, routage des modèles, mise en cache des réponses, API par lots et garde-fous de coûts par locataire pour les agents de production.
Actualisation incrémentielle de Power BI pour les tables de plus de 10 millions de lignes
Playbook d'actualisation incrémentielle Power BI pour plus de 10 millions de tables de lignes : conception de partitions, RangeStart/RangeEnd, stratégies d'actualisation, repliement des requêtes et hybrides DirectQuery.
Débogage et surveillance des webhooks : le guide de dépannage complet
Maîtrisez le débogage des webhooks avec ce guide complet couvrant les modèles de défaillance, les outils de débogage, les stratégies de nouvelle tentative, les tableaux de bord de surveillance et les meilleures pratiques de sécurité.
Tests de charge k6 : testez sous contrainte vos API avant le lancement
Maîtrisez les tests de charge K6 pour les API Node.js. Couvre les montées en puissance des utilisateurs virtuels, les seuils, les scénarios, HTTP/2, les tests WebSocket, les tableaux de bord Grafana et les modèles d'intégration CI.