שיטות מומלצות לניהול זיכרון

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

במאמר הזה:

• מושגים בניהול זיכרון – מושגי מפתח שחשוב להכיר כדי לשמור על תקינות של מופע Memorystore.

• פעולות שדורשות הרבה זיכרון – פעולות שעלולות לגרום לעומס על הזיכרון.

• מעקב אחרי השימוש בזיכרון של המכונה – מדדים שכדאי לעקוב אחריהם כדי להבין איך המכונה משתמשת בזיכרון.

• פתרון בעיה של חוסר זיכרון – שלבים לפתרון בעיות שקשורות למצב של חוסר זיכרון.

• בחירת הגודל המתאים למכונת Memorystore – במקום ליצור מכונה עם הקצאת-יתר, כדאי ללמוד איך לבחור את הגודל המתאים למכונה.

מושגים שקשורים לניהול זיכרון

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

קיבולת המכונה

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

הגדרת Maxmemory

• ‫Maxmemory היא הגדרת Redis שמאפשרת להגדיר את מגבלת הזיכרון שבה מדיניות ההוצאה שלכם נכנסת לתוקף. ב-Memorystore for Redis, ההגדרה הזו מסומנת כ-maxmemory-gb. כשיוצרים מופע, הערך של maxmemory-gb מוגדר לקיבולת של המופע. בהתאם למדד של יחס השימוש בזיכרון המערכת, יכול להיות שתצטרכו להקטין את המגבלה maxmemory-gb כדי לספק תקורה של זיכרון לעליות פתאומיות בעומס העבודה.

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

  כאן מוסבר איך לשנות את maxmemory-gb.

יחס השימוש בזיכרון המערכת

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

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

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

הזיכרון שנעשה בו שימוש

• המדד used memory (זיכרון בשימוש) מראה כמה נתונים יש במופע Memorystore. נפח הזיכרון בשימוש של מופע יכול לגדול עד למגבלת התצורה maxmemory-gb. כשנפח הזיכרון בשימוש חורג מהמגבלה maxmemory-gb, מדיניות ההוצאה שלכם נכנסת לתוקף.

מדיניות בנושא פינוי

• מדיניות הפינוי של המופע (שנקראת גם מדיניות maxmemory) קובעת איך Redis מפנה מפתחות כשנתוני המופע מגיעים למגבלה maxmemory-gb. ‫Redis מוציא מפתחות מהמטמון כחלק מתרחיש השימוש הרגיל במטמון. הסרת מפתחות מתרחשת כתהליך ברקע, ולכן מפתחות לא מוסרים מיד אחרי שמגיעים למגבלה של maxmemory-gb. קצב כתיבה גבוה עלול להיות מהיר יותר מקצב סילוק המפתחות, וכתוצאה מכך להוביל למצב של חוסר בזיכרון.

  מדיניות ההוצאה של מופע Memorystore היא volatile-lru כברירת מחדל. אם אתם משתמשים במדיניות פינוי volatile-*, הקפידו להגדיר ערכי TTL למפתחות שאתם רוצים שייפוגו, אחרת ל-Redis לא יהיו מפתחות לפינוי.

  רשימה של כללי מדיניות בנושא פינוי זמינה במאמר כללי מדיניות בנושא Maxmemory.

  במאמר הגדרת מופעי Redis מוסבר איך לשנות את מדיניות הפינוי.

פיצול הזיכרון

• פיצול הזיכרון עלול לגרום למכונת Memorystore להיגמר הזיכרון גם כשהיחס בין הזיכרון בשימוש לבין maxmemory-gb נמוך. פיצול הזיכרון קורה כשמערכת ההפעלה מקצה דפי זיכרון ש-Redis לא יכול להשתמש בהם באופן מלא אחרי פעולות כתיבה ומחיקה חוזרות. הצטברות של דפים כאלה עלולה לגרום למערכת להיגמר הזיכרון ובסופו של דבר לגרום לקריסת שרת Redis. הגדרת activedefrag Redis יכולה לעזור לצמצם את הפיצול.

דפרגמנטציה פעילה

• בגרסאות 4.0 ומעלה של Redis יש הגדרה של activedefrag. אם אפשר, כדאי ליצור את מופע Memorystore באמצעות Redis 4.0. ב-Memorystore, ההגדרה של activedefrag היא no כברירת מחדל. אם מגדירים את activedefrag ל-yes, יש לכך השפעה על המעבד, אבל זה יכול לעזור לצמצם את פיצול הזיכרון, שגורם לבעיות של חוסר זיכרון.

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

פעולות שדורשות הרבה זיכרון

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

פעולת ייצוא

