פתרון בעיות שקשורות לחריגה מהזמן הקצוב לתפוגה ב-Spanner

בדף הזה מוסבר על שגיאות מסוג deadline exceeded ב-Spanner: מה הן, למה הן מתרחשות ואיך לפתור אותן.

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

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

הדדליין של Spanner והגישה לניסיון חוזר

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

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

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

מהי שגיאה של חריגה מתאריך היעד?

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

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

מידע נוסף על מועדים סופיים ב-gRPC זמין במאמר gRPC ומועדים סופיים.

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

יכול להיות שתיתקלו בשגיאות DEADLINE_EXCEEDED עבור סוגי הבעיות הבאים:

בעיות ב-API של גישה לנתונים

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

בדיקת העומס על המעבד של מופע Spanner

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

רזולוציה

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

בדיקת פירוט של זמן האחזור מקצה לקצה של הבקשה

כשבקשה עוברת מהלקוח לשרתי Spanner ובחזרה, היא עוברת כמה צעדים ברשת: מספריית הלקוח אל ממשק הקצה של Google‏ (GFE), מה-GFE אל ממשק הקצה של Spanner API, ולבסוף מממשק הקצה של Spanner API אל מסד הנתונים של Spanner. אם יש בעיות ברשת באחד מהשלבים האלה, יכול להיות שיוצגו שגיאות של חריגה מהמועד האחרון.

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

רזולוציה

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

בעיות ב-Data API

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

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

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

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

רזולוציה

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

בדיקה של תחרות על נעילה

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

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

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

רזולוציה

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

בדיקה של סכימות לא אופטימליות

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

רזולוציה

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

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

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

רזולוציה

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

בדיקה של הגדרות זמן קצוב לתפוגה שהוגדרו בצורה שגויה

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

רזולוציה

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

בעיות ב-Admin API

בקשות Admin API הן פעולות יקרות בהשוואה לבקשות Data API. יכול להיות שיעברו כמה שניות עד שתתקבל תשובה לבקשות אדמין כמו CreateInstance, CreateDatabase או CreateBackups. ספריות הלקוח של Spanner מגדירות מועדים של 60 דקות לבקשות של מופעים ושל מסדי נתונים. כך השרת יוכל להשלים את הבקשה לפני שהלקוח ינסה שוב או שהפעולה תיכשל.

רזולוציה

אם אתם משתמשים בספריית הלקוח של Google Spanner כדי לגשת אל Admin API, ודאו שספריית הלקוח מעודכנת ושהיא משתמשת בגרסה העדכנית ביותר. אם אתם ניגשים ל-Spanner API ישירות דרך ספריית לקוח שיצרתם, ודאו שאין לכם הגדרות תוקפניות יותר של מועד אחרון מההגדרות שמוגדרות כברירת מחדל (60 דקות) עבור בקשות של מנהלי מופע ומסד נתונים.

Google Cloud בעיות במסוף

משך הזמן של שאילתות שמופעלות מהדף של Spanner Studio במסוף Google Cloud לא יכול להיות יותר מחמש דקות. אם תיצרו שאילתה יקרה שיידרכו יותר מחמש דקות להרצה שלה, תוצג הודעת השגיאה הבאה:

צילום מסך של הודעת השגיאה 'חריגה מהמועד האחרון של המסוף' Google Cloud

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

רזולוציה

אפשר לשכתב את השאילתה באמצעות השיטות המומלצות לשימוש בשאילתות SQL.

בעיות ב-Dataflow

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

רזולוציה

אם מתרחשת שגיאה שקשורה לחריגה ממועד סיום בשלבים ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions, כדאי לבדוק את טבלת הנתונים הסטטיסטיים של השאילתות כדי לגלות איזו שאילתה סרקה מספר גדול של שורות. לאחר מכן, משנים את השאילתות האלה כדי לנסות לקצר את זמן הביצוע.

דוגמה נוספת לשגיאה מסוג Dataflow deadline exceeded מוצגת בהודעת החריגה הבאה:

exception:
     org.apache.beam.sdk.util.UserCodeException:
     com.google.cloud.spanner.SpannerException: DEADLINE_EXCEEDED:
     io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after
     3599.999905380s.
     [remote_addr=batch-spanner.googleapis.com/172.217.5.234:443] at
 org.apache.beam.runners.dataflow.worker.GroupAlsoByWindowsParDoFn$1.output(GroupAlsoByWindowsParDoFn.java:184)

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

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

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

  • זמן אחזור ארוך של ממשק קצה של Google‏ (GFE), אבל זמן אחזור קצר של בקשות Spanner API
  • זמן אחזור גבוה של בקשת Spanner API, אבל זמן אחזור נמוך של שאילתה

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