2

For no good reason (no large queries, no large cpu load, nothing changed) Mysql 5.1 on Ubuntu 10.04 just suddenly freed up about 20% of it's pooled memory and moved it to the swap. Now my swap memory usage is at a constant ~30%.. (unless it lowers and re-adjusts itself)

but why does it do this? According to top, mysql VIRT and RES stayed the same @ 12.5g 11g . So why did the memory move like this?

this is on a 16GB system with 12GB reserved as the Innodb_buffer_pool .

The mysql service has not been restarted in about 3 months.enter image description here

Improve this question

2 Answers 2

Reset to default
3

MySQL isn't responsible for managing swap on the server; that's the job of the kernel's memory management subsystem. The kernel tunable that governs this particular behavior is called "swappiness" and you can read more about it here:

http://kerneltrap.org/node/3000

Basically, if an application requests some amount of memory and the server's memory is full, it makes the application wait until enough idle memory contents can be paged out, which causes latency in the application. Because we don't want this latency, the kernel tries to always keep a certain amount of memory free. By doing this preemptively and in the background when the server comes close to running out of memory, it ensures that any new requests for memory on the server are fulfilled immediately, speeding things up without noticeably impacting any running applications. That's the theory, anyway.

Sometimes you don't want that, especially if all the physical memory on the server is supposed to be used as cache by some application (e.g. MySQL). In those cases, you'll want to lower the vm.swappiness sysctl to 0.

Improve this answer
1

The system moves stuff out of RAM if it hasn't been accessed in a very, very long time. This makes more physical memory available to hold stuff that can affect performance.

The reason so much information moved at once is likely that the swap out behavior was never triggered before (or not for a very long time) so there a lot of information accumulated that was as old as they system was able to track. Ejecting anything triggered ejecting all of that. (The system's page age tracking is very coarse because tracking granularity comes with a large increased cost in soft page faults.)

Likely almost all of this is data that will never get used. It will set on disk until the system reboots. So the extra free memory the system now has to hold data that will be used is effectively free.

Improve this answer
2
  • Will the page size shrink back to normal? It's kind of scary see that large page size just sitting there on a production system.
    – John Ingles
    Jan 25, 2012 at 2:59
  • 1
    No. It will not shrink. This is data that will most likely never be accessed, but the system cannot prove it will never be accessed. So the system has to keep it on disk just in case the application ever reads it. You should not care about large page size if there's low paging activity.
    – David Schwartz
    Jan 25, 2012 at 3:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .