פתרון בעיות בהתאמה אוטומטית לעומס ב-Dataflow

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

המשימה לא גדלה או קטנה בהתאם לעומס

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

לא מתבצעת סילומיות אנכית (scale up) למשימת סטרימינג

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

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

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

אי אפשר להגדיל את נפח העבודה של משימות באצווה ובסטרימינג

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

הבעיה הזו יכולה לקרות בגלל אחת מהסיבות הבאות:

• אין גישה לקבצים הזמניים או לקבצים שמועברים לסביבת Staging. אם העבודה שלכם משתמשת בקטגוריה של Cloud Storage, יכול להיות שלקטגוריה יש הגדרת מחזור חיים שמוחקת אובייקטים בקטגוריה. האובייקטים שנמחקו כוללים תיקיות וקבצים של staging ו-temp. כדי לוודא שהקבצים נמחקו, צריך לבדוק את ההגדרה של מחזור החיים לקטגוריה. אם תיקיות או קבצים זמניים או שלבי ביניים נמחקו אחרי שהעבודה התחילה, יכול להיות שהחבילות שנדרשות ליצירת עובדים חדשים לא קיימות. כדי לפתור את הבעיה, צריך ליצור מחדש את התיקיות והקבצים בדלי.
• כללי חומת האש מונעים מהעובדים לשלוח ולקבל תעבורת נתונים ביציאות ה-TCP הנדרשות. יכול להיות שכללים של חומת האש ימנעו את הפעלת העובדים. לעובדי Dataflow צריכה להיות אפשרות לשלוח ולקבל תנועה ביציאות TCP‏ 12345 ו-12346. למידע נוסף, כולל שלבים לפתרון הבעיה, אפשר לעיין במאמר בנושא כללים של חומת אש ב-Dataflow.
• למקור בהתאמה אישית יש שיטה getProgress() שמחזירה ערך NULL. כשמשתמשים במקור מותאם אישית, מדדי ה-backlog מסתמכים על ערך ההחזרה של שיטת getProgress() במקור המותאם אישית כדי להתחיל לאסוף נתונים. ההטמעה של getProgress() שמוגדרת כברירת מחדל מחזירה ערך NULL. כדי לפתור את הבעיה, צריך לוודא שמקור הנתונים המותאם אישית מחליף את שיטת ברירת המחדל getProgress() ומחזיר ערך שאינו NULL.
• עדכון שמופעל על ידי שינוי גודל אוטומטי אנכי משבית באופן זמני את שינוי הגודל האוטומטי האופקי. מידע נוסף זמין במאמר בנושא ההשפעה על שינוי גודל אוטומטי אופקי.
• אם אתם משתמשים בפעולה map בצינור Python והעבודה לא מתרחבת, יכול להיות שתצטרכו להוסיף Reshuffle טרנספורמציה לקוד של צינור העבודה. מידע נוסף מופיע במאמר בנושא Reshuffle במסמכי התיעוד של Apache Beam.

לא מתבצעת הפחתה בהתאם לעומס בעבודת סטרימינג

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

• כשעבודות לא משתמשות ב-Streaming Engine, ‏ Dataflow מאזן את מספר הדיסקים הקבועים בין העובדים. כתוצאה מכך, לכל עובד צריך להיות מספר שווה של דיסקים קשיחים. לדוגמה, אם יש 100 דיסקים ו-100 עובדים, לכל עובד יש דיסק אחד. כשמצמצמים את היקף העבודה, יכולים להיות 50 עובדים עם שני דיסקים קבועים לכל עובד. העבודה לא תצטמצם שוב עד שיהיו 25 עובדים עם ארבעה דיסקים קבועים לכל עובד. בנוסף, המספר המינימלי של עובדים הוא הערך שמוקצה ל-maxNumWorkers חלקי 15. מידע נוסף זמין במאמר טווח שינוי הגודל של צינורות להתאמה אוטומטית לעומס של סטרימינג.

• כשמשתמשים ב-Streaming Engine לעיבוד משימות, יעד ההקטנה מבוסס על יעד ניצול CPU של 75%. אם אי אפשר להגיע לניצול המעבד הזה, ההקטנה מושבתת.

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

• ‫PeriodicImpulse נתמך בגרסאות 2.60.0 ואילך של Apache Beam SDK. כשמשתמשים ב-PeriodicImpulse בצינור עיבוד עם גרסאות SDK של Apache Beam‏ 2.59.0 ומטה, העובדים ב-Dataflow לא מצטמצמים כמו שצריך.

