שאלה למה לשחרר מטמון בלינוקס?


בשרתים שלנו יש לנו הרגל להפיל מטמון בחצות.

sync; echo 3 > /proc/sys/vm/drop_caches

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


81
2018-05-20 03:12




מצא את מי לשים את זה ולשאול אותו למה הוא עשה את זה. כפי שניחשת נכון, אין סיבה טובה לכך. - Michael Hampton♦
ניקוי באגים. זה בערך הכל. זה לא ממש לשחרר את כל RAM; זה טיפות מטמון, כפי שהשם מרמז, ובכך מקטין את הביצועים. - Michael Hampton♦
@ivcode אז אתה צריך למצוא ולתקן את הבעיה עם השרת הזה במקום לנסות למנוע את התנאים לגרום לזה. אם המכונית שלי נעצרה בכל פעם שעשיתי פנייה חדה ימינה, הימנעות מפניות ישרות חדה היא תיקון מחורבן. - David Schwartz
קשורים thedailywtf.com/Articles/Modern-Memory-Management.aspx בטענה חזקה זה רעיון רע. - Drunix
קשור, וכן תיאור שימושי של "הבעיה": לינוקס - Bill Weiss


תשובות:


אתה 100% נכון. זה לא מנהג טוב לשחרר RAM. זה כנראה דוגמה של מערכת פולחן המטען המערכת.


85
2018-05-20 04:59



