Postgres ضبط الإنتاج الذي يقلل زمن الوصول

postgresql.conf، في حالته الافتراضية، تم تصميمه بحيث لا يفشل التثبيت أبدًا، وليس لاستيعاب حركة المرور الخاصة بك. القيمة التاريخية لـ shared_buffers، 128 ميجابايت، تسمح لـ Postgres بالبدء على جهاز بسيط دون حجز أي موارد مهمة. max_connections بسعر 100 يناسب خادمًا مشتركًا صغيرًا. لم يتم اختيار أي منهما للتحميل الفعلي.

لذا فإن المشكلة لا تكمن في أن Postgres تم ضبطه بشكل سيئ افتراضيًا: بل في أنه لم يتم تعيينه لك مطلقًا. تستعرض الأقسام التالية الإعدادات بالترتيب الذي تحقق فيه أكبر فائدة، بدءًا من عنق الزجاجة الأكثر شيوعًا (الاتصالات) إلى الأبطأ في الظهور (WAL).

المشروع الأول ليس الذاكرة، بل هو الاتصالات. يفتح كل اتصال Postgres عملية خادم مخصصة تستهلك ذاكرة الوصول العشوائي (RAM) ووقت وحدة المعالجة المركزية (CPU) للسياق، حتى لو كانت خاملة. تؤدي زيادة max_connections لتجنب أخطاء نوع "عدد كبير جدًا من الاتصالات" إلى تغيير المشكلة: بما يتجاوز عدد معين من الاتصالات النشطة المتزامنة، يؤدي تنافس وحدة المعالجة المركزية إلى تقليل زمن الوصول لجميع الطلبات، بما في ذلك الطلبات الأسرع.

يعكس النهج الصحيح الترتيب المعتاد: قم بقياس max_connections على التزامن الفعلي للخادم، ثم استوعب التزامن من جانب التطبيق باستخدام مُجمّع مثل PgBouncer في pool_mode=transaction. يقوم المجمع بمضاعفة مئات اتصالات العميل على عدد قليل من اتصالات الخادم النشطة بالفعل. تفاصيل مقالتنا المخصصة آلية وضع المعاملة وحدودها (البيانات المعدة، LISTEN/NOTIFY)، ومقارنة بين PgBouncer وSupavisor وPgCat لاختيار التنفيذ.

max_connections عبارة عن معلمة سياق "postmaster": يتطلب تغييرها إعادة تشغيل الخادم بالكامل، وليس إعادة تحميل بسيطة. في مثيلات Postgres المخصصة لـ Aurabase (خطط Pro وEnterprise، مجموعة CNPG واحدة لكل مشروع)، يتم تكوين هذا الإعداد لكل طبقة خطة بدلاً من تركه عند قيمته الافتراضية. إن إعادة التشغيل ليست عملية تافهة يمكن تكرارها في الإنتاج، وهو ما يبرر هذا الاختيار على مراحل وليس على قيمة ثابتة. صيغة اختيار القيمة الخاصة بك بحدودها هي موضوع مقال منفصل: size max_connections.

أربعة إعدادات للذاكرة تزن أكثر من جميع الإعدادات الأخرى مجتمعة: shared_buffersو effective_cache_sizeو work_mem و maintenance_work_mem. تحدد الثلاثة الأولى مقدار البيانات التي يحتفظ بها Postgres في الذاكرة قبل العودة إلى القرص؛ والرابع يحدد سرعة إنشاء الفراغ أو الفهرس.

shared_buffers يقوم بتعيين ذاكرة التخزين المؤقت الداخلية المشتركة بين جميع الاتصالات. المعيار الموثق عادة بواسطة مشروع PostgreSQL هو حوالي 25% من ذاكرة الوصول العشوائي المتوفرة على خادم قاعدة بيانات مخصص. وبعد ذلك، تنخفض المكاسب وتتولى ذاكرة التخزين المؤقت على قرص نظام التشغيل المسؤولية. effective_cache_size لا يخصص أي شيء: إنه تقدير، يُعطى لمخطط الاستعلام، لإجمالي الذاكرة المتاحة لذاكرة التخزين المؤقت (Postgres ونظام التشغيل مجتمعين). يؤدي تصغير حجمه إلى دفع المجدول نحو عمليات الفحص التسلسلي بينما يتم تخزين الفهرس مؤقتًا إلى حد كبير؛ يتراوح المعيار الحالي بين 50 و 75٪ من ذاكرة الوصول العشوائي.

