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

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

כשניגשים לממשקי ה-API של Spanner, יכול להיות שהבקשות ייכשלו בגלל שגיאות DEADLINE_EXCEEDED. השגיאה הזו מציינת שלא התקבלה תשובה בפרק הזמן הקצוב שהוגדר.

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

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

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

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

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

מהי שגיאת חריגה מהמועד האחרון?

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

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

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

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

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

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

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

בדיקת העומס על המעבד (CPU) במכונה של Spanner

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

רזולוציה

במאמר הפחתת ניצול המעבד (CPU) מוסבר איך להפחית את ניצול המעבד (CPU) של המכונה.

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

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

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

רזולוציה

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

בעיות ב-Google Data API

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

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

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

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

רזולוציה

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

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

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

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

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

רזולוציה

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

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

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

רזולוציה

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

חיפוש נקודות לשיתוף אינטרנט

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

רזולוציה

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

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

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

רזולוציה

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

בעיות ב-Admin API

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

רזולוציה

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

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

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

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

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

רזולוציה

אתם יכולים לשכתב את השאילתה בעזרת המדריך לשיטות מומלצות לשאילתות SQL.

בעיות ב-Dataflow

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

רזולוציה

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

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

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 Front End, אבל זמן אחזור קצר בבקשות ל-Spanner API
  • זמן אחזור ארוך של בקשת Spanner API, אבל זמן אחזור קצר של שאילתה

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