למה כוונון autovacuum ב-PostgreSQL לא מצליח לעמוד בעומס
הסימפטום הראשון כמעט אף פעם אינו כשל — תחילה עולה זמן התגובה בשיאים. טבלאות מתנפחות מהר יותר ממה שהניקוי ברקע מספיק לעבד: גרסאות שורות מתות נשארות בעמודים, המקום עבורן לא מוחזר למחזור, וכל שאילתה קוראת באופן ניכר יותר עמודים מאשר הנתונים השימושיים שבהם.
מדאיג במיוחד שמבחוץ זה נראה כמו עבודה שגרתית — אינדקסים בשימוש, תוכניות שאילתות לא משתנות, והדרדרות מצטברת במשך חודשים.
ספי ברירת המחדל מחושבים לפרופיל עומס אחר. סף של חמישית מגודל הטבלה עבור טבלה גדולה משמעו שהניקוי יופעל לאחר עשרות מיליוני שורות ששונו — ועד אז מצטברות עוד באותה כמות שינויים.
הגבלת מספר העובדים המקבילים מביאה לכך שמעבר כבד אחד מחזיק בתור ושאר הטבלאות ממתינות; השהיות בין מעברים כברירת מחדל גדולות מדי עבור מסד נתונים עם כתיבה מתמדת. בסופו של דבר הניקוי ברקע לא מספיק לא בגלל טעות בכוונון, אלא בגלל שאף אחד לא חישב מחדש את הפרמטרים לזרימת השינויים האמיתית.
לאחר מכן מצטרף משוב חיובי: ככל שהתנפחות הטבלאות חזקה יותר, כך הניקוי אורך זמן רב יותר, כך הוא מסתיים לעתים רחוקות יותר, וכך המסד גדל מהר יותר. תחזוקה מתוכננת הופכת לחירום — הפעלה ידנית של ניקוי בשעות העבודה, נעילות, ירידה בביצועים במהלך המעבר, סיכון להיתקל במקום פנוי בדיסק. אנו מפרקים כיצד זה נסגר: כיצד לחשב ספים לפי פרופיל הכתיבה בפועל וכיצד להחזיר לתחזוקה סדירות.
מה נותן ניקוי טבלאות מנוהל: אפקט במספרים
התנפחות ונפח אחסון
סף ההפעלה כברירת מחדל קשור לשיעור מהטבלה, ולכן בטבלה גדולה autovacuum ממתין עד שיצטברו מיליוני שורות מתות — והקבצים גדלים מהר יותר ממה שהניקוי מספיק להחזיר אותם.
אנו מורידים את הסף למספר שורות סביר, מוסיפים מרווח מקום פנוי בעמודים לגרסאות שורות עתידיות, ומגדירים כללים נפרדים לטבלאות "חמות" במקום כלל גלובלי אחד. לפי מונים מערכתיים ניתן לראות ששיעור השורות המתות מצטמצם פי כמה, וגודל היחס מפסיק לגדול בין מחזורי ניקוי.
תגובה ויציבות
תמונה אופיינית תחת עומס — ניקוי ארוך מושך קלט/פלט דיסק ומחזיק נעילות בדיוק כשמגיעות שאילתות שיא: זמן התגובה עולה בקפיצות, ותור השאילתות מצטבר.
אנו מגבילים את עוצמת הניקוי, מפזרים אותו בין עובדים ומעבירים ריצות כבדות לחלונות של עומס נמוך, ומשאירים הפעלה אוטומטית פועלת עבור שאר הטבלאות. כתוצאה מכך שאילתות שיא מפסיקות להיתקל בניקוי, התגובה נשארת צפויה, וריצות חירום ידניות לפי לוח זמנים נעלמות כסוג של כשל.
מצבי VACUUM: השוואת גישות ואופטימיזציה של לוח זמנים
שורות מתות מצטברות בכל מצב — ההבדל הוא מי ומתי מפעיל את הניקוי. להלן ארבע חלופות עבודה והתנאים שבהם כל אחת מהן מתאימה.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| ניקוי אוטומטי לפי סף | זרימת שינויים אחידה, טבלאות בגודל צפוי | סף לפי שיעור מהגודל מופעל מאוחר: בין מעברים מצטברות שורות מתות |
| ניקוי ידני לפי חלון | טעינות אצווה, חישובי לילה, עדכונים המוניים | נדרש מתזמן חיצוני; פגיעה של החלון בשיא התעבורה מביאה לעלייה בהשהיות |
| ניקוי לפי מחיצות | יומנים ומאורעות מחולקים עם נשירת מחיצות ישנות | מעבר על טבלת האב של המחיצה אינו מנקה — יש לתחזק כל אחת |
| הקפאה נדחית | טבלאות עם עדכונים נדירים וגרסאות שורות ישנות | ההפעלה אינה קשורה לחלון תחזוקה, המעבר עובר על כל הטבלה |
כיצד לבחור מצב לפי פרופיל העומס
הסתכלו על היחס בין שורות מתות לחיות, קצב הגדילה של מונה הטרנזקציות וקיומו של חלון עם ירידה בתעבורה.
ספים גלובליים קובעים את התנהגות ברירת המחדל, אך עבור טבלאות חמות הם נעקפים ברמת הטבלה עצמה — טבלה גדולה מפסיקה להמתין לתור הכללי של הניקוי האוטומטי ואינה צוברת שורות מתות בין מעברים נדירים.
מגבלות: נעילות, שכפול, פיגור העתקים
הניקוי אינו חוסם קריאה וכתיבה, אך מתנגש עם שינוי מבנה הטבלה והאינדקסים. במקביל הוא כותב ליומן הכתיבה המוקדמת: בשכפולים זרימת השינויים גדלה, וההעתק עלול לפגר במעברים כבדים.
את הקצב מגבילים בהשהיות עלות, ומעברים מלאים והקפאה נדחית מוציאים לחלון של עומס נמוך, כדי שהתחזוקה לא תחפוף לדוחות או לייצוא.
סדר העבודות: ממלאי מסדי נתונים ועד לתקנון תחזוקה
אנו בונים את העבודה על בסיס עובדות, ולא על סט פרמטרים טיפוסי: תחילה מצלמים את מצב המסד, לאחר מכן משנים את התצורה. ששת השלבים שלהלן מספקים תוצר בדיק בכל שלב, ולכן ההחלטה על שילוב במתאר העבודה מתקבלת לפני השינויים, ולא אחריהם.
הכנה ופיילוט בטוח
- מצלמים סטטיסטיקת ניקוי: כמה שורות מתות הצטברו לפי טבלאות, באיזו תדירות עובר הניקוי האוטומטי, היכן מונה השורות המתות גדל במהירות הרבה ביותר.
- אוספים פרופיל עומס וגדילת טבלאות: שעות שיא של כתיבה ועדכון, גידול יומי ושבועי, טרנזקציות ארוכות שמחזיקות תמונת מצב ומפריעות לניקוי.
- מתכננים ספים וחלונות: מקדמים נפרדים לטבלאות גדולות ופעילות, לוח זמנים לניקוי כפוי בפרקי ביניים בין שיאים, מגבלת עומס על תת-מערכת הדיסק.
- מתרגלים את התכנית על העתק: פורסים העתק של המסד, משחזרים עומס אמיתי, בוחנים את התנהגות הניקוי תחת כתיבה מתחרה ומודדים את משך הנעילות.
כיצד אנו בודקים את התוצאה
- עורכים מדידות בקרה לפני ואחרי: שיעור השורות המתות, זמן שאילתות כבדות, גודל הקבצים, תדירות ניקוי החירום.
- מוסרים תקנון: מפת טבלאות עם ספים, כללי בחינה מחדש עם גידול הנתונים, סט שאילתות לבדיקה עצמית וסדר פעולות במקרה של אנומליות.
תצורות, תבניות חלונות ותקנוני תחזוקה בפלט
אנו מוסרים לא סט פקודות חד-פעמיות, אלא תצורה עובדת: כללים שלפיהם המסד מתחזק את עצמו, ונהלים למקרים שבהם הניקוי האוטומטי אינו מצליח. הכל נמצא במאגר התצורה ובתיעוד — ההגדרות משוחזרות בסביבת בדיקה ובסביבת ייצור ללא פערים.
מה אנו מגדירים במסד
- ספי ניקוי אוטומטי לפי קבוצות טבלאות: עבור חמות שיעור השורות ששונו מופעל מוקדם יותר, עבור ארכיונים גדולים המרווחים מורחבים כדי שניקוי מתוכנן לא ידחוק ניקוי דחוף.
- תבנית חלונות תחזוקה: פעולות כבדות רק בשעות עומס נמוך, עם הגבלת משך וקשירה לתורנויות.
- רשימת חריגים: טבלאות וארכיונים גדולים עם תרחיש נפרד — הכנסות חד-פעמיות, מחיצות לחיתוך, נתונים לקריאה בלבד.
- שאילתות בקרה והתראות: שיעור שורות מתות, זמן הניקוי האחרון, התקרבות למונה הטרנזקציות המקסימלי, קצב גדילת הקבצים.
מה נשאר לצוות שלכם
- סדר תחזוקה מתוכננת: מי פותח חלון, מה נבדק לפני ואחרי, היכן נרשמת התוצאה.
- תקנון הסלמה: לפי אילו מדדים התורן מעלה משימה, למי מעביר ומה מספיק לעשות לפני חזרה לאחור.
- הרשאות ויומן פעולות ידניות: חשבונות נפרדים לתחזוקה, הגבלה ועקיבה אחר ביצוע.
- תיעוד עם נימוק לכל סף — עם גידול הנתונים הכללים מחושבים מחדש, ולא נבחרים מחדש.
מקרה בוחן: צמצום התנפחות פי שלושה ללא עצירת השירות
נתוני פתיחה ומגבלות הפרויקט
אשכול PostgreSQL שירת שירות עם זרימת כתיבה רציפה: מספר טבלאות יומן עובדו כל הזמן, והניקוי האוטומטי פעל לפי ספי הפעלה סטנדרטיים. ההתנפחות גדלה מהר יותר ממה שהניקוי הספיק לאסוף — שיעור השורות המתות בטבלאות החמות ביותר הגיע ל-40%, ונפח האחסון תפח כמעט פי שלושה מהנתונים השימושיים. לא היה חלון אי-זמינות: השירות פועל מסביב לשעון, ולא יכולנו לעצור את המסד לצורך ניקוי ידני.
המגבלה השנייה — ריצות חירום של ניקוי. הן הופעלו ידנית כשההתנפחות חצתה את הסימן הקריטי; כל ריצה פגעה בתגובה והחזיקה את המהנדסים במתח.
תוצאה ומה השתנה בתחזוקה
ספי ההפעלה ועלות הניקוי חושבו מחדש לפי פרופיל הכתיבה של טבלאות מסוימות, והמעבר בוצע על מסד פעיל: תחילה ריצת ההגדרות החדשות על העתק, השוואת תוכניות ועומס, לאחר מכן מעבר חלק ללא חלון אי-זמינות.
שיעור השורות המתות ירד מ-38% ל-11%, נפח האחסון הצטמצם פי שלושה, התגובה בשיא נעשתה אחידה יותר — ירידות הביצועים בניקוי הפסיקו להיות מורגשות במדדים.
מספר ריצות החירום ירד מכמה בחודש לאחת-שתיים ברבעון, וגם אז מסיבות מתוכננות. התחזוקה עברה ממצב של "כיבוי שריפות" למצב של תצפית: התנפחות, תדירות ניקויים וגיל הטרנזקציות הוותיקות ביותר נמצאים כעת על לוח מחוונים של מדדים, והספים נבחנים מחדש בעת שינוי פרופיל הכתיבה.
במה נבדלות מדיניות ספים מלוח זמנים לפי חלונות?
מדיניות ספים נשענת על מספר השורות ששונו: שיעור השורות המתות בטבלה עולה על אחוז נתון — איסוף מופעל בלי להמתין לתאריך בלוח השנה. זה נותן תגובה לפרצים: מחיקה בקבוצות או הזרמה המונית מעלות מיד את המונה, וגרסאות שורות מיושנות לא מספיקות לנפח את הקבצים.
הצד השני — אי-צפיות בעומס. בטבלה גדולה סף האחוז מושג לעתים רחוקות ומאוחר, בטבלה קטנה — האיסוף מתרחש כמעט ברציפות. שיאי קלט/פלט חלים ברגעים שבהם המערכת ממילא עמוסה, ואי אפשר לתאם אותם עם גיבוי ועדכון: פשוט אין לוח זמנים.
חלונות תחזוקה מתוכננים מסירים את אי-הוודאות הזו. הפעלת הניקוי קשורה לחלון לילה, המהנדס יודע מראש מתי המסד יבזבז משאבים על איסוף אשפה, ומשלב זאת עם עבודות תקנוניות אחרות.
המחיר — פיגור: בין חלונות הטבלה צוברת שורות מתות, ופרץ ברגע לא מוצלח מספיק לנפח את הקבצים מהר יותר מאשר יגיע לוח הזמנים.
תכנית ניקוי היברידית לוקחת את התגובתיות של הספים ואת הצפויות של החלונות: ניקוי רקע מתבצע לפי לוח זמנים, עבור טבלאות עם כתיבה גבוהה מורידים ספים ומגדירים מצב אגרסיבי יותר, והקפאה ואינדוקס מחדש נשארים בחלון.
עבור מסדים שמתוחזקים כבר ידנית, זו אפשרות עובדת: הפעלה ידנית נשמרת כנקודת בקרה, והספים מפצים על חלון שהוחמץ.
ניקוי אוטומטי תחת עומס: נעילות, טבלאות גדולות, בדיקה
הניקוי האוטומטי מופעל מעצמו, ובמסד עמוס הוא נתקל באופן קבוע בנעילות, טבלאות גדולות ומחסור בזמן למעבר. להלן תשובות לספקות שנשמעים לרוב לפני שינוי ההגדרות הללו.
כולם עוסקים בתפעול ללא אי-זמינות: מה ניתן לתקן במסד פעיל, ומה דורש חלון.
הניקוי ינעל טבלאות ויפיל את השירות?
מעבר שגרתי לוקח נעילה חלשה ואינו מפריע לא לקריאה ולא לכתיבה. נעילה בלעדית מוחזקת רק על ידי בנייה מחדש מלאה של הטבלה ובנייה מחדש של אינדקסים — אותם מוציאים לחלון תחזוקה.
האם ניתן לשנות פרמטרים ללא הפעלה מחדש?
ספים והשהיות מוגדרים עבור טבלה מסוימת ונכנסים לתוקף עבור המעברים הבאים — אין צורך בהפעלה מחדש. הגדרות של מאגר זיכרון משותף מוחלות בעת האתחול, ואותן מתכננים מראש.
מה לעשות עם טבלאות גדולות וארכיונים?
בטבלה של מאות ג'יגה-בייט שיעור השורות ששונו אינו מגיע לסף במשך זמן רב, והיא נשארת לא מעובדת. מפצלים אותה למחיצות לפי זמן, מגדירים ספים בנפרד, וארכיונים ישנים מתחזקים לפי תקנון משלהם מחוץ לניקוי האוטומטי.
כיצד להשתכנע שהעיבוד מתבצע?
בוחנים תצוגות מערכת ויומן: זמן המעבר האחרון, מספר השורות המתות, מוני הקפאה. לפיהם מגדירים התראה — על קיפאון נודע לפני שהקובץ גדל.
המסד מתוחזק שנים, הכל פועל — ממה להתחיל?
מבדיקה: היכן מצטבר מת, אילו טרנזקציות ארוכות מחזיקות את הניקוי, היכן מונה המזהים קרוב לגבול. שינויים מריצים על העתק ורק לאחר מכן מעבירים למתאר העבודה.
נדון במשימה: נאסוף פרופיל עומס ותוכנית עבודה
כדי שההערכה תישען על עובדות ולא על הנחות, אנו זקוקים לנתוני מקור על המסד שלכם. ניתן לאסוף אותם במעבר אחד על תצוגות מערכת ויומנים — על בסיס זה נחשב את היקף העבודה ואת סדר השינויים.
- סטטיסטיקת ניקוי: כמה שורות מתות מצטברות, אילו טבלאות נופלות מהעיבוד, באיזו תדירות מופעל הניקוי האוטומטי והיכן הוא אינו מספיק לעמוד בקצב הכתיבה;
- דינמיקת גידול של טבלאות ואינדקסים — כמה נפח מתווסף ביממה ובאילו אובייקטים הגידול עוקף את הניקוי;
- חלונות עומס: מתי שיא הכתיבה, באילו שעות ניתן להפעיל פעולות כבדות בלי להשפיע על המשתמשים;
- מגבלות אי-זמינות: משך אי-זמינות מותר, קיום העתקים ואפשרות מעבר אליהם;
- הגדרות שכבר הוחלו — ספי ניקוי אוטומטי ששונו, לוחות זמנים ידניים, כללי עקיפה שמישהו הנהיג בעבר;
- פרמטרי שרת וגרסת ענף: נפח זיכרון, מספר ליבות, סוג דיסק, תצורת יומן טרנזקציות;
- היסטוריית אירועים: מתי בפעם האחרונה גדל היומן או ירד קצב השאילתות לאחר עדכון המוני.
תארו את המשימה וצרפו את מה שיש — נחזור עם הערכה ותוכנית עבודה. בתוכנית יהיה ניתן לראות מה משנים בספים, מה מעבירים לתקנון קבוע ובאילו מדידות בקרה מאשרים את התוצאה.