הגדלת מספר העצירות

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

הבעיה הזו מתרחשת כשמגיעים למגבלות של מכסת השימוש.

• מכסות ב-Compute Engine: המכסות של Compute Engine בפרויקט חלות על משימות Dataflow. אם כמה עבודות פועלות, יכול להיות שהפרויקט הגיע למגבלה של מכסת Compute Engine. במקרה כזה, Dataflow לא יכול להגדיל את מספר העובדים.
• מכסות CPU: גם משימות Dataflow כפופות למכסת ה-CPU של הפרויקט. אם סוג העובד משתמש ביותר ממעבד אחד, יכול להיות שהפרויקט הגיע למגבלת מכסת המעבד.
• מכסות של כתובות IP חיצוניות: כשג'וב משתמש בכתובות IP חיצוניות כדי לתקשר עם משאבים, צריך מספר כתובות IP חיצוניות ששווה למספר העובדים. ככל שמספר העובדים גדל, כך גדל גם מספר כתובות ה-IP החיצוניות. כשמגיעים למגבלת כתובות ה-IP, העובדים מפסיקים להגדיל את קנה המידה.

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

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

ההצעה לניצול העובדים לא משפיעה

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

כדי להבין את הבעיה הזו, עוברים אל תרשים השימוש במעבד של העובד ובודקים אם רמז השימוש בעובד נמצא בשימוש פעיל. אם נעשה שימוש ברמז, התרשים יציג CPU utilization hint (actively used by autoscaler). אחרת, מוצגות האפשרויות CPU utilization hint (not actively used by autoscaler).

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

התנהגות ההתאמה שנצפתה	למען הקהילה	מדדים שכדאי לבדוק
ללא שינוי	הגעתם למספר המינימלי או המקסימלי של עובדים. מספר העובדים מוגבל על ידי מספר המפתחות שעוברים עיבוד במקביל. ההגבלה של משימות מתבצעת על ידי RPC חיצוניים. ההתאמה להקטנת קנה המידה קטנה מדי או ש-Dataflow ממתן את הקטנת קנה המידה. מידע נוסף זמין במאמר בנושא היוריסטיקה של שינוי גודל אוטומטי של סטרימינג.	job/aggregated_worker_utilization job/max_worker_instances_limit job/min_worker_instances_limit job/processing_parallelism_keys שגיאות RPC שדווחו ביומני השגיאות של העובד קריסות שדווחו ביומני עובדים
הגדלת נפח הפעילות	הצטברות גדולה של בקשות או יעד זמן טעינה ארוך מבטלים את ההצעה. המספר המינימלי של העובדים עודכן לערך גבוה יותר מהמספר הנוכחי של העובדים.	job/aggregated_worker_utilization job/backlog_bytes job/backlog_elements job/estimated_timer_backlog_processing_time job/min_worker_instances_limit
הקטנת קנה מידה	המספר המקסימלי של העובדים עודכן לערך נמוך יותר מהמספר הנוכחי של העובדים.	job/aggregated_worker_utilization job/max_worker_instances_limit

מידע נוסף זמין במאמר בנושא היוריסטיקה של שינוי גודל אוטומטי בסטרימינג.

פערים במדדים של התאמה לעומס (autoscaling)

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

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

המעבד (CPU) לא מחולק באופן שווה

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

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

מידע נוסף זמין בהנחיות בנושא שגיאות במקשי קיצור.

פריט העבודה שמבקש לקרוא את המצב כבר לא תקף בשרת העורפי

במהלך תקשורת בין מופעי worker VM לבין משימות של Streaming Engine בצינור עיבוד נתונים של סטרימינג, מתרחשת השגיאה הבאה:

The work item requesting state read is no longer valid on the backend.
The work has already completed or will be retried.
This is expected during autoscaling events.

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

אין מספיק משאבים של מנוע הסטרימינג

אם Streaming Engine לא יכול להקצות את המספר המינימלי של העובדים שביקשתם, השגיאה הבאה מוחזרת:

Streaming Engine does not currently have enough resources available to fulfill
the request.

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

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

בקטע הזה מפורט טווח ההתאמה לעומס של צינורות להתאמה אוטומטית לעומס של סטרימינג.

Java

