Updated: 9 November 2026 · Applies to: Linux servers (tested on Ubuntu 24.04 and Debian 13), Apache 2.4.69, nginx 1.30

You cannot switch off the Linux disk cache (the page cache), and you should not want to: it uses free memory to keep recently read files, and the kernel gives that memory back to programs the moment they need it. What you can do is clear it once with sync; echo 3 > /proc/sys/vm/drop_caches (as root), stop a single job from filling it, or, if you mean the cache of a website, send no-cache headers. Each is shown below.

First check: is the cache really a problem?

free -h

Lab example from our Ubuntu 24.04 test server:

               total        used        free      shared  buff/cache   available
Mem:           3.7Gi       695Mi       1.4Gi        74Mi       2.0Gi       3.1Gi
Swap:          1.2Gi        78Mi       1.1Gi

Look at available, not free. Here 2.0 GiB is cache, yet 3.1 GiB is available to programs, because most of the cache can be dropped instantly. A server with a big buff/cache number is healthy, not short of memory. If available is low and the server swaps, the cache is not the cause: find the process using the memory (see Find Top Running Processes by Highest Memory and CPU Usage in Linux) or add memory. How to Check Memory Usage in Linux explains every column.

Clear the page cache once (drop_caches)

As root:

sync; echo 1 > /proc/sys/vm/drop_caches

According to the Linux kernel documentation:

  • 1 frees the page cache (file contents).
  • 2 frees reclaimable slab objects, such as dentries and inodes (file and directory metadata).
  • 3 frees both.

Only clean cache is dropped. Data waiting to be written (dirty pages) stays, which is why sync runs first. The same can be done with sysctl -w vm.drop_caches=3. The kernel documentation also says this is not a way to limit the cache, because the kernel reclaims these objects automatically, and that using it outside testing or debugging is not recommended: everything dropped must be read from disk again, so the server is slower until the cache refills.

Good reasons to drop caches: a fair disk benchmark (so a test reads from the disk and not from memory), or checking how much memory is really in use. A cron job that drops caches every few minutes only makes a server slower. Step-by-step details are in How to clear the buffer and pagecache (disk cache) under Linux.

Read-only file system inside a container

Inside a container, including our unprivileged podman test containers, the command fails even as root:

bash: line 6: /proc/sys/vm/drop_caches: Read-only file system

sysctl -w vm.drop_caches=3 printed sysctl: setting key "vm.drop_caches", ignoring: Read-only file system and still returned exit code 0, so do not trust the exit code here. The page cache belongs to the host kernel, so only the host can drop it. The same applies to container-based virtual servers. On a KVM VPS or a dedicated server you run your own kernel and the command works as root.

Keep one job out of the cache

The usual real complaint is a backup or a large copy pushing useful data out of the cache. You can stop that job from filling the cache without touching anything else. fincore (package util-linux-extra on Ubuntu 24.04) shows how much of a file is cached; we used a 64 MB test file.

After reading the file normally:

fincore /root/big.bin

Output:

  RES PAGES SIZE FILE
  64M 16384  64M /root/big.bin

Drop just this file from the cache (GNU coreutils dd 9.4):

dd if=/root/big.bin iflag=nocache count=0 status=none

Output of fincore /root/big.bin afterwards:

RES PAGES SIZE FILE
 0B     0  64M /root/big.bin

Run a whole command so that the files it reads do not stay in the cache, with the nocache tool (apt install nocache, version 1.1 in our test):

nocache tar -czf /backup/home.tar.gz /home

Copy a large file with direct I/O, which skips the cache entirely:

dd if=/root/big.bin of=/root/copy.bin bs=1M iflag=direct oflag=direct status=none

In our test, fincore showed 0B cached for the copy made this way and 64M for a copy made with cp. Direct I/O can be very slow with small blocks, so keep a large block size such as bs=1M.

Tune instead of disabling: vfs_cache_pressure

vm.vfs_cache_pressure controls how readily the kernel reclaims memory used for caching directory and inode objects. The kernel default is 100 (also the value on our test server):

sysctl vm.vfs_cache_pressure

Higher values reclaim that cache sooner. Change it only to fix a measured problem; for a server where the slab cache keeps growing, see What to do if Slab cache grows and overall server performance is bad.

Disable caching for a website (browser and proxy cache)

If "cache" means pages that visitors or a CDN keep showing in an old version, send headers that tell them not to store the page. In Apache, through .htaccess (needs mod_headers, which most hosting servers have):

<Files "index.php">
    FileETag None
    <IfModule mod_headers.c>
        Header unset ETag
        Header set Cache-Control "no-cache, no-store, must-revalidate"
        Header set Pragma "no-cache"
        Header set Expires 0
    </IfModule>
</Files>

Response headers in our Apache 2.4.69 test:

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

In nginx, inside the matching location block, then reload with nginx -t && systemctl reload nginx:

location /api/ {
    add_header Cache-Control "no-store" always;
    expires off;
    etag off;
}

Our nginx 1.30.5 test returned Cache-Control: no-store for files under /api/. Turning off caching for a whole site makes it slower and increases server load, so limit it to the pages that change often or hold personal data. If the site also uses a server cache (for example the cPanel NGINX cache, see Varnish on cPanel: Why We Recommend the cPanel NGINX Cache Instead), a WordPress cache plugin or a CDN, clear or bypass that cache as well, because these headers do not empty copies that are already stored.

Official documentation: Linux kernel documentation for /proc/sys/vm, Apache mod_headers, nginx headers module.

Related services

KVM VPS hosting

NVMe SSD and full root access, with Free Basic Managed Support.

Unmanaged dedicated servers

full root access and free IPMI KVM, with Free Basic Managed Support.

Managed dedicated servers

our engineers look after the server for you, from $135 a month.

Was this answer helpful?

Still stuck? Open a ticket