/dev/null 重定向的 IO 利用率？

Question

我总是用它nohup来启动我的系统。但是，输出nohup太大，我想将其重定向到/dev/null.我担心的是，重定向是否也会/dev/null引发一些 I/O 操作，例如写入普通文件？

或者，我应该深入到代码级别并删除所有这些日志信息吗？ （但我可能需要它们）。

我唯一关心的是 I/O 利用率和文件大小。

Answer 1

写入的数据/dev/null不会去任何地方。由于它没有写入任何文件，因此不会对文件大小产生任何影响。

如果程序写入/dev/null，则会发生系统调用。但系统调用几乎立即返回，而没有将数据写入任何地方。因此，从应用程序的角度来看存在 I/O，但从硬件的角度来看则没有。

除了你之外，没有人知道写信的微小成本是否/dev/null太多。如果您担心，请进行基准测试。

Answer 2

这感觉有点像XY问题。您真正应该做的是添加通过配置文件或命令行使用越来越多的 's 来控制日志记录级别的功能-v。-vvv正如许多命令行工具一样。

nohup然后，您仍然可以使用添加/删除切换来调用服务器-vv..，并且仅在必要时添加它。

另外看看使用真正的日志记录工具，例如日志4j,log4perl, log4X 其中 X 是您的语言。然后，您可以从 log4X .conf 文件控制日志记录级别，还可以指定日志轮换等内容。

显然，您可以按原样重定向日志记录，/dev/null但作为开发人员，您也应该考虑这些其他选项。

Answer 3

写入 /dev/null 会产生非零成本，但如果它影响您的系统性能，则该软件的作者做了一些非常错误的事情。调用 sys_write() 是高度优化的。写入发送给它的数据确实会通过各种库和内核系统，直到到达空驱动程序。这条路是非常高效的。

是的，一个程序可能应该有一个禁用输出的标志，但如果没有，并且写入 /dev/null 会产生性能问题，那么您就会遇到一个奇怪的系统。

请记住“过早的优化是万恶之源”。编辑代码来解决这个问题是浪费时间，除非您可以首先编写一个基准测试来表明这确实是最大的性能瓶颈。

历史注释：

Linux 的原始版本的 /dev/null 非常慢。它做了很多处理只是为了最后扔掉数据。有一个令人尴尬的基准测试（抱歉，我找不到链接！）显示 Linux 的 /dev/null 比 FreeBSD 和 Solaris（当时流行的类 Unix 系统）慢得多。 Linux 的下一个版本有更快的 /dev/null。同样，Linux 中的环回 NIC 过去非常慢，因为它完全处理了数据包，检查 CRC 错误（这不可能是错误的），并执行其他不必要的工作。一些令人尴尬的糟糕基准被发布，很快问题就得到了修复。