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. 세 번째 경우의 쓰기 속도는 상당히 빠르며, 이는 /dev/null처음 두 경우에서 다른 요인(예: 구현된 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해당 경우의 쓰기 처리량에 대략적으로 비례합니다.

해석하는 방법을 잘 모르는 두 가지 다른 관찰:

• EC2 인스턴스에서는 htop메모리 사용량이 write 이후의 크기와 비슷하다고 표시되지만 /dev/shm/fake.txt내 데스크톱에서는 그렇지 않습니다.
• EC2 인스턴스에서는 동시 디스크 쓰기 정체로 인해 공유 메모리에 대한 쓰기 속도가 디스크에 쓰는 속도만큼 느려지는 것처럼 보이지만 내 데스크톱에서는 그렇지 않습니다.