The OpenVZ VPS in santrex.net have what they call burstable RAM. My VPS have 512MiB guaranteed RAM and 1024MiB brustable RAM.
The question here is, what is *brustable RAM*? The answer for me is not really clear at all. When your hosting provider is setting up your OpenVZ host, they will specify the amount of RAM you can use, and they will give you some extra RAM that you can use for a small amounts of time. This can be done since all the VPS are running in a single physical machine and they will not be using the 100% of the RAM available. Your provider can tell to you: well, you can use the memory of the other VPSs (in the same physical machine, of course) if they are not using that memory. As soon as they need their memory, we have a problem. And they only have one way of solving this problem: by killing processes that are using a lot of memory in your VPS until you are using only your guaranteed memory. And you don't want to have processes killed randomly so you must use less than 512MiB even if the command "free" says to you that you have more memory free.
So, the processes that uses more memory are (virtual memory):
- mysqld: 137 MB
- cherokee-worker: 37MB
- php-cgi: 35 MB (three instances, so 105MB)
- All the other processes (sshd, bash, sudo, some stuff) uses insignificant amount of memory
If we sum it all together we have 280MB of memory usage (56%). For just running this blog. Gosh. That's too much.
Ok, let's start with mysqld and try to reduce a little bit the use of RAM. We will have to modify the file on /etc/mysql/my.conf and change the follow parameters. Be careful! If you do a lot of queries on your DDBB this configuration can create errors or something. This configuration is just for reducing the memory usage in small enviroments. You can avoid this step and just apply the step below because we don't save that much memory and it can be dangeorus.
key_buffer = 8M thread_stack = 128K thread_cache_size = 8 max_connections = 30 # Be careful. If your host have a lot of connections this can give you problems. table_cache = 4 query_cache_limit = 512K query_cache_size = 8M skip-bdb
With this step we reduce the memory usage of the process mysqld from 137MB to 120MB. 17MB saved, 3.4% of the total memory. Not that much....
Well, the problem we are facing here is not a 'mysql memory usage' but a OpenVZ memory management issue. In a real machine (or with Xen VPS), the resident memory is what counts, and not the VIRT(virtual) memory. A process can allocate a lot of VIRT memory without a bad OS impact. In fact you can have 1.000 processes each mapping a 1GB file on a machine with 2GB of RAM, and each processes consuming 1GB of virtual memory and no actual physical memory gets consumed until you don't start touching that memory area and you start to consume physical memory (and RSS goes up).
But in OpenVZ it is different because the VIRT memory is limited and is what "it counts". So, what can we do for reducing the amount of VIRT memory used? Decrease the thread stack size.
And why decreasing the thread stack size we will reduce the useage of virtual memory? It turns out that for multi-threaded applications, each thread will be allocate 8MB of stack (althogh not actually used). So, if we reduce the size of the thread stack size, we will reduce the virtual memory usage too. Let's try it. Open a console and try this commands:
$ sudo su - root $ ulimit -s 256 $ /etc/init.d/mysql stop $ /etc/init.d/mysql start $ /etc/init.d/cherokee stop $ /etc/init.d/cherokee start
Note that is very important to use the "stop/start" commands and not "restart" because we want to actually kill the process and start them again. So, after executing this commands how many virtual memory are our processes using?
- mysqld 65MB (was 135MB)
- cherokee-worker 5.3MB (was 37MB)
- php-cgi 30 (was 35 MB)
From 280MB (56%) to 160MB (32%). Wow! That's nice.
If you want to save this setting and be able to have the same configuration after a reboot you can add "ulimit -s 256" in the file /etc/init.d/rc just after the text "umask 022".
32% of RAM usage for a mysql+cherokee+php for me is too much, but I can live with it ;)
Note: be careful because depending on your VPS provider, changing the thread stack size can lead in problems and hungs. If you start having problems, restore the old values. Then you can try to increase a little bit and see if the system is stable.
Note2: The xen VPS are awesome and the memory footprint is way less than the OpenVZ. Take a look to the offers in digitalocean.com if you are interested in it.