+1 להזכיר את ניהול מערכת המטען. כל sysadmin מי לא יודע את המונח ואת מה זה אומר צריך להיות מפוטר. - Tonny
@Tonny: היינו נשארים ללא מחלקת מעבדה אז :( - PlasmaHH
כמו רוב האנושות, אני אוהב טענות חוצפניות עם הרבה אישור, אבל ציטוט או הנמקה היה להרוויח +1 של האני העליון שלי. - Aaron Hall
הסבר את ממשל הכתות, כמו גם את האמור לעיל, אם לא אכפת לך. אולי בעריכה עוקבת? אני עדיין מנע את ה- +1 שלי ...: P - Aaron Hall
"זה אפשרי כי למרות היישום שלך לא יכול להשתמש אלה RAM אבל לינוקס הוא במטמון אגרסיבי לתוך הזיכרון שלה, למרות היישום צריך זיכרון זה רגיל חינם חלק המטמון אבל מעדיף להתחיל להחליף." לא מאוד ספציפי. בפועל, ניהול זיכרון אינו מושלם, ויש לנו כפתור להפוך כאשר זה חוסר השלמות מופיע הוא דבר טוב. - Dan Pritts


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

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


62
2018-05-20 06:26



+1 להסבר למה זה רעיון רע. - Ogre Psalm33


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

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

לצטט מתוך תיעודYou

קובץ זה אינו אמצעי לשלוט על הצמיחה של הקרנל השונים   מטמון (inodes, dentries, pagecache, וכו '...) אובייקטים אלה   מחודשת באופן אוטומטי על ידי הקרנל כאשר הזיכרון נדרש במקום אחר   על המערכת.

שימוש בקובץ זה עלול לגרום לבעיות בביצועים. מאז זה משליך   אובייקטים במטמון, זה עלול לעלות כמות משמעותית של I / O ו CPU   לשחזר את האובייקטים ירד, במיוחד אם הם היו תחת שימוש כבד.   מסיבה זו, השימוש מחוץ לסביבת בדיקה או איתור באגים הוא   לא מומלץ.


34
2018-05-20 13:51



כמובן, בהתאם למה שאתה מנסה לעשות, אפילו אתחול מחדש מלא לא מספיק לנקות את המטמון בדיסק. - α CVn
"אובייקטים אלה מוחזרים באופן אוטומטי על ידי הקרנל כאשר הזיכרון נחוץ" היא מטרת התכנון אבל זה לא יכול להיות תמיד ההתנהגות בפועל. - Dan Pritts
@ DanPritts מה בדיוק גורם לך לחשוב שזה לא כך? - Joe
המקרה הברור הוא כאשר אתה רוצה לנקות את RAM כדי לאפשר את הקצאת יותר (שאינם trnsparent) trempages; מקרה אחר הוא אוסף שקוף אשפה ענקית עמודים (לראות את התשובה שלי / הערות במקום אחר על שאלה זו). אבל ההערה שלי נועדה למקרה הכללי. לפעמים האנשים שמפעילים את המערכת יודעים טוב יותר מהאנשים שעיצבו / יישמו אותה. לעתים קרובות, לא - זה מה התגובה שלהם מנסה להגן מפני. אני פשוט שמח - Dan Pritts


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

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

בסביבה שלי, ניחושים לינוקס טועים לעתים קרובות מאוד, ובתחילת הבורסות ביותר באירופה (סביב 0900 זמן מקומי) שרתים יתחילו לעשות דברים שהם עושים רק פעם ביום, צורך להחליף בזיכרון שהיה בעבר החליפו כי בכתב logfiles, דחיסת אותם, העתקת אותם וכו 'היה מילוי מטמון עד לנקודה שבה צריך היה להחליף את הדברים.

אבל האם השחרור מטמון הפתרון לבעיה זו? בהחלט לא. מה יהיה הפתרון כאן הוא להגיד לינוקס מה זה לא יודע: כי קבצים אלה סביר להניח שלא יהיה בשימוש יותר. זה יכול להיעשות על ידי יישום הכתיבה באמצעות דברים כמו posix_fadvise()או באמצעות כלי קו cmd כמו vmtouch (אשר יכול לשמש גם כדי לבדוק את הדברים כמו גם קבצי מטמון).

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

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


25
2018-05-20 19:46



כל היישומים בשרת שלי פועל על nohup. אולי nohup.out הוא להיות במטמון ולאכול את הזיכרון? - ivcode
@ivcode: זו יכולה להיות הסיבה, לבדוק איך nohup.out גדול הוא. אולי להשתמש vmtouch כדי להבין כמה זה במטמון. - PlasmaHH
יש לי עבודה cron cat /dev/null > path/nohup.out בכל 15 דקות כמו nohup.out גדל במהירות. אולי לינוקס הוא במטמון nohup.out גם אם אני מסיר את זה - ivcode
@ivcode אם אתה לא צריך את הפלט מ nohup אתה צריך לכוון את זה מחדש /dev/null. זה נשמע כאילו היו לך כמה sysadmins חסרי ניסיון מאוד עובד על המערכות שלך בשלב כלשהו. ראה stackoverflow.com/questions/10408816/... איך לכוון nohupהפלט של /dev/null - David Wilkins
למרות nohup.out מסומנת ב 15 דקות intervals, אם תהליך היישומים נהרג מסיבה כלשהי, nohup.out יהיה backedup באופן אוטומטי מתוך סקריפט אחר. ניסיתי vmtouch. זה כלי טוב מאוד - ivcode


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

דפים גדולים ב- Linux צריך לעתים קרובות defrag RAM כדי למצוא 2MB של זיכרון פיזי רציף להכניס לדף. שחרור כל המטמון הקובץ עושה את התהליך הזה קל מאוד.

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


16
2018-05-22 00:47



אני הצביעו על הצבעה על הדעה הקדומה מסדר הוא תגובות ירידה מטמונים. - Noah Spurrier
כמו כן, ביישומי HPC בצמתים גבוהים (1Tb), קריאה במספר קבצים גדולים גורמת לכמות גדולה של זיכרון שמור. מאחר ויישומי HPC רבים מבצעים את malloc של מאות GB, המערכת יכולה לדלוק במשך שעות כמו תהליכי הגירה לזוז נתחים זעירים של זיכרון מקוטע ללא פריים על פני NUMA צמתים לאחר שהמערכת מגיעה לזיכרון "זיכרון". גרוע מכך, שום דבר שאתה יכול לעשות ב Userland כדי לשחרר את המטמון למעט טריק המערכת לתוך הקצאת כל 2MB בלוקים זעירים זה יכול בבת אחת ואז שחרור, ומאפשרות defrag ענקית ואת היישומים לפעול כרגיל. - user1649948
+1 הפקודה ליצור דפים גדולים (sysctl -w vm.nr_hugepages=...) מסרב אפילו לעבוד אלא אם כן אני הראשון מטמון ירידה (Arch linux). - Aleksandr Dubinsky


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

משחרר משאבים

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

מה אוכל את הזיכרון?

אתה צריך לקבוע מה גורם הרבה לצריכת זיכרון שגורמת השמטת מטמונים נראה לעבוד. זה יכול להיגרם על ידי מספר כלשהו של תצורה גרועה או פשוט פשוט בשימוש שגוי תהליכים השרת. לדוגמה, בשרת אחד אני עדים ניצול הזיכרון מקסימום כאשר אתר מגנטו הגיע מספר מסוים של מבקרים בתוך 15 דקות מרווח. זה בסופו של דבר נגרמת על ידי Apache להיות מוגדר לאפשר תהליכים רבים מדי לרוץ בו זמנית. יותר מדי תהליכים, באמצעות הרבה זיכרון (Magento הוא חיה לפעמים) = החלפה.

שורה תחתונה

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


8
2018-05-20 15:16





לינוקס / m68k יש למעשה באג ליבה שגורם kswapd להשתגע ולאכול 100% מעבד (50% אם יש עוד משימה קשורה CPU, כמו חבילה בינארית ביבי אוטובוס - vulgo buildd - פועל כבר), אשר יכול (ביותר של הזמן, לא תמיד) להיות מקולקל על ידי הפעלת פקודה זו כל כמה שעות.

זה נאמר ... השרת שלך הוא כנראה לא m68k (Atari, Amiga, קלאסי Macintosh, VME, Q40 / Q60, Sun3) המערכת ;-)

במקרה זה, האדם שהכניס את השורות גם בעקבות כמה מפוקפק או, במקרה הטוב, ייעוץ מיושן, או קיבלתי את הרעיון על איך RAM צריך לשמש טועה (חשיבה מודרנית אכן אומר "זיכרון RAM חינם הוא מבוזבז" ומציע אחסון במטמון) , או "גילה" כי זה "מתקן" [sic!] בעיה אחרת במקום אחר (והיה עצלן מכדי לחפש לתקן הנכון).


4
2018-05-21 08:03



"באג kernel שגורם kswapd להשתגע" - איזה באג זה? - Ben
@ ראה זה פתיל (הודעה זו וכמה מעקב, שאחד מהם כולל ניחוש מהיכן הוא יכול להגיע) - mirabilos
אני נתקל בבעיה דומה (למרות שזה x86_64) והפתרון היחיד כרגע הוא להוריד מטמונים serverfault.com/questions/740790/... - Fernando
@ פרננדו יש לי "ירידה במטמון" cronjob על תיבת m68k גם כן - mirabilos