work_mem هو الفخ الأكثر شيوعًا. هذا ليس الحد العالمي. يمكن أن تستهلك كل عملية فرز أو تجزئة في استعلام حصتها الخاصة منها، ويمكن للاستعلام الذي يحتوي على صلات متعددة حجز حصته الخاصة عدة مرات. يمكن أن تؤدي القيمة السخية جدًا مع max_connections العالية إلى استنفاد ذاكرة الوصول العشوائي للخادم تحت التحميل المتزامن، حتى لو كان كل طلب يتم أخذه على حدة يبدو معقولاً. maintenance_work_mem، على العكس من ذلك، يمكن أن تظل أكثر سخاءً بشكل ملحوظ: فهي تنطبق فقط على عمليات الصيانة (VACUUM، CREATE INDEX)، والتي نادرًا ما تكون متزامنة مع بعضها البعض.

فقط shared_buffers يتطلب إعادة التشغيل. يتم إعادة تحميل الثلاثة الأخرى بشكل سريع، بما في ذلك جلسة معزولة: SET work_mem = '64MB'; لمدة طلب جشع واحد، دون التأثير على الإعداد العام.

لا تقم مطلقًا بتعطيل الفراغ التلقائي في الإنتاج، حتى ولو مؤقتًا من أجل "تحرير الموارد" أثناء ذروة الحمل. يستخدم Postgres MVCC: كل تحديث وكل حذف يترك حدًا نهائيًا لا يمكن استرداده إلا بالفراغ. وبدون ذلك، تتضخم الجداول، وتتدهور الفهارس، وتتدهور خطط التنفيذ تدريجيًا، مع عدم ظهور أي أخطاء حتى فوات الأوان.

القيمة الافتراضيةautovacuum_vacuum_scale_factor (20% من الصفوف الميتة قبل التشغيل) مناسبة لجدول صغير، وليس لجدول صفوف كثيف الكتابة يبلغ عدة ملايين. على طاولة مكونة من 10 ملايين صف، يمثل هذا الـ 20% 2 مليون صف ميت متراكم قبل التمريرة الأولى. قم بخفض جدول العتبة هذا حسب الجدول بدلاً من تغيير القيمة الإجمالية لقاعدة البيانات بأكملها.

-- قم بتخفيض العتبة على جدول مثقل بالكتابة، وليس بشكل عام
ALTER TABLE orders SET (
  autovacuum_vacuum_scale_factor = 0.05,
  autovacuum_vacuum_cost_limit = 2000
);

يتحقق المستشار المدمج في Aurabase Studio من هذا التكوين عند كل تحليل للمشروع، بنفس طريقة الجداول التي لا تحتوي على مفاتيح أساسية أو مفاتيح خارجية غير مفهرسة. وهذه إشارة صريحة وليست تدهورًا صامتًا تم اكتشافه بعد فوات الأوان.

غالبية مشاكل زمن الوصول في الإنتاج لا تأتي من وحدة المعالجة المركزية ولا من ذاكرة الوصول العشوائي: فهي تأتي من فهرس غائب أو تم اختياره بشكل سيئ. قبل لمس معلمة واحدة لـ postgresql.conf، يظل EXPLAIN (ANALYZE, BUFFERS) في الاستعلام المعني هو التشخيص الأكثر موثوقية. إنه يقلل من زمن استجابة طلب Postgres جيدًا قبل إضافة الموارد.

-- تشخيص استعلام بطيء قبل لمس التكوين
EXPLAIN (ANALYZE, BUFFERS)
SELECT o.id, o.total
FROM orders o
WHERE o.customer_id = '…'
ORDER BY o.created_at DESC
LIMIT 20;

يشير Seq Scan على جدول صفوف متعدد الملايين، حيث كان من المتوقع Index Scan، دائمًا إلى وجود مشكلة في الفهرس. تظهر ثلاثة أسباب في أغلب الأحيان: فهرس مفقود، أو نوع عمود غير متوافق مع الفهرس الموجود، أو إحصائيات قديمة بعد عملية استيراد ضخمة بدون ANALYZE. تؤدي إضافة ذاكرة الوصول العشوائي (RAM) أو زيادة work_mem في بعض الأحيان إلى إخفاء هذا العَرض على حجم صغير من البيانات؛ تظهر المشكلة مرة أخرى بمجرد نمو الجدول.

لتحديد موقع هذه الطلبات دون البحث عنها واحدًا تلو الآخر، يقوم pg_stat_statements بتجميع إحصائيات التنفيذ لجميع طلبات الخادم. خطأ شائع: يجب أولاً إدراج الامتداد في shared_preload_libraries، وهو معلمة سياق "postmaster" التي تتطلب إعادة التشغيل. بدون هذه الخطوة، CREATE EXTENSION pg_stat_statements; ينجح بصمت ولكنه لا يجمع شيئًا.

# يتطلب إعادة تشغيل كاملة (المعلمة "postmaster")
shared_preload_libraries = 'pg_stat_statements'

-- بمجرد إعادة تشغيل الخادم، في كل قاعدة بيانات للمراجعة:
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT query, calls, mean_exec_time, max_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

