[hcoop/zz_old/ikiwiki] / UsingResourceLimits.mdwn

To prevent users from monopolizing system resources with runaway processes, we impose ulimits in a way that will lead to your processes dying mysteriously if they try to exceed them.  You can see what limits are being imposed in your current login by running the following command, with output shown:\r
\r
{{{you@new:~$ ulimit -aS\r
core file size        (blocks, -c) 0\r
data seg size         (kbytes, -d) unlimited\r
file size             (blocks, -f) unlimited\r
max locked memory     (kbytes, -l) unlimited\r
max memory size       (kbytes, -m) unlimited\r
open files                    (-n) 1024\r
pipe size          (512 bytes, -p) 8\r
stack size            (kbytes, -s) unlimited\r
cpu time             (seconds, -t) unlimited\r
max user processes            (-u) 20\r
virtual memory        (kbytes, -v) 100000}}}\r
\r
These limits are known as '''soft limits'''.  Similarly, you can see your '''hard limits''' by running `ulimit -aH`.  Soft limits are the limits that actually apply to your processes at a given time.  You have the option to increase your soft limits to any values no greater than your hard limits.  For instance, if you really need to run 21 processes at once instead of just 20, you can do this, because your hard limit is probably 50.  The proper command is:\r
\r
{{{ulimit -Su 21}}}\r
\r
The `-S` indicates that you are setting a soft limit, and `u` is the name of a resource limit kind, taken from the output above.\r
\r
You can even ''decrease'' your available resources, to put yourself in a self-imposed sandbox.  For instance, you can lower your stack size hard limit to 1000 by running:\r
\r
{{{ulimit -Hs 1000}}}\r
\r
= How Draconian!  Why do we have these limits?? =\r
\r
On our old server, we had multiple instances of users running benign yet out-of-control processes that ended up allocating all available memory.  Shared daemons, like our web and mail servers, would then crash when trying to allocate memory, creating denial-of-service for everyone.  The ssh daemon wasn't even able to work properly without available memory, so we sometimes needed to ask the techs at our hosting facility to reboot the server for us!  It's always better safe than sorry when it comes to protecting users from breaking other users' services.\r
Commit	Line	Data
ee25310d	1	To prevent users from monopolizing system resources with runaway processes, we impose ulimits in a way that will lead to your processes dying mysteriously if they try to exceed them. You can see what limits are being imposed in your current login by running the following command, with output shown:\r
	2	\r
	3	{{{you@new:~$ ulimit -aS\r
	4	core file size (blocks, -c) 0\r
	5	data seg size (kbytes, -d) unlimited\r
	6	file size (blocks, -f) unlimited\r
	7	max locked memory (kbytes, -l) unlimited\r
	8	max memory size (kbytes, -m) unlimited\r
	9	open files (-n) 1024\r
	10	pipe size (512 bytes, -p) 8\r
	11	stack size (kbytes, -s) unlimited\r
	12	cpu time (seconds, -t) unlimited\r
	13	max user processes (-u) 20\r
	14	virtual memory (kbytes, -v) 100000}}}\r
	15	\r
	16	These limits are known as '''soft limits'''. Similarly, you can see your '''hard limits''' by running `ulimit -aH`. Soft limits are the limits that actually apply to your processes at a given time. You have the option to increase your soft limits to any values no greater than your hard limits. For instance, if you really need to run 21 processes at once instead of just 20, you can do this, because your hard limit is probably 50. The proper command is:\r
	17	\r
	18	{{{ulimit -Su 21}}}\r
	19	\r
	20	The `-S` indicates that you are setting a soft limit, and `u` is the name of a resource limit kind, taken from the output above.\r
	21	\r
	22	You can even ''decrease'' your available resources, to put yourself in a self-imposed sandbox. For instance, you can lower your stack size hard limit to 1000 by running:\r
	23	\r
	24	{{{ulimit -Hs 1000}}}\r
	25	\r
	26	= How Draconian! Why do we have these limits?? =\r
	27	\r
	28	On our old server, we had multiple instances of users running benign yet out-of-control processes that ended up allocating all available memory. Shared daemons, like our web and mail servers, would then crash when trying to allocate memory, creating denial-of-service for everyone. The ssh daemon wasn't even able to work properly without available memory, so we sometimes needed to ask the techs at our hosting facility to reboot the server for us! It's always better safe than sorry when it comes to protecting users from breaking other users' services.\r