search

ray-project / ray

Ray is a unified framework for scaling AI and Python applications. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.
https://ray.io
Apache License 2.0
33.31k stars 5.64k forks source link

Ray dashboard should not exit when GCS exits or becomes unavailable #45940

Closed ruisearch42 closed 2 months ago

ruisearch42 commented 3 months ago

What happened + What you expected to happen

There are recent cases that dashboard exits when RPC to GCS failed: (ses_7tcnunfk2da5qwby5t946m5tw7) (g-b7d2114c85b440001) [/tmp/ray/session_2024-06-09_14-01-52_504758_3738/logs/dashboard.log] 2024-06-10 06:41:53,037 ERROR head.py:198 -- Dashboard exiting because it received too many GCS RPC errors count: 41, threshold is 40. Several previous tickets also describe the same or similar issue: https://github.com/ray-project/ray/issues/39822 https://github.com/ray-project/ray/issues/31261 https://github.com/ray-project/ray/issues/16328

From observability point of view, dashboard should never exit when GCS exits or is unreachable. So what was the reason we designed the current dashboard exit behavior? Can we change it to not exit?

Versions / Dependencies

ray:2.9.0

Reproduction script

N/A

Issue Severity

None

ruisearch42 commented 3 months ago

cc: @alexeykudinkin

ruisearch42 commented 3 months ago

Per discussion, @rynewang has a related task and will address this altogether.

rynewang commented 3 months ago

We can simply remove the Dashboard check on gcs liveness, or follow the config RAY_gcs_rpc_server_reconnect_timeout_s used by raylet and workers.

However we also need to update PythonGcsClient to do proper retrying. For example, when GCS is down, now PythonGcsClient keeps all pending requests until the GCS is back alive. If there are so many reqs, the client may OOM. The C++ GcsClient, on the other hand, blocks the thread when the amount of pending reqs exceeds RAY_gcs_grpc_max_request_queued_max_bytes. We need to adapt this behavior to PythonGcsClient, by removing the latter and binding the C++ GcsClient to Python side.

This involves (in this order):

rynewang commented 3 months ago

Process:

  1. https://github.com/ray-project/ray/pull/45817
  2. https://github.com/ray-project/ray/pull/46186
  3. we can resolve this issue here: remove "number of failed checks". Since it now uses GcsClient (GcsRpcClient) it will inherit its "kill self on gcs_rpc_server_reconnect_timeout_s timeout` behavior and wo don't need to do anything on python side.
  4. gcs client async to reimplement GcsAioClient
anyscalesam commented 2 months ago

Very much under progress; waiting on 2) and than we can close this.

rynewang commented 2 months ago

Fixed by #46186