عندما تظهر رسالة Too many connections في قاعدة البيانات، فإن شراء سيرفر أكبر ليس القرار الأول دائماً. قد تكون سعة الاتصالات موزعة بطريقة خاطئة بين عمليات التطبيق، أو تحتجز استعلامات بطيئة الاتصالات، أو يتسرب الاتصال دون إعادته إلى التجمع. ابدأ بتحديد الجهة التي رفضت الاتصال والحد الذي وصلت إليه، ثم قارن الاتصالات المفتوحة بالعمل المنفذ فعلياً. الهدف استعادة الطلبات الناجحة مع هامش تشغيلي، لا مجرد رفع رقم في الإعدادات.
أين صدر الرفض: التطبيق أم القاعدة أم الوسيط؟
رسالة انتهاء انتظار connection pool داخل التطبيق تختلف عن رفض اتصال جديد من محرك قاعدة البيانات. وقد يكون بينهما وسيط يفرض حداً آخر. احتفظ بنص الخطأ ورمزه ومصدره وتوقيته، وحدد هل فشل إنشاء الاتصال أم انتظر الطلب اتصالاً متاحاً أم توقفت المصادقة. تشابه أثر الأخطاء على المستخدم لا يعني تطابق العلاج.
توضح وثائق MySQL لخطأ Too many connections ارتباطه باستخدام الاتصالات المتاحة، وتحكم المتغير max_connections في الحد العام. لكن قد توجد أيضاً حدود لحساب معين أو للخدمة المدارة أو للوسيط؛ اسأل عن الحد الفعلي الذي رفض الطلب قبل تعديل الخادم.
اقرأ العدد مع الحالة والزمن
في MySQL، قارن مؤشرات الاتصالات المفتوحة بالعمليات العاملة، وافحص قائمة الجلسات بصلاحية مناسبة. وفي PostgreSQL، راجع نشاط الجلسات وانتظارها والمعاملات المفتوحة. المطلوب معرفة من يحتفظ بالاتصالات، وكم يستغرق استخدامها، وما إذا كان العدد ينخفض بعد انتهاء الذروة. صورة واحدة بعد زوال الحادث قد تخفي السبب.
الجلسة الخاملة ليست بالضرورة تسرباً؛ قد يحتفظ التجمع بها لإعادة الاستخدام. لكن استمرار نموها بعد كل موجة عمل يستحق الفحص. كذلك تختلف جلسة خاملة خارج معاملة عن جلسة خاملة داخل معاملة قد تحتفظ بأقفال أو تؤخر أعمال الصيانة. لا تنه جميع الاتصالات الخاملة عشوائياً؛ حدد مالكها وحالتها وأثر إنهائها أولاً.
احسب ميزانية الاتصالات على مستوى التطبيق كله
إعداد الحد الأقصى للتجمع غالباً يخص عملية واحدة أو تجمعاً معيناً، وليس جميع خوادم التطبيق. احصر عمليات الويب وعمال الطوابير والمهام المجدولة والتقارير، ثم اجمع حدود تجمعاتها المتجهة إلى قاعدة البيانات نفسها. أضف أثر نشر نسخة جديدة بالتوازي مع القديمة والتوسع التلقائي، واترك هامشاً للمراقبة والإدارة والخدمات الأخرى وفق خصائص المحرك.
مثال افتراضي للتوضيح: أربع عمليات ويب، لكل منها تجمع أقصاه 20 اتصالاً، تسمح نظرياً بوصولها إلى 80 اتصالاً. إضافة ثلاث عمليات خلفية بحد 10 لكل منها ترفع السقف المحتمل إلى 110 قبل التقارير. الأرقام ليست توصية شراء؛ وبعض التجمعات تنشئ الاتصالات عند الحاجة. القيمة العملية للحساب أنه يكشف سقف الطلب الممكن وماذا يحدث عند مضاعفة النسخ.
اختر العلاج بحسب نمط الاستهلاك
| الملاحظة | ما ينبغي فحصه | العلاج المحتمل |
|---|---|---|
| العدد يتزايد ولا يعود لطبيعته | إرجاع الاتصال عند النجاح والاستثناء | إصلاح دورة حياة الاتصال |
| قفزة أثناء النشر فقط | تزامن العمليات القديمة والجديدة | ميزانية نشر وتدرج الاستبدال |
| اتصالات كثيرة تنتظر استعلاماً | أقفال وخطة تنفيذ ومدة المعاملات | تقليل زمن احتجاز الاتصال |
| انتظار في التجمع والقاعدة مرتاحة | حد التجمع ومدة اقتناء الاتصال | ضبط مدروس بعد اختبار |
| عمل فعلي مرتفع مع اختناق الموارد | CPU وذاكرة وقرص أثناء الحمل | تحسين الحمل ثم تقييم السعة |
راجع أيضاً إعادة المحاولة: إذا أعاد كل طلب فاشل الاتصال فوراً مرات متعددة، تتضخم الذروة. اجعل عدد المحاولات محدوداً وتوقيتها متدرجاً ومناسباً للعملية، مع منع تكرار الأثر في الكتابة. ضبط الانتظار مفيد، لكنه لا يجعل قاعدة مشبعة قادرة على تنفيذ حجم غير محدود من الطلبات.
متى يفيد connection pooling ومتى يسبب مشكلة؟
إعادة استخدام الاتصال تقلل كلفة إنشائه، لكنها تحتاج حدوداً ومدة انتظار وآلية واضحة لإرجاعه. تجمع ضخم في كل عملية قد يزاحم بقية الخدمات، وتجمع صغير جداً قد يحجب سعة متاحة. قس زمن انتظار الحصول على الاتصال منفصلاً عن زمن الاستعلام حتى تعرف أي الحدين تضبط.
إذا استخدمت وسيطاً مثل PgBouncer مع PostgreSQL، فاختيار نمط التجميع جزء من توافق التطبيق. توضح وثائق PgBouncer أن تجميع المعاملات يعيد اتصال الخادم بعد انتهاء المعاملة، مع قيود على خصائص تعتمد على الجلسة. اختبر سلوك مكتبة الاتصال وخصائص التطبيق المستخدمة وفق الإصدار؛ لا تبدل النمط في الإنتاج باعتباره زر تسريع عام.
لماذا لا نرفع max_connections مباشرة؟
الاتصال ليس رقماً مجانياً؛ تنفيذ عمل متزامن إضافي قد يستهلك ذاكرة ومعالجاً ويزيد التنافس على الأقفال والتخزين. وتشير وثائق PostgreSQL 17 إلى أن بعض الموارد تحسب بناءً على max_connections، وأن هناك اتصالات محجوزة بشروط محددة. تختلف التفاصيل وإمكان تغيير الإعداد دون إعادة تشغيل بين المحركات والخدمات.
إذا كان الحمل مشروعاً والموارد تسمح، يمكن اختبار رفع تدريجي ضمن خطة رجوع ومراقبة. أما إذا زاد زمن الاستعلام بعد الرفع وانخفض عدد المعاملات المكتملة، فقد نقلت الطابور إلى داخل قاعدة البيانات فقط. معيار القبول هو معدل العمل الناجح وزمنه واستقرار الذاكرة، مع بقاء منفذ إدارة للطوارئ وفق إعداد مدروس.
كيف تقرر بين الترقية وفصل قاعدة البيانات؟
في متجر افتراضي، قد تتنافس تقارير طويلة مع الدفع وتحتجز الاتصالات؛ جدولة التقارير أو تحسينها قد يكفي. وفي SaaS يتوسع أفقياً، قد يتجاوز مجموع تجمعات النسخ حد القاعدة رغم انخفاض استهلاك كل نسخة. أما عندما تثبت القياسات اختناقاً مستمراً بعد الضبط، فادرس زيادة موارد القاعدة أو عزلها عن التطبيق أو اختيار خدمة مدارة.
قارن الخيارات على الحمل نفسه ومدة تشغيل مماثلة، وضمّن حدود الاتصالات والنسخ الاحتياطي والمراقبة في العرض. يفيد مقال أخطاء النسخ الاحتياطي في تقييم حماية البيانات، ويكمل دليل نقل الاستضافة متطلبات الانتقال إذا استلزم الحل تغيير البيئة. لا تجعل اختفاء رسالة الخطأ وحده اختبار نجاح النقل.
قائمة القياس قبل طلب عرض سعر
- المحرك والإصدار ونص الخطأ والطبقة التي أصدرته.
- الحد العام وحد الحساب والوسيط وإعدادات تجمع كل عملية.
- عدد النسخ والعمال والزيادة المؤقتة أثناء النشر.
- مدة انتظار الاتصال والاستعلام ونمط الجلسات والمعاملات.
- الموارد أثناء الذروة ومعدل الطلبات الناجحة والمرفوضة.
- التغيير المقترح وخطة اختباره والرجوع عنه.
أسئلة شائعة عن كثرة الاتصالات
هل عدد زوار الموقع يساوي عدد اتصالات القاعدة؟
لا. تتأثر الاتصالات بتصميم التطبيق والتجمع والتخزين المؤقت ومدة الطلب والعمال الخلفيين. أعداد الزيارات وحدها لا تكفي لتحديد الحد المطلوب.
هل إعادة تشغيل قاعدة البيانات حل؟
تقطع الاتصالات وتؤثر في العمل الجاري وقد تخفي النمط مؤقتاً. إن لزمت لاستعادة الخدمة، تنفذ كإجراء حادث محسوب، ويتبعها إصلاح السبب.
هل الخدمة المدارة تمنع هذا الخطأ؟
لا؛ لها حدود أيضاً، ويظل التطبيق مسؤولاً عن استخدام الاتصالات. قيم وضوح الحدود والمراقبة وآلية التوسعة والدعم ضمن العرض.
اطلب سعة قاعدة مبنية على الاستخدام
أرسل خريطة عمليات التطبيق وحدود التجمع وقياسات الذروة عبر طلب عرض سعر لتقييم قاعدة البيانات. اطلب ضمن حلول سيرفرات قواعد البيانات مراجعة ميزانية الاتصالات وتحسين الانتظار، ثم تحديد الترقية أو الفصل إذا أثبتت التجربة الحاجة إليهما.