EC2インスタンスの「/dev/shm」がEBSドライブに似たI/Oスループットを持つのはなぜですか？

私は最近便利な「共有メモリ」ファイルシステムについて学びました/dev/shm。時々、ディレクトリから書き込んで読み取るディスクバインディングプログラムを高速化するためにこれを使用できるかどうかを確認したかったので、EC2インスタンス（Ubuntu 16.04を実行しているc4.8xlarge）でいくつかの実験を実行しました。

$ time yes asdfjkl | head -1000000000 > /mnt/fake.txt
real    0m21.381s
$ time yes asdfjkl | head -1000000000 > /dev/shm/fake.txt
real    0m20.266s
$ time yes asdfjkl | head -1000000000 > /dev/null
real    0m14.334s

EC2インスタンスの書き込みスループットはEBSドライブと似ていますが/dev/shm/、これは驚くべきことです。htopマシンが書き込みにスワップスペースを使用しないことを示します/dev/shm。 3番目のケースの書き込み速度はかなり速く、これは/dev/null最初の2つのケースで他の要因（実装されたCPUなど）によって制限されない可能性があることを示しています。yes

/dev/shm私は基本的に7.5GBのメモリが十分なパソコンで同じ実験を行いました。asdfjkl\nまた、Ubuntu 16.04を実行しながら重要だと思う人がいる場合は、より多くのハードウェアの詳細を掘り下げることができます。

$ time yes asdfjkl | head -1000000000 > /mnt/fake.txt
real    0m36.520s
$ time yes asdfjkl | head -1000000000 > /dev/shm/fake.txt
real    0m12.516s
$ time yes asdfjkl | head -1000000000 > /dev/null
real    0m11.252s

これは私が期待していたものにはるかに近いです。両方のシステムと両方のファイルシステムの読み取りスループット（書き込み）は、/dev/nullその場合の書き込みスループットにほぼ比例します。

解釈する方法がわからない2つの異なる観察：

• EC2インスタンスでは、htopメモリ使用量はwrite以降のサイズに似ているとマークされていますが、/dev/shm/fake.txt私のデスクトップではそうではありません。
• EC2 インスタンスでは、同時ディスク書き込みの輻輳により、共有メモリへの書き込み速度がディスクへの書き込み速度と同じくらい遅くなるように見えますが、私のデスクトップではそうではありません。