פתרון בעיות בתוכניות הלימודים בענן

לפני שמתחילים

במאמר הזה מוסבר איך לפתור בעיות שקשורות לעומסי עבודה ב-Pathways.

צפייה ביומנים

ב-Logs Explorer של Cloud Logging, משתמשים בשאילתה הבאה, שמותאמת לפרויקט, לאזור, לאשכול ולעומס העבודה שלכם.

resource.type="k8s_container"
resource.labels.project_id="PROJECT"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER"
resource.labels.namespace_name="default"
resource.labels.pod_name:"WORKLOAD_NAME"

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

  • ‫PROJECT : מזהה הפרויקט ב- Google Cloud
  • ‫LOCATION: האזור או האזור שבו יצרתם את אשכול GKE
  • ‫CLUSTER : השם של אשכול GKE
  • ‫WORKLOAD_NAME : השם של עומס העבודה כשמשתמשים ב-XPK או השם של JobSet כשמשתמשים ב-kubectl

השאילתה הזו תתאים לכמה קונטיינרים של Kubernetes ב-Pathways עם שמות כמו pathways-rm, pathways-proxy, pathways-worker. כדי לצמצם את האפשרויות ולגלות איזה מאגר גורם לבעיה, אפשר להוסיף מסנן לפי שם המאגר, כמו resource.labels.container_name:"<container_name>"

מעקב

מעקב אחר בריאות

אפשר לעקוב אחרי תקינות הרכיבים השונים של Pathways על ידי חיפוש רשומות ביומני של הקונטיינר, למשל:

‫pathways-proxy מוכן לטפל בבקשות חדשות לחיבור כשהיומן הבא נכתב:

kubectl logs ${HEAD_POD_NAME} --container pathways-proxy
...
I1101 04:51:41.967764       1 proxy_server.cc:125] IFRT proxy server started with status OK

pathways-rm מוכן לטפל בבקשות חדשות לחיבור כשהיומן הבא נכתב:

kubectl logs $HEAD_POD_NAME --container pathways-rm
...
I1101 04:50:41.967764       1 server_lib.cc:1473] Pathways Server serving on [::]:29001

כדי לוודא שכל ה-TPU שרשומים ב-Pathways Resource Manager מוכנים, אפשר לחפש את ***<num slices>/<num slices> Pathways Slices Now Ready *** ביומני של מאגר התגים pathways-rm:

kubectl logs $HEAD_POD_NAME --container pathways-rm
...
I1101 04:52:41.967764       1 multi_job_allocator.cc:1063] *** 2/2 Pathways Slices Now Ready ***

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

‫pathways-worker מוכן לטפל בבקשות חדשות לחיבור כשהיומן הבא נכתב:

kubectl logs $WORKER_POD_NAME --container pathways-worker
...
I1101 04:50:41.967764       1 server_lib.cc:1473] Pathways Server serving on [::]:29001

אוסף מדדים

התכונה 'תוכניות לימודים' יכולה לכתוב מדדים של מערכת ברמה נמוכה ל-Cloud Monitoring לצורך ניפוי באגים. המדדים כוללים:

  • זמן האחזור של העברת נתונים ב-DCN
  • זמן האחזור הכולל
  • השהיית העברה ממארח למכשיר
  • זמן האחזור של העברה ממכשיר למארח

אפשר למצוא את המדדים במרכז הבקרה של Cloud Monitoring שלGoogle Cloud הפרויקט שבו פועל אשכול GKE.

כדי לעקוב אחרי המדדים האלה באמצעות Metrics Explorer:

  1. עוברים אל Metrics Explorer.
  2. מסננים לפי שם המדד באמצעות השדה בחירת מדד.
  3. כדי לסנן לפי שם עומס העבודה וטווח הזמן, לוחצים על Add Filter (הוספת מסנן) ומסננים לפי pod_name.
  4. בוחרים סוג צבירה מתאים בהתאם למדד ולעומסי העבודה שאתם עוקבים אחריהם.

זמן האחזור של העברת נתונים ב-DCN

