我正在开发一个旧的遗留应用程序，并且我经常遇到一些没有人解释的设置。
显然，在某个时候，应用程序中的某些进程达到了每个进程允许的最大文件描述符数，然后团队决定通过将以下内容添加到其 shell 的 init 文件 (.kshrc) 来增加限制：
((nfd=16#$(/etc/sysdef | grep "file descriptor" | awk '{ print $1 }' | cut -f3 -d "x")))
ulimit -n $nfd
这将输出ulimit -n从 256 增加到 65536。实际上我们机器上的每个进程都在这个高软限制下运行。
这种粗暴的方法有什么风险吗？正确的校准方法是什么ulimit？
附带问题：我如何知道正在运行的进程当前使用的 FD 数量？
环境
- 操作系统：SunOS .... 5.10 Generic_120011-14 sun4u sparc SUNW，Sun-Fire-V215
- 外壳：KsH 版本 M-11/16/88我
答案1
要查看正在运行的进程正在使用的文件描述符的数量，请运行pfiles在进程 ID 上。
增加进程可用的 fd 数量可能会对性能产生影响，具体取决于软件及其编写方式。程序可以使用 fd 的最大数量来调整数据结构的大小，例如select(3c)位掩码数组，或对所有 fd 执行诸如循环关闭之类的操作（尽管为 Solaris 编写的软件可以使用fdwalk(3c)函数仅针对打开的 fd 执行此操作，而不是最大可能值）。
答案2
看到了我们需要解决的问题限制应用程序的 shell 只有 256 个可用的文件描述符。该应用程序非常旧，显然使用了 fd 的最大数量，并尝试将该数字放入“unsigned char”类型的变量中，该变量最多只能容纳整数 256（导致核心转储）。因此，对于这个特定的应用程序，我们必须将其限制为只有 256 个可用的 fd。
与 alanc 不同，我真的不相信按照您的建议将其设置得非常高会对性能产生任何可衡量的影响。不这样做的原因更多是为了防止流氓进程消耗太多资源。
最后，alanc 是正确的，该pfiles命令将告诉您给定进程当前正在使用的 fd 数量。但请记住，该pfiles命令会暂时停止该进程以进行检查。我见过进程因pfiles对它们运行命令而崩溃......但我承认这可能是您的应用程序永远不会遇到的极端情况。抱歉，我不知道有什么安全的方法来查找进程当前使用的 fd 数量。我的建议：在针对进程运行pfiles命令后，始终监视该进程是否仍然存在。