יום שבת, 7 בנובמבר 2009

פודקאסט מספר 42 - אוטו זבל...


היום אירחנו את גילי נחום מ- IBM לשיחה על פינוי אשפה (Garbage Collection)
  • גילי הציג את עצמו ומה הוא עושה ביום יום.
  • מה זה בכלל איסוף זבל ולמה צריך את זה.
  • כמה דימויים מ"חברה קדישא".
  • מה היה לפני GC. ואנשים שקשה להם "לשחרר".
  • מימושים של GC: ספירת קישורים, עצים ורשימות.
  • מה האתגרים במימוש GC ואיך לא "תוקעים" את התכנית.
  • בעיית "חירור" של זיכרון רציף.
  • דליפות פיזיות ולוגיות.
  • איך מוצאים דליפות זיכרון - האם יש כלים.
  • XM אמו - ומה זה בכלל.
  • זכרונות מסוגים שונים שאליהם מתייחס ה-GC.
  • בית התינוקות ובית גיל הזהב.
  • מדינויות של "מתי לנקות".
  • איך "רומזים" ל- GC לנקות את החדר.
  • OOME - זה רע.
  • מהו .PERM AREA.
  • עשינו קצת "גלישת עננים" וריכלנו על IBM.
היה כיף ותודה לגילי ול Cotendo.

הקובץ נמצא כאן
האזנה נעימה

6 תגובות:

  1. מספר דברים שכדאי לציין (סליחה אם פיספסתי).
    Also sorry for the english, the hebrew fonts are getting messed up.
    1. Interesting to mention the new G1 GC which has a revolutionized way to GCing. I expect it to solve problems we see in very large heaps.
    2. ArrayList is in many cases faster and memory prudent then LinkedList . If you need sequencial iteration then it saves you the comutation of the next list element and lavarages the principal of locality since the next node in the linked list is actually a yet another object which may be anywhare on the heap and the ArrayList keep them all close together (in the same array). the other issue is that the pointers/references also takes space, its especially bad in a 64bit machine where links are very expensive in spese.
    3. Very important to profile your serverside application at least once in a while to detect GC problems you might not be awhare of. I recommend using the GC log and tailing for the dreaded Full GC which results in a non responsive application. We use Scribe and/or collectd for that. Btw, even with a Cuncurent you may have the Full GC of death.
    4. Will be nice to emphisize the diferance between Throughput / Cuncurent / Parallel GCs and why they all have a good place in the toolbox (i.e. no magic bullet).
    5. Immutability of objects is very helpful for modern GCs!
    6. Escape analysis in the new JVMs (starting Java 6 Update 14) help a lot as well, so don't reference an object from the heap if you don't have to!

    השבמחק
  2. הי ישי, תודה על ההערות, נקודות טובות. אם תרצה להצרף לעוד הקלטה בנושא אתה יודע איפה למצוא אותי ;-)

    השבמחק
  3. תודה ישי!
    1. GC1 - לא הספקתי לקרוא הכל, אבל כן עלעלתי קצת כאן: http://java.sun.com/javase/technologies/hotspot/gc/g1_intro.jsp
    ראיתי שימוש בכל הליבות לצורך ה- GC (קיים), אלגוריתם דורות (קיים), וטענות לזמן איסוף יותר צפוי מראש (עדיין לא זמן אמת או זמן אמת רך כמו ה- Metronome GC).
    מה מגדיר אותו מהפכני? לא ראיתי בנצ'מקרים כלשהם. טוב, אני עוד אראה את המצגת שלו מ JAVAONE 2008.
    2. מעניין. מתי כן תמליץ להשתמש ב- LinkedList?
    3. אני בדרך כלל פותח את לוג ה- GC עם תוכנת GUI יעודית שמציגה את הנתונים בגרפים נאים + אזהרות על נתונים חריגים במיוחד (10 שניות GC למשל).
    משלי:
    למי שבא להתפרע, כדאי לבדוק את פרוייקט: Jikes RVM - שם גם אתם תוכלו לפתח אלגו' GC משלכם. או לשנות שורה בודדת ולקרוא לו מוד GC על שמכם.

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

    השבמחק
  4. Again, sorry for the English

    Ran, define a topic and lets do it

    Gili, I think it was a good podcast, I didn't intend to suggest it wasn't so.
    Actually I think it was better then the one I had, and yes - having a prepared agenda would make the podcasts better (at least for novices like me). I was in the JavaOne '08 presentation about G1 and got very impressed by the technology. I didn't try it in production yet since they did alert that its still "beta" and not recommended for production. I'll give it a try in one of our offline number crunching servers and have a post about my conclusions.
    2. I would almost say never unless there is a very interesting edge case. The perception of LinkedList performance benefits does not match reality (in most cases). Again, I can find some interesting edge cases but they are rare.
    3. I believe that any ops activity should be automated, i.e. ops without a system admin. That's why I hired an engineer to automate our ops. Opening the log and manually looking at it is good when the alarms are blowing off, not as a day to day activity. Every release may cause problems and looking at the logs of the GC few hours after the release to verify it looks good doesn't scale. Btw, I know you didn't mean that you open the log every release, just wanted to clarify a point :-)

    השבמחק
  5. באסה שאני לא מקבל עדכון על פוסטים חדשים כאן, מזל שחזרתי לבדוק.
    טוב לדעת לגבי הלינקד ליסט, זה מסוג האנטי פטרנס שהם גם אנטי אינטואיטיבים. בכל מקרה, בפעם הבאה שיעלה על דעתי להשתמש בזה אני אעמיק לחפור בנושא השלכות הביצועים טרם ההחלטה.
    אני מנתח לוגים של GC כחלק משלב בדיקות העומסים במהלך הפיתוח (אני כותב מוצר ולא מערכת עם התקנה בודדת).
    אם אתה מתכוון לכך שאתה בודק איך מתנהגת המערכת שאותה אתה כותב בשעות הראשונות לאחר הפרישה של הגרסה החדשה, אז זה זהה לבדיקות הידניות שאני מבצע.
    לגבי ניטור אוטומטי, לא יודע אם שווה לפתח דבר כזה בעצמך, אני יודע שיש תחום שלם של מוצרים לניטור סביבת הייצור של ארגוני IT שהממון נמצא בכיסם, למשל המוצר של willly, שמסוגל (או לפחות מתיימר) לתת התראות בדיוק על נושא צריכת זכרון וביצועי GC של פרוססי JAVA.
    בעבר כתבתי סקריפט לזיהוי דליפות זכרון: תוך כדי בדיקת עומסים אני מייצר DUMP זכרון טקסטואלי (יש דבר כזה) ואז סופר את כמות האובייקטים (אלה המועדים לנזילה) אל מול הכמות התיאורטית שאמורה להתקיים בסטדי-סטייט של המערכת. נטשתי את זה בשלב כלשהוא. זה לא הצדיק את ההשקעה.

    השבמחק
  6. Hey Gili,

    I have the luxury of owning the installation environment of the application I make. The previous comment assumes about owning the full environment and that the application has high transaction count and the usage patterns are changing rapidly and unexpectedly, i.e. no steady state. Moreover, the application is continuously updated in production. For example we have a five minute release cycle and dozens of production code pushes a day.

    All that said, there are very few companies and applications like that (compared to the grand scheme of things). Continues monitoring may not be relevant to applications of other natures.

    Monitoring such system's GC (full GC or time spent) is actually very easy since all of tools are in the open source. Dump the logs into file, pipe and filter them through a script or hadoop to match keywords or count time -> done. If its a distributed system they can be piped to a hub using Scribe.

    השבמחק