קטגוריה: unix

יצירה וטעינה של ספרייה משותפת בגו

גו היא שפת תכנות מהודרת, אשר יוצרת קבצי ריצה טבעיים של מערכת ההפעלה. מאז גרסה 1.5, נכנסה האפשרות ליצור ספרייה משותפת דינמית (DSO). בגרסה 1.5, התמיכה הייתה ניסיונית, ובגרסה של 1.6, התמיכה נכנסה כתמיכה רשמית של המהדר.

מה זו בעצם ספרייה משותפת?
בקצרה, על רגל אחת, ספרייה משותפת זהו קובץ "ריצה" (למשל בפורמט PE בווינדוז או ELF ביוניקס), אשר אינו מחזיק בחלק ריצה כפרוסס (לרוב נקרא main).
לקובץ הריצה יש רשימה של פונקציות אשר "מיוצאות", כלומר הכתובות שלהם נגישות כלפי חוץ כאשר רוצים להשתמש באותן הפונקציות.
השמות של אותן הפונקציות נקראות symbols והגישה אליהן מתרחשת על ידי כתובות זיכרון.
במידה ופרוסס מסויים מקשר אליהן בצורה סטטית, כלומר בזמן הידור, יודעים את המיקום שלו ביחס לשאר הפונקציות של הפרוסס, כאילו היה חלק מהפרוסס עצמו.
כאשר הטעינה מתבצעת בזמן ריצה, יש אתחול זיכרון דינאמי אשר מחזיק את הכתובת.

כיצד יוצרים ספרייה משותפת בגו? להמשיך לקרוא

סינטרה מודולרית

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

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

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

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

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

אנחנו משתמשים בRack בעצם, היות וכמעט וכל הframeworks עבור בניית מערכות web ברובי משתמשים בו, אנו זקוקים לקובץ קבוע בשם config.ru.

הקובץ הזה, בעצם אחראי על התחלת השרת, וטעינה של המערכת שלנו, כאשר הוא תומך בטעינה של יותר ממערכת אחת בו זמנית, כולל שני framework או יותר, אך נכון לגרסה הנוכחית, אני משתמש בו רק עבור Sinatra.

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

לאחר טעינת התלויות, אני טוען קובץ בודד בשם app.rb שהוא בעצם מה שמנהל את האפליקציה שלי. אך במקום להשתמש ב require "רגיל", אני משתמש בפונקציה בשם require_relative, אשר מאפשרת לטעון דברים מהמיקום הנוכחי של הקובץ המנסה לטעון אותה.

כל הקסם של ניהול מספר מחלקות, נעוץ אצלי ב app.rb.
אני יצרתי אותו שיהיה מאוד פשוט – טען לי את המחלקות האחרון והכנס אותן לסביבת העבודה של רובי, על ידי שימוש ב use.

למערכת שיצרתי ישנם שני מצבים – מערכת לדיבוג REST, ומערכת "בדיקות" אשר עליה אפשר לבדוק שדברים עובדים, והיא בעיקר על תקן "echo" כלשהו.

את המערכת של יצירת המסכים, ושליחת ה REST, יצרתי בקובץ rest.rb, והכל מאוגד שם.
יש שם משהו שהולך לעבור למקום אחר בקרוב, וזה מספר מתודות לסיוע בפעולות.

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

Sinatra תומך במשהו אשר קיבל את השם Helpers, וזה מתודות אשר מסייעות לנו לבצע דברים, בצורה שלא נהיה צריכים לחזור עליה כל פעם, וזה זמין גם ל view שלנו, ובגרסה הבאה שאשחרר (נכון לכתיבת הפוסט), המידע יעבור לקובץ בשם helpers.rb ואיתו עובדים קצת שונה ברובי.

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

במקרה הזה, הגדרתי כי במצב של ‎:development משתמשים ב Sinatra::Reloader, אשר מגיע עם Sinatra-Contrib – תת פרוייקט המספק הרבה כלי עזר לדברים שונים.
הסיבה לשימוש ב Reloader הוא לא לאתחל את השרת בכל שינוי שעושים למחלקה של סינטרה, כאשר Reloader מגלה כי התוכן של הקובץ השתנה, הוא גורם ל rack לטעון אותו שוב, וככה אנחנו לא זקוקים לטעינה מחודשת של השרת עצמו.

