I have a dedicated server for MariaDB 10.8.3 and the features as follows:

248GB free disk space.
innodb_buffer_pool_size = 12286766080

Memory results:

[root@server user]# free -h
              total        used        free      shared  buff/cache   available
Mem:           19Gi        12Gi       507Mi       129Mi       6,1Gi       6,2Gi
Swap:         1,9Gi       1,5Gi       403Mi

MariaDB swap memory 620MB (31%).
MariaDB used RAM VIRT: 14.1GB RES: 12.4GB (63.6%), from top linux command
1 core. The server is a virtual machine.

The question is why MariaDB is consuming SWAP when there is available space (6.2GB)?

  • Perhaps you can read why swap space is used and why it isn't necessarily a bad thing, e.g. here. Unless you actually observe active swapping, which is different from merely using the swap space, there's no reason for concern.
    – mustaccio
    Feb 24 at 20:30
  • Also see discussion on MDEV-29097
    – danblack
    Feb 25 at 0:42

1 Answer 1


When Linux uses swap for virtual memory even once, it generally leaves it stored there, even if it also has the same memory in physical RAM. If the content of the RAM does not change, and the process needs to use swap for that memory later, at least it doesn't have to write to disk again.

This doesn't mean that the process is necessarily reading from swap and incurring the performance hit. It might be reading that data from RAM with high performance. But it still shows up as swap space "in use" in the report from free.

I'd use vmstat or top to monitor if there is swap reads or writes going on currently. That's what causes the performance hit.

If you are concerned, you might consider disabling swap space on your database server. That's what I've done in the past. Swapping is so bad for database performance that I'd rather just prevent swapping by having no swap partition.

This does create a risk that if any process allocates memory in excess of physical RAM, it triggers an out-of-memory (OOM) reaction, and the kernel will kill some process to free RAM. This often ends up being the database server process, because its big buffer pool allocation is usually the biggest user of RAM on the server (assuming the server is a dedicated database server). But if you monitor memory consumption and tune your allocation so there's some breathing room, this should be rare and the risk is minimal.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.