כיצד ניתן לבדוק את השימוש ב-inode ב-HestiaCP? מה גורם לחוסר היכולת לכתוב קבצים גם כאשר יש מספיק מקום פנוי בדיסק?

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

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

אבל כשהוא בדק עם `df -h`, הוא נדהם לגלות שבדיסק יש בבירור עשרות ג'יגה-בייט של מקום פנוי. איך הוא יכול להיות מלא?

אמרתי לו באותו רגע, "אחי, לא רק שיש לך מלא מקום אחסון, ה-Inode שלך ​​עמוס יתר על המידה."

הוא ענה בסימן שאלה: מה זה בעצם אינוד?

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

בואו נבהיר קודם מה זה Inode.

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

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

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

בלינוקס , כל קובץ וכל ספרייה חייבים לתפוס inode, לא משנה כמה קטן הקובץ.

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

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

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

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

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

הטריק הראשון הוא להשתמש ב-`df -i` כדי לקבל סקירה מהירה.

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

df -i

הוא יפרט את המספר הכולל של צמתי ה-innodes, המספר שבו נעשה שימוש והמספר שנותר עבור כל מחיצה מותקנת.

בפלט, יש עמודה בשם IUse%, שהיא המדד המרכזי שעליך לעקוב אחריו.

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

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

השיטה השנייה היא להשתמש בפונקציה `find` כדי לספור במדויק משתמש ספציפי.

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

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

find /home/用户名/web/你的域名/public_html | wc -l

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

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

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

for d in /home/*; do echo -n "$d: "; find "$d" 2>/dev/null | wc -l; done

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

האסטרטגיה השלישית היא לזהות את תת-הספריות שצורכות הכי הרבה יוד.

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

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

find /home/用户名/web/你的域名/public_html -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 | wc -l' \; | sort -n -r -k 2 | head -n 10

פקודה זו תפרט את 10 תיקיות המשנה המובילות שצורכות הכי הרבה קבצים.

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

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

הטיפ הרביעי הוא לבדוק את מגבלת המכסה באמצעות repquota.

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

repquota -a

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

שימו לב היטב לקטע "מגבלות קבצים" בפלט; העמודה "הקבצים שנעשה בהם שימוש" מציינת כמה קבצים היו בשימוש.

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

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

לסיכום, בואו נחבר את נקודות החקירה.

בואו נחזור לחבר שהרס את השרת באמצע הלילה בהתחלה.

הוא ביצע את ארבעת השלבים שתיארתי, החל מ-`df -i` כדי לאשר שה-inode אכן מלא.

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

לבסוף, בדיקת `repquota` אישרה שהוא אכן הגיע לגבול הקשיח.

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

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

ראשית, השתמשו בפונקציה `df -i` כדי להסתכל על ה-inode; ייתכן מאוד שהאמת מוסתרת בכרטיס האינדקס הזה שמעולם לא שמתם לב אליו קודם.

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