הבאג שנלכד

מאז שעברתי לשרת החדש, היו לי בעיות עם שרת האפאצ'י: לפעמים הוא פשוט הפסיק לענות לבקשות, וחזר לעצמו רק אחרי restart.
בהתחלה לא היה לי ברור מה גורם לזה. חקרתי איך אפשר לראות מה עושה האפאצ'י בזמן שהוא רץ, וגיליתי את mod-status, שמאפשר לדעת מה עושה כל Worker באפאצ'י, ועוד כמה דברים שימושיים.
חיכיתי בסבלנות שהבעיה תופיעה שוב, וכשהיא קרתה אחרי כמה ימים – גיליתי כמובן שאני לא יכול לגשת לURL של mod-status בגלל הבעיה.
הצעד הבא היה לכתוב סקריפט קטן שידגום את הstatus של האפאצ'י כל שתי דקות וישמור את התשובה לקובץ.
אחרי כמה ימים הבעיה שוב קרתה והפעם ראיתי שרוב הWorkerים בשרת היו עסוקים בלנסות לדבר עם trac, שלא ממש ענה בגלל איזו שהיא בעיה עם בסיס הנתונים שלו.
פניתי לקבוצת הדיון של מפתחי trac, והם הציעו שאני אשדרג את sqlite (שהוא בסיס הנתונים שtrac משתמש בו ברוב ההתקנות), וגם ביקשו דברים שדורשים די הרבה זמן – כמו לקמפל את mod-wsgi עם מידע דיבאג, ולהתחבר אליו עם gdb ברגע שהעסק תקול כדי לראות מה הוא עושה.
שידרגתי, וכמובן שהבעיה לא נפתרה – אבל לא מצאתי זמן לעשות את מה שהם ביקשו.
בשלב הזה כבר הייתי די מעוצבן מזה שכל כמה ימים נופל לי האפאצ'י עד שאני בועט בו, והתקנתי את Monit, שמנתר את השרת ויכול להפעיל אותו מחדש אוטומטית אם הוא נופל (עוד על Monit בקרוב).
Monit איתחל את השרת תוך 4-5 דקות מרגע שהבעיה הופיע, וזה שינה את הסימפטומים מהמצב החמור של "השרת לא עונה לכמה שעות כל כמה ימים" למצב הנסבל של "השרת לא עונה לכמה דקות כל כמה ימים".
נסבל, וכדרכם של עצלנים, סבלתי עד שלפני כמה ימים Monit פישל ולא עבד משום מה, והשרת שוב היה למטה חצי לילה.
פניתי שוב לקבוצת הדיון של trac – הפעם מצויד בכל מידע הדיבאג שהם ביקשו, וסיפרתי להם שלמרות ששידרגתי הבעיה ממשיכה.
בינתיים ניסתי לראות איך אני משחזר את הבעיה – חיפשתי כלי לStress test לשרתי HTTP, משהו פשוט שיאפשר לי להפציץ URL בודד.
מצאתי את Siege, כלי פשוט שנותן בדיוק את זה.
בשימוש פשוט בSiege, גיליתי שאני מצליח להפיל את השרת אם אני מפעיל 15 משתמשים מול הURL של קו הזמן של trac, אחד הדפים הדורשניים ביותר במערכת.

במקביל פניתי לערוץ הIRC של טראק, ודיברתי עם osimons – אחד המפתחים של trac – על הבעיה.
גילינו שכשאני מריץ את Siege, טראק פותח את קובץ בסיס הנתונים מאות פעמים, מה שלא בדיוק הסתדר עם זה שיש בטראק Connection pooling.
המשכתי לחקור את העניין לבד, ובסוף גיליתי שהConnection pooling בכלל מכובה עבור חיבורי SQLite במכונות שלא מריצות… חלונות NT.
הגיוני? לא יודע. הפעלתי מחדש את העסק, ומאז נפתרה הבעיה.

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

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

Facebook Comments

3 תגובות בנושא “הבאג שנלכד”

  1. תודה
    בזמן כתיבת שורות אלו לא ידעתי בכלל מה זה trac אבל דרך החשיבה שלך מלמדת אותי הרבה.
    ושוב פעם, תודה רבה על השיתוף.
    יוסי

  2. אם העומס שאתה רוצה להפעיל על השרת לא דורש תחכום גדול מדי, היוטיליטי ab שמגיע עם כל apache יעשה את העבודה (אם אני זוכר נכון זה במחיצת ה- BIN).
    הבעיה לגשת למוד סטטוס נובעת מכך שבעת שהבעיה מתרחשת אין ולו worker thread אחד פנוי לעיבוד בקשת ה- HTTP להצגת נתוני הסטטוס… אולי ניתן להורות לו לרוץ על טרד דדיקטד משלו ולרשום את הסטטוס לקובץ. לחילופין אולי ניתן לייצר CORE DUMP ולראות מה כל הטרדים עושים בעת שהבעיה קורה.
    טוב, נו, כבר פתרת את זה, לא משנה.

  3. כן, מצד שני היה הרבה יותר פשוט לכתוב סקריפט bash חיצוני שיעשה את אותו דבר, כאמור 🙂

סגור לתגובות.