הגדרת PgBouncer (connection pooling) לאפליקציית ווב

PgBouncer הגדרה: מתי מאגר חיבורים מציל את האפליקציה

האפליקציה פותחת חיבור ל-Postgres עבור כל בקשה ומחזיקה אותו עד סוף העיבוד. כל עוד המשתמשים נספרים בעשרות, זה לא מורגש. בעומס שיא מספר החיבורים בו-זמנית נתקע ב-max_connections, ומשם מתחילה מפולת: בקשות חדשות מקבלות שגיאת חיבור, התור לחיבור שהתפנה גדל, וזמן התגובה מגיע לשניות. הגרוע מכל הוא שהכשל מגיע בדיוק כשהעומס מקסימלי — ברגע של מבצע מכירות, קמפיין דיווח או זינוק בוקר.

כל חיבור ב-Postgres הוא תהליך נפרד עם זיכרון משלו. להחזיק מאות תהליכים כאלה זה יקר: מסד הנתונים מבזבז משאבים על מעבר ביניהם במקום לעבד בקשות, וחלק מהחיבורים עומדים בטלים בהמתנה. הגדלת המגבלה היא דרך ללא מוצא: השיא הבא שוב יתקע בתקרה, רק שהפעם הכשל יהיה עמוק יותר.

PgBouncer פותר זאת אחרת. האפליקציה מתחברת למאגר, ולא ישירות למסד הנתונים, והמאגר עושה שימוש חוזר בקבוצה קטנה של חיבורים אמיתיים בין מאות לקוחות. במצב transaction החיבור חוזר למאגר מיד לאחר סיום הטרנזקציה, ולכן כמה עשרות בקאנדים משרתים אלפי בקשות בו-זמנית.

ההגדרה מצטמצמת לשלושה דברים: לבחור מצב מאגר, להגדיר default_pool_size ו-max_client_conn, להגדיר פסקי זמן של חוסר פעילות ולהפריד כראוי חיבורים שירותיים שזקוקים למצבי סשן.

מאגר מוגדר כהלכה מסיר שגיאות חיבור בעומסי שיא, מאזן השהיות ומפחית את העומס על מסד הנתונים בלי לשכתב את קוד האפליקציה. בואו נפרק כיצד זה נסגר בפועל.

מה נותן מאגר חיבורים מוגדר היטב

מאגר חיבורים הוא לא "אפשרות לאופטימיזציה", אלא מפריד בין אפליקציה שעומדת בעומס לבין אפליקציה שקורסת בשיא. כאשר כל בקשה פותחת חיבור חדש למסד הנתונים, זמן התגובה גדל באופן לא ליניארי: ב-50 משתמשים בו-זמניים עוד נסבל, ב-300 — תור לחיבור ופסקי זמן. להלן מה בדיוק משתנה לאחר הגדרת PgBouncer, עם הצמדה למטריקות שנראות בניטור.

• זמן התגובה מפסיק להיות תלוי במספר המשתמשים. החיבורים ממוחזרים ממאגר מוכן, והאפליקציה לא מבזבזת זמן על יצירת חיבור חדש ואימות עבור כל בקשה. בגרף זמן התגובה נשמר בקו ישר היכן שקודם היה גידול מדורג.
• כשלי חיבור נעלמים כקטגוריה. המגבלה על מספר החיבורים מצד מסד הנתונים כבר לא נתקלת בתקרה: בקשות עודפות ממתינות בתור המאגר שברירי שנייה במקום שגיאה. שגיאות מסוג "too many connections" נעלמות מהלוגים של האפליקציה.
• עומס שיא נבלם ללא גידול במשאבים. פרץ תעבורה מטופל על ידי תור המאגר, ולא על ידי מפולת של חיבורים חדשים למסד הנתונים. שרת מסד הנתונים מפסיק להיכנס לעומס יתר בזיכרון ובמעבד בכל שיא.
• יציבות תחת עומס הופכת לצפויה. התנהגות האפליקציה בעת גידול תעבורה מתוארת מראש: ידוע כמה חיבורים מחזיקים, כמה ממתינים, מה קורה בעת הצפה. זה מסיר כשלים "צפים" שקשה לשחזר.
• ביצועי האפליקציה גדלים ללא כתיבה מחדש של קוד. המאגר מוגדר ברמת התשתית, הלוגיקה של האפליקציה לא משתנה. האפקט נראה מיד לאחר העברת התעבורה למאגר.
• משאבי השרת מתבזבזים באופן אחיד יותר. מסד הנתונים מחזיק מספר קבוע של תהליכי עבודה במקום מאות חיבורים לא פעילים — הזיכרון שהתפנה הולך לקאש ולעיבוד בקשות.

