אתה משתמש בדפדפן מיושן. יתכן והאתר הנוכחי יוצג באופן שגוי, כמו כן אתרים אחרים ברשת.
אנא שדרג את הדפדפן או השתמש בדפדפן חילופי.
אנא שדרג את הדפדפן או השתמש בדפדפן חילופי.
שימוש בxmx מונע oom killer?
- פותח הנושא TakeCtrl
- פורסם בתאריך
יש לי את הdmesg מ OOM
[55796.674830] Killed process 1831 (java) total-vm:10203812kB, anon-rss:7805060kB, file-rss:0kB
[75956.949679] Killed process 14681 (java) total-vm:10199932kB, anon-rss:7852576kB, file-rss:0kB [75957.053241] Killed process 1658 (java) total-vm:4236880kB, anon-rss:46708kB, file-rss:0kB [76366.957083] Killed process 2628 (java) total-vm:10215660kB, anon-rss:7894140kB, file-rss:0kB [76367.071981] Killed process 2034 (java) total-vm:4103752kB, anon-rss:25520kB, file-rss:0kB [76469.704886] Killed process 5376 (java) total-vm:10196872kB, anon-rss:7844800kB, file-rss:0kB [76761.420596] Killed process 7400 (java) total-vm:10219820kB, anon-rss:7892404kB, file-rss:0kB [76761.842409] Killed process 5202 (java) total-vm:4103752kB, anon-rss:22860kB, file-rss:0kB [231505.019515] Killed process 9367 (java) total-vm:10134684kB, anon-rss:7804720kB, file-rss:0kB [232227.708168] Killed process 15862 (java) total-vm:10125300kB, anon-rss:7898536kB, file-rss:0kB [232227.868810] Killed process 9000 (java) total-vm:4236880kB, anon-rss:12244kB, file-rss:0kB [232771.681270] Killed process 16321 (java) total-vm:10207732kB, anon-rss:7900632kB, file-rss:0kB
אנחנו תמיד אוכלים אותה כשאיזה שרת שולח לנו DOM ב Soap יחד עם כמה תמונות בattachments.
[ 145.614194] Killed process 1503 (java) total-vm:10264060kB, anon-rss:7919392kB, file-rss:0kB [ 145.897401] Killed process 1202 (java) total-vm:4037188kB, anon-rss:3856kB, file-rss:0kB [55796.674830] Killed process 1831 (java) total-vm:10203812kB, anon-rss:7805060kB, file-rss:0kB
[75956.949679] Killed process 14681 (java) total-vm:10199932kB, anon-rss:7852576kB, file-rss:0kB [75957.053241] Killed process 1658 (java) total-vm:4236880kB, anon-rss:46708kB, file-rss:0kB [76366.957083] Killed process 2628 (java) total-vm:10215660kB, anon-rss:7894140kB, file-rss:0kB [76367.071981] Killed process 2034 (java) total-vm:4103752kB, anon-rss:25520kB, file-rss:0kB [76469.704886] Killed process 5376 (java) total-vm:10196872kB, anon-rss:7844800kB, file-rss:0kB [76761.420596] Killed process 7400 (java) total-vm:10219820kB, anon-rss:7892404kB, file-rss:0kB [76761.842409] Killed process 5202 (java) total-vm:4103752kB, anon-rss:22860kB, file-rss:0kB [231505.019515] Killed process 9367 (java) total-vm:10134684kB, anon-rss:7804720kB, file-rss:0kB [232227.708168] Killed process 15862 (java) total-vm:10125300kB, anon-rss:7898536kB, file-rss:0kB [232227.868810] Killed process 9000 (java) total-vm:4236880kB, anon-rss:12244kB, file-rss:0kB [232771.681270] Killed process 16321 (java) total-vm:10207732kB, anon-rss:7900632kB, file-rss:0kB
אנחנו תמיד אוכלים אותה כשאיזה שרת שולח לנו DOM ב Soap יחד עם כמה תמונות בattachments.
כשמופעל ה-OOM זה מאוחר מדי
 
