How can you reduce the consumption of RAM on the VPS by 2 times, without changing anything in the program settings
Took a VPS, built on OpenVZ. I put Debian Lenny there and all sorts of programs (the usual LAMP, in fact). From the point of view of resource consumption, I almost didn’t set anything up, about 200M of occupied RAM came out (right after the start).
Posted by
If you have a VPS on Xen or similar, then you do not have a rake, with whom I fought here. If on OpenVZ (Virtuozzo) and comrades, you probably have the same rake on a VPS.
In the article - why and how it works.
')
The difference between OpenVZ and Xen, which interests us here: OpenVZ is limited to virtual memory . Ie, for example, the tariffs of the form “256 + 256 burstable” mean that max is available to us. 256M is virtual memory (and 512M virtual on holidays).
Many programs allocate themselves virtual memory "in reserve", because during normal operation (or virtualization through Xen and friends), it can be allocated as many as you want (physically accessible) without any consequences. This is one of the reasons why VPS on Xen cost more than the same VPS on OpenVZ - they really provide more resources.
For each running thread in virtual memory, space is allocated for the stack . So, in debian lenny, for example, by default this place is = 10M. We take some apache with mpm_worker (which creates a bunch of threads), run under OpenVZ - hundreds of megabytes of memory are spent.
10 megabytes per stack is a lot. And it is set so much, because If linux is started normally, this memory is “free” - you could install at least 100M without negative effects (unless programs with recursion bugs would be agonizing longer). Typically, the program requires several times less, even with the account "in reserve".
The server is not a public computer; programs that will be launched there are known in advance. These programs usually do the same thing all the time. Somehow I don’t see the reasons for the abrupt changes in the size of the memory stack they need.
To reduce the default stack size, use the
There is an obvious warning - if you set a limit too low, something complicated (with a bunch of recursive code or an incomprehensible-why-sly work with the stack) can start to fall. Caution does not hurt. You are warned. Make backups. But 10M under the stack is, in most cases, a lot)
It seemed to me the optimal size of 2M. Extremes and experimenters can reduce further (I tried it, everything worked fine with me at 32K), but there the gain is already small, and the risk increases, there is little sense in general. Try it though.
In principle, running ulimit for all processes is pretty rough. For more fine-tuning, you can (zadolbatsya) edit the launch scripts of individual demons. Also, for some programs, it is possible to change memory in configs, which they will allocate to the thread thread, for example, apache, ThreadStackSize directive for mpm_worker. As a matter of fact, my Apache was set up in worker mode (php via fastcgi, if that), and stack memory was limited using ThreadStackSize without ulimit (the decrease was 2 times due to mysql with InnoDB, fastcgi php processes, mail servers and any trifles).
To test this whole affair, if you are afraid to go straight into /etc/init.d/rc, you can
1) to see how much a process takes in memory,
2) in the shell enter
3) restart the process (something like
4) look again, how much it takes now, and check that everything works
As a result, we have: OpenVZ users are paying a lot of RAM for the possibility of sometime (devils when) run a rare tricky program, whereas for all the rest it costs nothing. Therefore, we act as it seems to me logical: when virtualizing OpenVZ, we reduce the max. stack depth to 1-2M. On all HP-UX (which I, however, had never seen), for example, 64K, and do not cry. And from reducing the max. stack depth is released a bunch of RAM for more important pieces.
Criticism and comments are welcome.
Posted by
ulimit -s 1024 in /etc/init.d/rc closer to the top. Rebooted. Memory consumption on VPS more than doubled, it was about 100M.If you have a VPS on Xen or similar, then you do not have a rake, with whom I fought here. If on OpenVZ (Virtuozzo) and comrades, you probably have the same rake on a VPS.
In the article - why and how it works.
')
Openvz vs xen
The difference between OpenVZ and Xen, which interests us here: OpenVZ is limited to virtual memory . Ie, for example, the tariffs of the form “256 + 256 burstable” mean that max is available to us. 256M is virtual memory (and 512M virtual on holidays).
Many programs allocate themselves virtual memory "in reserve", because during normal operation (or virtualization through Xen and friends), it can be allocated as many as you want (physically accessible) without any consequences. This is one of the reasons why VPS on Xen cost more than the same VPS on OpenVZ - they really provide more resources.
But that is not all
For each running thread in virtual memory, space is allocated for the stack . So, in debian lenny, for example, by default this place is = 10M. We take some apache with mpm_worker (which creates a bunch of threads), run under OpenVZ - hundreds of megabytes of memory are spent.
10 megabytes per stack is a lot. And it is set so much, because If linux is started normally, this memory is “free” - you could install at least 100M without negative effects (unless programs with recursion bugs would be agonizing longer). Typically, the program requires several times less, even with the account "in reserve".
Reduce default stack size
The server is not a public computer; programs that will be launched there are known in advance. These programs usually do the same thing all the time. Somehow I don’t see the reasons for the abrupt changes in the size of the memory stack they need.
To reduce the default stack size, use the
ulimit -s < > command. The parameter changes for programs launched from the current shell (well, hierarchically, too, essno). We start this thing when the system boots (inside the script that starts the daemons) - that's all.There is an obvious warning - if you set a limit too low, something complicated (with a bunch of recursive code or an incomprehensible-why-sly work with the stack) can start to fall. Caution does not hurt. You are warned. Make backups. But 10M under the stack is, in most cases, a lot)
It seemed to me the optimal size of 2M. Extremes and experimenters can reduce further (I tried it, everything worked fine with me at 32K), but there the gain is already small, and the risk increases, there is little sense in general. Try it though.
In principle, running ulimit for all processes is pretty rough. For more fine-tuning, you can (zadolbatsya) edit the launch scripts of individual demons. Also, for some programs, it is possible to change memory in configs, which they will allocate to the thread thread, for example, apache, ThreadStackSize directive for mpm_worker. As a matter of fact, my Apache was set up in worker mode (php via fastcgi, if that), and stack memory was limited using ThreadStackSize without ulimit (the decrease was 2 times due to mysql with InnoDB, fastcgi php processes, mail servers and any trifles).
To test this whole affair, if you are afraid to go straight into /etc/init.d/rc, you can
1) to see how much a process takes in memory,
2) in the shell enter
ulimit -s <-, > ,3) restart the process (something like
/etc/init.d/mysql restart )4) look again, how much it takes now, and check that everything works
Thoughts
As a result, we have: OpenVZ users are paying a lot of RAM for the possibility of sometime (devils when) run a rare tricky program, whereas for all the rest it costs nothing. Therefore, we act as it seems to me logical: when virtualizing OpenVZ, we reduce the max. stack depth to 1-2M. On all HP-UX (which I, however, had never seen), for example, 64K, and do not cry. And from reducing the max. stack depth is released a bunch of RAM for more important pieces.
Criticism and comments are welcome.
Source: https://habr.com/ru/post/53236/
All Articles