כל סעיף נבדק לפי מטריקות: זמן תגובה באחוזונים, מספר שגיאות חיבור, עומס מסד הנתונים בשיא. אם לפחות מדד אחד לא זז — ההגדרה חלקית, ואנחנו רואים זאת בשלב הקבלה, ולא בפרודקשן.

מצבי עבודה של pool: השוואת גישות

מצב ה-pooling קובע באיזו רמה PgBouncer מחזיר את חיבור השרת חזרה ל-pool. מכך תלויים גם תפוקת העומס וגם התאימות לתכונות PostgreSQL: שאילתות מוכנות מראש, SET, advisory locks, cursors. להלן — הווריאציות המעשיות שביניהן באמת בוחרים בעת ההגדרה.

עבור מצב טרנזקציה קריטי להגדיר server_reset_query ל-DISCARD ALL ולכבות את מטמון השאילתות המוכנות מראש בצד ה-driver או להפעיל את התמיכה בהן ב-PgBouncer עצמו. אחרת האפליקציה תקבל שגיאות «prepared statement already exists» תחת עומס — כשל קלאסי במעבר ממצב סשן.

תרחישים משולבים נפתרים על ידי הפרדת pools: instance נפרד של PgBouncer לתעבורת טרנזקציות ו-instance נפרד — לאנליטיקה ולמשימות רקע. זה מסיר את הקונפליקט של המגבלות ומאפשר להגדיר באופן בלתי תלוי את pool_mode, max_client_conn ו-default_pool_size עבור כל פרופיל עומס.

כיצד אנו מיישמים מאגר חיבורים: שלבי העבודה

יישום מאגר חיבורים אינו מתחיל בהתקנת PgBouncer, אלא בביקורת של האופן שבו האפליקציה עובדת עם מסד הנתונים כעת. אנו בוחנים חיבורים פעילים תחת עומס, את התנהגות הדרייבר וה-ORM, את משך הטרנזקציות, ואת קיומן של סשנים "רדומים" שמחזיקים חיבור פתוח במשך שעות.

לעתים קרובות כבר בשלב זה ניכר כי חלק מהחיבורים מתבזבזים לשווא — למשל, משימות רקע מחזיקות מאגר נפרד שאינו חופף לתעבורת האינטרנט.

לאחר מכן אנו בוחרים את מצב המאגר ומחלקים את העומס לקבוצות. מצב טרנזקציוני מתאים לרוב אפליקציות האינטרנט, אך דורש שהקוד לא יסתמך על מצב הסשן בין בקשות — אנו בודקים זאת בנפרד, מכיוון שביטויים מוכנים מראש וטבלאות זמניות מתנהגים אחרת.

אם האפליקציה משתמשת בהם באופן פעיל, אנו משאירים מצב סשן עבור קבוצה מסוימת ואיננו שוברים את הלוגיקה לשם חיסכון בחיבורים.

1. ביקורת חיבורים. אנו מפיקים פרופיל עומס: מספר השיא של סשנים בו-זמניים, התפלגות לפי זמן, שיעור החיבורים שאינם פעילים, והטרנזקציות הארוכות ביותר.
2. תכנון המאגר. אנו קובעים את מספר הקבוצות, את המגבלות לכל אחת, את מצב הפעולה ואת כללי הניתוב של האפליקציה לקבוצה הנדרשת.
3. הגדרת PgBouncer. אנו מגדירים את גדלי המאגרים, זמני המתנה לחוסר פעילות ולהחזקה, מגבלות לכל לקוח, ופרמטרים לחיבור מחדש למסד הנתונים.
4. עריכת תצורת האפליקציה. אנו מעבירים את הדרייבר לפורט של המאגר, מסירים מאגר עצמאי במקום שבו הוא מכפיל את המאגר החיצוני, אחרת משמעות ההגדרה אובדת.
5. בדיקה תחת עומס. אנו מריצים פרופיל הקרוב לזה הייצורי: בודקים שמספר החיבורים למסד הנתונים נשמר בגבולות שהוגדרו, וזמן התגובה אינו עולה בשיאים.
6. מסירת תיעוד. אנו מוסרים את התצורה, את סכימת הקבוצות, את התקנון לשינוי מגבלות ואת ההוראות לאבחון, כדי שהצוות יוכל לתחזק את המאגר בלעדינו.

