हमारी Performance & Scalability श्रृंखला का हिस्सा
पूरी गाइड पढ़ेंOdoo के लिए PostgreSQL प्रदर्शन अनुकूलन: ट्यूनिंग, इंडेक्सिंग और मॉनिटरिंग
** एक ठीक से ट्यून किया गया PostgreSQL इंस्टेंस डिफ़ॉल्ट सेटिंग्स की तुलना में Odoo प्रतिक्रिया समय को 2-5x तक सुधार सकता है। ** अधिकांश Odoo प्रदर्शन समस्याएं डेटाबेस कॉन्फ़िगरेशन पर वापस आती हैं - डिफ़ॉल्ट PostgreSQL सेटिंग्स न्यूनतम संसाधन उपयोग के लिए डिज़ाइन की गई हैं, न कि बहु-उपयोगकर्ता ईआरपी सिस्टम को पावर देने के लिए।
मुख्य बातें
- डिफ़ॉल्ट PostgreSQL सेटिंग्स केवल 128MB साझा बफ़र्स का उपयोग करती हैं - उत्पादन Odoo को 25% RAM की आवश्यकता होती है
- अक्सर पूछे जाने वाले कॉलम पर गुम अनुक्रमणिका पूर्ण तालिका स्कैन और धीमे पृष्ठ लोड का कारण बनती है
- PgBouncer के साथ कनेक्शन पूलिंग डेटाबेस कनेक्शन ओवरहेड को 80% तक कम कर देता है
- नियमित वैक्यूम और विश्लेषण टेबल ब्लोट को रोकता है और क्वेरी योजनाओं को इष्टतम रखता है
PostgreSQL कॉन्फ़िगरेशन ट्यूनिंग
मेमोरी सेटिंग्स
अपने हार्डवेयर के लिए उपयुक्त सेटिंग्स के साथ postgresql.conf संपादित करें। 16 जीबी रैम वाले सर्वर के लिए, शेयर्ड_बफ़र्स को 4 जीबी (कुल रैम का 25%), इफेक्टिव_कैश_साइज़ को 12 जीबी (कुल रैम का 75%), वर्क_मेम को 64 एमबी प्रति ऑपरेशन, मेंटेनेंस_वर्क_मेम को 1 जीबी और वॉल_बफ़र्स को 64 एमबी पर सेट करें।
क्वेरी प्लानिंग के लिए, SSD स्टोरेज के लिए रैंडम_पेज_कॉस्ट को 1.1 पर सेट करें (डिफ़ॉल्ट 4.0 HDD मानता है), SSDs के लिए इफेक्टिव_io_concurrency को 200 पर सेट करें, और अधिक सटीक क्वेरी प्लान के लिए default_statistics_target को 200 पर सेट करें।
आकार संबंधी दिशानिर्देश:
| सर्वर रैम | साझा_बफ़र्स | प्रभावी_कैश_आकार | काम_मेम |
|---|---|---|---|
| 4 जीबी | 1जीबी | 3 जीबी | 16एमबी |
| 8जीबी | 2 जीबी | 6GB | 32एमबी |
| 16जीबी | 4 जीबी | 12जीबी | 64एमबी |
| 32जीबी | 8जीबी | 24जीबी | 128एमबी |
| 64जीबी | 16जीबी | 48GB | 256एमबी |
कनेक्शन सेटिंग्स
max_connections को कम से कम Odoo Workers x 2 प्लस बफर पर सेट करें। 4 श्रमिकों और 2 क्रोन धागे के साथ, आपको कम से कम 12 कनेक्शन की आवश्यकता है। व्यवस्थापक उपकरण, निगरानी और पृष्ठभूमि कार्यों के लिए कनेक्शन जोड़ें। 200 का मान आरामदायक हेडरूम प्रदान करता है।
ओडू के लिए अनुक्रमण रणनीतियाँ
गुम सूचकांकों की पहचान करना
log_min_duration_statement को 500ms पर सेट करके धीमी क्वेरी लॉगिंग सक्षम करें। फिर पूर्ण तालिका स्कैन की पहचान करने के लिए धीमी क्वेरी लॉग का विश्लेषण करें।
सामान्य ओडू सूचकांक
Odoo प्राथमिक कुंजी और विदेशी कुंजी पर स्वचालित रूप से अनुक्रमणिका बनाता है। सेल_ऑर्डर(स्टेट), अकाउंट_मूव(स्टेट), स्टॉक_मूव(स्टेट), अकाउंट_मूव(दिनांक), और सेल_ऑर्डर(डेट_ऑर्डर) जैसे बार-बार फ़िल्टर किए गए कॉलम पर इंडेक्स जोड़ें।
मल्टी-कॉलम इंडेक्स सामान्य फ़िल्टर संयोजनों में सुधार करते हैं: अकाउंट_मूव_लाइन (अकाउंट_आईडी, दिनांक) और स्टॉक_क्वांट (प्रोडक्ट_आईडी, लोकेशन_आईडी)।
स्थिति कॉलम वाली तालिकाओं के लिए, सक्रिय रिकॉर्ड पर आंशिक अनुक्रमणिका अधिक कुशल होती हैं - केवल उन पंक्तियों को अनुक्रमित करें जहां स्थिति रद्द नहीं की गई है या नहीं की गई है।
व्याख्या विश्लेषण के साथ क्वेरी विश्लेषण
निष्पादन योजनाओं को समझने के लिए धीमी क्वेरी पर EXPLAIN (विश्लेषण, बफर) चलाएँ। खोजें:
- सेक स्कैन: पूर्ण तालिका स्कैन एक अनुपलब्ध सूचकांक का संकेत देता है
- नेस्टेड लूप: बड़े परिणाम सेट के साथ महंगा हो सकता है
- सॉर्ट: इन-मेमोरी सॉर्ट्स वर्क_मेम से अधिक होकर डिस्क पर फैल जाते हैं
- ** बफ़र्स साझा रीड**: उच्च मूल्यों का मतलब है कि डेटा कैश नहीं किया गया है
सामान्य प्रदर्शन हत्यारे:
- WHERE क्लॉज कॉलम पर अनुपलब्ध अनुक्रमणिका
- Odoo ORM द्वारा उत्पन्न बड़े IN खंड
- संग्रहित परिकलित फ़ील्ड लिखने पर पुनर्गणना को ट्रिगर करते हैं
- 5+ तालिकाओं को जोड़ने वाली जटिल रिपोर्ट क्वेरीज़
वैक्यूम और रखरखाव
जब पंक्तियाँ अद्यतन या हटाई जाती हैं तो PostgreSQL MVCC मृत टुपल्स बनाता है। VACUUM इस स्थान को पुनः प्राप्त करता है और आँकड़ों को अद्यतन करता है।
ओडू वर्कलोड के लिए ऑटोवैक्यूम कॉन्फ़िगर करें: 3 अधिकतम श्रमिकों, 60-सेकंड नैपटाइम, 0.05 के वैक्यूम स्केल फैक्टर के साथ ऑटोवैक्यूम सक्षम करें, और 0.02 के स्केल फैक्टर का विश्लेषण करें। हाई-राइट टेबल (अकाउंट_मूव_लाइन, स्टॉक_मूव, मेल_मैसेज) के लिए, अधिक आक्रामक प्रति-टेबल सेटिंग्स सेट करें।
कुल संबंध आकार और मृत टुपल गिनती की जांच करके टेबल ब्लोट की निगरानी करें। वैक्यूम फुल का उपयोग केवल अत्यधिक सूजन (50% से अधिक मृत स्थान) के लिए और केवल रखरखाव खिड़कियों के दौरान करें क्योंकि यह टेबल को लॉक कर देता है।
PgBouncer के साथ कनेक्शन पूलिंग
PgBouncer Odoo और PostgreSQL के बीच बैठता है, ओवरहेड को कम करने के लिए कनेक्शन पूल करता है। ओडू के लिए लेनदेन पूल मोड का उपयोग करें, जो लेनदेन के बीच कनेक्शन जारी करता है। default_pool_size को 40 और max_client_conn को 200 पर सेट करें। Odoo को सीधे PostgreSQL के बजाय PgBouncer पोर्ट पर इंगित करें।
निगरानी
आवश्यक मेट्रिक्स
- सक्रिय कनेक्शन: max_connections से काफी नीचे रहना चाहिए
- कैश हिट अनुपात: 99% से ऊपर होना चाहिए
- लेन-देन दर: बेसलाइन और विसंगतियों पर नजर रखें
- धीमी क्वेरी संख्या: आपकी सीमा से अधिक क्वेरी
- प्रतिकृति अंतराल: यदि पढ़ी गई प्रतिकृतियों का उपयोग किया जा रहा है
- डिस्क उपयोग: डेटाबेस आकार वृद्धि दर
- टेबल ब्लोट: प्रति टेबल डेड टपल अनुपात
समय के साथ क्वेरी प्रदर्शन को ट्रैक करने के लिए pg_stat_statements एक्सटेंशन का उपयोग करें। यह प्रत्येक विशिष्ट क्वेरी पैटर्न के लिए निष्पादन गणना, कुल समय, औसत समय और लौटाई गई पंक्तियों को रिकॉर्ड करता है।
अक्सर पूछे जाने वाले प्रश्न
प्रश्न: मुझे कैसे पता चलेगा कि PostgreSQL बाधा है?
धीमी क्वेरी लॉगिंग सक्षम करें और Odoo प्रदर्शन लॉग जांचें। यदि अधिकांश धीमे अनुरोध धीमी क्वेरी से मेल खाते हैं, तो ट्यूनिंग से मदद मिलेगी। यदि प्रश्न तेज़ हैं लेकिन ओडू धीमा है, तो बाधा एप्लिकेशन कोड या नेटवर्क में है।
प्रश्न: क्या मुझे Odoo के लिए PostgreSQL प्रतिकृतियों का उपयोग करना चाहिए?
प्राथमिक डेटाबेस से प्रतिकृतियां ऑफलोड रिपोर्टिंग क्वेरी पढ़ें। ओडू मूल रूप से पढ़ने/लिखने के विभाजन का समर्थन नहीं करता है, इसलिए कस्टम कॉन्फ़िगरेशन केवल-पढ़ने के लिए क्वेरी को प्रतिकृतियों पर रूट करता है। यह मुख्य रूप से बहुत बड़ी तैनाती के लिए उपयोगी है।
प्रश्न: मुझे Odoo के साथ किस PostgreSQL संस्करण का उपयोग करना चाहिए?
अपने Odoo संस्करण द्वारा समर्थित नवीनतम स्थिर रिलीज़ का उपयोग करें। नए संस्करणों में क्वेरी ऑप्टिमाइज़र सुधार और बेहतर वैक्यूम प्रदर्शन शामिल हैं। PostgreSQL 16 or 17 are recommended for current Odoo versions.
प्रश्न: उचित ट्यूनिंग वास्तव में कितनी मदद करती है?
हमारे अनुभव में, डिफ़ॉल्ट सेटिंग्स से ट्यून किए गए कॉन्फ़िगरेशन पर जाने से आम तौर पर औसत पेज लोड समय में 40-60% सुधार होता है और धीमी क्वेरी आवृत्ति 80-90% तक कम हो जाती है। सुधार नाटकीय और तत्काल है.
आगे क्या है
PostgreSQL ट्यूनिंग Odoo प्रदर्शन के लिए एकल उच्चतम-प्रभाव अनुकूलन है। मेमोरी सेटिंग्स और इंडेक्सिंग से शुरुआत करें - अकेले ये दो परिवर्तन अक्सर प्रतिक्रिया समय को आधा कर देते हैं।
डेटाबेस अनुकूलन सहायता के लिए ECOSIRE से संपर्क करें, या चल रहे प्रदर्शन प्रबंधन के लिए हमारी Odoo समर्थन सेवाओं का पता लगाएं।
ECOSIRE द्वारा प्रकाशित - एंटरप्राइज़ सॉफ़्टवेयर समाधानों के साथ व्यवसायों को बड़े पैमाने पर मदद करना।
लेखक
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
Odoo ERP के साथ अपना व्यवसाय बदलें
आपके संचालन को सुव्यवस्थित करने के लिए विशेषज्ञ ओडू कार्यान्वयन, अनुकूलन और समर्थन।
संबंधित लेख
How to Add a Custom Button to an Odoo Form View (2026)
Add custom action buttons to Odoo 19 form views: Python action method, view inheritance, conditional visibility, confirmation dialogs. Production-tested.
How to Add a Custom Field in Odoo Without Studio (2026)
Add custom fields via custom module in Odoo 19: model inheritance, view extension, computed fields, store/non-store decisions. Code-first, version-controlled.
How to Add a Custom Report in Odoo Using External Layout
Build a branded PDF report in Odoo 19 using web.external_layout: QWeb template, paperformat, action binding. With print logo + footer overrides.
Performance & Scalability से और अधिक
Odoo 19 HR: Skills Matrix, Career Plans, Performance Cycles
Odoo 19 HR upgrade: native skills matrix, career path planning, performance review cycles, 9-box grid, succession planning, HRIS integration.
Odoo 19 Performance Benchmarks: PostgreSQL 17 Tuning Numbers
Real-world Odoo 19 performance benchmarks: web client speed, ORM throughput, PG17 tuning settings, connection pooling, worker counts, scaling thresholds.
OpenClaw Cost Optimization and Token Efficiency at Scale
OpenClaw token cost optimization: prompt caching, model routing, response caching, batch APIs, and per-tenant cost guardrails for production agents.
Power BI Incremental Refresh for Tables Over 10 Million Rows
Power BI Incremental Refresh playbook for 10M+ row tables: partition design, RangeStart/RangeEnd, refresh policies, query folding, and DirectQuery hybrids.
वेबहुक डिबगिंग और मॉनिटरिंग: संपूर्ण समस्या निवारण मार्गदर्शिका
विफलता पैटर्न, डिबगिंग टूल, पुनः प्रयास रणनीतियाँ, मॉनिटरिंग डैशबोर्ड और सुरक्षा सर्वोत्तम प्रथाओं को कवर करने वाली इस संपूर्ण मार्गदर्शिका के साथ वेबहुक डिबगिंग में महारत हासिल करें।
k6 Load Testing: Stress-Test Your APIs Before Launch
Master k6 load testing for Node.js APIs. Covers virtual user ramp-ups, thresholds, scenarios, HTTP/2, WebSocket testing, Grafana dashboards, and CI integration patterns.