Postgres max_connections بدون مجمع

لا يستخدم Postgres تجمع سلاسل رسائل خفيف الوزن لاتصالاته. يؤدي كل اتصال بالعميل إلى تشغيل عملية نظام كاملة.

تقوم عملية postmaster بإنشاء عملية جديدة ("شوكة") لكل محاولة اتصال، مخصصة لهذه الجلسة الفردية حتى يتم إغلاقها. تصف وثائق المشروع الرسمية هذه الآلية بدقة في الفصل الخاص بالأساسيات المعمارية (postgresql.org/docs/current/connect-estab.html، قسم "دلالات الاتصال"، تم الوصول إليه في 24 أغسطس 2026).

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

هناك آليتان مختلفتان تؤثران على الذاكرة، والخلط بينهما يؤدي دائمًا إلى تشخيص خاطئ.

الأول ثابت. عند بدء التشغيل، يحتفظ Postgres بهياكل الذاكرة المشتركة (الأقفال، جدول العمليات) بحجم قيمة max_connections، سواء تم فتح هذه الاتصالات لاحقًا أم لا. تشير الوثائق الرسمية للإعداد صراحةً إلى أن زيادته قد تتطلب ذاكرة مشتركة للنظام أكبر مما يسمح به التكوين الافتراضي لنظام التشغيل لديك (postgresql.org/docs/current/runtime-config-connection.html، تم الوصول إليه في 24 أغسطس 2026).

والثاني متغير، وأكثر خطورة على نطاق واسع: لا يتم تخصيص work_mem مرة واحدة لكل اتصال، ولكن مرة واحدة لكل عملية فرز أو تجزئة في خطة الاستعلام. الوثائق الرسمية واضحة بشأن هذه النقطة: يمكن للاستعلام المعقد إطلاق العديد من هذه العمليات بالتوازي، ويمكن لعدة جلسات أن تفعل الشيء نفسه في وقت واحد، بحيث يمكن أن تبلغ قيمة الذاكرة المستخدمة بالفعل عدة مرات Work_mem (postgresql.org/docs/current/runtime-config-resource.html، تم الوصول إليه في 24 أغسطس 2026).

يوثق ويكي مشروع PostgreSQL الرسمي صيغة مرجعية لحساب عدد اتصالات النشطة التي يمكن لجهازك معالجتها بكفاءة بالتوازي، وليس عدد الاتصالات المفتوحة إجمالاً (wiki.postgresql.org/wiki/Number_Of_Database_Connections، تم الوصول إليه في 24 أغسطس، 2026).

على خادم يحتوي على 8 مراكز فعلية ومخزن SSD، تعطي الصيغة (8 × 2) + 1 = 17 اتصالًا نشطًا قبل أن يبدأ معدل النقل في الانخفاض. غالبًا ما يكون هذا الرقم مفاجئًا: فهو يبدو صغيرًا مقارنة بمئات الاتصالات التي يفتحها التطبيق عمليًا. وهذا هو بالضبط موضوع الفقرة التالية.

يقيس الرقم المحسوب بواسطة الصيغة التزامن الذي يمكن لوحدة المعالجة المركزية والقرص استيعابه، وليس عدد اتصالات العميل التي يحتاج التطبيق الخاص بك إلى فتحها. يفتح أسطول مكون من 20 عملية تطبيق، كل منها بمجموعتها الخاصة المكونة من 10 اتصالات، 200 اتصال متزامن لـ Postgres حتى لو كان 17 منها فقط تعمل بنشاط في أي وقت محدد. بدون مُجمِّع، يجب أن تغطي max_connections 200، وليس 17. هذه الفجوة هي التي تدفع معظم المعماريات لإضافة مُجمِّع في وضع المعاملة، حتى لو كان ذلك يعني اختيار أي منها (راجع مقارنة PgBouncer وSupavisor وPgCat).

لم يتم تبديل max_connections بشكل سريع. هذه معلمة سياق postmaster: يقرأها Postgres مرة واحدة، عند بدء التشغيل، لتحديد حجم الذاكرة المشتركة الخاصة به. إعادة تحميل التكوين (pg_reload_conf() أو SIGHUP) ليست كافية، يجب عليك إعادة تشغيل الخادم.

تحقق أولاً من القيمة الحالية وسياقها للتأكد من أن إعادة التشغيل ستكون ضرورية:

SHOW max_connections;

SELECT name, setting, context
FROM pg_settings
WHERE name = 'max_connections';

-- يؤكد context='postmaster' أن إعادة التشغيل مطلوبة

ثم قم بتطبيق القيمة الجديدة، ثم أعد التشغيل:

ALTER SYSTEM SET max_connections = '300';

-- مكتوب في postgresql.auto.conf.
-- لا يوجد أي تأثير حتى يتم إعادة تشغيل Postgres.

# مع النظام د
sudo systemctl restart postgresql

# بدون systemd، مباشرة باستخدام pg_ctl
pg_ctl restart -D $PGDATA -m fast

إن تحديد حجم max_connections ليس مجرد تمرين نظري. إليك كيفية قيام Aurabase بتخصيصها لمجموعات Postgres المُدارة:

مجموعات مخصصة: مجموعة Postgres واحدة لكل مشروع

على هذا المستوى (راجع مقارنتنا المخصصة مقابل القاعدة المشتركة)، يتلقى كل مشروع مجموعة CloudNativePG الخاصة به وميزانية max_connections الخاصة به، والتي تتناسب مع حجم المثيل:

المجموعات المشتركة: عدة مشاريع لمنظمة ما، وميزانية مشتركة

في هذا المسار الثاني، تتصل جميع مشاريع نفس المؤسسة عبر مجمع CNPG (وضع PgBouncer، transaction) أمام ملف أساسي مشترك:

تتصل جميع المشاريع في المؤسسة من خلال دور تطبيق مشترك. لذلك، فإن max_user_connections وحده يحدد إجمالي اتصالات الخادم التي يمكن لهذا الدور فتحها عبر المجموعة بأكملها: هذه هي الحماية الحقيقية للمجموعة العالمية، وليس max_client_conn، الذي يحد فقط من اتصالات العميل بالمجمع نفسه.

ومع ذلك، لا يخدم هذا المجمع سوى حركة مرور تطبيقات SDK. يظل PostgREST، من جانبه، متصلاً مباشرة بالخدمة الأساسية (-rw): سيؤدي التجميع في وضع المعاملة إلى كسر آلية إعادة تحميل المخطط الخاصة به، والتي تستمع إلى قناة LISTEN مخصصة تسمى pgrst. وبالتالي، فإن اتصالاتها الخاصة (2 لكل نسخة متماثلة على المستوى المشترك، و10 لكل نسخة متماثلة على المستوى المخصص) يتم احتسابها مباشرة في ميزانية max_connections الأساسية، خارج أي مجمع، وهو بالضبط نوع الاتصال "المنسي" الذي يجب أن تتضمنه الخطوة 1 من الإجراء أدناه.

لا يعتمد هذا الإجراء على أي أداة معينة: فهو ينطبق على أي خادم Postgres، مُدارًا أو مستضافًا ذاتيًا.

1. قم بإحصاء اتصالات العميل الفعلية. عدد عمليات التطبيق مضروبًا في حجم مجموعتها الداخلية، بالإضافة إلى أدوات الإدارة والنسخ والمراقبة. هذا الرقم، وليس الصيغة، هو الذي يحدد الحد الأقصى للاتصالات.
2. احسب التزامن المثالي لجهازك باستخدام الصيغة من PostgreSQL wiki: (النوى المادية × 2) + الأقراص الفعالة. يشير هذا الشكل إلى عدد هذه الاتصالات التي يمكن أن تعمل فعليًا بالتوازي دون انخفاض الإنتاجية.
3. قم بتعيين max_connections فوق الحاجة الفعلية للخطوة 1، مع هامش لـ superuser_reserved_connections ولأي أدوات إدارية تفتح اتصالاتها الخاصة خارج التطبيق.
4. قم بتطبيق التغيير باستخدام ALTER SYSTEM SET، ثم أعد تشغيل الخادم. هذه معلمة مدير مكتب البريد: إعادة التحميل البسيطة ليست كافية، كما هو مفصل أعلاه.
5. مراقبة pg_stat_activity مع مرور الوقت. إذا كان عدد الاتصالات الخاملة يتجاوز عدد الاتصالات النشطة بشكل كبير، فهذه ليست مشكلة max_connections: إنها إشارة إلى أنك بحاجة إلى مُجمّع أمام الخادم، وليس رقمًا أعلى.

طلب المراقبة من الخطوة 5، قابل للاستخدام مباشرة:

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

يتم إرجاع ثلاث إشارات بشكل منهجي عندما لا تعد max_connections وحدها كافية، مهما كانت قيمتها.

1. يظهر الخطأ FATAL: sorry, too many clients already أثناء التحميل الأقصى، بينما تكون غالبية الاتصالات المعروضة بواسطة pg_stat_activity في حالة الخمول.
2. يعمل التطبيق في بيئة بدون خادم أو مع عمال سريعين (وظائف الحافة، المهام القصيرة)، والتي تفتح وتغلق الاتصالات بشكل أسرع بكثير من نموذج العملية لكل اتصال الذي صممه Postgres لاستيعابه.
3. لقد تم بالفعل تطبيق الصيغة والإجراء أعلاه، وتستمر الحاجة الفعلية لاتصالات العميل في تجاوز ما يمكن تخصيصه من الذاكرة المتاحة دون تعريض ذاكرة العمل أو المخزن المؤقت المشترك للخطر.

في هذه الحالات الثلاث، تكون الإجابة الصحيحة دائمًا تقريبًا عبارة عن مُجمِّع متوضع بين التطبيق وPostgres، وليس الحد الأقصى للاتصالات. لدينا مقارنة PgBouncer وSupavisor وPgCat توضح بالتفصيل الخيارات الثلاثة، ويشرح دليل الخاص بنا لوضع المعاملة التسوية الأكثر شيوعًا بمجرد وضع المجمع في مكانه الصحيح. بالنسبة لجميع عمليات ضبط Postgres خارج نطاق الاتصالات، راجع قائمة التحقق من ضبط Postgres للإنتاج .