RAM לעומת אחסון

למחשב שלי יש SSD בנפח 1TB ומאות ג'יגה-בייט פנויים. אז למה הוא נתקע כשאני מפעיל במקביל Android Studio, אמולטור, דפדפן וכמה כלי פיתוח?

השאלה הזאת נובעת מבלבול נפוץ בין שני רכיבים שונים לחלוטין: זיכרון העבודה של המחשב, RAM, והאחסון שלו, בדרך כלל SSD.

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

הארון והשולחן

אפשר לדמיין את האחסון כארון תיוק גדול ואת ה-RAM כשולחן העבודה.

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

ה-SSD הוא הארון:

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

ה-RAM הוא השולחן:

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

שולחן קטן לא נעשה גדול יותר מפני שיש לידו ארון ענק.

מה קורה כשמפעילים תוכנה?

נניח שמשחק מותקן על ה-SSD וגודלו 80GB. אין פירוש הדבר שנדרשים 80GB של RAM כדי להפעיל אותו.

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

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

מערכת ההפעלה מחלקת את הזיכרון לדפים ומחליטה היכן נמצא כל דף:

• ב-RAM.
• ב-Swap שבאחסון.
• בתוך קובץ ממופה.
• או שעדיין לא הוקצה לו דף פיזי כלל.

מהו Working Set?

ה-Working Set הוא קבוצת דפי הקוד והנתונים שבהם התהליך משתמש באופן פעיל בתקופה הנוכחית.

הוא אינו כל גודל התוכנה, אינו כל הקובץ הממופה ואינו כל מרחב הכתובות הווירטואלי.

לדוגמה, תוכנה יכולה למפות קובץ בגודל 40GB, אבל לקרוא בפועל רק 200MB. במקרה כזה:

• ה-Virtual Memory עשוי לגדול בכ-40GB.
• ה-RSS עשוי להיות קרוב יותר ל-200MB.
• אין הכרח שכל הקובץ ייטען ל-RAM.
• אין הכרח שה-Swap יגדל.

כל עוד קבוצות העבודה של כל התוכנות הפעילות נכנסות ב-RAM, המחשב יכול לעבוד בצורה חלקה.

הבעיה מתחילה כאשר קבוצת העבודה הכוללת גדולה מקיבולת ה-RAM.

למה Android Studio, אמולטור ודפדפן צורכים כל כך הרבה RAM?

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

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

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

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

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

מאות ג'יגה-בייט פנויים ב-SSD אינם משנים את העובדה שאין מספיק שטח עבודה מהיר.

כיצד מערכת ההפעלה מתמודדת עם מחסור ב-RAM?

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

פינוי Cache

המערכת משתמשת ב-RAM פנוי כ-Cache לקבצים ולמידע שסביר שיידרש שוב. זה שימוש יעיל בזיכרון.

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

לכן העובדה ש-15GB מתוך 16GB RAM מוצגים כ"בשימוש" אינה בהכרח בעיה. אם ה-Memory Pressure ירוק, ה-Swap אינו גדל והמחשב מגיב במהירות, ייתכן שהמערכת פשוט מנצלת היטב את הזיכרון הזמין.

דחיסת זיכרון

מערכות כמו macOS יכולות לדחוס דפים בתוך ה-RAM.

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

שימוש ב-Swap

אם עדיין אין מספיק מקום, המערכת יכולה להעביר דפים פחות פעילים מה-RAM לאזור באחסון הנקרא Swap. ב-Windows נעשה שימוש במונח Pagefile.

כאשר התוכנית זקוקה שוב לדף שהועבר, מתרחש Page Fault. מערכת ההפעלה צריכה:

1. למצוא מקום פנוי ב-RAM.
2. לקרוא את הדף מה-SSD.
3. לעדכן את מיפוי הזיכרון.
4. להפעיל מחדש את ההוראה שניסתה לגשת אליו.

המעבד אינו עובד ישירות על הדף כשהוא ב-Swap. הדף חייב לחזור תחילה ל-RAM.

מדוע Swap אינו שווה ל-RAM?

SSD מודרני יכול להיות מהיר מאוד ביחס לכונן קשיח, אך הוא עדיין איטי משמעותית מ-RAM.

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

RAM תוכנן לשמש זיכרון עבודה פעיל. SSD תוכנן לשמש אחסון מתמיד.

לכן:

8GB RAM ועוד 8GB Swap אינם שווים בביצועים ל-16GB RAM.

ה-Swap מאפשר למחשב להמשיך לפעול גם כשה-RAM אינו מספיק. הוא מנגנון הישרדות חשוב, אך אינו תחליף שווה ערך.

מהו Thrashing?

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

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

המצב הזה נקרא Thrashing.

הסימנים האפשריים:

• מעבר איטי בין תוכנות.
• תקיעות של כמה שניות.
• תגובה מאוחרת ללחיצות.
• עלייה מהירה ב-Swap.
• Memory Pressure גבוה.
• פעילות אחסון רבה גם כשלא נשמרים קבצים.

SSD מהיר יכול לקצר חלק מזמן ההמתנה, אך לא לפתור את הבעיה הבסיסית: קבוצת העבודה הפעילה גדולה מכמות ה-RAM.

מה קורה כשגם זה אינו מספיק?

אם המערכת אינה יכולה עוד לספק זיכרון, היא מגיעה למצב OOM, כלומר Out of Memory.

התוצאות האפשריות משתנות בין מערכת הפעלה ותוכנה:

• בקשת ההקצאה נכשלת.
• התוכנית מקבלת `MemoryError` או `OutOfMemoryError`.
• התהליך קורס משום שלא טיפל בכישלון.
• מערכת ההפעלה סוגרת תהליך כדי לפנות זיכרון.
• ב-Linux מנגנון ה-OOM Killer עשוי לבחור תהליך ולהרוג אותו.

OOM אינו זליגת זיכרון. זליגה היא תקלה שבה תוכנה ממשיכה לשמור זיכרון שכבר אינו דרוש. זליגה ממושכת יכולה לגרום בסופו של דבר ל-OOM.

איך מזהים זליגת זיכרון?

עלייה חד-פעמית ב-RSS אינה מוכיחה זליגה.

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

דפוס תקין אפשרי:

• הפעולה הראשונה מעלה את ה-RSS ל-1GB.
• הפעולה השנייה מעלה אותו ל-1.2GB.
• הפעולות הבאות נשארות סביב 1.2GB.

דפוס מחשיד יותר:

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

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

ניסוי מעשי ב-macOS

אפשר לראות את ההתנהגות הזאת בניסוי קטן ב-Python.

בניסוי הקציתי בהדרגה 512MiB ונגעתי בכל דף כדי לגרום להקצאה להתממש בפועל. מדד ה-RSS עלה לכ-526.7MiB, מעט יותר מגודל הנתונים עצמם בגלל Python, הספריות ומבני הניהול של התהליך.

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

לאחר מחיקת האובייקטים, ה-RSS נשאר גבוה גם לאחר 20 שניות. זה לא הוכיח זליגה. Python או מנהל ההקצאות של המערכת יכלו לשמור את הזיכרון בתוך התהליך לצורך שימוש חוזר.

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

ב-macOS ניתן לבדוק את מצב הזיכרון באמצעות:

ps
vm_stat
memory_pressure
sysctl vm.swapusage

אפשר גם להשתמש ב-Activity Monitor ולבחון את Memory Pressure, Compressed Memory ו-Swap Used.

Virtual Memory, RSS ו-Shared Memory

כאשר בודקים תהליך, חשוב לא להתבלבל בין המדדים.

Virtual Memory

זהו מרחב הכתובות של התהליך. הוא יכול לכלול:

• כתובות שמורות.
• קבצים ממופים.
• ספריות משותפות.
• דפים שלא נטענו ל-RAM.
• זיכרון שהוקצה בצורה עצלה.
• אזורים גדולים שהתהליך אינו משתמש בהם בפועל.

Virtual Memory של 60GB אינו אומר שהתהליך צורך 60GB RAM.

RSS

RSS הוא בקירוב כמות דפי התהליך שנמצאים כרגע ב-RAM.

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

Shared Memory

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

לא תמיד נכון לחבר RSS ו-Shared Memory, משום שהזיכרון המשותף עשוי כבר להיכלל ב-RSS.

Unified Memory במחשבי Apple Silicon

במחשבי Apple Silicon ה-CPU וה-GPU משתמשים באותו מאגר זיכרון פיזי.

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

במחשב עם 16GB Unified Memory אין 16GB למעבד ועוד 16GB לגרפיקה. יש מאגר כולל של 16GB.

אם ה-GPU משתמש ב-5GB, הכמות הזאת אינה זמינה באותו זמן לשאר המערכת.

Unified Memory הוא עדיין RAM:

• הוא מהיר.
• הוא משמש לעבודה פעילה.
• הוא נדיף.
• המידע שבו אובד בכיבוי מלא אם לא נשמר באחסון.
• הוא אינו SSD.

Sleep לעומת Hibernate

גם ההבדל בין Sleep ל-Hibernate מדגים את ההבדל בין RAM לאחסון.

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

ב-Hibernate, מערכת ההפעלה כותבת לאחסון תמונת מצב של ה-RAM. לאחר מכן המחשב יכול להיכבות. בהפעלה הבאה התמונה נטענת מהאחסון בחזרה ל-RAM.

מערכות מסוימות משתמשות במצבים משולבים, אך העיקרון נשאר זהה: RAM דורש חשמל; אחסון מתמיד אינו דורש חשמל כדי לשמור את המידע.

אז מה כדאי לשדרג?

כאשר המחשב מציג:

• Memory Pressure גבוה.
• Swap שעולה באופן קבוע.
• תקיעות בזמן עבודה מקבילית.
• האטה משמעותית במעבר בין תוכנות.
• Android Studio, אמולטור ודפדפן שפועלים יחד.

השדרוג הישיר הוא בדרך כלל יותר RAM.

כאשר אי אפשר לשדרג, אפשר להקטין את קבוצת העבודה הפעילה:

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

לעומת זאת, כאשר הבעיה היא `No space left`, התקנות שנכשלות או חוסר אפשרות לשמור קבצים, הבעיה היא באחסון. במקרה כזה צריך לפנות מקום או להגדיל את נפח ה-SSD.

השורה התחתונה

RAM ו-SSD אינם שתי גרסאות מהירות ואיטיות של אותו דבר.

ה-SSD הוא המקום שבו המידע נשמר לאורך זמן. ה-RAM הוא סביבת העבודה המהירה שבה התוכנות הפעילות מחזיקות את הקוד והנתונים הדרושים להן כרגע.

כאשר ה-RAM מתמלא, מערכת ההפעלה יכולה לפנות Cache, לדחוס דפים ולהשתמש ב-Swap. הפעולות האלה עוזרות למחשב להמשיך לפעול, אבל אינן הופכות את ה-SSD ל-RAM.

לכן מחשב עם SSD בנפח 1TB ו-8GB RAM עדיין יכול להיתקע תחת עומס כבד. האחסון גדול, אך שולחן העבודה קטן.