Sunday, February 28, 2010

Accurately Measuring GC Suspensions

כשבאים לנתח ביצועים של אפליקציית Managed, ורוצים להבין מה הם צווארי הבקבוק שעשויים להכשיל אותה בתרחישי עומס איתם היא אמורה להתמודד, אחד הפרמטרים החשובים שצריך לשים לב אליהם הוא מידת הזמן שהאפליקציה שלנו מבלה ב-GC. בשביל לדעת את זה, תמיד אפשר להריץ במקביל לאפליקציה את Perfmon  ולקבל ניתוח כללי של התנהגות ה-GC באפליקציה שלנו, כשהמדד העיקרי שנסתכל עליו בדרך כלל הוא אחוז ה-Time in GC.
התבוננת בנתונים האלה יכולים אמנם לתת לנו "מבט כללי" על השפעת ה-GC על ביצועי האפליקציה, אבל הוא פשוט לא מספיק בשביל לקבל תובנות מעמיקות יותר ולקשר תקיעות שנצפות בפרוסס ל-Collection'ים שיתכן והופעלו באותו הזמן. למשל, גם אם נראה שב-90% מהזמן אנחנו מבלים רק 2% ב-GC, זה עדיין לא אומר שלא יתכן מצב בו ברגע קריטי במערכת פתאום הוחלט להריץ Gen2 שתקע לנו את כל הפרוסס למשך של כ-200 מילישניות. מה שעשוי לגרום לנזק לא מבוטל אצל אפליקציות הרגישות למדי לתקיעות בלתי צפויות שכאלה. כל הרעיון הוא שה-GC לא גורם לתהליכים לעבוד יותר לאט, אלא הוא פשוט יכול לתקוע את כל הפרוסס לחלוטין. לכן הסתכלות נאיבית על גרף ה-Time in GC לא באמת אומרת לנו בצורה מובהקת מה הנזק האמיתי של כל GC במקרה הפרטי שלנו. אם נסתכל על הגרף, יתכן שנראה איזשהיא קפיצה "באזור הזמן" של התקיעה, אבל מאחר והרזולוציה הגבוהה ביותר של Perfmon עומדת על שנייה אחת, ואנחנו לא באמת יודעים באמת כמה זמן כל GC באזור השניה ההיא לקח, אין לנו דרך לקשר בצורה ישירה וברורה בין התקיעה "הכללית" שנצפתה בפרוסס, לבין Collection מסויים שיתכן וקרה או לא קרה באותו הזמן. מה גם, שלא תמיד פשוט לדאוג שבכל מקום שמריצים את האפליקציה ידאגו גם להריץ Collector'ים של Perfmon שידאגו לאסוף את הנתונים האלה בכל רגע נתון.

Posted via email from jasper22's posterous