September 2009 - Posts
English: how to find what can make your IIS server 100% crazy, and fix it. debugging high CPU usage by w3wp.exe with Microsoft's IIS debugging tools.
לעיתים נתקלים בשרת ש"נחנק" ומגיע ל-100% ניצולת מעבד. כמה רעיונות בסיסיים להתחלת פיתרון בבעיה.
במקרה כזה דפים מגיבים באיטיות, ומדי פעם נתקעים עם שגיאות כגון Service Unavailable או Server too busy.
1. מה חונק את השרת?
Ctrl + Alt + Esc יפעיל את מנהל המשימות. נמיין את "תהליכים" ונחפש מי מתעלל בשרת. בדרך כלל זה יהיה w3wp.exe, (ב-IIS5 זה היה אאל"ט dllhost.exe), אבל ממש לא תמיד.
זה יכול להיות גם מסד נתונים (mysqlnt.exe או sqlsrvr.exe ב-MySQL או SQL Server בהתאמה), אבל לא נדון בבעיה הזו הפעם (בעבר כתבתי על זה בקצרה, ובהמשך אדון בזה).
2. זיהוי האתר הגורם לבעיה
אחרי שווידאנו שהבעיה היא אכן w3wp.exe, נתחיל לבדוק מה קורה.
ראשית - יש להפריד כל אתר במערכת ל-Application Pool נפרד, ועכשיו נחכה לתקיעה הבאה. כשזו תקרה - "נרצח" את התהליך ונראה איזה אתר בדיוק זרק Service Unavailable. זה האתר הבעייתי.
3. איתור הדף הגורם לבעיה, שאת זה עושים עם IIS DebugDiag שאותו מורידים מכאן.
יש שם אשף קטן וקל להבנה שבו מחפשים את התקיעה ונותנים לו לזהות לבד, או לארוב ולבקש "DUMP" עכשיו.
את השלב הבא עדיף לעשות על המחשב הפרטי שלכם: העתיקו את תוצאות ה-DUMP מהתיקיה
C:\Program Files\DebugDiag\Logs
למחשב אחר, התקינו גם שם את הכלי והשתמשו באחד הסקריפטים המגיעים איתו, אלו שמיועדים לטפל בבעיות נפוצות.
בטאב Advanced Analysis תוכלו לבחור קבצי נתונים (תבחרו את ה-DUMPים מקודם) ולבחור תוכנית חיפוש.
העבודה תיקח הרבה מאוד זמן, זה בסדר.
צריך קצת ידע כדי לנתח את התוצאות, אבל זו בהחלט התחלה יעילה לאיתור הרכיב הבעייתי, ולמחשבה מה ניתן אחר כך לעשות איתו.
ועוד טיפ אחד קטן: הקפידו להגדיר Timeout נמוך (לא יותר מ-9-10 שניות) ברמת ASP/ASP.net, על מנת שהדף שתוקע אותכם יפול על Timeout לפני שהכל יפול על ניצולת CPU חריגה.
אם יש צורך, ניתן להחריג מהכלל הזה תיקיה או קובץ בודד.
עוד מומלץ (לאחר מחשבה על רכיבי האפליקציה ולא בצורה "עיוורת") להגדיר תחת Application Pools, מגבלה של 5-6 שניות על 100% ניצולת CPU, שלאחריה יבוצע Recycle, ויש עוד כלים רבים נוספים שיוסיפו לבריאות השרת שלכם.
נושא הביצועים בתחום ה-Web מורכב הרבה יותר משניתן לתאר, והכרות עמוקה עם התחום הזה, היא חובה של כל ראש צוות ומתכנת. מי שלא מכיר את התחום - חזקה עליו שיכיר אותו בדלית ברירה ועדיף שלא בשעות הלילה המאוחרות כשהוא חולם על הכרית והמיטה.
מבחר הפיתרונות שקיים היום רחב למדיי, והיכולת להתמודד ולהכיר את הפיתרון הטוב ביותר (מה שמנוגד לא אחת לקלות הפיתוח שמבטחיחים רכיבי ASP.NET שונים) היא מורכבת.
בהצלחה !
עוד לקריאה:
Timeout בסביבת ייצור (עיינו גם בתגובות!)
בעיות ופתרונות בשימוש ב-OutputCache
לפני כשנתיים כתבתי על מודם סלולארי סלולרי לאחר שהשתמשתי בו (בקושי רב) ביישוב החרב חומש, ותיארתי בקצרה את ייתרונותיו ומגבלותיו.
כמה דברים השתנו מאז, ולכן החלטתי להעתיק את המדריך המקורי, תוך שכתוב והתאמה למצב שנתיים אחר כך.
קריאה מהנה.
1. חבילה
הסיפור הזה יהיה יקר מדי בלי חבילה, אבל החבילות עצמן לא יקרות כשהיו.
חבילה של 5G בחודש מספיקה למי שמשתמש במודם הסלולארי כחיבור משני לרשת, ללא הורדת סרטים וכו'.
המחיר: 50-100 שקל בחודש, תלוי איפה ובאילו תנאים.
2. מגבלות קליטה
החיבור הנפוץ הוא דור שלישי/דור שלישי וחצי, ששטח הכיסוי שלו כולל את רוב שטח היישובים בארץ ישראל המערבית.
מקומות חסרי קליטה לדוגמא: צומת ה-T (לכיוון בית אל) וואדי חרמיה על כביש 60, בסיס גדנ"ע צלמון, חומש, שא נור (באחרון אין כיסוי בכלל, גם לא דור שני).
בבסיסי צה"ל רבים וב"חורים"נוספים נתקלתי בכיסוי דור שלישי בלבד (UTMS - עד 340Kbps), מה שפוגע בביצועים אבל עדיין אפשרי לעבודה.
בקיצור - כבישים הרריים, עם דגש חזק על אלו של יהודה ושומרון וצפון הארץ. בשפלה כמעט ולא נתקלתי בבעיות כיסוי.
על כביש 60 בדרך ליישוב החרב חומש, כאן אין קליטה בכלל. האנטנות של Orange הקרובות ביותר ממומקות ביישוב שבי שומרון המוסתר על ידי ההרים.
3. מגבלות הרשת
א. מהירות - דור 3.5 מבטיח בערך עד 1.5-2Mbti, בפועל - הגעתי בדרך כלל לסביב ה-100-120KBps לשניה משרתי HTTP. דור שלישי UTMS (כאמור - נפוץ בבסיסי צה"ל) הוא בקצבים של עד 380Kbps. כשמהירויות ההורדה האפקטיביות בפועל משרתי HTTP הן סביב 32-33KBps, בתנאים טובים הגעתי לסביבות ה-46KBps שזה פחות או יותר המקסימום.
ב. שיהוי (Delay) מטורף - 200-600ms הוא זמן התגובה של פינגים לארץ בדרך כלל. בדור שני המצב גרוע בהרבה ומגיע לעד שניה וחצי.
דור 3.5 לא שינה דבר בהקשר הזה.
ג. פרוקסי - בעיה נוספת עבור מפתחי Web היא העובדה (אותה ניתן לגלות למי שקצת מבין) שישנו שרת פרוקסי שקוף המופעל על ידי החברות הסלולאריות, ששומר תמונות וקבצים סטטיים למשך כיומיים.
תקלה דחופה שתיקנת - אתה לא יכול לבדוק את הקובץ העדכני.
ד. שימוש בכתובות IP פנימיות - חוסם את האפשרות להתחבר לרשתות מרוחקות המשתמשות באותם הטווחים.
בסלקום הבנתי שהיום המצב שונה, אבל לא מידיעה אישית.
4. פיתרונות יצירתיים
כך תשפרו את הביצועים בחיבור הזה:
א. הגדלת מספר החיבורים בו זמנית של IE מ-2 (ברירת המחדל) ל-10. משפר את הביצועים בעשרות אחוזים. במקום להוריד 2 תמונות במקביל (ויש הרי שיהוי מטורף), הוא מוריד 10 במקביל.
ב. התחברות ב-VPN או SSL VPN (עדיף!) ושימוש בפרוקסי הנמצא ברשת אחרת (שימו לב לטווח הכתובות שבשימוש הרשת המרוחקת), יעקוף את בעיות ה-Cache בפרוקסי של הספקית.
ג. לדעת לבחור אתרים שכתבו HTML נקי וקצר, ולא מערכות מבוססות Community Server או האתרים הישראליים הפופולאריים (YNET, NRG) שאליהם אי אפשר להיכנס בכלל בחיבור הזה בתנאי שדה.
אתר חדשות כמו ערוץ 7 למי שתהה - עובד חלק, וכך גם אתרים שמשקל דפי ה-HTML שם הוא עד כ-50KB.
English: Some Tips for bypass Query Cache problems.
First code: simple QueryCache
Second code: Add to admin section on the website, and flush cache for URL
Last Code: how to force Proxies/Browsers to not store cached content, and return to origin server.
I used this technique for set long-time OutputCache, and clear it manually when I know that content changed.
In Hebrew I explain why Query Cache fro long times is bad, and why Cache Dependencies is bad and expensive (especially SQLCacheDependency on heavy SQL Server), but often useless.
אחת הבעיות הקשות (אך החיוביות) איתם מתמודדים מנהלי פרוייקטים, או מתכנתים בודדים, היא צמיחה חיובית של נפח הפעילות במערכת שלהם, מה שגורר עליה בעומס ובניצולת המשאבים, תגובה איטית של האתר, וכו' וכו'
הפיתרון הפשוט לחלק נרחב מהבעיות הוא שימוש ב-Cache עם טיימר, אלא שהפיתרון הזה רחוק מלהיות יעיל.
- באתר חדשות, Cache למשך דקה הוא בלתי נסבל כשיש פיגוע
- הפיתרון לא רלוונטי לדפים בסגנון פורומים, רכיכי Ajax שונים ורכיבים דינאמים אחרים
ניקח למשל דף של כתבת חדשות. דף ללא רכיבים מותאמים ללקוח, רק כותרת, תוכן, תקציר, תאריך (תמונות...), תגובות וכו'
לדף הוגדר OutputCache בסיסי של ASP.NET:
<%@ OutputCache VaryByParam="*" Duration="300" %>
מגיע עורך חדשות, משכתב את הכתבה ומרגע זה עד לעדכון באתר "יוצאת נשמתו". המצב בלתי נסבל בעולם בו זמני תגובה שלחדשות נמדדים בדקות.
הפיתרון הפשוט הוא לקצר את זמני התגובה של ה-Cache (מחזיר את הבעיה המקורית).
הפיתרון המעט יותר מתוחכם הוא להוסיף תלויות (Response.AddCacheDependency) בקבצים או אפילו בSQL.
הפיתרון הזה בסדר עד בעייתי כשמדובר במערכת קבצים, ורע כשמדובר ב-SQL, שעלות הבדיקה אם "פקע" הקאש היא יקרה למדי, במיוחד כשידוע לנו שה-DB הוא הרכיב היקר ביותר באפליקציה בד"כ.
הפיתרון שאני אוהב להשתמש בו, כולל הוספת השורה הבאה במנגנון הניהול של האתר, על כל הדפים המושפעים:
HttpResponse.RemoveOutputCacheItem(sURL)
גם הפיתרון הזה לא חף מבעיות, מכיוון ששרתי Proxy בדרך מחזיקים את המידע הישן, ולא יעדכנו את גולשיהם במידע החדש שהתעדכן.
בנוסף - במקרה של עומס, אם הדף עדיין לא בוצע, השרת "יתקע" באלפי בקשות זהות
הפיתרון לבעיה הזו גם הוא פשוט יחסית. פשוט להוסיף בדף:
Response.Cache.SetCacheability(HttpCacheability.ServerAndNoCache)
גם זה לא פותר את כל הבעיות, אבל זו התחלה טובה יותר. שאר הפיתרונות הם כבר יותר מכווני אפליקציה ותלויות שונות (SQL,CDN) שרלוונטיות לכל הסיפור הזה.
בהצלחה!
לקריאה נוספת:
GetFromCache: פונקציה לפישוט שמירת משאבים ב-Cache, כולל המתנה עד שדף אחר ישמור את התוצאות ב-Cache.
שימוש בפרוקסי הפוך לשיפור ביצועים
כי תעביר אתספלורר שש מן הארץ
(שיבוש של תפילת עמידה לר"ה ויו"כ)
שנה טובה, שנה שבה ירדו מחירי הקוים עם קצב העלאה גבוה, שנה שבה נבנה יותר בפחות זמן ונתמודד עם פחות תקלות, שנה שבה סוף סוף, יועבר אקספלורר 6 הארור לעולם האמת.
שנה שבה בכל תחומי חייכם, יתגשמו כל משאלות ליבכם לטובה!
תכלה שנה וקללותיה, תחל שנה וברכותיה!
משה.
ערוץ 7 - מחלקת הפיתוח
www.inn.co.il / www.israelnn.com