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

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

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

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

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

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

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

בקטעים הבאים מפורטים ערכי ברירת המחדל להורדות של אובייקט יחיד ושל כמה אובייקטים.

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

כשמורידים אובייקט אחד, ה-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

הגדרת מאפייני בו-זמניות וחלוקה לפרוסות

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

  1. מתקינים או מעדכנים את Google Cloud CLI לגרסה 583.0.0 ואילך.

  2. בסביבת הפיתוח, מריצים את הפקודה gcloud config configurations create כדי ליצור ולהפעיל פרופיל הגדרות:

    gcloud config configurations create CONFIGURATION_NAME

    מחליפים את CONFIGURATION_NAME בשם לפרופיל ההגדרות האישיות, למשל rapid-perf.

  3. מריצים את הפקודה 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

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫THREAD_COUNT: מספר השרשורים לכל תהליך של Worker, למשל 1.
    • ‫PROCESS_COUNT: מספר תהליכי ה-worker, למשל 64.
    • ‫THRESHOLD_SIZE: הגודל המינימלי של אובייקט שנדרש כדי להפעיל חלוקה לפרוסות, למשל 128 MiB לעומסי עבודה של כמה ג'יגה-בייט (או 32 MiB לאובייקטים קטנים יותר).
    • ‫COMPONENT_SIZE: גודל היעד של כל פרוסה להורדה, למשל 128 MiB לעומסי עבודה של כמה ג'יגה-בייט (או 32 MiB לאובייקטים קטנים יותר).
    • ‫MAX_COMPONENTS: המספר המקסימלי של רכיבי פרוסה לכל אובייקט, למשל 16.

    מידע נוסף על המאפיינים האלה זמין במאמר כוונון המלצות.

  4. כדי להוריד אובייקטים לנתיב האחסון המקומי, מריצים את הפקודה gcloud storage cp:

    gcloud storage cp -r gs://BUCKET_NAME/SOURCE_PATH LOCAL_DESTINATION_PATH

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫BUCKET_NAME: שם הקטגוריה האזורית.
    • ‫SOURCE_PATH: ספריית קובצי המקור או נתיב האובייקט בקטגוריה.
    • ‫LOCAL_DESTINATION_PATH: הנתיב לספרייה המקומית (למשל ./data/) או נקודת הטעינה של נפח האחסון המקומי (למשל /mnt/hyperdisk/data/).

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

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

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

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

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

כאשר:

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

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

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

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

הגבלת כל תהליך של Worker ל-thread יחיד במכונות עם 48 מעבדי vCPU או יותר, מפחיתה את התחרות על משאבים בין ה-threads של 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 פרוסות. לדוגמה, הורדת אובייקט של 100GiB עם component_size=128 MiB ו-max_components=16 יוצרת 16 פרוסות של 6.25GiB כל אחת.

ה-CLI של gcloud מוריד כל פרוסה בנפרד ובמקביל, בהתאם לקיבולת הכוללת של ה-workers‏ (storage/process_count × storage/thread_count).

רוויית עובדים

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

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

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

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

בידוד של כרטיס הרשת (NIC)

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

gcloud config set storage/use_nic_isolation True

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

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