המערכת שכתבתי, משתמשת ב template בשם haml, למעשה פעם ראשונה אשר אני משתמש בה מרצון. תוכלו למצוא את ה layout.haml שהוא המסגרת הרגילה וכן כרגע קובץ בשם index.haml תחת ספריית view.
ועבור העיצוב, אני משתמש ב Foundation 5, אשר אני אוהב אותה יותר מאשר bootstrap.
עבור Javascript יש גם את jQuery וגם את knockout.js, כאשר אני נעזר גם ב lodash.js למספר דברים פשוטים, והיא מספקת בעצם גרסה שעברה אופטימיזציה ל underscore.

את הקבצים של Foundation, וכל ה Javascript ניתן למצוא תחת public.

דבר אחרון שנשאר לספר עליו הוא שאני משתמש במשהו אשר נקרא puma.
מה זה ?
puma הוא משהו שלוקח את rack וגורם לו להיות שרת לכל דבר ועניין, אשר ניתן לבצע עליו חיבור לשרתי HTTP שונים, כדוגמץ apache או nginx.
החיבור נעשה על ידי הגדרת proxy בשרתים.

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

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

טיפים על עבודה ב ssh

כאשר פותחים חיבורים של ssh,אנחנו מקבלים משהו שנקרא channels, שהם בעצם הצורה ש ssh מזהה את החיבורים שלנו על אותה "מנהרה" שמוצפנת.
חשוב להדגיש כי חיבור לשרתים שונים, לרוב לא יכללו את אותה המנהרה, אלא רק חיבורים לאותו השרת, אך כל חיבור מכיל channels.
אני נוהג להשתמש בצורה שבה כל חיבור לשרת, משתמש בsocket בודד, וכך עושה את החיבור יעיל אפילו יותר – היות וגם ככה כל חיבור מנוהל על ידי channel.

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

בתוך הספרייה ניצור קובץ בשם config ונכנס לו את ההגדרה הבאה:

Host *
  ControlPath ~/.ssh/sockets/master-%l-%r@%h:%p
  ControlMaster auto
  GSSAPIAuthentication=no
  ServerAliveInterval 25
  Compression yes
  IdentityFile ~/.ssh/id_rsa

ה"חלק" הזה שיצרנו בעצם יוצר קבוצה של הגדרות עבור 100% מהחיבורים שלנו (אלא אם נדרוס אותן). אנחנו יודעים זאת, בזכות הglob של כוכבית.
אנחנו אומרים לו ליצור קובץ socket על שם החיבור המדויק שלנו, ושopenssl ינהל אותו לבד. מדובר למעשה ב unix socket, וזה מה שמאפשר את השיתוף.
אנחנו אומרים למערכת שלנו כל 25 שניות לשלוח סוג של ping בשביל להשאיר את החיבור פתוח (אחרת יש חיבורים שיסגרו בשרתים שונים אם אין תגובה אחת לזמן מסוים), אנחנו דוחסים את המידע העובר עם החיבור, ובסוף אומרים מה המפתח ברירת המחדל שלנו.

כל האופציות האלו, הן אופציות שניתן להגדיר גם בשורת הפקודה, וגם תחת ssh_config שנמצא ב etc, אך כאן אנחנו עוקפים את ההגדרות של הקובץ האחרון, ובנוסף אין צורך ליצור משהו בשורת הפקודה, ואפילו alias מיותר.
בשורת הפקודה אנחנו מגדירים את רובם עם הדגל של ‎-o, ואז מציינים את ההגדרה שרוצים.

הקובץ של config מאפשר לנו גם לבצע הגדרות מדוייקות לשרתים שונים. למשל: להמשיך לקרוא

אפצ'י מפסיק לפעמים להגיב לבקשות בצורה רנדומאלית

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

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

הגעתי אל המשרדים של השותף, במטרה ליום שלם של מחקר בנושא. ובאיזשהו שלב, גם הצלחתי לשחזר את הבעיה – ובעיה זו היתה מאוד קשה לשחזר, ולמעשה רק אחרי הצהריים הצלחתי להגיע אליה, למרות שהתחלתי את המחקר ב9 בבוקר.

הפעלתי wireshark, וגיליתי כי three way handshake אינו מתבצע עד הסוף, ולמעשה ה ACK האחרון לא נשלח חזרה על ידי השרת (ה wireshark היה על השרת עצמו).
יש מספר נסיונות שליחה של לחיצת היד, ובסוף יש RST על הבקשה כי לא ניתן היה ליצור קשר, והבקשה התנתקה.

