/dev/null 的原理是什么？大量写入会影响系统性能吗？

[yjsslab]

[bellchu]

/dev/null类似一个黑洞，写入任何东西都会返回成功，但是实际写入数据随即被丢弃。

/dev/null的io只是软件层面的，实际没有存储的io动作。但是既然是软件层面的，就会有userspace到kernel的system call,会耗费相当多的CPU和内存。

因为传入/dev/null的数据几乎是在其被从软件传出的同时被丢弃的，所以传输的速度基本没有延迟，CPU占用率基本会迅速被占满。

[bellchu]

<amp-youtube data-videoid="3qNzOq4EXRY" layout="responsive" width="480" height="270"></amp-youtube>

[rming]

好像，貌似，记得，有人说过这个问题，在 C 的实现中，是直接使用的 return

[julyclyde]

@rming 这个不存在所谓在C的实现中的说法。虽说内核都是C写的，但这事和语言没关系

[tabris17]

会有系统调用，所以开销也不算小

[rming]

@bellchu 说的很对

[rrfeng]

@bellchu

这个实验说明了 yes 能使 CPU 使用率增加到 100%。

[ryd994]

@bellchu 这只是yes本身的开销而已吧……
不能认为是/dev/null的

[tianice]

http://zh.wikipedia.org/wiki/Yes_%28Unix%29

[loading]

不是你写到哪，写这个动作就耗资源，只是io部分少很多。

[bellchu]

@ryd994 对哦，那换一个往null写0的，更贴切点
cat /dev/zero > /dev/null

[bellchu]

@rrfeng 这个实验也说明了频繁写入/dev/null同样会消耗资源影响性能，而不会像很多人想象的输出到null的就不耗费任何资源，但实际上CPU的开销是一样的。

如果纠结yes命令的话。就换cat /dev/zero > /dev/null，其实效果是一样的，只不过一个是不断输出y，一个是不断输出0.

我的本意只想表达：把/dev/null当成一个0延迟的IO设备，当IO没有延迟的时候，CPU会成为最大的系统瓶颈，CPU会因为无法及时处理排队的数据而满负载。

[ryd994]

@bellchu 那就变成cat的开销了……
不过到null没开销这个肯定不可能，系统调用是少不了的。不过有多大开销就很难说了，如果只是百分之一/千分之一，认为可以忽略也没什么。

[bellchu]

@ryd994 楼主和我说的都是写入null造成的开销，不能单纯说是一个进程的开销或者是null的开销

这类似于讨论网络 A发送包给B 当A到B的延迟很高时会不会性能下降 当A到B基本无延迟时会不会有性能下降。还有性能下降的程度和速度。当量达到一定程度的时候，例如A有无数个副本同时发送数据给B的时候，一定量时B就瘫痪了，ddos成功。

就像你所说百分之一千分之一的开销基本可忽略，所以很多人喜欢把null当成焚化炉，把垃圾输出全丢null，不占用存储，不消耗io。现代系统的大多数应用的性能瓶颈都是io。

歪楼了...

[bellchu]

@ryd994 或者换句话说，百分之一千分之一的量不能算是大量。大数据时代要机器所产生的数据很简单就能“大量”。

可以参照keen.io

[ryd994]

@bellchu 即使是yes这样的程序，生成这么多数据的开销也比null丢弃这么多的大。那么忽略null的开销就是合理的。
这时候需要检讨的不是为什么输出到null，而是为什么平白无故生成这么多无用的数据。这么多数据，无论输出到哪里都是浪费。
这就像listen lo和用socket的区别。用loopback固然比用sock开销大，不过实际上可以忽略。倒不如考虑一下怎么减少不必要的进程间数据交换。

[yjsslab]

所以，没有实际的 IO 发生，只是 return count 的开销。

[yjsslab]

谢谢楼上各位。

[wizardoz]

要是写的时候不返回size的话，应用程序岂不是认为没有写进去进而重复写同一个内容？

[bellchu]

@ryd994 你说的都对，但是你没考虑到垃圾达到一定程度的时候的问题。

http://devnull-as-a-service.com/