Minha resposta teve 2 partes: investigação do driver de dispositivo de bloco; e otimização vale a pena olhar com o seu caso de uso. Mas eu removi a última parte como foi relatado que pode levar à perda de dados. Ver comentários.
Investigação de Hardware
Eu entendi que para o mesmo aplicativo, mas em dois conjuntos diferentes de hardware, o desempenho é muito diferente e você gostaria de entender o motivo. Portanto, proponho primeiro um meio para ajudá-lo a encontrar uma resposta para o "porquê".
Por desempenho, costumo me referir ao Mapa de Desempenho do Linux fornecido por Brendan Gregg em seu blog. Pode-se ver que, para o nível baixo (mais próximo do hardware), uma ferramenta como blktrace seria perfeita.
Não conhecendo realmente esta ferramenta, pesquisei e encontrei este artigo interessante sobre o blktrace por Marc Brooker. Basicamente, sugere o seguinte: executar um rastreio de E / S usando blktrace ; usando a ferramenta btt para extrair informações desse rastreamento. Isso seria algo assim (para um rastreamento de 30 s):
# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less
A saída pode ser bastante longa, mas procure por entradas D2C. Isso lhe dará uma idéia do tempo que leva para que uma E / S entregue ao driver de dispositivo seja relatada como concluída por esse driver.
Exemplo de saída ( dnf upgrade em execução em uma VM do VirtualBox no meu laptop ocupado):
ALL MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
...
D2C 0.000046515 0.045781696 3.940577359 11713
...
Mostra uma média decepcionante de 45 ms por E / S com até 3,94 s para o pior caso!
Para mais formas de usar blktrace para realizar esta investigação, leia o artigo de Marc Brooker, muito instrutivo.