February 14, 2009 at 7:40 We use memory intelligently, or mod_wsgi at 256 megabytes
Some time ago, it was required to transfer projects from a dedicated server to VPS. For these purposes, slicehost was selected . In general, I like the office and am ready to recommend it to everyone.
Only one problem happened: notifications began to come about too heavy disk usage (read / write). For a long time, the problem could not be solved due to lack of time, but this resulted in incomprehensible failures, accompanied by statistics in> 200% of CPU usage. After much perversion, the problem was found, and then its solution.
The problem was that swap was used. For reference: I have a 256Mb slice (i.e. RAM), apache2, mod_wsgi, django, postgresql, all on arch linux.
For the uninformed, the swap size can be viewed with the command
So, at the entrance we have a picture:
As you can see, swap is used and ... it's already bad. swap - there is nothing more than an attempt to compensate for the lack of RAM due to HDD . Those. if the OS understands that the data does not fit into the RAM, it will swap it to the hard drive. As you know, RAM is much ... MUCH faster than the HDD , but that’s not the point - the hard disk has its own read / write resource (due to moving parts), which is why the slash host is customized for using swap.
Now more specifically. If you still use django with mod_python - throw the last one. If wsgi, then more details.
Tuning Apache did not lead to anything adequate, so it was decided to delve into the WSGI settings. We will be interested in the WSGIDaemonProcess directive(by the way, it’s located 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 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 this value can be reduced to 512kb (524288 bytes), which will already be only 4Mb. Now WSGIDaemonProcess will look like this:
Here maximum-request = 200 - the number of requests after which the process will be restarted. This helps in the presence of memory leaks: during a reboot, the process memory returns to its original state.
In principle, I stopped there, as I achieved more than acceptable results
If this is not enough for you, then you should pay attention to a couple of options:
Also do not forget about it
. initially it is 0 (i.e. without optimization).
Well that's all, comments are welcome :)
via Retta
Only one problem happened: notifications began to come about too heavy disk usage (read / write). For a long time, the problem could not be solved due to lack of time, but this resulted in incomprehensible failures, accompanied by statistics in> 200% of CPU usage. After much perversion, the problem was found, and then its solution.
The problem was that swap was used. For reference: I have a 256Mb slice (i.e. RAM), apache2, mod_wsgi, django, postgresql, all on arch linux.
For the uninformed, the swap size can be viewed with the command
free -m(by the way, a good articleeng). 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 ... it's already bad. swap - there is nothing more than an attempt to compensate for the lack of RAM due to HDD . Those. if the OS understands that the data does not fit into the RAM, it will swap it to the hard drive. As you know, RAM is much ... MUCH faster than the HDD , but that’s not the point - the hard disk has its own read / write resource (due to moving parts), which is why the slash host is customized for using swap.
Now more specifically. If you still use django with mod_python - throw the last one. If wsgi, then more details.
Tuning Apache did not lead to anything adequate, so it was decided to delve into the WSGI settings. We will be interested in the WSGIDaemonProcess directive(by the way, it’s located 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 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 this value 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 - the number of requests after which the process will be restarted. This helps in the presence of memory leaks: during a reboot, the process memory returns to its original state.
In principle, I stopped there, as 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 (15 by default)
- inactivity-timeout - 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)
Also do not forget about it
WSGIPythonOptimize 2. initially it is 0 (i.e. without optimization).
Well that's all, comments are welcome :)
via Retta