تعطل الموقع وPostgreSQL يرفض الاتصالات الجديدة

الموقف الحرج: يعرض التطبيق too many connections. يزيد الفريق عدد العمال بينما يواصل التطبيق إعادة المحاولة بلا توقف. قد يستهلك الإجراء التعويضي آخر سعة اتصال متاحة في قاعدة البيانات.

احتواء موجة الاتصالات أولاً

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

فحص الحالة باتصال إداري

إذا بقيت خانة محجوزة، فقد يستطيع دور إداري مصرح له الاتصال. الاتصال المحلي وحده لا يتجاوز حد الاتصالات. نفّذ الاستعلامات التالية للقراءة فقط في جلسة PostgreSQL الإدارية:

SHOW max_connections;

SELECT application_name, usename, state, count(*) AS sessions
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY application_name, usename, state
ORDER BY sessions DESC;

يساعد الخرج في تحديد التطبيقات أو الحسابات كثيرة الجلسات. عرض تفاصيل الجلسات الأخرى يحتاج إلى صلاحيات مناسبة. كثرة اتصالات idle لا تثبت تسرباً؛ فقد يكون المجمع كبيراً. وحالة idle in transaction تختلف عن اتصال خامل بلا معاملة مفتوحة.

ربط الحل بالسبب

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

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

معيار انتهاء الحادث

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

قرار الإنقاذ: اضبط إنتاج الاتصالات أولاً، بدلاً من الاكتفاء بتكبير الوعاء.

المراجع الفنية: PostgreSQL / Connections · PostgreSQL / Statistics · PostgreSQL / Administration.