פתרון בעיות שקשורות לזמן טעינה

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

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

הסבר על הסיבות לזמן אחזור גבוה

הגורמים הבאים תורמים לבעיות שקשורות לזמן האחזור ב-Bigtable:

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

לפני שמתחילים

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

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

פתרון בעיות שקשורות לזמן טעינה

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

  1. בדיקת זמן האחזור של השרת: אפשר להשתמש בדף Monitoring במסוףGoogle Cloud כדי לראות את זמן האחזור של השרת. מידע נוסף זמין במאמר בנושא מעקב באמצעות Cloud Monitoring. בודקים את זמן האחזור של המופע. אם המופע מכיל כמה אשכולות, צריך לפלח את המדד לפי אשכול. אם אתם רואים עלייה בזמן האחזור בגרפים של זמן האחזור של קריאה או כתיבה, או במדדים בצד הלקוח, פועלים לפי השלבים לפתרון בעיות שקשורות לזמן האחזור של השרת בקטע פתרון בעיות שקשורות לזמן האחזור של השרת במסמך הזה.
  2. בדיקת זמן האחזור של הלקוח: אחרי שמפעילים את המדדים בצד הלקוח, מחפשים את bigtable.googleapis.com/client ב-Metrics Explorer ב-Cloud Monitoring. מעיינים במדדים הזמינים בצד הלקוח. אם אתם רואים עלייה בזמן האחזור במדדים בצד הלקוח, אבל לא בצד השרת, כדאי לבדוק את האפליקציה ואת החיבור לרשת. מידע נוסף זמין בקטע פתרון בעיות של זמן אחזור בצד הלקוח במאמר הזה.

בתרשים הבא מוצג תהליך פתרון הבעיות של עלייה בחביון ב-Bigtable:

תרשים זרימה לפתרון בעיות שקשורות לזמן האחזור ב-Bigtable.
איור 1. תהליך פתרון הבעיות שקשורות לזמן האחזור ב-Bigtable (אפשר ללחוץ כדי להגדיל).

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

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

לפני שמתחילים

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

  • מפעילים מדדים בצד הלקוח ב-Bigtable.
  • אם אתם משתמשים בלקוח Java בגרסה 2.17.1 או בגרסה מוקדמת יותר, אתם צריכים להפעיל את האפשרות 'הכנת הערוץ'. רענון הערוץ מופעל כברירת מחדל החל מגרסה 2.18.0.
  • כדאי לחזור על התהליך כדי לקבוע את הגודל האופטימלי של מאגר החיבורים לעומס העבודה. מספר לא מספיק או מוגזם של ערוצים עלול לגרום לזמני אחזור ארוכים של ניסיונות.

בדיקת השהיות של חסימת אפליקציות

בודקים את המדד Application Blocking Latencies במסוף Google Cloud ומבצעים אחת מהפעולות הבאות:

  • אם זמני האחזור של חסימת האפליקציה גבוהים ומתאימים לעלייה בזמן האחזור שדווחה, כדאי להתמקד בפתרון בעיות בצד הלקוח.
  • אם זמן האחזור של חסימת האפליקציה גבוה והלקוח מתארח בתשתיתGoogle Cloud כמו GKE או Compute Engine, צריך להעביר את הפנייה לצוות התמיכה המתאים. Google Cloud
  • אם זמני הטעינה של חסימת האפליקציה נמוכים וגם זמני הטעינה של Bigtable נמוכים, סביר להניח שצוואר הבקבוק של זמני הטעינה נמצא ברכיב ביניים של הרישות או של נתיב תעבורת הנתונים, כמו הרשת או הקצה הקדמי של Google. כדאי להעביר את הבעיה לטיפול של Google Cloud צוות הרשתות כדי שיעזרו לך ללכוד את כל החבילות ולזהות את צוואר הבקבוק של זמן האחזור.

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

  1. אם הערך של connectivity_error_count גבוה, לאפליקציה קשה להגיע לחלק הקדמי של Google. הגדרת פסק זמן נמוך יותר של RPC כדי שהבקשה תוכל לנסות שוב בערוצים שונים.
    • אם הזמן הקצוב לתפוגה של RPC נמוך מדי, הוא עלול לגרום גם לזמני אחזור גבוהים של פעולות. קובעים את הזמן הקצוב לתפוגה האופייני של RPC ב-P99 במהלך פעולות רגילות. הגדרת ערך פסק זמן של RPC שקרוב יותר לערך הזה תעזור לכם לשפר את הביצועים.
  2. אם הערך של retry_count גבוה, בודקים את תג הסטטוס attempt_latencies. אם הניסיונות נכשלים עם שגיאות DEADLINE_EXCEEDED, משמעות הדבר היא שמועד סיום הבקשה קצר מדי בהשוואה לזמן התגובה הממוצע attempt_latencies.

בקשות לכתובות שממתינות בתור בשרשור gRPC

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

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

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

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

האם העומס על האשכול גבוה מדי

  1. בודקים את הגרפים Read requests ו-Write requests כדי לראות אם יש שינויים ב-QPS.
  2. בודקים את התרשים Node count כדי לראות אם יש שינויים במספר הצמתים.
  3. בודקים את התרשימים Read throughput ו-Write throughput כדי לראות אם יש עלייה ברוחב הפס. מידע נוסף זמין במאמר בנושא הסבר על הביצועים.
  4. כדי לזהות איך המעבד (CPU) נמצא בשימוש בפרופיל האפליקציה, בשיטה ובטבלה כדי לפתור בעיות בביצועים, אפשר לעיין בפוסט בבלוג Where is your Cloud Bigtable cluster spending its CPU?‎.
  5. הגדלת מספר הצמתים באשכול המושפע. מידע נוסף זמין במאמרים הוספה או הסרה של צמתים באופן ידני והתאמה אוטומטית לעומס. מוודאים שהשימוש הממוצע במעבד נשאר מתחת לסף המומלץ.

בדיקה אם יש נקודות לשיתוף אינטרנט

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

  1. אפשר לראות את האזורים הפעילים בתרשים CPU utilization (hottest node) high granularity.
  2. כדי לזהות טאבלטים פופולריים, אפשר להשתמש בhot tablets או בכלי Key Visualizer.
  3. בניגוד לניצול יתר של CPU ברמת האשכול, שאפשר לצמצם אותו בדרך כלל על ידי הוספת צמתים (הרחבה אופקית), יכול להיות שיהיה צורך בטכניקות אחרות כדי לצמצם את ההשפעה של נקודות חמות. הטכניקות האלה כוללות שינוי של אופן בניית מפתחות השורה או שינוי הסכימה. מידע נוסף זמין בפוסט בבלוג בנושא הסרת נקודות חמות ב-Cloud Bigtable.

טיפול בזמן אחזור עם QPS נמוך

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

  1. אם התרשימים Read requests ו-Write requests מציגים QPS נמוך, צפויים זמני תגובה איטיים יותר.
  2. כדי לצמצם את הבעיות שקשורות להפעלה במצב התחלתי, כדאי לפעול לפי השיטות המומלצות שמתוארות במאמר הפעלה במצב התחלתי וערכי QPS נמוכים.

הערכת היעילות של הבקשה

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

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

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

העברה לטיפול ברמה גבוהה יותר בתמיכה של Bigtable

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

המאמרים הבאים