Linux在/proc/sys/fs
中提供以下值:
file-max和file-nr,file-max的值表示Linux内核将分配的最大文件句柄数。当您收到大量有关文件句柄不足的错误消息时,可能需要增加此限制。
nr_open 表示进程可以分配的最大文件句柄数。默认值是1024*1024(1048576),对于大多数机器来说,这应该足够了。实际限制取决于RLIMIT_NOFILE资源限制。
MacOS通过sysctl提供以下值:
kern.maxfiles: 245760
kern.maxfilesperproc: 122880
kern.num_files: 8685
FreeBSD 也通过 sysctl 提供这些信息,但对于打开的文件有不同的名称。
kern.maxfiles: 64534
kern.maxfilesperproc: 58077
kern.openfiles: 1339
OpenBSD也通过sysctl提供它们,并使用不同的名称。
kern.maxfiles=7030
kern.nfiles=143
Solaris提供了位于
kstat:/kmem_cache/kmem_default/file_cache
中的
buf_inuse
和
buf_max
值。
在一些基于Unix的文件系统中,您可能可以捕获
lsof -nl
的命令行输出以计算当前文件数(尽管这可能会很慢),以及
ulimit -n
获取最大值。
OSHI从Linux的procfs、macOS、FreeBSD、OpenBSD的sysctl以及Solaris的kstat返回值,以及从上面的命令行中获取AIX的值。
作为OSHI的作者,我可能有偏见,但这可能是跨平台获取这些值的最简单方法。
对于Windows来说,并没有“文件限制”这样的概念。Windows对句柄进行限制。有关这些限制的更多详细信息,请参见
此Stack Exchange问题。该问题和答案是OSHI javadocs中所提到的合格语言的来源。
理论上,在64位Windows中,进程可以打开的句柄的最大数量是2的32次方,因为句柄有32位有效位。但实际上,它已被限制为每个进程16,777,216(2的24次方)。在32位Windows中,限制可能是2的16次方
并且
但是,对于使用默认C运行时库的单个进程,则默认限制为512。
还有
不清楚Windows中所有进程的总文件句柄数的最大值。