هذا هو بالضبط الخطأ الذي ترجعه الواجهة الخلفية لـ Aurabase عند غياب هذا الامتداد: رسالة صريحة بدلاً من قائمة فارغة صامتة، والتي يمكن الخلط بينها وبين "لا يوجد استعلام بطيء". يذهب Studio Advisor إلى أبعد من ذلك: فهو يصنف تلقائيًا أي طلب بمتوسط ​​وقت يزيد عن 150 مللي ثانية كتحذير، وأكثر من 500 مللي ثانية كطلب حرج. تستند هذه الحدود إلى نفس إحصائيات pg_stat_statements.

تجبر نقطة التفتيش Postgres على الكتابة إلى القرص جميع الصفحات التي تم تعديلها في الذاكرة منذ الصفحة السابقة. افتراضيًا، قد تركز هذه الكتابة على فترة زمنية قصيرة جدًا. والنتيجة هي ارتفاع ملحوظ في زمن استجابة القرص من جانب التطبيق، وهو نوع من التباطؤ الدوري الذي يصعب ربطه بطلب محدد.

يتحكم checkpoint_completion_target في انتشار هذه الكتابة خلال الفاصل الزمني بين نقطتي التحقق. هناك تفصيل مفقود من قوائم المراجعة القديمة: قام PostgreSQL 14، الذي تم إصداره في عام 2021، بتغيير قيمته الافتراضية من 0.5 إلى 0.9. في مثيل PostgreSQL 16، مثل مجموعات مستأجر Aurabase المخصصة، يكون هذا الإعداد صحيحًا بالفعل بشكل افتراضي؛ يعد ضبطه يدويًا أمرًا منطقيًا فقط في الإصدار الذي يسبق الإصدار 14. راجع المقارنة الخاصة بنا PostgreSQL 16 vs 17 vs 18 للتعرف على تغييرات الإصدار الأخرى التي تؤثر على الضبط.

تعمل max_wal_size في نفس الاتجاه: تؤدي القيمة المنخفضة جدًا إلى تشغيل نقاط تفتيش أكثر تكرارًا من المتوقع، حتى عندما لم يتم الوصول إلى checkpoint_timeout بعد. وتؤدي زيادته إلى تقليل تكرار نقاط التفتيش، على حساب وقت أطول للتعافي بعد التعطل نظرًا لوجود عدد أكبر من WALs لإعادة التشغيل. حل وسط يتم تحديده وفقًا لتسامحك مع عدم التوفر، وليس قيمة عالمية.

قائمة المراجعة هذه ليست عملية تدقيق لمرة واحدة يتم التحقق منها مرة واحدة قبل الدخول في الإنتاج. إن القاعدة التي تتضاعف في الحجم أو حركة المرور التي تتضاعف ثلاث مرات تجعل المعايير المختارة عند بدء التشغيل قديمة، غالبًا بدون خطأ واضح، مجرد تدهور تدريجي لزمن الوصول p95.

هناك ثلاث إشارات تستحق المراقبة المستمرة. يحدد pg_stat_statements الطلبات التي تنخفض بمرور الوقت. يُبلغ pg_stat_activity عن الاستعلامات المحظورة أو التي يتم تشغيلها لفترة طويلة بشكل غير طبيعي، وتتوقع نسبة الاتصالات النشطة إلى max_connections التشبع قبل أن تنتج أخطاء من جانب التطبيق.

تغطي علامة التبويب "قابلية المراقبة" في Studio جزءًا من هذا الأساس لأي مشروع Aurabase، دون الحاجة إلى تثبيت أدوات خارجية. يسرد الطلبات البطيئة، ويسمح لك بإلغاء أو إنهاء طلب نشط بواسطة PID، ويعرض مؤشر تشبع المجمع الذي يذهب إلى تحذير فوق استخدام 80٪. في مثيل مستضاف ذاتيًا، يتم إنشاء نفس المراقبة يدويًا، مع تنشيط pg_stat_statements وتوصيل أداة مراقبة خارجية به.

ثمانية إعدادات، بالترتيب الذي تحقق فيه أكبر فائدة، مع ما تحتاج إلى معرفته قبل أن تلمسها.

تعتبر الحدود المذكورة هنا، مثل تشبع المجموعة 150 مللي ثانية و80% التي يراقبها Aurabase Studio Advisor، نقطة بداية تم التحقق من صحتها برمجيًا، وليست حقيقة عالمية. تظل التهمة الفعلية هي الحكم النهائي الوحيد. لتحديد حجم max_connections بدقة بدلاً من اتباع قاعدة عامة، توضح المقالة المخصصة تفاصيل الصيغة وحدودها.

ثلاثة أسئلة تطرح بشكل منهجي بمجرد تطبيق القائمة المرجعية لأول مرة.