I'm seeing more frequent memory exhaustion across several full-session RDS farms. The environments include Windows Server 2019, 2022, and 2025, and the biggest consumers tend to be Office applications, Chrome or Edge, Teams, and WebView2. These are traditional desktop session farms rather than published individual applications. What memory-per-user figures are others using, and which practical changes have helped reduce usage? Is the main answer simply enforcing better browser-tab and application hygiene, or are there more effective tuning options?
4 Answers
Rather than packing many users onto large hosts, we moved to more smaller session hosts with only a few users each. Running three or four users per server gives much better isolation when someone opens a large Office workload, a browser full of tabs, Teams, and WebView2 at the same time. It costs more infrastructure-wise, but one runaway session is less likely to affect everyone.
Browser policies for suspended tabs, memory saver features, and video limits can help at the margins. We also found that unmanaged streaming was causing complaints about poor performance, so limiting non-work browsing and reminding users to close unused tabs made a noticeable difference. Some administrators also investigate unusually heavy Adobe or AI-related processes, particularly after application updates, but changes like blocking executables should be carefully tested before being rolled out.
For workloads like this, there isn’t a universal number, but one commonly used starting point is around 64 GB of RAM with a fixed 32 GB page file for roughly 40 users. Browser policies can also limit Chrome and Edge memory usage. Windows doesn’t provide a simple way to enforce a memory cap per user session, so workload testing is still important.
The biggest improvement is often reducing the workload instead of trying to tune every process. Keep corporate browsing in the RDS session, but have users run meetings, streaming media, and other GPU- or audio-heavy activities on their local workstation when possible. Teams alone can consume well over a gigabyte during active use, especially in chats with lots of files.
That density would be far too high for our users. We run closer to 10–15 users on a 64 GB host and consider that the practical limit for this workload.