Centos – Is it safe to set a very high ulimit for a process

centoscentos7ulimit

I currently have the following entry in /etc/security/limits.d/90-nproc.conf based on Mongo DB's recommended ulimit settings.

mongod     soft    nofile    64000
mongod     soft    nproc     64000

I need to massively increase the number of permitted file descriptors to – say – 999999. In normal situations only a few thousand files are likely to be accessed per day. The reason for the large number of files is the way the WiredTiger storage engine works. It uses several files per collection, of which I have many thousands.

Are there any negative impacts to this situation?

Is it detrimental to system performance to have a huge number of file descriptors open, but largely unused?

Best Answer

nproc is the number of processes limit. If you mean files you want nofiles.

It is merely a maximum limit counter. Increasing the limit doesn't use resources until that many things are in use on the system.

64k is a lot of processes. Your performance may suffer depending on how much memory and CPU you have. The Linux scheduler overhead may become significant with this many tasks.

Also adjust file descriptors if necessary, as mentioned in mongodb reference on ulimit. File descriptors are relatively lightweight, and you need one for every open file and socket, but 64k is still a lot.

Related Solutions

Linux ulimit – Practical Maximum Open File Descriptors for High Volume Systems

These limits came from a time where multiple "normal" users (not apps) would share the server, and we needed ways to protect them from using too many resources.

They are very low for high performance servers and we generally set them to a very high number. (24k or so) If you need higher numbers, you also need to change the sysctl file-max option (generally limited to 40k on ubuntu and 70k on rhel) .

Setting ulimit:

# ulimit -n 99999

Sysctl max files:

#sysctl -w fs.file-max=100000

Also, and very important, you may need to check if your application has a memory/file descriptor leak. Use lsof to see all it has open to see if they are valid or not. Don't try to change your system to work around applications bugs.

How to set ‘max threads per process’ ulimit for non-root user

You said AIX, but in the case of linux I think it would just be the -u limit switch. In Linux this states 'processes', but with bash, ulimit is just a interface to the setrlimit system call. This can be seen by running strace bash -c 'ulimit -u 10' which returns:

setrlimit(RLIMIT_NPROC, {rlim_cur=10, rlim_max=10}) = 0

The man page for setrlimit states:

RLIMIT_NPROC The maximum number of processes (or, more precisely on Linux, threads) that can be created for the real user ID of the calling process. Upon encountering this limit, fork(2) fails with the error EAGAIN.

So maybe it is the same for AIX? This link states: "AIX does not define RLIMIT_NPROC or RLIMIT_MEMLOCK resources.", but you might be able to find a more definitive answer on developerworks.

For the permissions issue, the solution may be to set the limit with root, and then su to the user you need to increase the limit for. I have had to do this for other resource limits in the past, for example, max open files. The limits.conf was not applied so I had do use sudo or su from root, and then the limit gets inherited.

Best Answer

Related Solutions

Linux ulimit – Practical Maximum Open File Descriptors for High Volume Systems

How to set ‘max threads per process’ ulimit for non-root user

Related Topic