הגדרת MongoDB WiredTiger: מטמון, דחיסה וניטור

כוונון MongoDB WiredTiger כאשר מסד הנתונים נתקע בזיכרון ובדיסק

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

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

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

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

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

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

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

מה משתנה לאחר כוונון פרמטרי המטמון והדחיסה

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

מה אנחנו מחזיקים על לוח המחוונים

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

אילו כשלים מפסיקים להתרחש

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

השוואת גישות: דחיסה, מטמון ופריסת קולקציות

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

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

קיצוניות נשברות באופן צפוי. אם דוחסים הכל максимально, השרת נתקע במעבד, והשהיית הקריאה עולה משום מקום. אם מחזיקים את כל ערכת העבודה במטמון, הגבול הפיזי של הזיכרון מחזיר את הפינוי וההחמצות — פשוט מאוחר יותר ובאופן פחות מורגש.

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

סדר העבודות: מפרופיל העומס ועד למסירה לשליטה

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

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

מה נשאר אצלכם: תצורות, סכימות ותקנות

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

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

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

מה היה לפני השינויים

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

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

מה עשינו

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

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

• גידול האחסון — פלוס 8% בחודש בהתחלה, פלוס 1-2% לאחר הכוונון;
• שיעור פעולות הקריאה מהדיסק — מכ-30% ל-3%;
• זמן תגובת הקריאה — הצטמצם פי כ-2.5;
• כשלים תחת עומס — מקרים בודדים ביום, במשך רבעון תצפיות אף לא אחד;
• נפח קבצי הנתונים — הדחיסה הביאה לצמצום פי שלושה, גיבויים נאספים פי כמה מהר יותר.

בנפרד עיגנו בניטור התראה על גידול ערכת העבודה: ההרחבה הבאה של הצומת מתוכננת מראש, ולא לאחר כשל.

במה WiredTiger שונה ממנועי אחסון אחרים?

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

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

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

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

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

ספקות טכניים: זיכרון, דחיסה, אינדקסים, כשלים

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

האם דחיסת אינדקסים לא תאט את השאילתות?

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

כיצד להבדיל בין מטמון עמוס למטמון מוצף?

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

האם ניתן לשנות פרמטרים כשהאפליקציה פועלת?

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

נדון במשימה: מה נדרש מכם להתחלה

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

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

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