פתרון בעיות שקשורות לעבודות אצווה איטיות או תקועות

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

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

זיהוי שורש הבעיה

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

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

   All workers have finished the startup processes and began to receive work requests
   

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

3. בודקים ביומני job-message אם יש בעיות כמו חריגה ממכסות, בעיות במלאי או מיצוי של כתובות IP.

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

5. בודקים אם יש עבודות שלא הסתיימו. מידע נוסף מופיע במאמר בנושא פתרון בעיות של משימות שמתעכבות בעבודות אצווה.

6. בודקים את מדדי התפוקה, המעבד (CPU) והשימוש בזיכרון.

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

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

8. בדיקה של מקשי קיצור

9. אם אתם לא משתמשים ב-ארגון נתונים של Dataflow, כדאי לבדוק את היומנים של פעולת ה-Shuffle כדי לראות אם יש אזהרות ושגיאות במהלך פעולת ה-Shuffle. אם מופיעה שגיאת זמן קצוב לתפוגה של RPC ביציאה 12345 או 12346, יכול להיות שחסר כלל חומת אש בעבודה. כללים של חומת אש ל-Dataflow

10. אם Runner v2 מופעל, צריך לבדוק את היומנים של harness כדי לראות אם יש שגיאות. למידע נוסף, ראו פתרון בעיות ב-Runner v2.

זיהוי של משתמשים שלא סיימו את התהליך

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

זיהוי שלבים איטיים או תקועים

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

אחרי שמאתרים את צוואר הבקבוק, אפשר לבצע את השלבים הבאים:

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

זיהוי עובד עם פיגור

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

• צפייה בקובצי היומן של העובד. מידע נוסף זמין במאמר בנושא מעקב אחרי יומנים של צינורות נתונים וצפייה בהם.
• אפשר לראות את מדדי השימוש במעבד ואת הפרטים של התקדמות העובדים כדי לזהות עובדים שמתעכבים. אם אתם רואים שימוש גבוה או נמוך באופן חריג ב-CPU, בקובצי היומן של העובד, חפשו את הבעיות הבאות:
  • A hot key ... was detected
  • Processing stuck ... Operation ongoing

כלים לניפוי באגים

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

• כדי ליצור קורלציה בין אירועים ולזהות צווארי בקבוק, אפשר להשתמש ב-Cloud Monitoring for Dataflow.
• כדי לעקוב אחרי הביצועים של צינור עיבוד הנתונים, משתמשים ב-Cloud Profiler.
• חלק מהטרנספורמציות מתאימות יותר לצינורות להעברת נתונים בכמויות גדולות מאחרות. הודעות ביומן יכולות לזהות טרנספורמציה של משתמש שנתקעה בצינורות של עיבוד באצווה או של עיבוד בזמן אמת.
• כדי לקבל מידע נוסף על משימה תקועה, אפשר להשתמש במדדים של משימות Dataflow. הרשימה הבאה כוללת מדדים שימושיים:
  • המדד Backlog bytes (backlog_bytes) מודד את כמות הקלט שלא עבר עיבוד בבייטים לפי שלב. אפשר להשתמש במדד הזה כדי למצוא שלב משולב שאין לו תפוקה. באופן דומה, המדד של רכיבי ה-backlog‏ (backlog_elements) מודד את מספר רכיבי הקלט שלא עברו עיבוד בשלב מסוים.
  • המדד Processing parallelism keys (processing_parallelism_keys) מודד את מספר מפתחות העיבוד המקבילי בשלב מסוים של צינור הנתונים בחמש הדקות האחרונות. אפשר להשתמש במדד הזה כדי לחקור את הבעיות הבאות:
    • מצמצמים את הבעיה לשלבים ספציפיים ומאשרים את האזהרות לגבי מקשי קיצור, כמו A hot key ... was detected.
    • איתור צווארי בקבוק בנפח הנתונים שמועברים שנגרמים בגלל חוסר מספיק של מקביליות. צווארי בקבוק כאלה עלולים לגרום לצינורות נתונים איטיים או תקועים.
  • המדד System lag (system_lag) והמדד per-stage system lag (per_stage_system_lag) מודדים את משך הזמן המקסימלי שפריט נתונים עובר עיבוד או ממתין לעיבוד. אפשר להשתמש במדדים האלה כדי לזהות שלבים לא יעילים וצווארי בקבוק במקורות הנתונים.

למדדים נוספים שלא נכללים בממשק האינטרנט של Dataflow לניטור, אפשר לעיין ברשימה המלאה של מדדי Dataflow במדדים של Google Cloud Platform.