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

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

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

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

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

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

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

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

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

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

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

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

  • יש בעיה בהקצאת מכונות וירטואליות של העובדים.
  • מאגר ה-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

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

  • הגדלת מספר העובדים. אפשר לקרוא מידע נוסף במאמר בנושא שינוי גודל אוטומטי של סטרימינג.
  • הגדלת מספר השרשורים של Worker Harness. מגדירים את אפשרות הצינור ‏numberOfWorkerHarnessThreads / number_of_worker_harness_threads.
  • צריך לצמצם את מספר המפתחות.
  • הפחתת זמן האחזור של הפעולה.
בעיה זמנית בשרת העורפי של מנוע הסטרימינג

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

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

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

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

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

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