בנפרד אנו בודקים תרחישי כשל: הפעלה מחדש של PgBouncer, אי-זמינות מסד הנתונים, וזינוק בתעבורה מעל לזה המחושב. התצורה צריכה לעבור זאת ללא התערבות ידנית — החיבורים משוחזרים מעצמם, והאפליקציה מקבלת שגיאה מובנת במקום בקשה תקועה.

מה הלקוח מקבל לידיו לאחר ההגדרה

אנחנו מגדירים את ה-pool כך שניתן יהיה להפעיל אותו ללא מחבר העבודה: התצורה, תרשים החיבורים והנהלים נשארים במאגר הפרויקט, ולא בהתכתבות. להלן — מה בדיוק אנחנו מוסרים.

• תצורת ה-pool — קבצי pgbouncer.ini ו-userlist.txt עובדים (סיסמאות בצורה מגובבת) במצב transaction או session, עם נימוק לבחירה. הפרמטרים max_client_conn, default_pool_size, reserve_pool_size והזמנים המוקצבים מוגדרים לפרופיל העומס של האפליקציה, ולא "כברירת מחדל".
• תרשים החיבורים — דיאגרמה: אפליקציה → pool → PostgreSQL, עם ציון אילו שירותים עוברים דרך PgBouncer, ואילו (מיגרציות, אנליטיקה, LISTEN/NOTIFY) — ישירות. בנפרד מסומנות נקודות הכשל וההתנהגות בעת אי-זמינות ה-pool.
• מדיניות גישה — אילו תפקידים ומסדי נתונים נראים דרך ה-pool, הגבלות לפי כתובות, משתמש נפרד לניטור. הכללים מתואמים עם מודל ההרשאות הנוכחי במסד הנתונים, כדי שה-pool לא יהפוך לדרך עוקפת.
• ניטור ומטריקות — ייצוא מטריקות ה-pool (תפוסה, המתנה, סירובים) למערכת הניטור שלכם, דאשבורד עם מדדים מרכזיים וספים להתראות.
• נהלי הפעלה — מה לעשות בעת מיצוי ה-pool, כיצד לטעון מחדש את התצורה בבטחה ללא ניתוק חיבורים, כיצד לחזור לחיבור ישיר אם ה-pool הידרדר.
• תיעוד — תיאור תמציתי של הארכיטקטורה, הוראות לשינוי פרמטרים וצ'ק-ליסט בדיקה לאחר השחרור. מיועד למהנדס תורן, ולא למי שהטמיע.
• תוכנית בדיקה — תרחישי עומס שאיתם אוששה התוצאה, והערכים המתועדים לפני ואחרי: מספר החיבורים למסד הנתונים, זמן התגובה בשיא.

את כל זה אנחנו מוסרים למאגר ולמערכת התיעוד שלכם, עם פירוט בשיחה. תארו את המשימה — נחזור עם הערכה ותוכנית.

מקרה בוחן: כיצד מאגר חיבורים ביטל כשלים בעומס שיא

הלקוח — שירות עם אזור אישי ותשלומים — הגיע עם תמונה קלאסית: בשעות היום האפליקציה שמרה על זמן תגובה תקין, אך בשעות השיא, כאשר דיוור המוני ונהירת משתמשים התרחשו בו-זמנית, חלק מהבקשות נכשלו עם שגיאת חיבור למסד הנתונים.

