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

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

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

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

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

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

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

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

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

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

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

• אין גישה לקבצים הזמניים או לקבצים שמועברים לבמה. אם העבודה שלכם משתמשת בקטגוריה של Cloud Storage, יכול להיות שיש לקטגוריה הגדרות מחזור חיים שמוחקות אובייקטים בקטגוריה. האובייקטים שנמחקו כוללים תיקיות וקבצים זמניים. כדי לוודא שהקבצים נמחקו, צריך לבדוק את ההגדרה של מחזור החיים לקטגוריה. אם תיקיות או קבצים זמניים או שלבי ביניים נמחקו אחרי שהמשימה התחילה, יכול להיות שהחבילות שנדרשות ליצירת עובדים חדשים לא קיימות. כדי לפתור את הבעיה, צריך ליצור מחדש את התיקיות והקבצים בדלי.
• כללי חומת האש מונעים מהעובדים לשלוח ולקבל תעבורת נתונים ביציאות ה-TCP הנדרשות. יכול להיות שכללים של חומת האש ימנעו את הפעלת העובדים. לעובדי Dataflow צריכה להיות אפשרות לשלוח ולקבל תנועה ביציאות TCP‏ 12345 ו-12346. למידע נוסף, כולל שלבים לפתרון הבעיה, אפשר לעיין במאמר בנושא כללים של חומת אש ב-Dataflow.
• למקור בהתאמה אישית יש שיטת getProgress() שמחזירה ערך NULL. כשמשתמשים במקור מותאם אישית, מדדי ה-backlog מסתמכים על ערך ההחזרה של שיטת getProgress() במקור המותאם אישית כדי להתחיל לאסוף נתונים. ההטמעה של getProgress() שמוגדרת כברירת מחדל מחזירה ערך NULL. כדי לפתור את הבעיה, צריך לוודא שהמקור המותאם אישית מחליף את שיטת ברירת המחדל getProgress() ומחזיר ערך שאינו NULL.
• עדכון שמופעל על ידי התאמה אוטומטית של משאבים אנכיים משבית באופן זמני את ההתאמה האוטומטית של משאבים אופקיים. מידע נוסף זמין במאמר בנושא ההשפעה על שינוי גודל אוטומטי אופקי.
• אם אתם משתמשים בפעולה map בצינור Python והעבודה לא מתרחבת, יכול להיות שתצטרכו להוסיף Reshuffle transform לקוד של צינור העבודה. מידע נוסף מופיע במאמר בנושא 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 בצינור עם Apache Beam SDK בגרסאות 2.59.0 ומטה, העובדים של Dataflow לא מצטמצמים כמו שצריך.

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

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

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

• מכסות של Compute Engine: עבודות של Dataflow כפופות למכסה של Compute Engine בפרויקט. אם כמה משימות פועלות, יכול להיות שהפרויקט יגיע למגבלת המכסות של 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 אחד, ולכן אי אפשר לחלק את העבודה בין כמה workers.

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

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

במהלך תקשורת בין מופעי 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.

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

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

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

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

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

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

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

Java

למשימות של התאמה אוטומטית לעומס של סטרימינג שלא משתמשות ב-Streaming Engine, שירות Dataflow מקצה בין 1 ל-15 Persistent Disk לכל worker. ההקצאה הזו אומרת שמספר ה-workers המינימלי שמשמשים לפייפליין של התאמה אוטומטית לעומס של סטרימינג הוא 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 Disk לכל worker. ההקצאה הזו אומרת שמספר ה-workers המינימלי שמשמשים לפייפליין של התאמה אוטומטית לעומס של סטרימינג הוא 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 לכל היותר.

המשך

למשימות של התאמה אוטומטית לעומס של סטרימינג שלא משתמשות ב-Streaming Engine, שירות Dataflow מקצה בין 1 ל-15 Persistent Disk לכל worker. ההקצאה הזו אומרת שמספר ה-workers המינימלי שמשמשים לפייפליין של התאמה אוטומטית לעומס של סטרימינג הוא 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, לפי הנמוך מביניהם.

המשך

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

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

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

Java

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

Python

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

המשך

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

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

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

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

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

Java

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

Python

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

המשך

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

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

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