Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
add comment

2 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 '12 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 '12 at 3:00
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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