תכונת הייצוא של Memorystore משתמשת בפעולה BGSAVE של Redis, שמשתמשת בהעתקה בעת כתיבה. בהתאם לגודל הנתונים, לנפח הכתיבה ולמפתחות שנעשה בהם שימוש, הזיכרון שנדרש לייצוא יכול להיות כפול מגודל המקום שהנתונים תופסים. לכן, כדי שהייצוא יצליח, יכול להיות שתצטרכו להקטין את המגבלה של maxmemory-gb ל-50% מהקיבולת של המופע במהלך הייצוא.

פעולות של שינוי גודל ושדרוג גרסה

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

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

תחזוקה

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

מעקב אחר השימוש בזיכרון במופע

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

מדדים שקשורים לניהול זיכרון

מדד	כתובת מלאה של מדד
Maxmemory	redis.googleapis.com/stats/memory/maxmemory
ניצול הזיכרון	redis.googleapis.com/stats/memory/usage
יחס השימוש בזיכרון	redis.googleapis.com/stats/memory/usage_ratio
משך העומס על זיכרון המערכת	redis.googleapis.com/stats/memory/system_memory_overload_duration
יחס השימוש בזיכרון המערכת	redis.googleapis.com/stats/memory/system_memory_usage_ratio
שיעור מציאות במטמון (cache hit)	redis.googleapis.com/stats/memory/cache_hit_ratio
מפתחות עם תוקף	redis.googleapis.com/keyspace/keys_with_expiration
מפתחות שפג תוקפם	redis.googleapis.com/stats/expired_keys
מפתחות שהוצאו	redis.googleapis.com/stats/evicted_keys

יחס השימוש בזיכרון

מדד יחס השימוש בזיכרון מציין עד כמה גודל קבוצת העבודה קרוב למגבלת maxmemory-gb. אלא אם מדיניות ההוצאה מהזיכרון מוגדרת ל-no-eviction, הנתונים של המופע שמגיעים ל-maxmemory לא תמיד מצביעים על בעיה. עם זאת, פינוי מפתחות הוא תהליך ברקע שלוקח זמן. אם קצב הכתיבה גבוה, יכול להיות שייגמר הזיכרון לפני ש-Redis יספיק להוציא מפתחות כדי לפנות מקום.

יחס השימוש בזיכרון המערכת

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

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

אם יחס השימוש בזיכרון המערכת מגיע ל-100%, כל פעולה שמגדילה עוד יותר את הזיכרון שבשימוש של המכונה נחסמת, ו-Redis מחזירה את השגיאה הבאה:

-OOM command not allowed under OOM prevention.

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

משך העומס על זיכרון המערכת

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

כדאי להגדיר התראה למדד הזה כדי לדעת מתי פעולות הכתיבה שלכם נחסמות במופע. בנוסף, אפשר לחזור למדד הזה כדי לפתור את הבעיה שגורמת להצגת השגיאה -OOM command not allowed under OOM prevention..

יחס פגיעות במטמון

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

מפתחות עם תאריך תפוגה ומפתחות שפג תוקפם

מדד Stackdriver‏ expirable keys (מפתחות עם תאריך תפוגה) עוקב אחרי מספר המפתחות שהוגדר להם תאריך תפוגה. אם אין מפתחות עם תאריך תפוגה, יכול להיות שלא הגדרתם ערכי TTL למפתחות. במקרים כאלה, כשנתוני המופע מגיעים למגבלת maxmemory-gb, אין מפתחות להסרה, וזה עלול לגרום למצב של חוסר זיכרון אם אתם משתמשים במדיניות הסרה של volatile-*.

מדד נוסף שכדאי לעקוב אחריו הוא expired keys. אם המדד הזה מראה הרבה מפתחות שתוקפם פג, אבל עדיין יש לחץ על הזיכרון במופע, כדאי להקטין את maxmemory-gb.

פתרון של מצב שבו אין מספיק זיכרון

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

1. אם אתם משתמשים בvolatile-* מדיניות פינוי, הקפידו להגדיר ערכי TTL למפתחות שאתם רוצים שיהיה להם תוקף. פרטים נוספים זמינים במאמר בנושא מדיניות פינוי.

2. במקרים שבהם פועלת גרסה Redis 4.0 ומעלה:

   1. מפעילים את activedefrag במופע. פרטים נוספים זמינים במאמר בנושא איחוי פעיל.

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

4. איך משנים את הערך של maxmemory כשמריצים פעולות שדורשות הרבה זיכרון

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

6. מומלץ להגדיל את הקיבולת של המופע.

7. אם אתם עדיין נתקלים בתנאי OOM, פנו לתמיכה של Google Cloud Platform.

בחירת הגודל המתאים למופע Memorystore

בקטע הזה נסביר על שלוש גישות שונות שיעזרו לכם להתאים את גודל המכונה לצרכים שלכם בהתאם לעומס העבודה:

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

קביעת הגודל הראשוני של מופע Memorystore