הלוגים הראו שתהליך האפליקציה פתח חיבור עבור כל בקשה והחזיק אותו עד סוף הטרנזקציה, ומסד הנתונים נתקל במגבלת החיבורים בו-זמניים. כל חיבור חדש — זהו תהליך נפרד בצד מסד הנתונים, ובזמן קפיצה מספרם גדל מהר יותר מכפי שמסד הנתונים הספיק לשרת אותם.

PgBouncer הוצב בין האפליקציה למסד הנתונים במצב מאגר טרנזקציוני: החיבור מוחזר למאגר מיד לאחר סיום הטרנזקציה, ולא תלוי עד סגירת הסשן. מספר החיבורים האמיתיים למסד הנתונים קובע על רמה שהוא מחזיק בשלווה — את השאר האפליקציה מקבלת מהמאגר באופן מיידי.

בנפרד הוגדרו פסקי זמן של חוסר פעילות ומגבלה ללקוח, כדי שחיבור אחד "תקוע" לא יאכל את המאגר.

מדדים לפני ואחרי

אפקט חשוב — צפיות מראש: מסד הנתונים הפסיק להיות צוואר בקבוק, ואת עומס השיא מחזיק כעת המאגר, ולא מרווח המשאבים של השרת. אם זמן התגובה שלכם יורד דווקא בשעות השיא ובלוגים נראים כשלי חיבור — תארו את המשימה, נחזור עם הערכה ותוכנית הגדרה בהתאם לפרופיל העומס שלכם.

במה שונה מצב טרנזקציוני ממצב סשן

מצב סשן מצמיד חיבור שרת ללקוח למשך כל הסשן: כל עוד האפליקציה מחזיקה בחיבור, היא תופסת באופן בלעדי backend אחד של PostgreSQL. זהו המצב היחיד שבו פועלות כל יכולות השרת — ביטויים מוכנים ברמת הסשן, טבלאות זמניות, SET ו-LISTEN/NOTIFY, נעילות advisory, קורסורים מחוץ לטרנזקציה.

המחיר הוא יכולת scaling: כל חיבור של אפליקציה דורש תהליך נפרד בבסיס הנתונים, ובמאות משתמשים בו-זמניים PostgreSQL נתקל במגבלת הזיכרון ובהחלפות הקשר הרבה לפני מיצוי המעבד.

מצב טרנזקציוני מוסר את חיבור השרת ללקוח רק למשך הטרנזקציה ומחזיר אותו ל-pool מיד לאחר COMMIT או ROLLBACK. backend אחד משרת עשרות לקוחות ברצף, ולכן pool של מאות אפליקציות מסתפק בשני תריסרים של חיבורים אמיתיים לבסיס הנתונים.

זהו מצב ברירת המחדל לאפליקציות ווב: שאילתה טיפוסית חיה אלפיות שנייה, וההפסקה בין שאילתות של משתמש אחד יכולה להימשך שניות — להחזיק חיבור עבורה זה בזבוז.

המגבלות של המצב הטרנזקציוני נובעות מכך שהלקוח אינו בעל ה-backend בין טרנזקציות. מצב הקשור לסשן הולך לאיבוד: ביטויים מוכנים, טבלאות זמניות, שינויים ב-search_path ובפרמטרים דרך SET, נעילות advisory ברמת הסשן. גם קורסורים עם WITH HOLD ו-LISTEN/NOTIFY אינם נשמרים.

דרכי עקיפה — SET LOCAL בתוך הטרנזקציה במקום SET, ביטויים מוכנים בעלי שם עם ניהול מפורש, והעברת משימות רקע ל-pool נפרד במצב סשן.

בחירת המצב היא בחירה בין תאימות לצפיפות. אם האפליקציה משתמשת במצב סשן או עובדת דרך driver עם ביטויים מוכנים משתמעים, מתחילים במצב סשן ומעבירים בהדרגה את המסלולים החמים למצב טרנזקציוני.

תצורה משולבת היא נורמלית: שני pools על פורטים שונים, טרנזקציוני לתעבורת ווב, סשן למיגרציות, אנליטיקה ומעבדי רקע. המגבלה על מספר החיבורים נקבעת בצד ה-pool, ולא בצד האפליקציה, — אחרת המשמעות של pooling הולכת לאיבוד.

