Use memory wisely, or mod_wsgi on 256 megabytes
Some time ago it was required to transfer projects from a dedicated server to a VPS. For these purposes, was selected slicehost . In general, the office is like and is ready to recommend it to everyone.
Only one problem happened: notifications about excessive use of the disk (read / write) began to come. For a long time, the problem did not find a solution due to lack of time, but this resulted in incomprehensible failures, accompanied by statistics of> 200% CPU usage. After long perversions, the problem was found, and then its solution.
The problem was that swap was used. For reference: I have 256Mb slice (i.e. RAM), apache2, mod_wsgi, django, postgresql, all this on arch linux.
For the ignorant, the size of the swap can be viewed with the
')
So, at the entrance we have a picture:
As you can see, swap is used and ... this is already bad. swap - there is nothing more than an attempt to compensate for the lack of RAM at the expense of HDD . Those. if the OS understands that the data does not fit into the RAM, it swaps them to the hard disk. As you know, RAM is much ... MUCH faster than HDD , but even that is not the case - the hard disk has its resource for reading / writing (due to moving parts), which is why the slash host is driven by the use of swap.
Now more specifically. If you're still using django with mod_python, throw the last one out. If wsgi, then in more detail.
Tuning the Apache did not lead to anything adequate, so it was decided to dig into the settings of the WSGI. We will be interested in the WSGIDaemonProcess directive (by the way, it is in VirtualHost). In the simplest case, it accepts only the name of the process, but this is not enough for fine tuning.
For the most part, we are interested in the stack-size option. By default, it is equal to 8MB per stream. Those. even with 15 threads per process we will have 15 * 8 = 120 Mb. Agree, not a little. The manual for mod_wsgi says that under VPS conditions, these values can be reduced to 512kb (524288 bytes), which will already be only 4Mb. Now WSGIDaemonProcess will look like this:
Here maximum-request = 200 is the number of requests after which the process will be restarted. This helps in the presence of memory leaks: when you restart the process memory comes in its original state.
Vpornitspe, I stopped at this because I achieved more than acceptable results
If this is not enough for you, then you should pay attention to a couple of options:
Just do not forget about
because initially it is 0 (i.e., without optimization).
Well, that's all, comments are welcome :)
via Retta
Only one problem happened: notifications about excessive use of the disk (read / write) began to come. For a long time, the problem did not find a solution due to lack of time, but this resulted in incomprehensible failures, accompanied by statistics of> 200% CPU usage. After long perversions, the problem was found, and then its solution.
The problem was that swap was used. For reference: I have 256Mb slice (i.e. RAM), apache2, mod_wsgi, django, postgresql, all this on arch linux.
For the ignorant, the size of the swap can be viewed with the
free -m command (by the way, a good article eng).')
So, at the entrance we have a picture:
total used free shared buffers cached Mem: 256 251 4 0 1 26 - / + buffers / cache: 224 31 Swap: 511,227,284
As you can see, swap is used and ... this is already bad. swap - there is nothing more than an attempt to compensate for the lack of RAM at the expense of HDD . Those. if the OS understands that the data does not fit into the RAM, it swaps them to the hard disk. As you know, RAM is much ... MUCH faster than HDD , but even that is not the case - the hard disk has its resource for reading / writing (due to moving parts), which is why the slash host is driven by the use of swap.
Now more specifically. If you're still using django with mod_python, throw the last one out. If wsgi, then in more detail.
Tuning the Apache did not lead to anything adequate, so it was decided to dig into the settings of the WSGI. We will be interested in the WSGIDaemonProcess directive (by the way, it is in VirtualHost). In the simplest case, it accepts only the name of the process, but this is not enough for fine tuning.
For the most part, we are interested in the stack-size option. By default, it is equal to 8MB per stream. Those. even with 15 threads per process we will have 15 * 8 = 120 Mb. Agree, not a little. The manual for mod_wsgi says that under VPS conditions, these values can be reduced to 512kb (524288 bytes), which will already be only 4Mb. Now WSGIDaemonProcess will look like this:
WSGIDaemonProcess mysite maximum-requests=200 stack-size=524288Here maximum-request = 200 is the number of requests after which the process will be restarted. This helps in the presence of memory leaks: when you restart the process memory comes in its original state.
Vpornitspe, I stopped at this because I achieved more than acceptable results
total used free shared buffers cached Mem: 256 203 53 0 2 29 - / + buffers / cache: 170 85 Swap: 511 6 505
If this is not enough for you, then you should pay attention to a couple of options:
- threads - the number of threads per process (by default 15)
- inactivity-timeout - the time after which the process will be considered inactive and will be restarted. Suitable for rarely visited sites, allows you to regularly clean the memory.
- processes - the number of processes (default 1)
Just do not forget about
WSGIPythonOptimize 2because initially it is 0 (i.e., without optimization).
Well, that's all, comments are welcome :)
via Retta
Source: https://habr.com/ru/post/51985/
All Articles