אתה צריך לבצע מעקב אחר צריכת הזכרון לפני שהבעיה מתרחשת.
 
אם מדובר בפעולה נקודתית שבבת אחת מעלה את צריכה הזכרון - או שתבצע אופטימיזציה שלה בצורה נקודתית (בחו בדיוק על מה מתבזבז הזכרון ושפר את זה) - או שתצטרך להגדית אל כמות הזכרון שאתה נותן ל-VM.
 
אתה צריך לבצע מעקב אחר צריכת הזכרון לפני שהבעיה מתרחשת.
 
אם מדובר בפעולה נקודתית שבבת אחת מעלה את צריכה הזכרון - או שתבצע אופטימיזציה שלה בצורה נקודתית (בחו בדיוק על מה מתבזבז הזכרון ושפר את זה) - או שתצטרך להגדית אל כמות הזכרון שאתה נותן ל-VM.
מתחיל להיות.. אני קורא במקביל...
הקטע של ההגדרה האוטומטית זה גם משהו שיצרו לפני ובדרך כלל לא גרם בעיות.
https://plumbr.eu/blog/memory-leaks/why-does-my-java-process-consume-more-memory-than-xmx
הקטע של ההגדרה האוטומטית זה גם משהו שיצרו לפני ובדרך כלל לא גרם בעיות.
https://plumbr.eu/blog/memory-leaks/why-does-my-java-process-consume-more-memory-than-xmx
BlackAdder1
New member
כמה דברים שיכןלים לעזור
1. מעבר לכמות הזיכרון בפועל, התקורה של ה GC מאוד משמעותית - האם יש גם הקצאה אוביקטים חדשים באופן אינטנסיבי, או שמדובר בנתנונים סטטיים יחסית?
אם מדובר בהקצאה דינמית כדי לשקול object pooling או off heap memory
2. כדאי לבדוק מה תופס מקום בזכרון - אם מדובר באמת בקובץ XML גדול יש סיכוי משמעותי שיש הרבה strings משוכפלים - כדאי לבצע caching, או לוותר עליהם לגמרי (לתרגם את קובץ ה XML למבנה נתונים רגיל - בו לא נשמרים שמות שדות, ובו ערכי השדות נשמרים בצורה יעילה.
1. מעבר לכמות הזיכרון בפועל, התקורה של ה GC מאוד משמעותית - האם יש גם הקצאה אוביקטים חדשים באופן אינטנסיבי, או שמדובר בנתנונים סטטיים יחסית?
אם מדובר בהקצאה דינמית כדי לשקול object pooling או off heap memory
2. כדאי לבדוק מה תופס מקום בזכרון - אם מדובר באמת בקובץ XML גדול יש סיכוי משמעותי שיש הרבה strings משוכפלים - כדאי לבצע caching, או לוותר עליהם לגמרי (לתרגם את קובץ ה XML למבנה נתונים רגיל - בו לא נשמרים שמות שדות, ובו ערכי השדות נשמרים בצורה יעילה.
אין לי הרבה שליטה על הxml (כלומר בכלל לא) ...
הpayload מגיע משרת חיצוני של חברה חיצונית בתור soaprequest אחד גדול כולל attachments , אז אכלנו ואת כל הבלגן אז זה מאוחר מדי.
 
בנוסף לכך יש לנו dom משלנו (כל קובץ הקונפיגורציה) ששוקלים להפוך אותו ל Jaxb (אבל יש רק בעיה "קטנה" אחת , כל שינוי סכמה דהיינו שינוי שם שדה, הורדת שדה, משכפלים את כל הסכמה לסכמה חדשה עם מספר גרסה חדשה) ואז קלט ופלט API עם גרסאות שונות עוברות שרשרת הסבה מגרסה לגרסה. jaxb יכריח אותנו ליצור גם ערימת classes נפרדת לכל סכמה (ולא, לא משתמשים בnamespace) . שיקול נוסף שחושבים עליו הוא לעבור לDB.
הנחמה היחידה שלי שגרסה חדשה לשרת החיצוני תביא לנו את זה כבר בjson וattachment יהיו אופציונליים.
יש לנו פגישות wishlist שבהן הצעתי להפריד את השרת שלנו לחלק שרק מחזיק data שאולי יהיה clusterd באיזה ehcache או משהו דומה , וחלק שרק עושה חישובים אבל החלק הזה דורש באמת גישה תכופה לdata (כגון המטריצות שהזכרתי קודם).
 
אבל כל זה בעתיד, כי עכשיו יש לנו לקוח שOOM פועל אצלו כנראה, בדקתי vm.overcommit אבל הוא מכוון ל-0. האפשרות היחידה שאני חושב עליה כרגע היא להקטין ידנית את xmx ל6 GB ולהישאר עם הגדרה של 8GB במכונה ואז אמור להיות יותר overhead לשאר הזיכרון שJVM אולי ירצה . ואז לנסות לבצע סינכרון שוב.
 
אגב, בדרך כלל רוב הלקוחות שלנו עובדים עם 4GB, מקרים נדירים היו 8GB (עקב טעות בכתיבת מדריך דרישות מערכות יש לקוחות שהתחילו לעבוד עם 16 GB ואז הGC באמת מתחיל להתקע, לכן אנו ממליצים להתחיל תמיד עם 4GB ורק אם יש בעיות לעבור ל8GB).
 
הpayload מגיע משרת חיצוני של חברה חיצונית בתור soaprequest אחד גדול כולל attachments , אז אכלנו ואת כל הבלגן אז זה מאוחר מדי.
 
בנוסף לכך יש לנו dom משלנו (כל קובץ הקונפיגורציה) ששוקלים להפוך אותו ל Jaxb (אבל יש רק בעיה "קטנה" אחת , כל שינוי סכמה דהיינו שינוי שם שדה, הורדת שדה, משכפלים את כל הסכמה לסכמה חדשה עם מספר גרסה חדשה) ואז קלט ופלט API עם גרסאות שונות עוברות שרשרת הסבה מגרסה לגרסה. jaxb יכריח אותנו ליצור גם ערימת classes נפרדת לכל סכמה (ולא, לא משתמשים בnamespace) . שיקול נוסף שחושבים עליו הוא לעבור לDB.
הנחמה היחידה שלי שגרסה חדשה לשרת החיצוני תביא לנו את זה כבר בjson וattachment יהיו אופציונליים.
יש לנו פגישות wishlist שבהן הצעתי להפריד את השרת שלנו לחלק שרק מחזיק data שאולי יהיה clusterd באיזה ehcache או משהו דומה , וחלק שרק עושה חישובים אבל החלק הזה דורש באמת גישה תכופה לdata (כגון המטריצות שהזכרתי קודם).
 
אבל כל זה בעתיד, כי עכשיו יש לנו לקוח שOOM פועל אצלו כנראה, בדקתי vm.overcommit אבל הוא מכוון ל-0. האפשרות היחידה שאני חושב עליה כרגע היא להקטין ידנית את xmx ל6 GB ולהישאר עם הגדרה של 8GB במכונה ואז אמור להיות יותר overhead לשאר הזיכרון שJVM אולי ירצה . ואז לנסות לבצע סינכרון שוב.
 
אגב, בדרך כלל רוב הלקוחות שלנו עובדים עם 4GB, מקרים נדירים היו 8GB (עקב טעות בכתיבת מדריך דרישות מערכות יש לקוחות שהתחילו לעבוד עם 16 GB ואז הGC באמת מתחיל להתקע, לכן אנו ממליצים להתחיל תמיד עם 4GB ורק אם יש בעיות לעבור ל8GB).
 
BlackAdder1
New member
הכוונה לא לשנות את ה XML, אלא את הייצוג שלו בזיכרון
אה.. זה אנחנו עושים גם ככה בקובץ קונפיגורציה...
כלומר יש לנו ערימות classes שעושות , marsheling ו, unmarsheling (בדיוק לאחרונה תפסיתי קוד שהפוך את כל הxml הזה לstring, עושה 3 פעמים replaceall ל \t\r\n ומחזיר את זה חזרה לDOM ,ההערה שם אמרה כי schema validator נוטה להפיל את זה לפעמים מסיבה בלתי ברורה.
 
אבל אין לי מה לעשות עם מה שמגיע מבחוץ.
 
מה שמעניין אותי במידה הזה הקטע של In memory db , האם במידה ואנחנו לא משתתמשים בDB רגיל יש מצב להשתמש בכזה דבר?
 
כלומר יש לנו ערימות classes שעושות , marsheling ו, unmarsheling (בדיוק לאחרונה תפסיתי קוד שהפוך את כל הxml הזה לstring, עושה 3 פעמים replaceall ל \t\r\n ומחזיר את זה חזרה לDOM ,ההערה שם אמרה כי schema validator נוטה להפיל את זה לפעמים מסיבה בלתי ברורה.
 
אבל אין לי מה לעשות עם מה שמגיע מבחוץ.
 
מה שמעניין אותי במידה הזה הקטע של In memory db , האם במידה ואנחנו לא משתתמשים בDB רגיל יש מצב להשתמש בכזה דבר?
 
BlackAdder1
New member
זה חלק מועד לפורענות
הרבה פעולות שמרגישות "זולות" בעבודה רגילה הופכות לקריטיות כשמדובר בכמות אוביקטים גדולה / הקצאה ושחרור אינטנסיביים.
דברים פשוטים יחסית שאפשר לבצע (אם רלוונטיים)
החלפת strings קבועים משוכפלים לעותק בודד (cache)
הימנעות מהחזקת כל ה XML בזכרון אלא לקרוא אותו הדרגתית, ולשמור בזכרון רק את האובייקט הסופי
קריאת הקובץ תוך שימוש ב string buffer במקום strings הדורשים הקצאה מחדש.
לניתוח יותר מפורט, כדאי להשתמש בפקודה jmap היא מאפשרת להוציא היסטוגרמה של צריכת זכרון לפי אובייקט (מאוד בסיסי, אבל עדיין מאוד שימושי) וגם dump מלא של הזכרון אותו ניתן לנתח בכלים חיצוניים (http://www.eclipse.org/mat) ולמעשה לראות את כל מבנה הזיכרון בחתכים שונים
in memory db הוא לא קשור ל DB - ולעיתים גם "מתנהג" באופן שונה (נניח כמו hashtable) אבל שים לב שמהירות הגישה בד"כ יותר נמוכה. היתרון העיקרי שלו הוא שהוא לא עובר GC (אבל מצד שני נדרש לנהל עצמאית את הזכרון)
הרבה פעולות שמרגישות "זולות" בעבודה רגילה הופכות לקריטיות כשמדובר בכמות אוביקטים גדולה / הקצאה ושחרור אינטנסיביים.
דברים פשוטים יחסית שאפשר לבצע (אם רלוונטיים)
החלפת strings קבועים משוכפלים לעותק בודד (cache)
הימנעות מהחזקת כל ה XML בזכרון אלא לקרוא אותו הדרגתית, ולשמור בזכרון רק את האובייקט הסופי
קריאת הקובץ תוך שימוש ב string buffer במקום strings הדורשים הקצאה מחדש.
לניתוח יותר מפורט, כדאי להשתמש בפקודה jmap היא מאפשרת להוציא היסטוגרמה של צריכת זכרון לפי אובייקט (מאוד בסיסי, אבל עדיין מאוד שימושי) וגם dump מלא של הזכרון אותו ניתן לנתח בכלים חיצוניים (http://www.eclipse.org/mat) ולמעשה לראות את כל מבנה הזיכרון בחתכים שונים
in memory db הוא לא קשור ל DB - ולעיתים גם "מתנהג" באופן שונה (נניח כמו hashtable) אבל שים לב שמהירות הגישה בד"כ יותר נמוכה. היתרון העיקרי שלו הוא שהוא לא עובר GC (אבל מצד שני נדרש לנהל עצמאית את הזכרון)
גם לא כדאי להפוך attachemnt לString base 64 ולשמור אותו בDOM
כמו שראיתי שעשינו , יש מצב שזה עדיין בגרסה שנדפקת בOOM.
בנוגע לקריאות קבצים אני משתדל להמנע מלעשות משהו ידני ולעבור לIOUtils של commons. אני מניח שאתה מתכוון לpull parsing. אם כי אני לא בטוח שזה יתאים לתשתית שלנו, יש לנו מעין adapters לכל אובייקט בschema ותת אובייקט שהופכים אותו לdom ול אובייקט חזרה. יש לנו גם מצבים של שמירה אוטומטית מהאובייקט חזרה ל xml, שיכולים לקרות כל 30 שניות.
 
אני מכיר את jmap ואת map, השתמשתי בהם בעבר, כולל memory leak report וגם כששמנו -heapdumpOnOutOfMemroy אבל הצרה שזה לא קורה כאן, ואפשר להשתמש בjmap רק כאשר יש לך jdk שלם. זה לא שיש לי כלי שאומר בהגיע Heap dump לגודל מסויים תשתמש בjmap
כמו שראיתי שעשינו , יש מצב שזה עדיין בגרסה שנדפקת בOOM.
בנוגע לקריאות קבצים אני משתדל להמנע מלעשות משהו ידני ולעבור לIOUtils של commons. אני מניח שאתה מתכוון לpull parsing. אם כי אני לא בטוח שזה יתאים לתשתית שלנו, יש לנו מעין adapters לכל אובייקט בschema ותת אובייקט שהופכים אותו לdom ול אובייקט חזרה. יש לנו גם מצבים של שמירה אוטומטית מהאובייקט חזרה ל xml, שיכולים לקרות כל 30 שניות.
 
אני מכיר את jmap ואת map, השתמשתי בהם בעבר, כולל memory leak report וגם כששמנו -heapdumpOnOutOfMemroy אבל הצרה שזה לא קורה כאן, ואפשר להשתמש בjmap רק כאשר יש לך jdk שלם. זה לא שיש לי כלי שאומר בהגיע Heap dump לגודל מסויים תשתמש בjmap
שווה לבדוק גם ballooning
אני מקווה שאני לא מטעה, אבל שווה לבדוק שהמכונה לא היתה ballooned ברגע שאותו ה - payload הגיע. זה קורה מדי פעם בסביבות VM, ואז אפשר להגיע למצב בו למכונה מסוימת יש בפועל הרבה פחות זכרון ממה שהוקצה לה, ואז spike רגעי בצריכה יכול לגרור OOM.
ניתן לראות זאת באחת הלשוניות של ה VM manager. אבל בכל מקרה שווה לנתח את ההתנהגות של המוצר בטרנזאקציה הספציפית הזו כפי שהציעו למעלה...
אני מקווה שאני לא מטעה, אבל שווה לבדוק שהמכונה לא היתה ballooned ברגע שאותו ה - payload הגיע. זה קורה מדי פעם בסביבות VM, ואז אפשר להגיע למצב בו למכונה מסוימת יש בפועל הרבה פחות זכרון ממה שהוקצה לה, ואז spike רגעי בצריכה יכול לגרור OOM.
ניתן לראות זאת באחת הלשוניות של ה VM manager. אבל בכל מקרה שווה לנתח את ההתנהגות של המוצר בטרנזאקציה הספציפית הזו כפי שהציעו למעלה...
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.