17 ديسمبر 2025·6 دقيقة
تجميع اتصالات PostgreSQL: تجميع داخل التطبيق مقابل PgBouncer
تجميع اتصالات PostgreSQL: قارن تجمعات التطبيق وPgBouncer لخلفيات Go، المقاييس التي تراقبها، والإعدادات الخاطئة التي تُسبب قفزات زمنية.
تجميع اتصالات PostgreSQL: قارن تجمعات التطبيق وPgBouncer لخلفيات Go، المقاييس التي تراقبها، والإعدادات الخاطئة التي تُسبب قفزات زمنية.
الاتصال بقاعدة البيانات مثل خط هاتف بين تطبيقك وPostgres. فتح اتصال يكلف وقتًا وموارد على الجانبين: إعداد TCP/TLS، المصادقة، الذاكرة، وعملية خلفية في جانب Postgres. يحافظ تجمع الاتصالات على مجموعة صغيرة من هذه “الخطوط” مفتوحة حتى يعيد التطبيق استخدامها بدلًا من إعادة الاتصال عند كل طلب.
عندما يكون التجميع مطفأًا أو مُعدًا بحجم خاطئ، نادرًا ما ترى خطأ واضحًا أولًا. ترى بطءً عشوائيًا. طلبات كانت تأخذ عادة 20–50 مللي ثانية فجأة تأخذ 500 مللي ثانية أو 5 ثوانٍ، ويرتفع p95. ثم تظهر المهلات الزمنية، يتبعها "عدد اتصالات كثير جدًا"، أو صف انتظار داخل التطبيق بينما ينتظر اتصالًا حرًا.
حدود الاتصالات مهمة حتى للتطبيقات الصغيرة لأن الحركة متقلبة. رسالة تسويقية، مهمة مجدولة، أو بعض النهايات البطيئة يمكن أن تسبب ضربات متزامنة للدatabase. إذا كان كل طلب يفتح اتصالًا جديدًا، قد يقضي Postgres الكثير من طاقته في قبول وإدارة الاتصالات بدلًا من تشغيل الاستعلامات. وإذا كان لديك تجمع كبير جدًا، قد ترهق Postgres بعدد كبير من العمليات النشطة مسببة تبديل سياق وضغط ذاكرة.
انتبه للأعراض المبكرة مثل:
التجميع يقلل من تقلب الاتصالات ويساعد Postgres على التعامل مع الطفرات. لكنه لن يصلح SQL البطيء. إذا كان الاستعلام يقوم بمسح كامل للجدول أو ينتظر أقفالًا، فالتجميع يغير غالبًا كيف يفشل النظام (الاصطفاف أبكر، المهلات لاحقًا)، وليس ما إذا كان سريعًا.
تجميع الاتصالات يتعلق بالتحكم في عدد اتصالات قاعدة البيانات الموجودة في نفس الوقت وكيف يعاد استخدامها. يمكنك فعل ذلك داخل تطبيقك (تجميع على مستوى التطبيق) أو مع خدمة منفصلة أمام Postgres (PgBouncer). كلاهما يحل مشكلات مرتبطة لكن مختلفة.
تجميع على مستوى التطبيق (في Go عادة تجمع database/sql) يدير الاتصالات لكل عملية. يقرر متى يفتح اتصالًا جديدًا، متى يعيد استخدام واحد، ومتى يغلق الاتصالات الخاملة. هذا يتجنب تكلفة الإعداد عند كل طلب. ما لا يستطيع فعله هو التنسيق عبر نسخ التطبيق المتعددة. إذا شغلت 10 نسخ، فعمليًا لديك 10 تجمعات منفصلة.
PgBouncer يجلس بين تطبيقك وPostgres ويجمع نيابة عن عملاء متعددين. يكون مفيدًا عندما لديك الكثير من الطلبات قصيرة العمر، نسخ تطبيق كثيرة، أو حركة متقطعة. يقيد الاتصالات على جانب الخادم إلى Postgres حتى لو وصلت مئات اتصالات العملاء دفعةً واحدة.
تقسيم بسيط للمسؤوليات:
يمكن أن يعملان معًا دون مشاكل "التجميع المزدوج" طالما أن لكل طبقة هدف واضح: تجمع database/sql معقول لكل عملية Go، بالإضافة إلى PgBouncer لفرض ميزانية اتصال عالمية.
خلاف شائع هو التفكير أن "المزيد من التجمعات يعني المزيد من السعة." عادة ما يعني العكس. إذا كان لكل خدمة وعامل ونسخة تجمع كبير خاص بها، قد ينفجر إجمالي عدد الاتصالات ويتسبب في الاصطفاف، تبديل السياق، وقفزات تأخير مفاجئة.
database/sql في Go فعليًافي Go، sql.DB هو مدير تجمع اتصالات، ليس اتصالًا واحدًا. عندما تستدعي db.Query أو db.Exec، يحاول database/sql إعادة استخدام اتصال خامل. إذا لم يستطع، قد يفتح واحدًا جديدًا (حتى الحد الذي عينته) أو يجعل الطلب ينتظر.
ذلك الانتظار هو حيث تأتي "زمنية الغموض" غالبًا. عندما يكون التجمع مُشبَعًا، تصطف الطلبات داخل التطبيق. من الخارج، يبدو أن Postgres بطيء، لكن الوقت يُقضى فعليًا في انتظار اتصال فارغ.
معظم التوليف يختزل إلى أربعة إعدادات:
MaxOpenConns: حد صارم على الاتصالات المفتوحة (الخاملة + المستخدمة). عند بلوغه، يمنع المستدعين حتى يتوفر اتصال.MaxIdleConns: عدد الاتصالات التي يمكن أن تبقى جاهزة لإعادة الاستخدام. منخفض جدًا يسبب إعادة اتصالات متكررة.ConnMaxLifetime: يجبر إعادة تدوير الاتصالات بشكل دوري. مفيد لموازنات الحمل ووقت انتهاء NAT، لكن إن كان قصيرًا جدًا يسبب تقلبًا.ConnMaxIdleTime: يغلق الاتصالات التي تبقى غير مستخدمة لفترة طويلة.إعادة استخدام الاتصالات عادة تقلل زمن الاستجابة وCPU في قاعدة البيانات لأنك تتجنب إعداد الاتصال المتكرر (TCP/TLS، المصادقة، تهيئة الجلسة). لكن التجمع الكبير جدًا قد يفعل العكس: يسمح بالمزيد من الاستعلامات المتزامنة مما قد لا تتحمله Postgres جيدًا، مما يزيد التنافس والحمولة.
فكر بالأعداد الكلية، لا بالعملية الواحدة فقط. إذا سمحت كل نسخة Go بـ 50 اتصالًا مفتوحًا وتدرجت إلى 20 نسخة، فقد سمحت فعليًا بـ 1000 اتصال. قارن هذا العدد بما يمكن لخادم Postgres تشغيله بسلاسة.
نقطة انطلاق عملية هي ربط MaxOpenConns بالتزامن المتوقع لكل نسخة، ثم التحقق من مقاييس التجمع (in-use، idle، ووقت الانتظار) قبل زيادته.
PgBouncer هو بروكسي صغير بين تطبيقك وPostgreSQL. يتصل خدمتك بـ PgBouncer، وPgBouncer يحتفظ بعدد محدود من اتصالات الخادم إلى Postgres. أثناء الطفرات، يصطف PgBouncer عملاء بدلاً من إنشاء مزيد من عمليات خادم Postgres فورًا. ذلك الصف قد يكون الفرق بين تباطؤ مسيطر عليه وقاعدة بيانات تنهار.
لـ PgBouncer ثلاث وضعيات:
تجميع الجلسة يتصرف أقرب لما يحدث عند الاتصال المباشر بـ Postgres. هو الأقل مفاجأة، لكنه يوفر عددًا أقل من اتصالات الخادم أثناء الحمل المتقطع.
بالنسبة لواجهات HTTP النموذجية في Go، غالبًا ما يكون تجميع المعاملة خيارًا قويًا افتراضيًا. معظم الطلبات تقوم باستعلام صغير أو معاملة قصيرة ثم تنتهي. تجميع المعاملة يسمح للعديد من اتصالات العميل بمشاركة ميزانية Postgres أصغر.
المقايضة هي حالة الجلسة. في وضع المعاملة، أي شيء يفترض بقاء حالة في اتصال الخادم قد يتعطل أو يتصرف بغرابة، بما في ذلك:
SET, SET ROLE, search_path)إذا اعتمد تطبيقك على هذا النوع من الحالة، فـ session pooling أكثر أمانًا. وضع statement هو الأكثر تقييدًا ونادرًا ما يناسب تطبيقات الويب.
قاعدة مفيدة: إذا كان كل طلب يمكنه إعداد ما يحتاجه داخل معاملة واحدة، فإن transaction pooling يميل للحفاظ على ثبات الزمن تحت الحمل. إذا احتجت لسلوك جلسة طويل الأمد، استخدم session pooling وركز على حدود أشد في التطبيق.
إذا تشغّل خدمة Go مع database/sql، فبالفعل لديك تجمع على جانب التطبيق. بالنسبة للعديد من الفرق، هذا يكفي: بضع نسخ، حركة ثابتة، واستعلامات ليست متقلبة جدًا. في هذا السيناريو، الخيار الأبسط والأكثر أمانًا هو ضبط تجمع Go، الحفاظ على حد اتصالات قاعدة بيانات واقعي، والتوقف عند هذا الحد.
يساعد PgBouncer عندما تتعرض قاعدة البيانات لعدد كبير من اتصالات العملاء في آن واحد. يظهر هذا عند وجود نسخ تطبيق متعددة (أو مقياس خادمless)، حركة مفاجئة، وكثير من الاستعلامات القصيرة.
يمكن أن يضر PgBouncer أيضًا إذا استُخدم في الوضع الخاطئ. إذا كان الكود يعتمد على حالة الجلسة (جداول مؤقتة، جمل محضرة تُعاد عبر الطلبات، أقفال إرشادية محفوظة عبر استدعاءات، أو إعدادات جلسة)، قد يسبب transaction pooling أخطاء غامضة. إذا كنت بحاجة فعلًا لسلوك الجلسة، استخدم session pooling أو تجنب PgBouncer وحجم تجمعات التطبيق بعناية.
استخدم هذه القاعدة التقديرية:
MaxOpenConns قد يتجاوز ما يمكن لـ Postgres التعامل معه، أضف PgBouncer.حدود الاتصالات هي ميزانية. إذا أنفقتها كلها دفعة واحدة، كل طلب جديد ينتظر وينفجر زمن الذيل. الهدف هو تحديد التزامن بطريقة مسيطرة مع الحفاظ على إنتاجية مستقرة.
قِس ذروة اليوم حاليًا وزمن ذيل التأخير. سجّل ذروة الاتصالات النشطة (ليس المتوسط)، بالإضافة إلى p50/p95/p99 للطلبات والاستعلامات الرئيسية. دوّن أي أخطاء اتصال أو مهلات.
حدّد ميزانية اتصال Postgres آمنة للتطبيق. ابدأ من max_connections وخصم مساحة لإدارة النظام، الترحيلات، وظائف الخلفية، والطفرات. إذا تشارك قواعد بيانات متعددة، قسّم الميزانية عن قصد.
اطبع الميزانية على حدود Go لكل نسخة. قسّم ميزانية التطبيق على عدد النسخ واضبط MaxOpenConns لهذا (أو أقل قليلاً). اضبط MaxIdleConns بما يكفي لتجنب إعادة اتصال مستمرة، وضع أوقات حياة لإعادة تدوير الاتصالات من دون تسبب في تقلب.
أضف PgBouncer فقط إذا احتجت إليه، واختر وضعًا مناسبًا. استخدم session pooling إذا احتجت لحالة الجلسة. استخدم transaction pooling عندما تريد أكبر خفض في اتصالات الخادم وتوافق تطبيقك مع ذلك.
نفّذ التغييرات تدريجيًا وقارن قبل وبعد. غيّر شيئًا واحدًا في كل مرة، اختبره على جزء من النسخ (canary)، ثم قارن زمن الذيل، وقت انتظار التجمع، وCPU لقاعدة البيانات.
مثال: إذا كان Postgres يمكنه أن يمنح خدمتك 200 اتصال بأمان وتدير 10 نسخ Go، ابدأ بـ MaxOpenConns=15-18 لكل نسخة. هذا يترك مجالًا للطفرات ويقلل احتمال أن تصل كل نسخة للسقف في نفس الوقت.
مشكلات التجميع نادرًا ما تظهر أولًا كـ "عدد اتصالات كثير". أكثر الأحيان ترى ارتفاعًا بطيئًا في وقت الانتظار ثم قفزة مفاجئة في p95 وp99.
ابدأ بما يبلغ عنه تطبيق Go. مع database/sql، راقب الاتصالات المفتوحة، in-use، الخاملة، wait count، وwait time. إذا ارتفع wait count بينما الحركة ثابتة، فالتجمع صغير جدًا أو الاتصالات محتجزة لفترة طويلة.
على جانب قاعدة البيانات، تتبع الاتصالات النشطة مقابل الحد، CPU، ونشاط الأقفال. إذا كان CPU منخفضًا لكن التأخير عالٍ، فغالبًا ما يكون بسبب الاصطفاف أو الأقفال، ليس قدرة حسابية خام.
إذا شغلت PgBouncer، أضف منظرًا ثالثًا: اتصالات العملاء، اتصالات الخادم إلى Postgres، وعمق الصف. صف متزايد مع اتصالات خادم ثابتة إشارة واضحة أن الميزانية ممتلئة.
إشارات تنبيه جيدة:
تظهر مشكلات التجميع غالبًا أثناء الطفرات: تتكدس الطلبات في انتظار اتصال، ثم يعود كل شيء لطبيعي. السبب الجذري غالبًا إعداد يبدو معقولًا على نسخة واحدة لكنه خطير عند تشغيل نسخ متعددة.
الأسباب الشائعة:
MaxOpenConns مضبوط لكل نسخة بدون ميزانية كلية. 100 اتصال لكل نسخة عبر 20 نسخة يعني 2000 اتصال محتمل.ConnMaxLifetime / ConnMaxIdleTime قصيرة جدًا. قد يؤدي ذلك لعواصف إعادة اتصال عندما تُعاد تدوير كثير من الاتصالات في نفس الوقت.طريقة بسيطة لتقليل القفزات هي اعتبار التجميع حدًا مشتركًا، ليس افتراضيًا محليًا: حد إجمالي للاتصالات عبر كل النسخ، حافظ على تجمع خامل معتدل، واستخدم أوقات حياة كافية لتجنب إعادة الاتصالات المتزامنة.
عندما تنفجر الحركة، عادة ترى أحد ثلاث نتائج: الطلبات تصطف في انتظار اتصال فارغ، الطلبات تتوقف بمهلة، أو كل شيء يصبح بطيئًا حتى تتكدس المحاولات.
الاصطفاف هو الخطر الخفي. المعالج ما زال يعمل لكنه متوقف في انتظار اتصال. ذلك الانتظار يصبح جزءًا من زمن الاستجابة، لذا يمكن لتجمع صغير أن يحول استعلامًا مدته 50 مللي ثانية إلى نقطة نهائية تستغرق ثوانٍ تحت الحمل.
نموذج ذهني مفيد: إذا كان التجمع يملك 30 اتصالًا قابلًا للاستخدام وفجأة لديك 300 طلب متزامن يحتاجون قاعدة البيانات، 270 منهم يجب أن ينتظروا. إذا كان كل طلب يحتجز الاتصال 100 مللي ثانية، يرتفع زمن الذيل إلى ثوانٍ بسرعة.
حدد ميزانية مهلة واضحة والتزم بها. يجب أن تكون مهلة التطبيق أقصر قليلًا من مهلة قاعدة البيانات حتى تفشل بسرعة وتقلل الضغط بدلًا من ترك العمل معلقًا.
statement_timeout حتى لا يحتجز استعلام واحد الاتصالاتثم أضف آليات رجوع ضغط حتى لا تجهد التجمع أصلًا. اختر آلية أو اثنتين متوقعتين، مثل تحديد التزامن لكل نهاية، إسقاط الحمل بأخطاء واضحة (مثل 429)، أو فصل وظائف الخلفية عن حركة المستخدم.
أخيرًا، أصلح الاستعلامات البطيئة أولًا. تحت ضغط التجميع، تستغرق الاستعلامات البطيئة الاتصالات لفترة أطول، مما يزيد الانتظار والمهلات والمحاولات. تلك الحلقة التغذوية هي كيف "قليل من البطء" يتحول إلى "كل شيء بطيء".
عامل اختبار التحميل كطريقة للتحقق من ميزانية الاتصال، ليس فقط للقدرة الإنتاجية. الهدف هو التأكد أن التجميع يتصرف تحت الضغط كما يفعل في المرحلة التجريبية.
اختبر بترافيك واقعي: نفس مزيج الطلبات، أنماط الطفرات، ونفس عدد نسخ التطبيق التي تشغلها في الإنتاج. اختبارات "نقطة نهاية واحدة" غالبًا ما تخفي مشاكل التجمع حتى يوم الإطلاق.
ضمّن فترة إحماء حتى لا تقيس تأثيرات الكاش البارد والتدرج. دع التجمعات تصل لحجمها الطبيعي، ثم ابدأ تسجيل الأرقام.
إذا كنت تقارن استراتيجيات، اجعل عبء العمل متطابقًا وشغل:
database/sql، بدون PgBouncer)بعد كل تشغيل، سجل بطاقة نتائج يمكنك إعادة استخدامها بعد كل إصدار:
مع الوقت، يحوّل هذا تخطيط السعة إلى شيئ يمكن تكراره بدلًا من التخمين.
قبل لمس أحجام التجمع، اكتب رقمًا واحدًا: ميزانية الاتصال الخاصة بك. هذا هو أقصى عدد اتصالات Postgres النشطة الآمنة للبيئة (dev, staging, prod)، بما في ذلك وظائف الخلفية والوصول الإداري. إن لم تستطع تسميته، فأنت تخمن.
قائمة تحقق سريعة:
MaxOpenConns) يتناسب مع الميزانية (أو مع حد PgBouncer).max_connections وأي اتصالات محجوزة تتماشى مع خطتك.خطة نشر تحافظ على سهولة التراجع:
إذا كنت تبني وتستضيف تطبيق Go + PostgreSQL على Koder.ai (koder.ai)، يمكن أن تساعدك Planning Mode على رسم التغيير وما ستقيسه، واللقطات مع التراجع تسهل الرجوع إذا ازدادت p95.
الخطوة التالية: أضف قياسًا واحدًا قبل القفزة التالية في الحركة. "الوقت الذي يُقضى في انتظار اتصال" داخل التطبيق غالبًا ما يكون الأكثر فائدة لأنه يظهر ضغط التجميع قبل أن يشعر المستخدمون به.
مخزن يحتفظ بعدد صغير من اتصالات PostgreSQL مفتوحة ويعيد استخدامها عبر الطلبات. هذا يتجنب تكلفة الإعداد (TCP/TLS، المصادقة، وإعداد عملية الخادم) مرات متكررة، مما يساعد على ثبات زمن الاستجابة أثناء الفواصل أو الطفرات في الحمل.
عندما يمتلئ التجمع، تنتظر الطلبات داخل التطبيق للحصول على اتصال فارغ، وهذه الفترة تنتج استجابات بطيئة. لذلك غالبًا ما تظهر المشكلة كـ "بطء عشوائي" لأن المتوسطات قد تبقى جيدة بينما ترتفع p95/p99 أثناء الطفرات.
لا. التجميع يغير في الغالب كيفية تصرف النظام تحت الحمل عن طريق تقليل تكرار إعادة الاتصال والتحكم بالتمازي، لكنه لا يجعل الاستعلام البطيء أسرع. إذا كان الاستعلام بطيئًا بسبب مسح كامل للجدول، تأمينات أو فهارس سيئة، يجب تحسين الاستعلام نفسه.
تجميع التطبيق يدير الاتصالات لكل عملية تطبيق، لذا كل نسخة من التطبيق لها تجمعها وحدها. PgBouncer يجلس أمام Postgres ويفرض ميزانية اتصالات عالمية عبر العملاء المتعددين، وهو مفيد بشكل خاص عند وجود نسخ متعددة أو حركة مفاجئة.
إذا كان لديك عدد قليل من النسخ وإجمالي الاتصالات المفتوحة أقل من حد قاعدة البيانات، فضبط تجمع database/sql في Go عادة ما يكفي. أضف PgBouncer عندما يمكن لعدد النسخ أو autoscaling أو الطفرات أن تدفع إجمالي الاتصالات إلى ما وراء ما يمكن لـ Postgres التعامل معه بسلاسة.
ابدأ بتحديد ميزانية اتصالات كلية للخدمة، قسمها على عدد نسخ التطبيق، واضبط MaxOpenConns أقل قليلاً من ذلك لكل نسخة. ابدأ بقيم صغيرة، راقب وقت الانتظار وp95/p99، ولا تزيد إلا إذا تأكدت أن قاعدة البيانات تملك مجالًا.
لواجهات HTTP في Go، غالبًا ما يكون وضع التجميع "transaction" خيارًا جيدًا لأنه يسمح لعدد أكبر من اتصالات العملاء بمشاركة عدد أقل من اتصالات الخادم أثناء الطفرات. استخدم وضع "session" إذا كان تطبيقك يعتمد على حالة الجلسة المستمرة عبر العبارات مثل الجداول المؤقتة أو إعدادات الجلسة.
البيانات المسبقة المحضرة (prepared statements)، الجداول المؤقتة، الأقفال الإرشادية (advisory locks)، وإعدادات الجلسة قد تتصرف بشكل مختلف لأن العميل قد لا يحصل على نفس اتصال الخادم في كل مرة. إذا كنت بحاجة لتلك الميزات، أبقِ كل شيء داخل معاملة واحدة لكل طلب أو استخدم session pooling.
راقب ارتفاع p95/p99 معًا وإشارة وقت الانتظار في التجمع داخل التطبيق، لأن وقت الانتظار غالبًا ما يرتفع قبل أن يشكو المستخدمون. على Postgres راقب الاتصالات النشطة، CPU، والـ locks؛ وعلى PgBouncer راقب client connections، server connections، وqueue depth.
أولًا حدِّد مهلة واضحة للتطبيق وقم بتفعيل statement_timeout حتى لا يحتجز استعلام واحد الاتصالات إلى الأبد. ثم ضع آليات رجوع ضغط مثل تقييد التزامن في النهايات الثقيلة بقاعدة البيانات، أو رفض الحمل بوضوح (مثل 429)، وقلل من إعادة الاتصالات عن طريق تجنب أوقات حياة اتصال قصيرة جدًا.