Atualmente, estou desenvolvendo um software que precisa de comunicação rápida entre processos e E/S temporária (imagens e grandes arrays hdf5). A “vida útil” dos dados é diferente e depende de vários fatores, 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 de forma persistente.
Portanto, pensei /dev/shmque deveria ser o caminho a seguir. No entanto, estou lutando para fazer benchmark /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 ddo bssinalizador para especificar quantos bytes devem ser lidos/gravados por vez, o resultado muda bastante:
sudo dd if=/proc/kcore of=/dev/shm/mem bs=$((1024*1024)) count=512
...resulta 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/gravar grandes pedaços de dados (muitos bytes 512 vezes) em comparação com pequenos pedaços de dados muitas vezes (1.000.000 de vezes, como na primeira tentativa)?
É "legítimo" fazer benchmark /dev/shmusando ddcomo /proc/kcorefonte? Ou está /proc/kcorede alguma forma limitando o benchmark?
Não posso dizer exatamente quanto desempenho eurealmentepreciso, mas gostaria de ter mais de 1 GB/s de velocidade de leitura e gravação (porque a maior quantidade de dados que estou lendo ou gravando é de 1 GB e gostaria de fazer isso em menos de um segundo).
Estou armazenando principalmente grandes arrays (50 MB até 1 GB) viaHDF5.