זהו מדד של Megascale XLA ‏ (MXLA) שמודד את ההתפלגות המצטברת של השהיות בהעברת נתונים ברשת עבור תעבורה של כמה פרוסות. מדידת זמן האחזור מתחילה כשמונפקת בקשה להעברת נתונים דרך ה-DCN, ומסתיימת כשמתקבל אישור שהעברת הנתונים הושלמה. כדי לעקוב אחרי המדד הזה, מסננים לפי dcn_transfer_latencies שם המדד.

זמן טעינה כולל

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

השהיית העברה ממארח למכשיר

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

זמן האחזור של העברה ממכשיר למארח

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

ניפוי באגים בשגיאות נפוצות

Unable to hash accelerator config warnings

ההודעות הבאות הן רק אזהרות ולא משפיעות על הביצועים של קוד JAX.

INFO:jax._src.cache_key:get (_hash_accelerator_config): unable to hash accelerator config, falling back to hashing devices + platform: UNIMPLEMENTED: GetTopologyForDevices is not supported for the IFRT proxy client. (type <class 'jaxlib.xla_extension.XlaRuntimeError'>)

ההרשאה logging.logEntries.create נדחתה במשאב

אם מופיעה השגיאה הבאה, צריך לוודא שלחשבון השירות של Compute Engine שבו נעשה שימוש ב-Vertex AI Workbench יש הרשאות לכתוב רשומות ביומן ב Google Cloud מערכת רישום היומנים.

INFO:absl:Created 'ArrayHandler' with primary_host=0, replica-id=0
WARNING:absl:pathwaysutils: Detected Pathways-on-Cloud backend. Applying changes.
Failed to submit 1 logs.
Traceback (most recent call last):
  File "/opt/conda/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 65, in error_remapped_callable
    return callable_(**args, **kwargs)
  File "/opt/conda/lib/python3.10/site-packages/grpc/_channel.py", line 1181, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/opt/conda/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 1006, in _end_unary_response_blocking
    raise _InactiveRpcError(state) # pytype: disable-not-instantiable
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
  status = StatusCode.PERMISSION_DENIED
  details = "Permission 'logging.logEntries.create' denied on resource (or it may not exist)."
  debug_error_string = "UNKNOWN:Error received from peer ipv4:216.239.34.174:443 {created_time:"2024-10-03T20:30:44.820425276+00.00", grpc_status:7, grpc_message:"Permission \'logging.logEntries.create\' denied on resource (or it may not exist)."}"
>

כדי לפתור את הבעיה, צריך להוסיף את התפקיד Logs Writer לחשבון השירות של Compute Engine.

לא ניתן להתחבר לשרת ה-proxy של IFRT

אם השגיאה הזו מופיעה, לקוח ה-proxy של IFRT לא מצליח להתחבר לשרת ה-proxy של IFRT.

  • מוודאים שהרשת של ה-VPC מוגדרת בצורה נכונה
  • מוודאים שחומת האש מוגדרת כך שהחיבור יתאפשר
  • מוודאים שהוקצה לכם אשכול של Pathways
  • בדיקה אם יש הודעות שגיאה בהפעלה

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

RuntimeError: Unable to initialize backend 'proxy': UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: DNS resolution failed (set JAX_PLATFORMS='' to automatically choose an available backend)

קיים חיבור לאשכול Pathways

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

INFO:absl:Created ArrayHandler with primary_host=0, replica_id=0
WARNING:absl:pathwaysutils: Detected Pathways-on-Cloud backend. Applying changes.
E0927 21:19:52.919607   37624 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:03.467547   37719 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:14.011645   37807 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:24.557955   37924 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
---------------------------------------------------------------------------
XlaRuntimeError                           Traceback (most recent call last)
File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:887, in backends()
    885   continue
--> 887 backend = _init_backend(platform)
    888 _backends[platform] = backend

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:973, in _init_backend(platform)
    972 logger.debug("Initializing backend '%s'", platform)
--> 973 backend = registration.factory()
    974 # TODO: consider raising more descriptive errors directly from backend
    975 # factories instead of returning None.

