Recentemente, aprendi sobre o conveniente sistema de arquivos de "memória compartilhada" em /dev/shm
. Eu queria ver se eu poderia usar isso para acelerar um programa às vezes ligado a disco que grava e lê de um diretório, então eu executei uma pequena experiência em uma instância do EC2 (c4.8xlarge executando o Ubuntu 16.04):
$ 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
A instância EC2 parece ter uma taxa de transferência de gravação comparável a /dev/shm/
, como ocorre com uma unidade EBS, o que foi surpreendente. htop
indica que a máquina não está usando espaço de troca para gravar em /dev/shm
. A gravação notavelmente mais rápida em /dev/null
no terceiro caso indica que provavelmente não estou vinculado a algum outro fator (por exemplo, CPU através da implementação de yes
) nos dois primeiros casos.
Eu executei o mesmo experimento no meu computador pessoal - memória suficiente que /dev/shm
pode armazenar 7,5 GB de asdfjkl\n
por padrão, posso pesquisar mais detalhes de hardware se alguém achar que eles serão importantes - também executando o 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
Isso está muito mais perto do que eu esperava. A taxa de transferência de leitura (gravação em /dev/null
) nas duas máquinas e em ambos os sistemas de arquivos é praticamente proporcional à taxa de transferência no caso correspondente.
Duas outras observações, que não sei bem como interpretar:
htop
indica um uso de memória comparável ao tamanho de /dev/shm/fake.txt
, uma vez gravado, enquanto na minha área de trabalho, não. Tags amazon-ec2 shared-memory