פתרון בעיות של צווארי בקבוק ב-Dataflow

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

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

הסבר על צווארי בקבוק

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

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

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

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

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

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

סוגים של צווארי בקבוק

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

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

הגורמים לצווארי בקבוק

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

פעולות עם זמן עיבוד ארוך

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

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

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

התחייבות למפתח גדולה מדי

ראו חריגה: התחייבות המפתח גדולה מדי.

זמן עיבוד ארוך בכל הפעולות

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

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

בודקים ביומני העובדים אם יש שגיאות, חריגים או עקבות מחסנית שמציינים שהשרשורים איטיים או תקועים. אם אתם משתמשים ב-Apache Beam SDK ל-Python, והפעולות הן ארוכות טווח מטבען (לדוגמה, קריאות איטיות ל-API חיצוני או קלט/פלט עם חביון גבוה), כדאי להשתמש ב-Async DoFn. התכונה הזו יכולה לשפר את קצב העברת הנתונים כי היא מונעת חסימה של העיבוד במשימות הארוכות האלה.

קריאה איטית של מצב מתמשך

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

כתיבה איטית של מצב קבוע

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

שליחת שינויים שנדחתה

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

אין מספיק מחיצות במקור Apache Kafka

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

  • הגדלת מספר המחיצות של Kafka.
  • כדי להפיץ מחדש את הנתונים בצורה יעילה יותר, צריך להוסיף את האפשרות .withRedistribute() כשמגדירים את הקריאה של Kafka IO במקביל. ‫Include .withRedistributeNumKeys(N) where N > partitions to provide an upper bound on the total number of keys. מספר מוגבל של מפתחות מאפשר יעילות באמצעות חבילת רשומות.
  • כדי לצמצם את העלות של ערבוב מחדש של ההפצה, משתמשים ב-.withOffsetDeduplication(). במצב הזה, כמות הנתונים שצריך לשמור כחלק מהערבוב היא מינימלית, ועדיין מתבצע עיבוד של כל נתון בדיוק פעם אחת.

מידע נוסף זמין במאמר בנושא מקביליות בדף קריאה מ-Apache Kafka אל Dataflow.

מקור Apache Kafka עם נפח גדול של מצב מתמשך

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

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

מידע נוסף זמין במאמר בנושא קריאה מ-Apache Kafka ל-Dataflow.

מקביליות המקור לא מספיקה

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

מקשי קיצור או מקביליות לא מספקת של מקשים

למשימה יש מקשי קיצור או שהמקביליות של המקשים לא מספיקה.

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

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

הקצאת-חסר של מעבדים וירטואליים

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

ניצול גבוה של vCPU, בהמתנה להגדלה

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

עומס לא מאוזן של vCPU שיוצר צווארי בקבוק בחלק מהעובדים החריגים

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

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:

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

ל-Dataflow אין אפשרות לתקשר עם כל מכונות ה-VM של העובדים. בודקים את הסטטוס של המכונות הווירטואליות של העובדים של המשימה. סיבות אפשריות:

  • יש בעיה בהקצאת מכונות וירטואליות של העובדים.
  • מאגר ה-worker VM נמחק בזמן שהעבודה פועלת.
  • בעיות ברשת.
יש שגיאות בשליפה ממקור Pub/Sub.

יש שגיאות בשליפה ממקור Pub/Sub. בודקים שקיימים הנושא והמינויים הנדרשים, ומאמתים את המכסה וההגדרה. אפשר גם לבדוק אם יש שגיאות ביומנים.

במקור Pub/Sub אין מספיק מקביליות

בחישוב של מקור Pub/Sub אין מספיק מפתחות Pub/Sub. כדי להגדיל את מספר המקשים, מגדירים את האפשרות num_pubsub_keys בשירות. מידע נוסף על מקורות מקבילים ב-Pub/Sub

הגבלת קצב העברת הנתונים ממקור Pub/Sub מסיבה לא ידועה

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

שליחת נתונים ליעד Pub/Sub איטית או תקועה

החישוב של יעד Pub/Sub איטי או תקוע. יכול להיות שהבעיה הזו נובעת מבעיה בהגדרות או ממגבלת מכסה.

זמן המתנה ארוך בתור העבודה

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

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

(key count / total harness threads) * latency per bundle

אפשר לנסות את הפתרונות הבאים:

בעיה זמנית בשרת העורפי של מנוע הסטרימינג

יש בעיה בהגדרות או בתפעול של ה-backend של Streaming Engine. יכול להיות שזו בעיה זמנית. אם הבעיה נמשכת, אפשר לפנות לתמיכה.

סיבה שלא ניתן לקבוע

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

מדדים של צווארי בקבוק

מדדי העבודות הבאים מספקים מידע על צווארי בקבוק:

  • ‫job/is_bottleneck: האם שלב ספציפי בפייפליין של Dataflow הוא צוואר בקבוק, ומה סוג צוואר הבקבוק והסיבה האפשרית.

  • ‫job/backlogged_keys: מספר המפתחות שהצטברו בשלב של צוואר בקבוק.

  • ‫job/recommended_parallelism: רמת המקביליות המומלצת לשלב מסוים כדי לצמצם את צוואר הבקבוק.

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