Managing Session Resources
By the end of this lesson, you will be able to:
- Explain why limiting session resources matters on a shared server
- Describe how cgroups-v2 lets Workbench enforce CPU and memory limits
- Distinguish resource profiles from user and group profiles
- Recognize how to restrict profile access to specific users and groups
1 Introduction
Data science workloads can easily consume large amounts of CPU and memory, sometimes unexpectedly. On a shared server, a single memory-intensive analysis can degrade performance for everyone, or in the worst case crash the server.
Workbench addresses this with two mechanisms that work together: cgroups-v2, the Linux kernel feature that enforces resource limits, and profiles that define which limits apply and who can select them. The same concepts apply whether Workbench runs on a single VM or schedules sessions across a Kubernetes cluster, because all Posit Launcher integrations support per-session resource limits.
- Reading time: 15 minutes
- Documentation reading time: 10-20 minutes
- Hands-on exercise time: 15-30 minutes
2 cgroups-v2: The Enforcement Mechanism
Resource limits only work if the operating system can enforce them. cgroups-v2 is the Linux kernel mechanism that makes this possible: it lets Workbench cap the CPU and memory a session process can use, so users cannot exceed their allocation.
On Ubuntu 20.04 and later, cgroups-v2 is typically enabled by default, and you can verify it is mounted with mount | grep cgroup2. Red Hat Enterprise Linux requires extra steps, which the documentation describes. Configure cgroups before defining profiles: without it, profiles can be defined but the limits cannot be applied.
3 Resource Profiles
Resource profiles define the session sizes available to your users. They live in /etc/rstudio/launcher.local.resources.conf, and each profile specifies a number of CPUs and an amount of memory, for example a default profile, a small profile, and a hugemem profile for memory-heavy work.
Choose these values in consultation with your users, based on the type of work they do, and consider the number of users and the CPU and memory available on your instance. With profiles defined, users pick a size when they launch a new session.
4 User and Group Profiles
By default, every Workbench user can select any resource profile. Often you will want to restrict the large profiles to the teams that need them. User and group profiles, configured in /etc/rstudio/launcher.local.profiles.conf, do exactly that: a [*] section sets defaults for everyone, and a [@group] section overrides them for members of a Linux group, including which profiles are visible and whether users may set custom resources.
One thing to remember: when users are provisioned just-in-time, Workbench does not create their Linux groups. Any group referenced in your profiles must already exist on the system, with the right users added to it.
Resource management affects both system stability and user satisfaction. Without limits, one user running a memory-intensive analysis can crash the server for everyone. With resource profiles, you get fair resource distribution and predictable performance, and users get session sizes matched to their work instead of a one-size-fits-all server.
In the accompanying lab, you will enable cgroups-v2, define resource profiles, restrict access to a large-memory profile by group, and test the configuration with different user accounts.