File /opt/conda/lib/python3.10/site-packages/pathwaysutils/proxy_backend.py:24, in register_backend_factory.<locals>.<lambda>()
     21 def register_backend_factory():
     22   xla_bridge.register_backend_factory(
     23       "proxy",
---> 24       lambda: ifrt_proxy.get_client(
     25           jax.config.read("jax_backend_target"),
     26           ifrt_proxy.ClientConnectionOptions(),
     27       ),
     28       priority=-1,
     29   )

XlaRuntimeError: UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: Connection to IFRT proxy server was terminated: CANCELLED: Cancelled

During handling of the above exception, another exception occurred:

RuntimeError                              Traceback (most recent call last)
Cell In[2], line 4
      1 import pathwaysutils
      3 import jax
----> 4 print(jax.devices())

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:1085, in devices(backend)
   1060 def devices(
   1061     backend: str | xla_client.Client | None = None
   1062 ) -> list[xla_client.Device]:
   1063   """Returns a list of all devices for a given backend.
   1064
   1065   .. currentmodule:: jaxlib.xla_extension
   (...)
   1083     List of Device subclasses.
   1084   """
-> 1085   return get_backend(backend).devices()

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:1019, in get_backend(platform)
   1015 @lru_cache(maxsize=None)  # don't use util.memoize because there is no X64 dependence.
   1016 def get_backend(
   1017     platform: None | str | xla_client.Client = None
   1018 ) -> xla_client.Client:
-> 1019   return _get_backend_uncached(platform)

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:998, in _get_backend_uncached(platform)
    994   return platform
    996 platform = (platform or _XLA_BACKEND.value or _PLATFORM_NAME.value or None)
--> 998 bs = backends()
    999 if platform is not None:
   1000   platform = canonicalize_platform(platform)

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:903, in backends()
    901       else:
    902         err_msg += " (you may need to uninstall the failing plugin package, or set JAX_PLATFORMS=cpu to skip this backend.)"
--> 903       raise RuntimeError(err_msg)
    905 assert _default_backend is not None
    906 if not config.jax_platforms.value:

RuntimeError: Unable to initialize backend 'proxy': UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address 'example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: Connection to IFRT proxy server was terminated: CANCELLED: Cancelled (set JAX_PLATFORMS='' to automatically choose an available backend)

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

‫LocalProxy.init() קיבל ארגומנט מילת מפתח לא צפוי 'unbound_message'

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

 pip3 list --outdated (replacing pip with pip3 as needed)

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

 pip install flask Werkzeug --upgrade ()

שגיאה פנימית משרת proxy

"Internal error from proxy server during Array::IsDeleted(): UNAVAILABLE:Connection to IFRT proxy server was terminated: FAILED_PRECONDITION:
GrpcClientSession: writes no longer allowed."

השגיאה הזו מציינת ששרת ה-Proxy של IFRT התנתק מהלקוח. כדי לפתור את הבעיה, אפשר להפעיל מחדש את הלקוח. במחברות, אפשר להפעיל מחדש את ליבת המחברת ולהריץ מחדש את המחברת.

SIGTERMS ו-HBM OOM

אם השגיאה RESOURCE_EXHAUSTED מופיעה ביומנים עם SIGTERM, יכול להיות שזו שגיאת OOM ב-HBM. במקרה כזה, אפשר להקטין את כמות הזיכרון ב-HBM שמשמשת בקוד JAX.

INVALID_ARGUMENT

"INVALID_ARGUMENT : Permanent error, with a last message of Lifecycle
matches_prefix cannot specify more than 50 prefixes per config.; Error while
initializing persistent cache storage Cloud Storage"

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

שגיאה קבועה

Permanent error, with a last message of The specified bucket does not exist.; Error while initializing persistent cache storage gcs

השגיאה הזו מודפסת בעובדים של מנהל המשאבים או Pathways כשמספקים מיקום לא תקין ב-Cloud Storage למאגרי Pathways.

תגובת שגיאה מהדמון

Error response from daemon: dockerfile parse error line 16: Unknown flag: exclude

הסיבה לכך היא גרסה ישנה של Docker. צריך לשדרג את גרסת Docker.

הלקוח והשרת של IFRT Proxy לא הצליחו להגיע להסכמה

IFRT Proxy client and server failed to agree on the protocol version; supported versions: client = [1, 1], server = [3, 14]

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

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