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:
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.
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 :)
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.
Post a Comment