מורידים את האשפה

היום הכוננים הקשיחים גדולים מתמיד, אבל אני עדיין מצליח להתקל במצבים כרוניים של חוסר מקום.
הסיבה לכך היא בעיקר שאני קמצן מדי כשאני מקצה מקום למחיצה הראשית של מערכת ההפעלה, בין אם זה הלינוקס שאני משתמש בו באופן שוטף שקיבל מחיצה של 24 ג'יגה (שנראתה גדולה מספיק כשהתקנתי אותו לפני שלוש-ארבע שנים), ובין אם זה חלונות המשחקים שלי שקיבל למחיצה הראשית רק 5 ג'יגה.

אז מדי פעם נגמר המקום וצריך למחוק זבל שהצטבר בכל מני פינות חשוכות של ההארדיסק.
הפרוצדורה הרגילה של כשנגמר לי המקום בדביאן היא למחוק לוגים ישנים, למחוק את המטמון של apt-get וסתם לתייר בהרדיסק ולחפש דברים גדולים.
כשנגמר לי המקום היום חשבתי שחייבת להיות דרך יותר נוחה, אז חיפשתי כזו:
[code]
root@main:~\# apt-cache search disk usage tree
kdirstat – graphical disk usage display with cleanup facilities
[/code]
נשמע מעניין, התקנתי וזה אכן בדיוק מה שרציתי.
kdirstat היא תוכנת KDE נחמדה שמאפשרת לראות בצורה נוחה אלו ספריות תופסות הרבה מקום, ואפילו לפעול לנקות אותן ישר מתוך התוכנה במגוון צורות (למחוק, לכווץ, להריץ make clean וכו').
היא מראה גם עץ ספריות שבו ברור כמה תופסת כל ספריה (עם כל המשפחה של הילדים שלה), וגם חיוון וויזואלי של כל הספריות כספריות גדולות הן ריבועים יותר גדולים (מגניב אבל לא מאוד שימושי).
בתמונה פה למשל, גיליתי שספריית הlocale תופסת 435 מגה, ונזכרתי שיש כלי בשם localepurge שמנקה אוטומטית קבצי locale לא רלוונטייים (בשפות אחרות מהשפות שהגדרתם שאתם מעוניינים בהם).
localepurge הצליח לנקות 470 מגה – כנראה הוא הצליח למצוא עוד קבצי תרגום תועים בכל מני חורים אחרים.

kdirstat

עוד ג'אנק ישן שהוא עזר לי לגלות זה קוד של קרנלים ישנים שקימפלתי בעבר, כשכל אחד תופס כמעט חצי ג'יגה!
והופה, לפני ששמתי לב – פתאום יש לי ארבע וחצי ג'יגה פנויים (במחיצה של 24 ג'יגה זה לא מעט בכלל).

למשתמשי חלונות המרובים שקוראים פה, תעברו ללינוקס.
סתם, יש לי גם כמה טיפים בשבילכם:
0. נסו את WinDirStat (ותודה לאריה)
1. תבטלו את הSystem restore ממאפייני המערכת, הוא תופס עשרות אם לא מאות מגה בייטים.
2. תזיזו את קובץ הדפדפוף למחיצה שונה מזו שחלונות מותקנת בה (שוב, מאפייני מערכת).
3. תזיזו את ספריית הTEMP למחיצה אחרת. (כן, ניחשתם – מאפייני מערכת)
4. תסירו תוכנות שמנות, ותתקינו אותן במחיצה אחרת.

הבאג שנלכד

מאז שעברתי לשרת החדש, היו לי בעיות עם שרת האפאצ'י: לפעמים הוא פשוט הפסיק לענות לבקשות, וחזר לעצמו רק אחרי 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.

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

The cake is a lie

כדור הארץ השלים את ההקפה ה31 שלו מאז שנולדתי.
בהמשך למסורת לבניית רשימה מקושרת, הנה לינק לפוסט היומולדת הקודם שלי.

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

