A week after install, Task Manager shows SQL Server holding almost every gigabyte on the machine — and it is working as designed. Here is the one setting that turns that design from a problem into a plan.
SQL Server caches data pages in RAM — the buffer pool — because reading from memory is thousands of times faster than reading from disk. Left alone, it will keep caching until it approaches the machine's total RAM. That behaviour is a feature on a dedicated database server and a slow-motion accident on a shared one. The control is a single number: max server memory.
Every time SQL Server reads a page, it keeps a copy in the buffer pool in case it is needed again. Over days of real work the pool grows to hold the working set of your databases, and Task Manager reports the difference as SQL Server 'using' nearly all RAM. This is deliberate and healthy — unused RAM on a database server is wasted money. The engine will also release memory when Windows signals real pressure. The problems start not from the caching, but from the absence of a planned boundary around it.
On a shared machine — SQL Server beside a file share, an application server, a billing app or a remote-desktop session host — an uncapped engine squeezes everything else. Windows starts paging to disk, other applications stutter, and in bad cases the operating system becomes so starved that the server feels hung while the database itself is perfectly happy. The cruel part: the symptoms look like 'the server is slow', so people blame the hardware. The actual cause is one configuration value that still holds its factory default, as you can check with EXEC sp_configure 'max server memory (MB)'; — the default reads 2,147,483,647 MB, which is to say, no limit at all.
The working rule used by most administrators: reserve the greater of about 4 GB, or roughly 20 to 25 percent of total RAM, for Windows and everything else, then give SQL Server the rest. On a 16 GB machine that means a cap near 10 to 12 GB. On a 32 GB dedicated server, reserving 4 to 6 GB is plenty because the percentage matters less as machines grow. If the box also runs other real workloads — reporting services, an application tier — reserve for them explicitly instead of hoping they will fight it out at runtime.
SQL Server 2022's installer includes a Memory page that offers a recommended cap — accepting it is a good default. Afterwards, the setting lives in SSMS under the server's Properties, Memory page, or in T-SQL as below. The change takes effect dynamically, with no restart, and if you lower the cap, the engine calmly hands memory back. There is no excuse for leaving this for 'later when it becomes a problem' — setting it takes one minute.
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;EXEC sp_configure 'max server memory (MB)', 10240; RECONFIGURE;EXEC sp_configure 'max server memory (MB)'; and check the run_value columnFirst, min server memory: a floor the engine will not shrink below once it has grown — set it only if you have a reason; the default of zero is fine for most. Second, on multi-instance machines every instance needs its own cap, and the caps added together must still leave Windows its share — two uncapped instances on one box is the shared-server accident squared. Finally, if your server has more than one NUMA node and very large RAM, this is a deep topic of its own; for the ordinary office server, the simple cap in this guide is the whole job.
Watch the install video and find the Memory page in setup — accepting the recommended cap there does this whole guide's job in one click.
▶️ Watch Full VideoOnly in the sense that less data fits in cache, so genuinely huge workloads read from disk more. For typical office databases the working set is far below any sane cap, and users notice nothing — while Windows and the rest of the machine stay responsive. A dedicated server with one small database can safely give SQL Server most of the RAM.
The cap limits the buffer pool and most engine memory, but the process also holds memory outside that counter, and the pool shrinks gradually rather than instantly. Give it a little time and judge by the committed total trend, not a single glance. If the machine is dedicated and performing well, high usage alone is not a problem.
Lock Pages in Memory is an advanced setting that stops Windows from paging out the buffer pool. It helps some very large, dedicated servers, but it removes Windows' safety valve and can starve the OS if the cap is wrong. Leave it alone unless you are following a specific, measured tuning plan.