mirror of
https://github.com/vale981/ray
synced 2025-03-05 10:01:43 -05:00
![]() There are mysterious memory usage growth in Ray clusters that disappear when running with jemalloc. Before we are able to figure out the root cause, it seems using jemalloc by default can be a good walkaround. Because of its efficiency, using jemalloc by default can be beneficial, but we need to run more benchmarks to verify. |
||
---|---|---|
.. | ||
distributed | ||
object_store | ||
single_node | ||
app_config.yaml | ||
distributed.yaml | ||
distributed_smoke_test.yaml | ||
many_nodes.yaml | ||
object_store.yaml | ||
README.md | ||
scheduling.yaml | ||
single_node.yaml |
Ray Scalability Envelope
Distributed Benchmarks
All distributed tests are run on 64 nodes with 64 cores/node. Maximum number of nodes is achieved by adding 4 core nodes.
Dimension | Quantity |
---|---|
# nodes in cluster (with trivial task workload) | 250+ |
# actors in cluster (with trivial workload) | 10k+ |
# simultaneously running tasks | 10k+ |
# simultaneously running placement groups | 1k+ |
Object Store Benchmarks
Dimension | Quantity |
---|---|
1 GiB object broadcast (# of nodes) | 50+ |
Single Node Benchmarks.
All single node benchmarks are run on a single m4.16xlarge.
Dimension | Quantity |
---|---|
# of object arguments to a single task | 10000+ |
# of objects returned from a single task | 3000+ |
# of plasma objects in a single ray.get call |
10000+ |
# of tasks queued on a single node | 1,000,000+ |
Maximum ray.get numpy object size |
100GiB+ |