קודם צריך לבחור אם רוצים ליצור מופע במסלול Standard או במסלול Basic. כדי לקבל מידע נוסף על המסלולים של Memorystore for Redis, אפשר לעיין במאמר יכולות המסלולים של Redis. אחרי שבוחרים את המסלול המתאים לאפליקציה, פועלים לפי השלבים הבאים כדי לקבוע את גודל המופע שצריך:

1. קובעים את גודל הנתונים.

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

2. בוחרים מדיניות פינוי.

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

3. הקצאת זיכרון נוסף למכונות במסלול הרגיל

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

4. הערכת קצב הכתיבה הממוצע וקצב הכתיבה בשיא

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

5. הגדלת נפח התעבורה כדי להגיע ליחס פגיעה במטמון הרצוי

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

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

אם מופיעה השגיאה הבאה:

-OOM command not allowed under OOM prevention.

לאחר מכן, בודקים אם:

1. מדד יחס השימוש בזיכרון המערכת חרג מ-80% ממש לפני שהתחילו בעיות במופע.
2. יחס השימוש בזיכרון המערכת גדל במהירות רבה לפני שהתרחשו בעיות במופע.
3. המדד system memory overload duration (משך העומס על זיכרון המערכת) הראה ערכים מעל אפס באותו פרק זמן שבו נתקלת בכתיבות חסומות.

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

ניהול יחס השימוש בזיכרון המערכת

מגדירים התראה כדי לקבל הודעה אם מדד יחס השימוש בזיכרון המערכת חורג מ-80%. אם יחס השימוש בזיכרון המערכת עולה על 80%, צריך לבצע פעולה מתאימה כדי שלא ייגמר הזיכרון של המופע. בהתאם לנפח הכתיבה ולדפוס הגישה למפתחות, השימוש בזיכרון המערכת עשוי לעלות במהירות ל-100%. ב-Memorystore יש כמה דרכים לנהל את יחס השימוש בזיכרון המערכת:

• מפעילים את activedefrag במופעים שמופעלת בהם Redis מגרסה 4.0 ואילך.
• מורידים את המגבלה של maxmemory-gb במכונה.
• מגדילים את המופע.
• בוחרים את מדיניות הפינוי המתאימה.
• הגדרת ערכי TTL למפתחות זמניים.
• מחיקה ידנית של מפתחות מהמופע.

הפעלת activedefrag

אם יחס השימוש בזיכרון המערכת עולה על 80%, מפעילים את activedefrag (במקרים שבהם מופעלת גרסה 4.0 של Redis ומעלה). יכול להיות שיחלפו שעות עד שהזיכרון המפוצל ישוחרר. אם תנועת הכתיבה גבוהה, יכול להיות שביטול הפיצול לבד לא יספיק כדי למנוע את מצב הזיכרון המלא במופע. לכן, יכול להיות שתצטרכו ליישם את ההמלצות הבאות:

הנמכת מגבלת הזיכרון המקסימלית של המופע

אם יחס השימוש בזיכרון המערכת עולה על 80%, צריך להקטין את הערך של maxmemory-gb, אבל קודם צריך לבדוק איך יחס השימוש בזיכרון המערכת השתנה לאורך זמן כדי להחליט איזו מגבלה חדשה להגדיר ל-maxmemory-gb.

תרחיש 1: יחס השימוש בזיכרון המערכת עולה בהדרגה ובאופן איטי. סביר להניח שהבעיה היא פיצול, ולכן צריך להקטין את maxmemory-gb במרווחים קטנים עד שיחס השימוש בזיכרון המערכת יתייצב מתחת ל-80%.

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

הגדלת המופע

חשוב: במהלך שינוי הגודל, Memorystore שומר על היחס בין maxmemory-gb לקיבולת המופע. יחס ברירת המחדל הוא 1:1 ו-maxmemory-gb שווה לקיבולת המופע. אם מקטינים את המכסה של maxmemory-gb ומגדילים את המכונה, היחס המוקטן של maxmemory-gb יחול על הגודל החדש של המכונה.

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

דוגמה לשינוי גודל של maxmemory:

אם יש לכם מופע בנפח 10GB והגדרתם את maxmemory-gb ל-8GB, יש לכם 8GB לאחסון מפתחות ו-2GB של תקורה בזיכרון. אם משנים את גודל המכונה ל-20GB, גודל הדיסק של maxmemory-gb ישתנה ל-16GB. לכן, למכונה שלך יש עכשיו זיכרון בנפח 16GB לאחסון מפתחות, ו-4GB של תקורה. הוראות להגדלה או להקטנה של גודל המכונה מופיעות במאמר בנושא שינוי גודל של מכונות Redis.

בחירת מדיניות הפינוי המתאימה

אם אתם מאחסנים נתונים שמשתנים במהירות, צריך לבחור אחת מvolatile-* מדיניות הסרת נתונים. אם אתם מאחסנים נתונים שלא משתנים במהירות, צריך לבחור אחת ממדיניות allkeys-*.

מחיקת מפתחות באופן ידני מהמופע

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