לגבי משימות של שינוי גודל אוטומטי של סטרימינג שלא משתמשות ב-Streaming Engine, שירות Dataflow מקצה בין 1 ל-15 Persistent Disks לכל עובד. ההקצאה הזו אומרת שמספר העובדים המינימלי שמשמשים לצינור התאמה אוטומטית לעומס של סטרימינג הוא N/15, כאשר N הוא הערך של --maxNumWorkers.

למשימות של התאמה אוטומטית לעומס של סטרימינג שמשתמשות ב-Streaming Engine, מספר העובדים המינימלי הוא 1.

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

הערך של --maxNumWorkers יכול להיות 1,000 לכל היותר.

Python

לגבי משימות של שינוי גודל אוטומטי של סטרימינג שלא משתמשות ב-Streaming Engine, שירות Dataflow מקצה בין 1 ל-15 Persistent Disks לכל עובד. ההקצאה הזו אומרת שמספר העובדים המינימלי שמשמשים לצינור התאמה אוטומטית לעומס של סטרימינג הוא N/15, כאשר N הוא הערך של --max_num_workers.

למשימות של התאמה אוטומטית לעומס של סטרימינג שמשתמשות ב-Streaming Engine, מספר העובדים המינימלי הוא 1.

‫Dataflow מאזן את מספר הדיסקים הקשיחים בין העובדים. לדוגמה, אם נדרשים שלושה או ארבעה עובדים בצינור במצב יציב, אפשר להגדיר --max_num_workers=15. הצינור מתרחב אוטומטית בין 1 ל-15 עובדים, באמצעות 1, 2, 3, 4, 5, 8 או 15 עובדים, שמתאימים ל-15, 8, 5, 4, 3, 2 או 1 דיסקים קשיחים קבועים לכל עובד, בהתאמה.

הערך של --max_num_workers יכול להיות 1,000 לכל היותר.

Go

לגבי משימות של שינוי גודל אוטומטי של סטרימינג שלא משתמשות ב-Streaming Engine, שירות Dataflow מקצה בין 1 ל-15 Persistent Disks לכל עובד. ההקצאה הזו אומרת שמספר העובדים המינימלי שמשמשים לצינור התאמה אוטומטית לעומס של סטרימינג הוא N/15, כאשר N הוא הערך של --max_num_workers.

למשימות של התאמה אוטומטית לעומס של סטרימינג שמשתמשות ב-Streaming Engine, מספר העובדים המינימלי הוא 1.

‫Dataflow מאזן את מספר הדיסקים הקשיחים בין העובדים. לדוגמה, אם נדרשים שלושה או ארבעה עובדים בצינור במצב יציב, אפשר להגדיר --max_num_workers=15. הצינור מתרחב אוטומטית בין 1 ל-15 עובדים, באמצעות 1, 2, 3, 4, 5, 8 או 15 עובדים, שמתאימים ל-15, 8, 5, 4, 3, 2 או 1 דיסקים קשיחים קבועים לכל עובד, בהתאמה.

הערך של --max_num_workers יכול להיות 1,000 לכל היותר.

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

Java

‫Dataflow פועל במסגרת המגבלות של מכסת מספר המכונות של Compute Engine בפרויקט או maxNumWorkers, לפי הנמוך מביניהם.

Python

‫Dataflow פועל במסגרת המגבלות של מכסת מספר המכונות של Compute Engine בפרויקט או max_num_workers, לפי הנמוך מביניהם.

Go

‫Dataflow פועל במסגרת המגבלות של מכסת מספר המכונות של Compute Engine בפרויקט או max_num_workers, לפי הנמוך מביניהם.

הגבלת התאמה אוטומטית לעומס כדי להפחית את ההשפעה על החיוב

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

Java

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

Python

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

Go

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

שינוי טווח קנה המידה

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

השבתת שינוי גודל אוטומטי בצינורות סטרימינג

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

Java

מגדירים את --autoscalingAlgorithm=NONE. מידע נוסף זמין במאמר בנושא השבתה של שינוי גודל אוטומטי אופקי.

Python

מגדירים את --autoscaling_algorithm=NONE. מידע נוסף זמין במאמר בנושא השבתה של שינוי גודל אוטומטי אופקי.

Go

מגדירים את --autoscaling_algorithm=NONE. מידע נוסף זמין במאמר בנושא השבתה של שינוי גודל אוטומטי אופקי.

שימוש במספר קבוע של עובדים

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