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