User guides#
This section explains how to use Ray’s key concepts to build distributed applications.
If you’re new to Ray, start with the walkthrough.
- Tasks
- Actors
- Specifying required resources
- Calling the actor
- Passing around actor handles
- Type hints and static typing for actors
- Generators
- Cancelling actor tasks
- Scheduling
- Fault tolerance
- FAQ: Actors, workers, and resources
- Task events
- More about Ray actors
- Objects
- Environment dependencies
- Concepts
- Preparing an environment using the Ray cluster launcher
- Runtime environments
- Specifying a runtime environment per job
- Specifying a runtime environment per task or per actor
- Common workflows
- API reference
- Frequently asked questions
- Are environments installed on every node?
- When does Ray install the environment?
- Where are the environments cached?
- How long does it take to install or to load from cache?
- What’s the relationship between runtime environments and Docker?
- Why can’t you import
runtime_envpackages when you log in to a node?
- Local URIs
- Remote URIs
- Hosting a dependency on a remote Git provider: Step-by-step guide
- Debugging
- Scheduling
- Scheduling at a glance
- Labels
- Resources
- Scheduling strategies
- Locality-aware scheduling
- More about Ray scheduling
- Use labels to control scheduling
- Resources
- Accelerator support
- Placement groups
- Key concepts
- Create a placement group (reserve resources)
- Schedule tasks and actors to placement groups (use reserved resources)
- Placement strategy
- Remove placement groups (free reserved resources)
- Observe and debug placement groups
- [Advanced] Child tasks and actors
- [Advanced] Named placement group
- [Advanced] Detached placement group
- [Advanced] Fault tolerance
- [Alpha] Topology strategy scheduling
- API reference
- Memory management
- Out-of-memory prevention
- Fault tolerance
- Design patterns and anti-patterns
- Pattern: Using nested tasks to achieve nested parallelism
- Pattern: Using generators to reduce heap memory usage
- Pattern: Using ray.wait to limit the number of pending tasks
- Pattern: Using resources to limit the number of concurrently running tasks
- Pattern: Using asyncio to run actor methods concurrently
- Pattern: Using an actor to synchronize other tasks and actors
- Pattern: Using a supervisor actor to manage a tree of actors
- Pattern: Using pipelining to increase throughput
- Anti-pattern: Returning ray.put() ObjectRefs from a task harms performance and fault tolerance
- Anti-pattern: Calling ray.get on task arguments harms performance
- Anti-pattern: Calling ray.get in a loop harms parallelism
- Anti-pattern: Calling ray.get unnecessarily harms performance
- Anti-pattern: Processing results in submission order using ray.get increases runtime
- Anti-pattern: Fetching too many objects at once with ray.get causes failure
- Anti-pattern: Over-parallelizing with too fine-grained tasks harms speedup
- Anti-pattern: Redefining the same remote function or class harms performance
- Anti-pattern: Passing the same large argument by value repeatedly harms performance
- Anti-pattern: Closure capturing large objects harms performance
- Anti-pattern: Using global variables to share state between tasks and actors
- Anti-pattern: Serializing ray.ObjectRef out of band
- Anti-pattern: Forking new processes in application code
- Ray Direct Transport (RDT)
- Ray Compiled Graph (beta)
- Resource isolation with cgroup v2
- Ray Sandboxes
- Advanced topics
- Tips for first-time users
- Type hints in Ray
- Starting Ray
- Ray generators
- Use namespaces
- Cross-language programming
- Use Ray with Jupyter Notebook and JupyterLab
- Lazy computation graphs with the Ray DAG API
- Miscellaneous topics
- Authenticate remote URIs in
runtime_env - Lifetimes of user-spawned processes
- Head node memory management