Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My team recently had an issue with ulimit being set too low on our Apache servers. We talked about increasing the limit to some arbitrary number, but we couldn't think of any reason not to just globally set it to unlimited.

Are there some good reasons not to do this?

We realise there could use more resources, but it's easier to deal with a resource usage probably than an application crash or a "out of fd" problem.

share|improve this question
I just realised I was being vague about which limit. The limit I and refering to is "nofile" – Joehillen Feb 1 '12 at 20:05

ulimit is an interface to set all kinds of limits on a Linux system, not just open file descriptor limits:

~# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

The reason you actually would set limits on resources is because resources are finite. Setting limits basically protects your system from becoming unresponsive at the cost of limiting specific users. Even if you only have a single application to care about, you still need to ensure it does not bring the system to a halt so you even can't login via SSH to fix matters any more.

In the specific case of open file descriptors, the overhead of asynchronous operations using select() or poll() calls increases significantly if the file descriptor table is too large (which does not happen under usual conditions but might happen easily if one of your processes is leaking handles). This will hurt overall performance for asynchronous I/O system-wide.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.