אזילת מקום היא הסיבה הנפוצה ביותר לכך ששרת מפסיק לעבוד בלי שום כוונת זדון מעורבת. האתר מחזיר 500, מסד הנתונים אינו כותב, הדואר אינו יוצא — ובאותה עת df -h מדווח על כמה ג׳יגה-בייטים פנויים. נעבור על שלושת המקרים שבהם זה קורה, ועל מה ששווה לדעת על SMART.
מקרה ראשון: נגמרו ה-inodes
מערכת קבצים מחזיקה שני משאבים מוגבלים: מקום לתוכן ורשומות על קבצים. והשני נגמר בנפרד מהראשון:
df -h
df -iאם IUse% בפקודה השנייה הוא 100, הבעיה היא ב-inodes. יש מקום, אבל אי אפשר ליצור אף קובץ, אפילו ריק.
והאשמים תמיד אותם אשמים: מיליוני קבצים זעירים. הפעלות PHP ב-/var/lib/php/sessions שאיסוף האשפה שלהן נשבר. מטמון של אפליקציה שאף פעם לא מנוקה. תור דואר תקוע. תיקיית תמונות ממוזערות. אפשר למצוא אותם כך:
sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20הפקודה מציגה את התיקיות עם הכי הרבה קבצים. במערכת גדולה היא רצה דקות — וזה נורמלי.
מקרה שני: הקובץ נמחק והמקום לא חזר
מצב ערמומי עוד יותר. מישהו הסיר עם rm יומן שהתנפח, אבל התהליך שכותב אליו עדיין מחזיק אותו פתוח. הקובץ כבר אינו בתיקייה, המקום עדיין תפוס, וכך יישאר עד שהתהליך יופעל מחדש.
sudo lsof +L1הפקודה מציגה קבצים עם אפס קישורים במערכת הקבצים שתהליך עדיין מחזיק בהם. התרופה היא הפעלה מחדש או טעינה מחדש עדינה של אותו תהליך, ולא ציד אחרי «לאן נעלמו הג׳יגה-בייטים».
מכאן הכלל: יומן שהתנפח אינו נמחק אלא מקוצר, וכך המתאר הפתוח נשאר שמיש:
sudo truncate -s 0 /var/log/huge.logומיד אחר כך הגדירו סבב — אחרת כל זה יחזור על עצמו תוך שבוע.
מקרה שלישי: היומנים אכלו
לאן בדיוק הלך המקום נראה בירידה שכבה אחר שכבה:
sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -hהדגל -x מונע נדידה למערכות קבצים אחרות; בלעדיו הספירה זוחלת אל /proc ואל נקודות עיגון רשת. וכל זה נוח יותר ב-ncdu, אם הוא זמין.
הזללנים הרגילים:
- journald. פקודה אחת פותרת:
journalctl --disk-usage. מוגבל בשורהSystemMaxUse=500Mב-/etc/systemd/journald.confומנוקה חד-פעמית עםjournalctl --vacuum-size=200M; - יומני כלי אבטחה. Suricata בתצורת ברירת המחדל כותבת שלושים סוגי אירועים ואינה מגדירה לעצמה שום סבב — בשרת אמיתי זה ייצר 15 ג׳יגה-בייט ביומיים. אותו דבר קורה עם audit.log ועם יומני איתור התקלות ב-nginx;
- גיבויים שנכתבים לאותו דיסק ואף פעם אינם נמחקים;
- מטמון apt —
apt cleanמחזיר מדי פעם כמה ג׳יגה-בייטים.
כמה מילים על /boot
מחיצה קטנה שמתמלאת בליבות ישנות. היא אינה מפילה את האתר בעצמה, אבל עוצרת את העדכונים לחלוטין: הליבה החדשה לא תותקן, ומאחוריה ייתקע כל תור החבילות. נרפא עם apt autoremove --purge, ונמנע בהפעלת מחיקה אוטומטית של ליבות שאינן בשימוש בהגדרות העדכונים האוטומטיים.
SMART: אילו מאפיינים חשובים
תחילה הסתייגות: בשרת וירטואלי SMART בדרך כלל אינו זמין — הדיסק וירטואלי ואינכם רואים את הפיזי שמתחתיו. זו אינה תקלה, פשוט אין נתונים. כל מה שלהלן נוגע לשרתים ייעודיים ולחומרה שלכם.
sudo smartctl -a /dev/sdaהשורה SMART overall-health self-assessment test result: PASSED אינה סיבה להירגע: היא נשארת ירוקה כמעט עד מות הכונן. מה שצריך להביט בו הם המונים המסוימים:
- 5, Reallocated_Sector_Ct — סקטורים שהוקצו מחדש. ערך שאינו אפס פירושו שהכונן כבר מידרדר; וגידול לאורך זמן פירושו החליפו בלי לדחות;
- 197, Current_Pending_Sector — סקטורים שאינם נקראים וממתינים להחלטה. המדאיג מכולם: בדרך כלל פירושו שחלק מהנתונים כבר אינו בר-שחזור;
- 198, Offline_Uncorrectable — אותו דבר, מאושר בבדיקה;
- SSD: Percentage Used / Media_Wearout_Indicator — עמידות הכתיבה שנוצלה. מספר צפוי, ולפיו מתכננים את ההחלפה.
ואילו טמפרטורה ושעות פעילות אינן אומרות דבר בפני עצמן: כונן עם חמש שנות פעילות ומוני שגיאות אפסיים אמין יותר מכונן חדש עם 1 במאפיין 197.
המשמעות של מעקב
כל האמור למעלה הוא תגובה למשהו שכבר קרה. ובכל זאת גם דיסק שמתמלא וגם בלאי של SSD הם תהליכים איטיים וצפויים לחלוטין: גרף תפוסה של שבועיים מראה את תאריך אזילת המקום הרבה לפני שזה קורה. וההבדל בין «האתר מושבת מהשעה שלוש בלילה» לבין «ביום חמישי צריך לנקות את היומנים» הוא רק בכך שהמספר לנגד עיניכם. איך זה נראה מקובץ מראה עמוד ההדגמה למטה.