גוגל לא עזר בכלל, כנראה שהבעיה מדוייקת מידי וקשה להסביר אותה במילים, ובסוף נשברתי, ושמתי nginx על אחד השרתים, ושום דבר לא חזר על עצמו, כלומר המערכת עבדה חלק בלי שום בעיות למשך יום וחצי של עבודה עוד.
לפני ה nginx ניסיתי אפילו את שרת הפיתוח של PHP בנושא, וגם אצלו לא היו בעיות שונות, הבעיה היתה רק באפצ'י. אם בהתחלה חשבתי שאולי יש באג בTCP Stack של לינוקס, זה די כיוון אותי לכיוון האפצ'י.

בנתיים דיברתי עם בוריס, והוא הצליח למצוא קישור מעניין שמדבר כי אפצ'י בברירת המחדל מגיע עם דגל של TCP_DEFER_ACCEPT. עד כמה שאני מבין, הדגל הזה אומר לשרת לא לחכות ל three way handshake, אלא במידה ונשלח מידע אחרי החיבור הראשוני, כשעוד אין ACK, אלא רק SYN-ACK, ניתן כבר לקבל את המידע, ולמעשה רק כשהוא יסתיים להישלח, ישלח גם ה ACK.

מסתבר שבאפצ'י 2 הדגל מאופשר בברירת המחדל (בניגוד לnginx ששם צריך להגיד לו את זה במפורש), ולכן צריך לכבות אותו.

בשביל לכבות את הדגל בחיבור, צריך לשים ב httpd.conf הראשי, את הקוד הבא:

 AcceptFilter http none

במידה ויש הגדרה אחרת בנושא, למשל עם data, יש לשכתב אותה לnone.
וזה מכבה למעשה את הדגל של TCP_DEFER_ACCEPT ועכשיו אפצ'י חייב לחכות ללחיצת היד כמו שצריך לפני שיוכל לנתח את מה שנשלח.

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

 

בזיון השעון (או איך חברות סלולר דופקות את הלקוחות שלהן)

בזמן כתיבת שורות אלו, קיבלנו צורך לשנות את השעון בטלפון החכם לשעון אתונה.
הסיבה לכך היא שישראל שינתה את החוקים להזזת השעון, אשר צריך להיות ב27/10/2013, אך לפני השינוי הזה, הזמן היה צריך להיות שונה, ולכן חברות הסלולר ממליצות להעביר את השעון לאתונה, ששם גם המעבר יהיה ב27/10/2013.

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

אם חברות הסלולר היו משחררות firmware מעודכן לטלפונים שברשותן רק עם שינוי של tzdata, מעולם לא היתה צריכה לעלות הבקשה להחליף מישראל לאתונה, היות והשעון היה מתחלף כמו שצריך בכוחות עצמו (אצלי בלינוקס):

$ zdump -v Asia/Jerusalem | grep 2013 | grep Oct
Asia/Jerusalem  Sat Oct 26 22:59:59 2013 UTC = Sun Oct 27 01:59:59 2013 IDT isdst=1 gmtoff=10800
Asia/Jerusalem  Sat Oct 26 23:00:00 2013 UTC = Sun Oct 27 01:00:00 2013 IST isdst=0 gmtoff=7200

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

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

where have all the desktops gone ?

The title of this post inspired by Paula Cole's song title, but not because of the song itself…

In the past several years, the Unix (and mostly Linux) Desktop field started to have a lot of big changes (The ice age is over ?). The changes are so massive, that people started to immigrate from one environment to another, while companies such as MS do a lot of copy paste to specific features that invented for the Unix desktop (and then they say that Unix desktop is not very user friendly :)).

Most people does not know how to handle changes. They like the icon in the same place, and even if you move it for them only by 2 pixels to the right, it's like a new environment for them, and they do not know what to do. However the desktop changes in Unix are much bigger then moving by 2 pixels away.

