פתרון בעיות

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

תרחישי שכפול

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

איך עוקבים אחרי השהיות בשכפול?

ל-Memorystore for Valkey יש את המדד /instance/replication/maximum_offset_diff. המדד הזה עוקב אחרי ההבדל המקסימלי בהיסטוריית השכפול (בבייטים) של צומת במופע ראשי.

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

מומלץ להגדיר ערך סף למדד maximum_offset_diff. אם הסף נחצה, Memorystore for Valkey יכול לשלוח לכם התראה.

על סמך סוג הצומת של המופע, מומלץ להגדיר את ערך הסף באופן הבא:

• אם סוג הצומת הוא shared-core-nano,‏ custom-pico,‏ custom-micro,‏ custom-mini,‏ standard-small,‏ highmem-medium,‏ highcpu-medium או standard-large, צריך להגדיר את הסף כך שיהיה נמוך מ-64MB.

• אם סוג הצומת הוא highmem-xlarge או highmem-2xlarge, צריך להגדיר את ערך הסף כך שיהיה קטן מ-1GB.

שימו לב: מומלץ להשתמש בסוג הצומת shared-core-nano רק למטרות פיתוח או בדיקה, כי לסוג הצומת הזה אין הסכם רמת שירות (SLA). אם אתם מפעילים את Memorystore for Valkey בסביבת ייצור, מומלץ להשתמש בסוג צומת אחר. מידע נוסף על סוגי הצמתים האלה זמין במאמר בחירת סוג הצומת.

מה עושים אם יש השהיה בשכפול בין המופע הראשי לבין העותקים שלו?

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

תרחישי שימוש במעבד

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

מה עושים אם נגמר המקום במאגר הפלט של המופע?

אם מאגר הפלט של מופע Memorystore for Valkey מתמלא, צריך לבצע את הפעולות הבאות:

• מגדירים ערך קטן יותר לפרמטר maxmemory.
• משתמשים במדיניות allkeys-lru maxmemory.

כשהזיכרון של מופע מלא ומגיעה פעולת כתיבה חדשה, שירות Memorystore for Valkey מפנה מקום לפעולת הכתיבה על ידי הוצאת מפתחות, בהתאם למדיניות maxmemory של המופע. מדיניות allkeys-lru מסירה את המפתחות שהשימוש בהם היה הכי פחות עדכני (LRU) מכל קבוצת המפתחות.

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

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

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

איך מבודדים את המקור של זמן האחזור של המופע?

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

כדי לבודד את מקור ההשהיה של המופע:

1. מתחברים למכונה וירטואלית ב-Compute Engine שנמצאת באותו אזור ובאותה רשת VPC כמו המופע.

2. אם הוא לא מותקן, מתקינים את הכלי valkey-cli במכונה הווירטואלית.

   • במכונות וירטואליות מבוססות Debian או Ubuntu, מריצים את הפקודה הבאה:

     sudo apt-get install valkey-tools
     

   • במכונות וירטואליות שמבוססות על RHEL או CentOS, מריצים את הפקודה הבאה:

     sudo yum install valkey-tools
     

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

   redis-cli --latency -h ENDPOINT_ADDRESS -p PORT
   

   אם המופע שלכם משתמש בהצפנה במעבר, צריך להוסיף את הדגל --tls ולציין את רשויות האישורים (CAs) כדי להתחבר.

   מחליפים את הפרטים הבאים:

   • ‫ENDPOINT_ADDRESS: כתובת ה-IP של נקודת הקצה של המופע.
   • ‫PORT: מספר היציאה ששמור לנקודת הקצה של המופע. בדרך כלל מספר היציאה הזה הוא 6379.

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

5. כדי להפסיק את הפקודה ולראות את התוצאות, לוחצים על Ctrl+C.

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

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

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

תרחישים של ניהול זיכרון

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

באיזה מדד אפשר להשתמש כדי לקבוע שהמופע נמצא במצב של עומס על הזיכרון?

כדי לעקוב אחרי השימוש בזיכרון במופע של Memorystore for Valkey, מומלץ להציג את המדד /instance/memory/maximum_utilization. אם השימוש בזיכרון של המופע מתקרב ל-80% ואתם צופים שהשימוש בנתונים יגדל, כדאי להגדיל את הגודל של המופע כדי לשפר את הביצועים ולפנות מקום לנתונים חדשים.

תרחישי מעקב

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

איך מגדירים התראות ל-Memorystore for Valkey?

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

תרחישים של ניהול חיבורים

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

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

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

אם זה קורה, צריך לבצע את הפעולות הבאות:

• משתמשים במדד /instance/node/stats/rejected_connections_count כדי לקבוע את מספר החיבורים ש-Memorystore for Valkey דוחה כי צומת המכונה הגיע למגבלת הלקוחות המקסימלית.
• משתמשים במדד /instance/node/clients/connected_clients כדי לקבוע את מספר הלקוחות שמחוברים לצומת המופע. כך תוכלו לראות אם כל הצמתים במופע נמצאים מתחת למגבלה.
• כדי להפסיק חיבורים לא רצויים או חיבורים שפרצו אליהם, משתמשים בפקודה client kill.
• להקטין את מספר החיבורים או את גודל המאגר באפליקציית הלקוח. מידע נוסף זמין במסמכי העזרה שקשורים לאפליקציית הלקוח.
• משנים את המגבלה על מספר הלקוחות המקסימלי. מידע נוסף מופיע במאמר בנושא הגדרת מופע.
• להגדיל את המופע לסוג צומת גדול יותר כדי שלמופע תהיה מכסת חיבורים גבוהה יותר.

