‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שיפור הביצועים של ה-CLI של gcloud עבור באקטים אזוריים

כש-Google Cloud CLI קורא אובייקטים מקטגוריות אזוריות ב-Rapid Bucket, הוא מחיל באופן אוטומטי הגדרות ברירת מחדל של מקביליות וחלוקה לפלחים על סמך משאבי המערכת הזמינים.

בדף הזה מתוארות הגדרות ברירת המחדל האלה ומוסבר איך אפשר להשתמש ב-CLI של gcloud כדי לשפר את הביצועים של עומסי עבודה ספציפיים. לשם כך, אפשר לשנות את הגדרות הבו-זמניות (concurrency), את קנה המידה של התהליך ואת התכונות האופציונליות (כמו בידוד של NIC) כדי לעזור לשפר את הביצועים של עומסי עבודה ספציפיים. במאמר ביצועים של Cloud Storage FUSE עבור Rapid Bucket מוסבר איך לשפר את הביצועים כשמטעינים קטגוריות אזוריות כמערכת קבצים.

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

הגדרות ברירת המחדל של מספר הבקשות המקבילות וחלוקת הנתונים

ההגדרות שמוגדרות כברירת מחדל בקטע הזה חלות באופן ספציפי כשקוראים אובייקטים מקטגוריות אזוריות ב-Rapid Bucket באמצעות ה-CLI של gcloud מגרסה 583.0.0 ואילך. בקטגוריות רגילות של Cloud Storage, ה-CLI של gcloud מחיל את הגדרות ברירת המחדל שלו לגבי מקביליות.

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

מספר התהליכים: storage/process_count
צפיפות החוטים: storage/thread_count
סף הפילוח: storage/sliced_object_download_threshold
מספר הנכסים המקסימלי: storage/sliced_object_download_max_components
גודל הרכיב: storage/sliced_object_download_component_size

הורדות של אובייקטים בודדים

כשמורידים אובייקט יחיד, ה-CLI של gcloud משתמש בערכי ברירת המחדל הבאים:

מעבדים וירטואליים זמינים	מספר התהליכים	צפיפות החוטים	סף הפילוח	מספר הרכיבים המקסימלי	גודל הרכיב
`≥ 8`	`8`	`2`	`50 MiB`	`16`	`5 MiB`
`< 8`	`4`	`2`	`50 MiB`	`8`	`5 MiB`

הורדה של כמה אובייקטים

כשמורידים כמה אובייקטים בו-זמנית, ה-CLI של gcloud משתמש בערכי ברירת המחדל הבאים:

מעבדים וירטואליים זמינים	מספר התהליכים	צפיפות החוטים	סף הפילוח	מספר הרכיבים המקסימלי	גודל הרכיב
`≥ 48`	`min(96, available_cores * 0.75)`	`1`	`10 MiB`	`5`	`5 MiB`
`4 to 47`	`16`	`4`	`10 MiB`	`10`	`5 MiB`
`< 4`	`2`	`10`	`50 MiB`	`10`	`5 MiB`

כוונון הגדרות הבו-זמניות וחלוקת המשימות

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

איך משתמשים בהגדרה

כדי להגדיר ולהחיל הגדרות של התאמה אישית, מבצעים את השלבים הבאים:

מתקינים או מעדכנים את Google Cloud CLI לגרסה 583.0.0 ואילך.
בסביבת הפיתוח, מריצים את הפקודה gcloud config configurations create כדי ליצור ולהפעיל פרופיל הגדרה:
```
gcloud config configurations create CONFIGURATION_NAME
```
מחליפים את CONFIGURATION_NAME בשם של פרופיל ההגדרות, לדוגמה, rapid-perf.
מריצים את הפקודה gcloud config set כדי להגדיר את מאפייני הבו-זמניות והפרוסות:
```
gcloud config set storage/thread_count THREAD_COUNT
gcloud config set storage/process_count PROCESS_COUNT
gcloud config set storage/sliced_object_download_threshold THRESHOLD_SIZE
gcloud config set storage/sliced_object_download_component_size COMPONENT_SIZE
gcloud config set storage/sliced_object_download_max_components MAX_COMPONENTS
```
מחליפים את ה-placeholders בערכים שמתאימים לעומס העבודה:
- ‫THREAD_COUNT: מספר השרשורים לכל תהליך עובד, למשל 1.
- ‫PROCESS_COUNT: מספר תהליכי העובד, למשל 64.
- ‫THRESHOLD_SIZE: ערך הסף המינימלי של גודל האובייקט להפעלת חלוקה לפרוסות, כמו 128 MiB לעומסי עבודה של כמה גיגה-בייט (או 32 MiB לאובייקטים קטנים יותר).
- ‫COMPONENT_SIZE: גודל היעד של כל פרוסה להורדה, למשל 128 MiB לעומסי עבודה של כמה גיגה-בייט (או 32 MiB לאובייקטים קטנים יותר).
- ‫MAX_COMPONENTS: המספר המקסימלי של רכיבי פרוסה לכל אובייקט, כמו 16.
מידע נוסף על הנכסים האלה זמין במאמר בנושא התאמה של המלצות.
מריצים את הפקודה gcloud storage cp כדי להוריד אובייקטים לנתיב האחסון המקומי:
```
gcloud storage cp -r gs://BUCKET_NAME/SOURCE_PATH/ /DESTINATION_PATH/
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BUCKET_NAME: השם של הקטגוריה האזורית.
- ‫SOURCE_PATH: נתיב המקור של ספריית קובצי המקור או האובייקט בקטגוריה.
- ‫DESTINATION_PATH: הנתיב לספרייה המקומית, כמו ./data/, או נקודת הטעינה של נפח האחסון המקומי, כמו /mnt/hyperdisk/data/.

שיפור ההמלצות

כדי לבחור ערכים מתאימים ל-placeholders בשלבים הקודמים, כדאי לעיין בהנחיות הבאות:

מספר התהליכים

מגדירים את המאפיין storage/process_count כדי לשנות את גודל התהליכים המקבילים של העובדים בהתאם לליבות ה-CPU הזמינות. להגביל את מספר התהליכים ל-80% לכל היותר ממספר הליבות הזמינות של המעבד:

storage/process_count = min(target_cores, 0.8 * available_cores)

כאשר:

‫target_cores: מספר ליבות ה-CPU או תהליכי העבודה שרוצים להקצות להעברה (למשל 64).
‫available_cores: המספר הכולל של יחידות ה-vCPU שזמינות במחשב (לדוגמה, על ידי הפעלת nproc ב-Linux).

לדוגמה, אם היעד הוא 64 תהליכי עובד, במכונות עם 80 או יותר מעבדים וירטואליים אפשר להגדיר את storage/process_count ל-64. במכונות עם פחות מ-80 יחידות vCPU, צריך להגדיר את storage/process_count ל-80% מהליבות הזמינות (לדוגמה, 51 במכונה וירטואלית עם 64 יחידות vCPU).

צפיפות החוטים

מגדירים את המאפיין storage/thread_count כדי לקבוע את מספר השרשורים לכל תהליך worker. במכונות עם 48 או יותר vCPU, מגדירים את הערך של storage/thread_count ל-1.

הגבלת כל תהליך עובד לשרשור יחיד במכונות עם ליבות רבות עוזרת לצמצם את התחרות על השרשורים ב-Python Global Interpreter Lock ‏ (GIL) וב-gRPC.

סף הפילוח

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

מומלץ להגדיר את הערך של storage/sliced_object_download_threshold כך שיהיה שווה ל-storage/sliced_object_download_component_size או גדול ממנו.

פרוסות לכל אובייקט

כדי לשלוט במספר הפרוסות המקבילות שנוצרות לכל אובייקט, מגדירים את המאפיינים storage/sliced_object_download_component_size ו-storage/sliced_object_download_max_components. ה-CLI של gcloud מחשב את הפרוסות לכל אובייקט באמצעות הנוסחה הבאה:

Slices per object = min(object_size / component_size, max_components)

אם האובייקט גדול מספיק כך שחלוקה שלו לפי הערך component_size תגרום לחריגה מהערך max_components, ה-CLI של gcloud יתעלם מהערך component_size ויחלק את האובייקט באופן שווה ל-max_components חלקים. לדוגמה, הורדה של אובייקט בגודל ‎100 GiB באמצעות component_size=128 MiB ו-max_components=16 יוצרת 16 פרוסות בגודל ‎6.25 GiB כל אחת.

כל פרוסה מורדת באופן עצמאי ובמקביל, בהתאם לקיבולת הכוללת של העובדים (storage/process_count × storage/thread_count).

רוויה של עובדים

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

Total slices across all objects >= storage/process_count * storage/thread_count

לדוגמה, נניח שרוצים להוריד ארבעה אובייקטים באמצעות 64 תהליכי עבודה (process_count=64 ו-thread_count=1):

ארבעה אובייקטים בגודל 2 GiB: ההגדרה component_size=128 MiB יוצרת 16 פרוסות לכל אובייקט (4 × 16 = 64 פרוסות), ומשתמשת באופן מלא בכל 64 תהליכי העבודה.
ארבעה אובייקטים בגודל 512 MiB: ההגדרה component_size=32 MiB יוצרת 16 פרוסות לכל אובייקט (4 × 16 = 64 פרוסות). לעומת זאת, שימוש ב-component_size=128 MiB באובייקטים בגודל 512 MiB יוצר רק 4 פרוסות לכל אובייקט (16 פרוסות בסך הכול), כך ש-48 תהליכי עובד נשארים ללא פעילות.

בידוד של כרטיס רשת

במכונות Linux עם יותר מ-16 ליבות CPU, אפשר להפעיל בידוד של כרטיס ממשק הרשת (NIC) על ידי הגדרת המאפיין storage/use_nic_isolation לערך True:

gcloud config set storage/use_nic_isolation True

כשמפעילים את המאפיין הזה, ה-CLI של gcloud מגדיר שיוך מעבד (CPU affinity) (os.sched_setaffinity()). ההגדרה הזו מבודדת 10% מליבות המעבד (CPU) לבקשות הפרעה (IRQ) של חומרת הרשת, ושומרת את הליבות הנותרות לעיבוד נתונים.