【问题标题】:Allocating a lot of file descriptors分配大量文件描述符
【发布时间】:2012-06-06 15:08:35
【问题描述】:

我有兴趣通过分配大量文件描述符并导致 Out-of-File-Descriptor 故障来使系统停机(例如 15 分钟)。 (别担心,我并没有试图破解任何东西。这是为了测试我正在编写的服务......看看它在其他程序行为不端的情况下如何表现。)有什么最佳实践吗?我应该在无限 for 循环中一直说 fopen() 吗? 15分钟后,我可以杀死进程吗?有人有这方面的经验吗?

更新:我正在运行 Linux,我正在编写的程序将具有超级用户权限。

谢谢, 〜瑜伽士

【问题讨论】:

  • 您没有指定您正在谈论的操作系统,但很可能打开大量文件描述符只会导致打开它们的进程出现“打开的文件过多”错误,而不是“关闭系统”。
  • 不是。基于每个进程的打开文件描述符?

标签: c linux file-descriptor


【解决方案1】:

您是否考虑在运行程序之前使用setrlimit RLIMIT_NOFILE 降低文件描述符限制?

这可以简单地使用 bash ulimit -n 内置函数在您测试应用程序的同一 shell 中完成,例如:

 ulimit -n 32

而且它不会对已经在运行的许多其他服务造成太大影响。降低该限制将使您的应用程序(在同一个 shell 中运行)迅速损害它(出于您的测试目的)。

在整个系统级别上,您还可以写入/proc/sys/fs/file-max,例如与

echo 1024 > /proc/sys/fs/file-max

【讨论】:

    【解决方案2】:

    取决于操作系统的实现,但是从同一个进程对同一个文件调用 fopen 不会分配新的文件描述,而只是增加引用计数器。

    我建议您阅读有关 stress testing 的内容

    这里有一些可用的软件(你没有标记任何操作系统平台):

    http://www.opensourcetesting.org/performance.php

    【讨论】:

      【解决方案3】:

      我在正常使用时发生过一次。我相信你在 linux 中运行 inode。我不知道打开文件的更快方法。请小心,我们锁定了我们的系统。那是前一阵子,所以我不记得是什么试图打开文件,但事情通常假设他们可以获得文件句柄并且在他们不能的情况下表现得不如他们应该的那样。 〜本

      【讨论】:

        【解决方案4】:

        我的 2 美分:

        1.编写一个创建大量文件描述符的程序。您可以通过以下方法之一来实现:

        (a)在您的代码中打开许多不同的文件
        (b)打开很多socket描述符

        (c)创建很多线程

        2.现在,使用 shell 脚本或类似的东西继续生成在步骤 1 中创建的程序的多个实例(即创建多个进程)。

        注意: 在 linux 以及大多数其他操作系统中,每个进程的文件描述符数量是有限制的(在 linux 中,我猜默认是 1024。你可以使用 ulimit -a 检查它)。因此,当您执行此操作时,您的过程将失败。我真的不太确定仅仅通过增加文件描述符使用的数量就可以使系统崩溃。

        【讨论】:

        • 我在想如果其他进程尝试写入或读取任何内容,系统将变得可用。
        【解决方案5】:

        您可以使用mkstemp 获取临时文件的文件描述符。

        【讨论】:

          猜你喜欢
          • 2010-09-08
          • 1970-01-01
          • 2010-10-28
          • 2018-12-22
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多