Sunday, 31 August 2008

Up The Limit

Recently while using the searchable plugin with Grails I've had exceptions citing too many open files. Linux systems typically limit resources on a per-user basis by various criteria such as number of processes and number of open files. Running ulimit -a I see the following:
core file size          (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 36864
max locked memory (kbytes, -l) 32
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) 36864
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
On this system I can only open 1024 files at once - I can increase this limit in /etc/security/limits.conf by adding something similar to the following:
gus  soft nofile  16384
gus hard nofile 16384
To ensure that PAM actually takes notice of these limits on login check /etc/pam.d/login for an entry like:
session    required     pam_limits.so
Can haz filez!

3 comments:

Glenn Saqui said...

Gus,

Hopefully you didn't spend too much time on this problem as Robf and I dealt with the same problem when we upgraded grails. I think it was a post on this blog as well.

Gus Power said...

Nah I've seen this before on a few other apps so quick to fix. Couldn't see anything on the list about it (nothing returned for 'ulimit') for figured I'd do a quick post to be nice :)

Dread Pirate Rob said...

Actually I think it's an unrelated issue. The thing we were dealing with was a bug in one of the versions of JDK 6 which did exciting things with classpaths specified in jar manifests.