ضبط أداء PostgreSQL: قِس أولاً، وغيّر أقل

ابدأ بالحمل

يبدأ ضبط الأداء بأهداف زمن الاستجابة وشكل الحمل: نسبة القراءة إلى الكتابة، والجلسات المتزامنة، ومدة المعاملات، وحجم مجموعة البيانات، والنمو. سجّل خط الأساس تحت حمل تمثيلي. نسبة وحدة المعالجة المركزية وحدها ليست تشخيصًا؛ اربط زمن استجابة التطبيق بانتظارات قاعدة البيانات، وزمن استجابة الإدخال/الإخراج، والقُفل، ونقاط الفحص، وإحصاءات الاستعلامات.

صحّح أنماط الاستعلامات المكلفة أولاً

استخدم pg_stat_statements لترتيب الاستعلامات حسب الوقت الإجمالي، والوقت المتوسط، وعدد الاستدعاءات، والصفوف، والإدخال/الإخراج المؤقت. افحص الخطط التمثيلية باستخدام EXPLAIN (ANALYZE, BUFFERS) في بيئة آمنة. الفهارس المفقودة، وترتيب الانضمام السيئ، والإحصاءات القديمة، واسترجاع الصفوف غير الضروري، وحلقات التطبيق الكثيرة تتفوق عادةً على أي تعديل إعدادات شامل كأهداف للتحسين.

عامل الذاكرة كميزانية

تتنافس shared_buffers، وwork_mem، وmaintenance_work_mem، وعدد الاتصالات، وذاكرة نظام التشغيل على ذاكرة RAM محدودة. work_mem متاحة لكل عملية فرز أو تجزئة، وليس لكل خادم، لذا فإن ضربها بالاستعلامات النشطة قد يسبب استنفادًا مفاجئًا للذاكرة. اضبط قيمًا افتراضية حذرة، وارفع الذاكرة لجلسات الصيانة أو التقارير المراقبة عندما تدعم الأدلة ذلك.

حافظ على سلاسة WAL ونقاط الفحص

تسبب ذروات نقاط الفحص في زمن استجابة حتى عندما يبدو متوسط الإدخال/الإخراج صحيًا. حدد حجم max_wal_size للحمل، واستخدم checkpoint_completion_target معقولاً، وراقب أوقات كتابة ومزامنة نقاط الفحص. التخزين السريع لا يعفي من نمو WAL غير المنضبط. فتحات التكرار، وفشل الأرشفة، والمعاملات الطويلة يمكن أن تحتفظ بـ WAL حتى تمتلئ نظام الملفات.

غيّر شيئًا واحدًا واحتفظ بـ rollback

طبّق تغييرًا واحدًا مقاسًا، وشغّل نفس الحمل، وقارن النسب المئوية بدلاً من متوسط واحد. تحقق من الصحة واستخدام الموارد بالإضافة إلى السرعة. حافظ على تغييرات الإعدادات مُرقّمة، واذكر ما إذا كان إعادة التشغيل مطلوبة. إذا لم يتحسن المقياس الذي برّر التغيير، أعد التراجع عنه؛ التعقيد دون أدلة هو دين تشغيلي.