Amazingly, I found myself taking the opposite direction of most Linux users today (now you understand the name of my blog ? ;)). At the year of 2,000 when I first owned my own Linux Installation -> Mandrake 7 (prior to that I used Unix's such as Solaris and IAX at work places), I could not find a good desktop environment to work with. I tried KDE 2, Gnome 1 and XFCE 3, and they sucked big time for me. Then KDE 3 came out, and later on, also Gnome 2, and then XFCE 4, and the only environment I found good enough for me was XFCE 4 (I used to work a lot with CDE on Unix), and also found out about WindowMaker (The NeXT like WM), and things was finally good for me. להמשיך לקרוא

לכידת אותות סוררים ביוניקס

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

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

אז מהם אותות או Signals ? ובכן הם דרך להגיד לתכנית שלנו לבצע כל מיני דברים "מבחוץ". כלומר לספק סוג של IPC (תקשורת בין תהליכים) בגישה הכי פשוטה ופרימיטיבית שיש, אשר עליה אפשר ליצור הרבה דברים נוספים.

הבעיה היא שהתעוד יחסית נורא בנושא כאשר מדובר בתכנות למי שהידע שלו בC אינו הכי חד או קיים בכלל.

למשל אם תכתבו בלינוקס : להמשיך לקרוא

עבודה עם /dev/random ו /dev/urandom

ישנם בעולם ה POSIX – בעיקר במערכות יוניקס 2 devices אשר מאפשרים לנו לקבל מספר כלשהו שיהיה בסיס לחישוב רנדומאלי (seed). ההבדל העיקרי בניהם הוא ש random הוא blocking, כלומר עד אשר לא אקבל תשובה אשאר "תקוע". בעוד ש urandom חוזר מייד, ולפעמים יביא מידע פחות איכותי (כלומר פחות רנדומאלי) לשימוש.

הפוסט הזה מדגים במספר שפות תכנות כיצד אפשר להשתמש ב2 ברכיבים האלו. הקוד מפורסם תחת MIT. להמשיך לקרוא

אבידה גדולה לעולם הטכנולוגיה

לפני שבוע הלך לעולמו אדם גדול אשר שינה את פני העולם כולו, ולמעשה כולנו מושפעים מאוד מכל מה שהוא יצר ועשה. אני מדבר על דניס ריצ'י כמובן. אם לא שמעתם על זה, אלא רק על סטיב ג'ובס, אז תדעו לכם כי אלמלא מר ריצ'י, אז לא היה לכם היום איפון, או Mac OS X, אבל התקשורת לא אוהבת לדבר על האנשים היצרניים, רק על אלו שיודעים להיות בכותרות.

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

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

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

הוא אחראי (שוב, בייחד עם עוד מספר אנשים), על מערכת הפעלה אשר שינתה את כל ההיסטוריה של עולם המחשבים בשם Unix. למעשה Mac OS X היא Unix עם תוספות מעליה. Linux לעומת זאת, היא מערכת דמויית Unix. המערכת הציגה פעם ראשונה ביצוע של ריבוי משימות טבעי וכן עבודה עם מספר רב של משתמשים בו זמנית, כאשר היה קל ונוח יותר (יחסית כמבן) לנהל את כל זה מאשר מה שהיה עד אז.

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

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

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

סתם שתקבלו קצת קנה מידה

להבין את load average ביוניקס

כל מי שעובד ביוניקס מספיק זמן מגלה את load average. ניתן להגיע אליו דרך הפקודות top, procinfo, w ו uptime. העניין הוא שלא הרבה יודעים מה זה בעצם אומר. אז אני אנסה להסביר כאן בקצרה (ובצורה מאוד לא ממצה, אבל מספיק ברורה אני מקווה) מה זה אומר.

ובכן אם נסתכל על ה load average אנחנו נראה שהוא מורכב מ3 קבוצות של מספרים:

load average: 0.40, 0.46, 0.47

הקבוצות מייצגות זמן. הקבוצה הראשונה מייצגת דקה, הקבוצה השנייה 5 דקות והקבוצה השלישית 15 דקות.

הקבוצות מראות בפרק זמן של כל אחת ואחת כמה תהליכים (process) מחכים לריצה מול מה שכבר הורץ באותו פרק זמן מבחינת ביצוע הפקודות על ידי המעבדים.

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

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

לקריאה מקיפה יותר אתם מוזמנים לגשת לקישורים הבאים:

http://www.lifeaftercoffee.com/2006/03/13/unix-load-averages-explained/

http://www.crucialp.com/resources/tutorials/server-administration/server-loads-explained-linux-unix.php

http://www.teamquest.com/resources/gunther/display/5/index.htm

http://en.wikipedia.org/wiki/Load_(computing)