תרחישים של פסק זמן

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

מה עושים אם מקבלים הודעה על פסק זמן של קלט/פלט?

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

אם מקבלים פסק זמן של קלט/פלט, מבצעים את הפעולות הבאות:

• משתמשים במדד instance/cpu/maximum_utilization כדי לקבוע את ניצול המעבד (CPU) של צומת במופע, מ-0.0 (0%) עד 1.0 (100%). מומלץ שכל הצמתים יהיו עם אחוז ניצול CPU של פחות מ-80%. מידע נוסף זמין במאמר בנושא שיטות מומלצות לשימוש במעבד.
• כשהלקוח מתנתק מהשרת כי פג הזמן הקצוב של השרת, צריך לנסות שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff) ועם Jitter. כך נמנע מצב שבו מספר לקוחות מעמיסים על השרת בו-זמנית.

תרחישים של שגיאות בקישוריות

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

שגיאת חיבור שנגרמת בגלל כללים של חומת אש

כללים בחומת האש עלולים לגרום לשגיאות בחיבור על ידי חסימת היציאות שמשמשות את Memorystore for Valkey. צריך להוסיף את כל היציאות לרשימת ההיתרים של שתי נקודות הקצה של Private Service Connect של המופע. מידע נוסף על נקודות הקצה זמין במאמר כתובות רשת שמורות.

שגיאת חיבור שנגרמת בגלל מדיניות הארגון

יכול להיות שיש לכם מדיניות ארגונית שחוסמת את החיבורים שלכם ל-Private Service Connect למופע Memorystore for Valkey.

אם במדיניות הארגון נעשה שימוש ב.restrictPrivateServiceConnectProducer policy, צריך להוסיף לרשימת ההיתרים את מספר התיקייה 672235397475, שהיא תיקייה שנועדה במיוחד ל-Memorystore for Valkey. לדוגמה:

name: organizations/Consumer-org-1/policies/compute.restrictPrivateServiceConnectProducer
spec:
    rules:
      - values:
          allowedValues:
          - under:folders/672235397475

אם במדיניות הארגון שלכם נעשה שימוש במדיניות .disablePrivateServiceConnectCreationForConsumers צריך להוסיף את SERVICE_PRODUCERS לרשימת ההיתרים. לדוגמה:

name: organizations/Consumer-org-1/policies/compute.disablePrivateServiceConnectCreationForConsumers
spec:
    rules:
      - values:
          allowedValues:
          - SERVICE_PRODUCERS

שגיאת חיבור שנגרמת בגלל חיבורים שלא מגיבים

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

• הגדרת פרמטרים של TCP keep-alive: מגדירים את הפרמטרים TCP keepalive time,‏ TCP keepalive interval ו-TCP keepalive probes כך שהלקוחות יזהו וינתקו באופן יזום חיבורים שלא מגיבים, גם כשהחיבורים לא פעילים. לדוגמה, אם מגדירים את הפרמטר TCP keepalive time ל-30 שניות, את הפרמטר TCP keepalive interval ל-10 שניות ואת הפרמטר TCP keepalive probes ל-3, הלקוחות יאפסו חיבורים לא פעילים שלא מגיבים תוך דקה.
• הגדרה של פסק זמן למשתמשים ב-TCP: מגדירים את פסק הזמן הזה בלקוחות כדי לאפס חיבורים שיש להם בקשות ממתינות ולא מגיבים. לדוגמה, אם מגדירים את הזמן הקצוב לתפוגה ל-15 שניות, הלקוחות מאפסים חיבורים שלא מגיבים שיש להם בקשות בהמתנה אחרי 15 שניות.

טיפול בשגיאות במופעים שבהם מצב האשכול מושבת

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

• במקרה של מעבר לגיבוי, החיבורים הקיימים מהאפליקציה ייסגרו ותופיע הודעת השגיאה ERR role change occurred. הודעת השגיאה הזו מוצגת גם אם האפליקציה מתחברת לנקודת הקצה לקריאה של מופע, וכל העותקים לקריאה של המופע נכשלים. במקרה כזה, האפליקציה צריכה לנסות להתחבר שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).

תרחישים של התמדה

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

תנועת הכתיבה שלך חורגת מהיכולת של Memorystore for Valkey לבצע דחיסה ולפנות מקום באמצעות שכתוב של AOF

אם זה קורה, קובץ ה-Append-Only File (AOF) גדל מהר יותר מהמהירות שבה תהליך השכתוב יכול להתמודד. כתוצאה מכך, הדיסק מתמלא, פעולות הכתיבה נכשלות והפעולות שדורשות יצירת עותק משוכפל וסנכרון מלא נחסמות.

ב-Memorystore for Valkey הוטמעו אמצעי בקרה כדי לווסת את קצב העברת הנתונים לכתיבה. כך אפשר לוודא ששכתוב קובץ ה-AOF יכול לעמוד בקצב של עומסי עבודה גבוהים ומתמשכים של כתיבה.