0

Today my server crashed with Too many open files in system: but I already have high values, what is a maximum value for this?

I feel like there aren't good results on google for this, explaining what needs to be taken in consideration for setting those values, they just say to set it to like 100k.

I have a 32 GB RAM server using only 10 GB right now, I assume increasing the file limits to very high values will increase RAM usage, is there some kind of formula you can use to calculate this? Like for 8 GB of ram you can have X number of files open?

Current settings:

cat /proc/sys/fs/file-max
100000
ulimit -Hn
1048576
ulimit -Sn
1024
|improve this question
  • Not an answer, but it strikes me that limiting the maximum number of open files is not a way to save RAM but disk I/O performance. Allowing a large number of open files implies allowing a (potentially) large number of simultaneous disk accesses. Also, you likely have a system-wide overall limit as well as a per-process limit on this. Not being a Linux user, I can't say much more about that, other than that ulimit will show/set a per-process resource limit. – Kusalananda♦ Apr 5 at 7:37
  • is this even a concern for SSD disks anyway? It's a server and I don't care if it dies, the hosting company will just replace it and I have backups. Also I read that network sockets can also cause this issue too, I care mostly about performance. I'm paying for the hardware either if I use 100% or 5% so as long it's improving performance why care? For a cloud server I could see this a issue but for dedicated hardware not really – Freedo Apr 5 at 7:39
  • Yes, the number of open sockets will count towards this limit too (open file-descriptors in general). I forgot about that. So if RAM is your only concern, I don't think I would worry about increasing the limit, unless that means that whatever service you provide starts allocating extra memory related to each open socket. This would be something that only you could investigate. – Kusalananda♦ Apr 5 at 7:44
0

As Kusalananda says, increasing file-max won’t directly have an impact on memory use, but it will allow processes to open more file descriptors which will have a knock-on effect (both from tracking file descriptions in the kernel, and increased memory usage in the processes using those descriptions and descriptors) — the kernel comments suggest approximately one kilobyte per file for the kernel’s data, and will reduce the default value of file-max (8192) if that ends up representing more than 10% of memory when the system boots (i.e. there’s only 80 MiB of RAM). The maximum value imposed by the kernel is the maximum value which can be stored in a variable of type long in C on your architecture.

If you increase file-max, you should also increase inode-max; the kernel documentation says this should be “3-4 times larger than the value in file-max, since stdin, stdout and network sockets also need an inode struct to handle them.”

Note that hitting file-max will result in a kernel log message saying “VFS: file-max limit n reached”, with the appropriate value for n. If you don’t have that in your logs, you’re either not hitting file-max, or filtering your logs too much (it’s an info-level log message).

(file-max doesn’t limit processes with CAP_SYS_ADMIN, so hitting it won’t stop everything.)

|improve this answer
  • So there is no downside in having a arbitrarily high numbers? I don't see inode-max in my system anyhwere? Ubuntu 16.04 here. I just want to prevent my server crashing again, I run multiple web services on this server and don't care about resources utilization – Freedo Apr 5 at 10:01
  • The downside is that runaway processes won’t get caught by the overall limit on file descriptions, so they could cause resource starvation in other ways. – Stephen Kitt Apr 5 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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