Atualmente, estou desenvolvendo um software que precisa de comunicação entre processos e temporária de E / S (imagens, bem como grandes matrizes hdf5). O "tempo de vida" dos dados é diferente e depende de várias coisas, mas na maioria dos casos algo entre segundos e minutos. Apenas alguns arquivos precisam ser armazenados por mais tempo. Nenhum dos dados precisa ser salvo persistentemente.
Por isso, achei que /dev/shm deveria ser o caminho a seguir. No entanto, estou lutando para comparar /dev/shm .
Minha primeira tentativa foi:
sudo dd if=/proc/kcore of=/dev/shm/mem count=1000000
... que mostra o seguinte resultado:
1000000+0 records in
1000000+0 records out
512000000 bytes (512 MB, 488 MiB) copied, 0,661147 s, 774 MB/s
No entanto, quando executo dd com o sinalizador bs para especificar quantos bytes precisam ser lidos / gravados por vez, o resultado é altamente alterado:
sudo dd if=/proc/kcore of=/dev/shm/mem bs=$((1024*1024)) count=512
... resultados em:
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 0,166003 s, 3,2 GB/s
Por que é muito mais rápido ler / escrever grandes blocos de dados (muitos bytes 512 vezes) comparado a pequenos pedaços de dados muitas vezes (1.000.000 vezes, como na primeira tentativa)?
É "legítimo" comparar o /dev/shm com dd usando /proc/kcore como a origem? Ou é /proc/kcore limitando o benchmark?
Eu não posso dizer exatamente quanto desempenho realmente preciso , mas gostaria de ter mais de 1 GB / s em leitura & velocidade de gravação (porque a maior quantidade de dados que estou lendo ou gravando é de 1 GB e gostaria de fazê-lo em menos de um segundo).
Estou armazenando principalmente grandes matrizes (50 MB até 1 GB) via HDF5 .