المستوى المطلوب: متوسط — مناسب لمن لديه أساسيات PostgreSQL ولامس مشاكل الإنتاج مرة واحدة على الأقل.
لو PostgreSQL عندك بياكل 8GB RAM مع 200 connection بس، المشكلة مش في حجم البيانات ولا في عدد الاستعلامات. كل connection بيتفتحله process مستقل في نظام التشغيل بياخد بين 5 و 10MB ذاكرة قبل أي query. pgbouncer بيخدم 1000 client متزامن بـ 50MB إجمالي بدلاً من 10GB. الفرق ليس تحسينًا تجميليًا — هو الفرق بين سيرفر يقع تحت الضغط وآخر يصمد.
Connection Pooling: مفتاح تشغيل PostgreSQL تحت ضغط حقيقي
المشكلة باختصار
PostgreSQL بيستخدم نموذج "process per connection" — كل client بيتفتحله process مستقل بـ fork من الـ postmaster. ده ممتاز للأمان والعزل بين الـ sessions، لكنه مكلّف جدًا للذاكرة. لو فاتح 500 connection، إنت بتدفع 2.5–5GB RAM قبل ما تنفّذ query واحد.
المهندسون عادة بيرفعوا max_connections لـ 1000 أو أكثر علشان يستوعبوا الترافيك، فيدخلوا في حلقة OOM. الحل مش "اشتري سيرفر أكبر" — الحل تشيل النموذج ده من المسار.
مثال موظف البنك (للمبتدئ)
تخيّل بنك فيه 500 عميل بيدخلوا الفرع في الساعة. كل عميل محتاج 30 ثانية بس مع موظف. عندك خياران:
- توظّف 500 موظف (واحد لكل عميل في وقت ذروة افتراضي). 90% منهم هيكونوا قاعدين بدون شغل أغلب الوقت، ومرتباتهم بتكسرك.
- توظّف 25 موظف بس، وتحط منظّم طابور بيوزّع العملاء بسرعة. كل عميل بياخد دوره خلال ثوانٍ.
الخيار التاني هو فكرة Connection Pooling بالظبط. الموظفون = الاتصالات الفعلية بـ PostgreSQL، المنظّم = pgbouncer، العملاء = الـ clients (تطبيقاتك). pgbouncer ما بيلغيش الاتصالات — هو بيعيد توزيع عدد قليل منها بذكاء.
التعريف العلمي
Connection Pool هو طبقة وسيطة بتحتفظ بعدد محدود من اتصالات PostgreSQL مفتوحة بشكل دائم، وبتعيد استخدامها بين الـ clients. الـ client بيتصل بـ pgbouncer (على بورت 6432 افتراضيًا) بدلاً من PostgreSQL مباشرة. pgbouncer بيختار connection فاضي من الـ pool، يوصّل الاستعلام، ويرجّعه للـ pool بعد انتهاء الـ transaction.
pgbouncer بيدعم 3 أنماط من الـ pooling — اختيارك بينهم بيحدد كل trade-offs بعد كده:
- session pooling: الـ connection مخصّص للـ client من أول ما يفتح لحد ما يقفل. آمن للـ session-level features (LISTEN/NOTIFY، SET، prepared statements)، لكن المكسب محدود لأن الـ pool بيتحجز.
- transaction pooling: الـ connection بيرجع للـ pool فورًا بعد كل
COMMITأوROLLBACK. ده الوضع اللي بيوفّر 90% من الذاكرة، ومستخدم في 95% من حالات الإنتاج. - statement pooling: الـ connection بيرجع بعد كل query منفرد. أعلى throughput نظري، لكنه بيكسر أي transaction متعدّد الـ statements، فنادر استخدامه.
إعداد pgbouncer شغّال في 8 سطور
الإعداد ده مجرّب على Ubuntu 22.04 و Debian 12 مع pgbouncer 1.22. ضعه في :
