Debugging high worker thread counts#
Each Ray worker process has its own gRPC runtime. On nodes that run many worker processes, the per-process gRPC threads can add up to a high node-level thread count.
Inspect worker threads#
On Linux, inspect the thread names for a representative worker process:
ps -L -p ${WORKER_PID} -o tid,comm
for task in /proc/${WORKER_PID}/task/*; do
cat "${task}/comm"
done | sort | uniq -c | sort -nr
Compare the thread-name counts across representative workers and at the node level.
Distinguish gRPC runtimes#
If the application imports the Python grpcio package, the worker can load a separate
gRPC runtime that isn’t controlled by RAY_worker_num_grpc_internal_threads. Inspect
the worker’s mapped libraries to distinguish that runtime from Ray’s bundled gRPC
runtime:
grep grpc /proc/${WORKER_PID}/maps
Check process and thread limits#
When sizing a node or container that runs many workers, monitor its process and thread
limits. On Linux, check the applicable cgroup pids.max and the user process limit:
cat /sys/fs/cgroup/pids.max
ulimit -u
If worker gRPC threads contribute to the high thread count, configure
RAY_worker_num_grpc_internal_threads as described in
Worker gRPC threads on high-CPU nodes. Compare task throughput, RPC latency, and
thread counts before and after changing the value.