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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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