عندما يشكو مستخدمو نظام Odoo من بطء التقارير وشاشات القوائم، يكون السبب غالبًا في طبقة قاعدة البيانات لا في التطبيق نفسه. تحسين أداء Odoo يبدأ من ضبط PostgreSQL — قاعدة البيانات التي يعتمد عليها Odoo بالكامل. في هذه الدراسة أجرينا قياسًا فعليًا: نصبنا Odoo 18 على خادم مرام حقيقي، حمّلنا قاعدة بأكثر من مليون سطر معاملات، وقِسنا زمن الاستعلامات قبل ضبط PostgreSQL وبعده — دون تغيير أي مكوّن عتاد. النتيجة المختصرة: تحسين أداء Odoo عبر إعدادات قاعدة البيانات وحدها خفّض زمن الاستعلام بنحو 20% ورفع الإنتاجية نحو 24%.
محتويات المقال
- ← ماذا يعني تحسين أداء Odoo على مستوى قاعدة البيانات؟
- ← بيئة الاختبار: كيف قِسنا الأداء بأرقام حقيقية
- ← النتائج قبل الضبط: من أين يأتي البطء؟
- ← الإعدادات التي غيّرناها في PostgreSQL
- ← النتائج بعد تحسين أداء Odoo: قبل وبعد بالأرقام
- ← الإنتاجية والتزامن: أين يتوقف الضبط؟
- ← درس work_mem والتخزين السريع
- ← من واقع مرام
- ← خطوات تحسين أداء Odoo على خادمك
- ← الأسئلة الشائعة
- ← الخلاصة
ماذا يعني تحسين أداء Odoo على مستوى قاعدة البيانات؟
Odoo إطار عمل ذكي، لكنه في النهاية يحوّل كل عملية — فتح قائمة مبيعات، توليد تقرير محاسبي، ترحيل قيد — إلى استعلامات SQL تُنفَّذ على PostgreSQL. لذلك فإن تحسين أداء Odoo على مستوى القاعدة يعني ثلاثة أشياء: أن تُحفَظ البيانات المتكررة في الذاكرة بدل قراءتها من القرص، أن يجد مُخطِّط الاستعلام (planner) مساحة ذاكرة كافية للفرز والتجميع، وأن يعرف أنك تعمل على تخزين سريع فيختار الخطط الصحيحة. الإعدادات الافتراضية لـ PostgreSQL محافِظة عمدًا كي تعمل على أي جهاز، وهي بعيدة تمامًا عن إمكانات خادم إنتاجي حديث.
الجميل أن هذه المكاسب لا تتطلب لمس كود Odoo ولا شراء عتاد أقوى — بل تعديل ملف postgresql.conf فقط. لكن كي لا نكتفي بالكلام، قِسنا الفرق بالأرقام.
بيئة الاختبار: كيف قِسنا الأداء بأرقام حقيقية
لتكون النتائج قابلة للتصديق والتكرار، بنينا بيئة Odoo حقيقية لا محاكاة نظرية. ثبّتنا Odoo 18 مع وحدات المبيعات والمحاسبة والمخزون والمشتريات وبياناتها التجريبية، ثم ضخّمنا جدولَي المعاملات الكبيرين (أسطر المبيعات وأسطر القيود) إلى أحجام تشبه شركة بعد سنوات من التشغيل. القياس تمّ بأداة pgbench الرسمية، بتشغيل مدته 30 ثانية لكل استعلام، مرة بعميل واحد لقياس زمن الاستجابة الصافي.
| العنصر | القيمة |
|---|---|
| نظام ERP | Odoo 18 Community |
| قاعدة البيانات | PostgreSQL 16 |
| نظام التشغيل | Ubuntu 24.04 LTS |
| المعالج | Intel Xeon — 4 vCPU |
| الذاكرة | 7.8 جيجابايت |
| التخزين | SSD |
| حجم القاعدة | 485 ميجابايت |
| أسطر المبيعات (sale_order_line) | 560,056 |
| أسطر القيود (account_move_line) | 570,057 |
| أداة القياس | pgbench — 30 ثانية لكل تشغيل |
أما الاستعلامات فاخترناها لتُمثّل عمل Odoo اليومي: تقرير مبيعات يجمع القيم حسب العميل، تقرير محاسبي يجمع الأرصدة حسب الحساب، وتقرير منتجات يربط ثلاثة جداول. هذه بالضبط أنواع الاستعلامات التي تُبطئ شاشات التقارير حين تكبر البيانات.
النتائج قبل الضبط: من أين يأتي البطء؟
بالإعدادات الافتراضية، كان shared_buffers يساوي 128 ميجابايت فقط — أي أن PostgreSQL يحتفظ بجزء ضئيل من البيانات في ذاكرته الخاصة ويعيد قراءة الباقي مرارًا. وأظهر أمر EXPLAIN (ANALYZE, BUFFERS) أن الاستعلامات تقرأ آلاف الكتل من القرص في كل مرة، وأن الفرز يتسرّب إلى القرص لأن work_mem لا يتجاوز 4 ميجابايت. متوسط زمن استعلامات التقارير الثلاثة كان نحو 124 ميلي ثانية للاستعلام الواحد. هذا هو خط الأساس الأمين الذي سنقيس عليه.
لماذا لا نبالغ في “قبل”؟ شغّلنا VACUUM ANALYZE قبل قياس خط الأساس تمامًا كما يفعل autovacuum تلقائيًا في أي تثبيت إنتاجي، حتى لا يأتي التحسّن من إحصاءات ناقصة بل من الضبط الفعلي وحده.
الإعدادات التي غيّرناها في PostgreSQL
طبّقنا مجموعة إعدادات متوازنة تناسب خادمًا بأربع أنوية وذاكرة 7.8 جيجابايت وتخزين SSD، ثم أعدنا تشغيل الخدمة. هذه هي القيم الدقيقة التي غيّرناها:
- shared_buffers: رفعناه من 128 ميجابايت إلى 2 جيجابايت (نحو 25% من الذاكرة) ليبقى الجزء الساخن من بيانات Odoo في الذاكرة.
- effective_cache_size: من 4 إلى 5.5 جيجابايت ليعرف المُخطِّط كم من الذاكرة متاح فعليًا للتخزين المؤقت.
- work_mem: من 4 إلى 32 ميجابايت لإبقاء عمليات الفرز والتجميع في الذاكرة.
- random_page_cost: من 4.0 إلى 1.1 لأن التخزين SSD لا يعاقب القراءة العشوائية كالقرص الدوّار.
- effective_io_concurrency: من 1 إلى 200 لاستغلال توازي الإدخال/الإخراج في التخزين الحديث.
- max_parallel_workers_per_gather: من 2 إلى 4 لاستغلال الأنوية الأربع في المسح المتوازي.
- jit: عطّلناه لأن كلفة توليد الشيفرة لحظيًا تضرّ بالاستعلامات القصيرة المتكررة أكثر مما تنفع.
النتائج بعد تحسين أداء Odoo: قبل وبعد بالأرقام
بعد الضبط فقط — البيانات نفسها، الاستعلامات نفسها، العتاد نفسه — انخفض زمن كل استعلام بثبات. هذه نتائج تحسين أداء Odoo الفعلية المقيسة بعميل واحد:
| الاستعلام | زمن قبل (ms) | زمن بعد (ms) | التحسّن | إنتاجية قبل (tps) | إنتاجية بعد (tps) |
|---|---|---|---|---|---|
| تقرير مبيعات حسب العميل | 120.3 | 97.4 | −19% | 8.31 | 10.27 |
| قيود محاسبية حسب الحساب | 101.7 | 81.9 | −19% | 9.83 | 12.20 |
| تقرير منتجات (ربط ثلاثي) | 151.1 | 118.6 | −22% | 6.62 | 8.43 |
| المتوسط | 124.4 | 99.3 | −20% | 8.25 | 10.30 |
انخفض متوسط زمن الاستعلام من 124 إلى 99 ميلي ثانية (−20%)، وارتفعت الإنتاجية من 8.25 إلى 10.3 استعلام في الثانية (+24%). قد يبدو الرقم متواضعًا مقابل وعود “أضعاف السرعة” التي تراها أحيانًا، لكنه رقم حقيقي مقيس على قاعدة Odoo فعلية — وتحسين ثابت بنسبة الخُمس على كل تقرير يعني شاشات أسرع محسوسة لكل مستخدم، مجانًا.
الإنتاجية والتزامن: أين يتوقف الضبط؟
حين كررنا القياس بأربعة عملاء متزامنين، كان التحسّن ضئيلًا جدًا. السبب أمين وواضح: على خادم بأربع أنوية، أربعة استعلامات ثقيلة متزامنة (كلٌّ منها يستخدم عمّالًا متوازين) تُشبع المعالج بالكامل. الضبط يقلّل العمل لكل استعلام، لكنه لا يضيف أنوية. هذه نقطة جوهرية:
الخلاصة الصادقة ضبط PostgreSQL يخفض زمن الاستعلام الواحد ويحسّن تجربة كل مستخدم، لكن خدمة عدد أكبر من المستخدمين المتزامنين تتطلب زيادة عدد الأنوية (ترقية الخطة) — لا مجرد ضبط القاعدة. الضبط والترقية أداتان مكمّلتان لا بديلتان.
درس work_mem والتخزين السريع
أردنا أن نعرف كم يساهم كل إعداد على حدة، فاختبرنا استعلام فرز كبيرًا مرة بـ work_mem افتراضي (4 ميجابايت) ومرة مضبوطًا (64 ميجابايت). عند القيمة الصغيرة أظهر المُخطِّط “فرزًا خارجيًا على القرص”، وعند القيمة الكبيرة تحوّل إلى “فرز في الذاكرة” — لكن زمن التنفيذ تغيّر بالكاد (516 مقابل 507 ميلي ثانية).
السبب أن تخزين مرام السريع (SSD/NVMe) يجعل حتى الفرز المتسرّب للقرص رخيصًا. هذا درس مهم في تحسين أداء Odoo: أثر كل إعداد يعتمد على عتادك. على تخزين بطيء يصبح work_mem حاسمًا، أما على تخزين مرام السريع فالمكاسب الأكبر تأتي من التخزين المؤقت في الذاكرة وتعطيل jit والتوازي. القياس على بيئتك هو الفيصل، لا القواعد العامة.
من واقع مرام
من واقع مرام: على خطة بأربع أنوية وذاكرة 7.8 جيجابايت وتخزين SSD، رفع ضبط PostgreSQL إنتاجية تقارير Odoo بنحو الرُبع دون أي ترقية عتاد. ومع نمو عدد المستخدمين المتزامنين، كانت الترقية إلى أنوية أكثر هي الحل الأنجع إلى جانب الضبط. النتائج تعتمد على بياناتك ونمط استخدامك — والقياس على بيئتك هو المرجع.
خطوات تحسين أداء Odoo على خادمك
إذا أردت تطبيق تحسين أداء Odoo على خادمك بنفسك، اتبع هذا التسلسل الآمن:
- خذ نسخة احتياطية كاملة، ثم قِس خط الأساس بـ
pgbenchوEXPLAIN (ANALYZE, BUFFERS)قبل أي تغيير. - اضبط
shared_buffersإلى نحو 25% من الذاكرة وeffective_cache_sizeإلى نحو 70%. - ارفع
work_memوmaintenance_work_memباعتدال حسب عدد الاتصالات المتوقعة. - عيّن
random_page_cost=1.1وeffective_io_concurrency=200إن كان تخزينك SSD أو NVMe. - فعّل التوازي بما يناسب عدد الأنوية، وعطّل
jitإن غلبت على عملك الاستعلامات القصيرة المتكررة. - أعد تشغيل الخدمة، شغّل
VACUUM ANALYZE، ثم أعد القياس وقارن بخط الأساس.
وإن أردت طبقة أعمق من التفاصيل حول كل إعداد، راجع دليلنا المخصص: تحسين أداء PostgreSQL: 12 إعداد لتسريع قاعدة بياناتك، ولتقدير حجم الخادم المناسب لعدد مستخدمي Odoo راجع بنية Odoo لـ100 و500 و1500 مستخدم. المرجعان الرسميان المفيدان هنا هما توثيق موارد PostgreSQL ودليل نشر Odoo الرسمي.
الأسئلة الشائعة
هل يتطلب تحسين أداء Odoo تغيير العتاد؟
لا بالضرورة. في اختبارنا خفّض ضبط PostgreSQL وحده زمن الاستعلام بنحو 20% ورفع الإنتاجية نحو 24% دون أي تغيير في العتاد. الترقية تصبح لازمة فقط عند ارتفاع عدد المستخدمين المتزامنين.
ما أهم إعداد في PostgreSQL لأداء Odoo؟
لا يوجد إعداد سحري واحد؛ التأثير الأكبر جاء من مجموعة: shared_buffers وeffective_cache_size وwork_mem وتعطيل jit، مع random_page_cost مناسب للتخزين. القيم تُشتق من حجم ذاكرة الخادم ونوع تخزينه.
لماذا لم يتحسّن الأداء تحت الحِمل العالي؟
لأن المعالج كان السقف. مع أربعة عملاء متزامنين على أربع أنوية، يُشبع المعالج ولا يضيف الضبط أنوية. خدمة تزامن أعلى تتطلب زيادة عدد الأنوية عبر ترقية الخطة.
هل work_mem يصنع فرقًا دائمًا؟
ليس دائمًا. على التخزين السريع (SSD/NVMe) كان الفرق بين الفرز على القرص والفرز في الذاكرة ضئيلًا في اختبارنا. يظهر أثر work_mem بوضوح أكبر على التخزين البطيء أو مع عمليات فرز أضخم بكثير.
كل كم ينبغي إعادة ضبط PostgreSQL؟
عند تغيّر حجم الذاكرة أو الخطة، أو عند نمو البيانات بشكل كبير. راقب pg_stat_statements لرصد الاستعلامات البطيئة وأعد التقييم دوريًا.
الخلاصة
أثبتت الأرقام الحقيقية أن تحسين أداء Odoo لا يبدأ دائمًا بترقية العتاد، بل بضبط PostgreSQL ضبطًا يناسب خادمك — وهو ما منحنا شاشات تقارير أسرع بنحو الخُمس مجانًا. الضبط الجيد يرفع سقف كل خادم، والترقية ترفع سقف التزامن؛ معًا يمنحان تجربة Odoo سريعة ومستقرة. في مرام نوفّر بنية تحتية سريعة وضبطًا احترافيًا يجعل ذلك جاهزًا من اليوم الأول.
