Digamos que apenas tenhamos o seu programa e o kernel (isso é uma simplificação). Seu programa emite gravações e o kernel diz "yup, I've got them" no momento em que ele as coloca em um buffer interno, permitindo que o seu programa continue. Somente se o buffer interno do kernel estiver muito cheio, seu programa bloqueará a gravação até que haja espaço para aceitá-la. Isso significa que, se um programa estiver gravando quantidades "pequenas" de dados em um sistema silencioso, ele nunca acabará esperando o disco atender às E / Ss - dissociámo-lo da velocidade do disco por meio do uso de um buffer. Obviamente, essa ilusão só pode durar tanto tempo e depende de quão grande é o buffer, quão cheio ele fica, etc.
Além disso, se houver RAM não utilizada, o kernel poderá usá-la para armazenar em cache partes de discos. Quando escrevo dados para o disco, se houver espaço, os dados que escrevo não só serão armazenados em buffer e liberados posteriormente, mas também poderão ser mantidos após a limpeza, caso seja necessário posteriormente. Você pode ver esse efeito escrevendo um arquivo e, em seguida, checando de graça e normalmente você verá que a quantidade de RAM caiu porque partes desse arquivo estão sendo mantidas no cache. Se eu acabar lendo o cache do Linux, a velocidade que eu obtenho é tipicamente próxima da velocidade da RAM e o disco não é tocado (se você souber como usar o iostat, você notará que ele não está reportando nenhum disco / I / Quando isso ocorrer).
Então:
- E / S de gravação normal pode ser armazenada em buffer
- A E / S normal pode ser armazenada em cache
- A leitura de dados em cache é MUITO mais rápida do que a leitura de dados não armazenados em cache
- Seu programa de leitura é suscetível ao ponto anterior
Observe que isso é uma simplificação. Eu não cobri coisas como readahead ou interações do sistema de arquivos porque fsync
e assim por diante.
Além disso, os blocos, à medida que o kernel os envia para o disco, podem ser diferentes do tamanho que o programa os envia. Você pode enviar gravações contíguas de 16 x 4Kbyte ao kernel, mas o kernel pode mesclá-las e enviar uma única gravação de 64 Kbytes para o disco. Isso geralmente é benéfico na vida real, mas é algo que você deve estar ciente ao fazer benchmarking sintético.
Em resumo, eu acho que seus resultados são "irreais" porque você está se beneficiando enormemente do buffer e do cache do Linux. Se a sua carga de trabalho real é realmente assim, a velocidade do seu SSD não é o seu gargalo e os discos mais rápidos não ajudam muito (é tão realista que é uma palavra complicada)! Você pode obter números mais próximos aos do próprio SSD, garantindo que os tamanhos dos conjuntos de dados sejam muitos (pelo menos três) maiores que o tamanho total da memória do sistema ou fazendo I / O que não podem ser armazenados em buffer ou em cache . Eu não posso falar por que você é mais lento do que o cor-de-rosa porque qualquer resposta para isso é altamente específica para cada trabalho e nenhum trabalho foi incluído na questão.