ולא לשכוח, The cake is a lie.

the_cake_is_a_lie_portal

הקיטשיות של הכותרות בThe Marker שוגרה ב12%, העקביות שלהם דהתה ב28%

hatach

אז שימו לב, נאסד"ק עלה 2.9%.
מארוול קפצה 20%, סאנדיסק זינקה ב25%, מה שאומר שזינקה זה יותר מקפצה.
עד פה הכל טוב.
סיוה הוסיפה 20%, מעניין שהיא לא קפצה 20% אלא רק הוסיפה.
סרגון איבדה 2.9% אבל קומברס התכווצה ב2.4%.
כנראה שלאבד זה יותר גרוע מלהתכווץ.
טאואר לעומת זאת, נחלשה ב10%, שזה הרבה יותר גרוע מלאבד או להתכווץ, מסתבר.
המגזר הפרטי לעומת זאת, לא איבד  התכווץ או נחלש.. הוא חתך בחודש נובמבר. אם הוא היה עושה את זה בתוך יום למשל, אין ספק שהוא היה נחשב כמנסר.
זה לא צחוק, לחתוך זה זה כמו לנסר, רק יותר עדין ועל יותר זמן.
אבל זה נורא כואב עדיין.

אני כותב תוכנה בחמש דקות שמצליחה להחליף את הכתב היצירתי שהשפריץ את הכותרת הזו.

בעיית שעון בשרתי לינוקס

לאחרונה נתקלתי בבעיה עיקשת וקשה לפיתרון:
השעון של אחד השרתים שאני אחראי אליהם החליט שדיוק זה לא הקטע שלו, ונדד משהו כמו ארבע שעות בכל יום.
סינכרון NTP יומי גרם לקפיצת זמן של 4-5 שעות בכל פעם, וברור היה שצריך לפתור את הבעיה האמיתית.
החשוד המיידי בבעיות שעון בדרך כלל הוא הBIOS או הסוללה של הCMOS, והפתרון הכי זריז אם זו אכן הבעיה היא להעביר את הדיסק של השרת למכונה אחרת.
חברת ההוסטינג עשתה את זה, והתברר שזה לא פתר את הבעיה.
כדי לעשות דברים יותר מעניינים, אני אוסיף ואגיד שיש בחווה ארבעה שרתים, חלקם עם חומרה כמעט זהה לזו של השרת המאחר והם לא סבלו מהבעיה.
בנוסף, כל השרתים הריצו דביאן Etch עם קרנל 2.6.18 סטנדרטי של דביאן (שהיא הגרסא הרשמית של דביאן Etch), בהבדל אחד: המכונה המאחרת הריצה קרנל של 64 ביט.
לא משהו שאמור לגרום לכזו בעיה, אבל בכל זאת הבדל.
השוואה של קבצי הקונפיגורציה של הקרנלים (בדיביאן קרנלים סטנדרטיים מגיעים עם קובץ הקונפיגורציה שאיתו קומפל הקרנל והוא יושב בספריית /boot) הראתה הבדל מעניין בין הקרנל המאחר לבין אלו שלא:
הקרנל המאחר לא קומפל עם GENERIC_TIME, והאחרים כן.
עדיין לא מוכיח כלום, אבל מעניין.
מסתבר שבלינוקס יש כמה מקורות לעדכון השעון הפנימי, חלקם מדוייקים יותר, חלקם מדוייקים הרבה פחות.
המקורות של הקרנל שרץ כרגע זמינים בקובץ
[code]
/sys/devices/system/clocksource/clocksource0/available_clocksource
[/code]
במכונה המאחרת היה זמין רק מקור אחד עם שם מוזר: jiffies
שהוא גם המקור הכי לא מדוייק שיש (למעשה הקרנל מעדכן איזה משתנה פנימי בקצב שאמור להיות תואם את המציאות, מה שלא ממש עובד)

במכונות האחרות היו זמינים כמה מקורות: acpi_pm jiffies tsc pit

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