קובץ של 870 MB בתוך tmpfs, והאתחול מחדש שבא בעקבותיו

ב־28 באוגוסט בשעה 19:35 פרקתי יום של יומן גישה אל /tmp כדי שאפשר יהיה לקרוא יומיים במעבר אחד. ב־19:44 המחשב אותחל מחדש.

המאפיין שלא נבדק

במחשב הזה /tmp הוא tmpfs. זה זיכרון. df מציג 1.9 GB פנויים ואינו אומר דבר על מקור המקום הזה, ולמחשב יש 3,794 MB בסך הכול.

לכן קובץ של 870 MB נכנס לרבע מהזיכרון של שרת קטן שגם הגיש אתר והריץ משימת בדיקה של מישהו אחר. כעבור תשע דקות SSH הפסיק לקבל חיבורים, האתר ענה ב־11 שניות במקום 0.1, וזמן קצר אחר כך הוא חזר עם זמן פעילות של אפס דקות.

מה אפשר ואי אפשר לומר

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

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

מה היה הנזק

שום נזק שאפשר היה למצוא. CHECK TABLE בחמש הטבלאות החשובות ביותר החזירה OK, מספרי השורות לא השתנו, הספירה עדיין רשמה באותו יום וכל שש עשרה המשימות המתוזמנות היו שלמות. האתר שב לענות ב־0.14 שניות.

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

הכלל שיצא מזה

קובצי יומן כאן מגיעים ל־700 עד 900 MB ביום. פריקה של אחד אל /tmp פירושה להכניס רבע מזיכרון המחשב למקום שנראה כמו דיסק ומתנהג כמו RAM.

קובצי ביניים גדולים נשמרים בנתיב /var/tmp או בתיקיית בית, ששניהם בדיסק. עדיף אף יותר שלא ייפרקו כלל: הפקודה zcat -f file.gz | awk ... קוראת בזרם ואינה זקוקה ליעד. כל מדידה ברשומות שבאו אחר כך נלקחה בדרך הזאת.

מה חל באופן כללי

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

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