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.)
ulimit
will show/set a per-process resource limit. – Kusalananda♦ Apr 5 '19 at 7:37