ספקות טכניים לפני הטמעת מאגר

לפני הפעלת המאגר, כמעט כל צוות עובר את אותה רשימת ספקות: "האם זה ישבור את ה-ORM", "האם הטרנזקציות ייפגעו", "האם המיגרציות יעברו", "מה יקרה עם שאילתות מוכנות מראש". להלן ניתוח נקודה-נקודה, בלי מילים כלליות.

האם טרנזקציות ונעילות לא יאבדו את השלמות?

ב-transaction pooling כל האופרטורים של טרנזקציה אחת חייבים לעבור דרך חיבור אחד — המאגר מבטיח זאת ואינו מוסר אותו ללקוחות אחרים עד ל-COMMIT או ROLLBACK. הבעיה מתעוררת עם SET, טבלאות זמניות ונעילות advisory ברמת הסשן: הם אינם שורדים את החזרת החיבור. מקומות כאלה מוציאים ל-session pooling באופן נקודתי או כותבים מחדש לרמת נעילה טרנזקציונלית.

מיגרציות ומשימות רקע — מאגר נפרד?

מיגרציות, pg_dump, חילוצים אנליטיים ומשימות רקע ארוכות מחזיקות חיבור למשך דקות. אם מריצים אותן דרך המאגר המשותף, הן יצרכו את כל המכסה ויפילו את תעבורת האינטרנט.

לכן עבורן מרימים מאגר נפרד עם מספר חיבורים קטן ומשתמש נפרד — אפליקציית האינטרנט ותהליכי השירות מפסיקים להתחרות על אותה קבוצה.

איך לחזור אחורה אם משהו ישתבש?

המאגר הוא פרוקסי בין האפליקציה לבסיס הנתונים, הוא אינו נוגע בסכימת הנתונים. החזרה אחורה — החלפת מחרוזת החיבור חזרה לכתובת ישירה של בסיס הנתונים; אורכת דקות ואינה דורשת מיגרציות. לכן בטוח לבצע הטמעה בשלבים: תחילה שירות אחד, מדידת השהיות ומספר החיבורים, ואחר כך השאר.

כל ארבעת החששות נסגרים בשלב התכנון — לפני שהמאגר נכנס למתאר העבודה.

נדון במשימה שלכם ונחזור עם הערכה

כדי לחזור עם הערכה ותוכנית עבודה, אנחנו צריכים מינימום של נתוני פתיחה: התצורה הנוכחית של PostgreSQL ו-PgBouncer (מצב ה-pool, מגבלות חיבורים, timeouts), אופי העומס — כמה משתמשים בו-זמניים, האם יש טרנזקציות ארוכות ודוחות כבדים, איך האפליקציה מחזיקה חיבורים (pool בצד האפליקציה או חיבור חדש לכל בקשה). זה מספיק כדי להבין את צוואר הבקבוק ולהציע מצב pool בלי לנחש.

מכאן עובדים בשלבים:

• מנתחים את המדדים הנוכחיים: מספר החיבורים הפעילים והממתינים, תורים בשיא, כשלים עקב timeout;
• קובעים מצב pool ויעד מגבלות בהתאם לפרופיל העומס, ולא "ברירת מחדל";
• בודקים תאימות עם ה-driver וה-ORM: prepared statements, טרנזקציות, סשנים;
• מכינים תצורה ותוכנית מעבר ללא השבתה — דרך מופע שני והעברת תעבורה;
• מריצים בדיקת עומס על עותק של בסיס הנתונים הפרודקשני ומתעדים מדדים לפני/אחרי;
• מפרסים לפרודקשן עם תוכנית rollback ונראות על חיבורים והשהיות;
• מתעדים את הפרמטרים הסופיים ומעבירים תיעוד לצוות שלכם.

מה נדרש מכם להתחלה: גישה לתצורה ולמדדים, חלון לבדיקה בסביבת טסט וקשר של מהנדס שיודע איך האפליקציה פותחת חיבורים. השאר — באחריותנו: תצורה, תוכנית מעבר, בדיקות ו-rollback.

תארו את המשימה — נחזור עם הערכה, תוכנית עבודה וצעדים הבאים ברורים.