Testando manualmente leitura / gravação de SSD

0

Estou tentando testar manualmente a velocidade de leitura e gravação de um SSD sobre o NVMe. O método atual que estou usando é montar um sistema de arquivos no SSD e ler / gravar 20GB em um arquivo nesse sistema de arquivos em tamanhos de bloco de 4KB, 32KB, 128KB, 215KB, 1MB, 64MB, 256MB e 1GB, enquanto grava. a hora do início da leitura / gravação e o tempo de conclusão. Este processo é chamado a partir de um script bash. O script bash tentará executar vários "aplicativos" chamando a função abaixo n vezes, cada vez que executar o processo em segundo plano.

while [ $instCnt -le $appInstances ]
    do
    fsrw -w $blocksize /fsmnt/fs${instCnt}/usernumber1/j.j &

Aqui está a função de leitura do executável fsrw

bool perform_readop ()
{
// File descriptor.
int32_t fd = -1;

// Function status.
bool status = false;

//Zero read count
int zero_reads = 0;

// Open the file.
fd = open (fname.c_str (), O_RDONLY);

// Verify the file has been opened.
if (fd == -1)
{
    cout << get_datetime_string() << "Read open of " << fname << " failed.  Errno: " 
    << errno << endl;
}
else
{
    // Total bytes read.
    uint64_t rd = 0;

    // Elapsed time.
    struct timeval tv = { 0 };
    get_elapsed_time (&tv);

    // Notify the user that the read test has started.
    cout << get_datetime_string() << "Starting read" << endl;

    while(rd < READ_LIMIT && zero_reads < 10) {
        // Run until it is time for the test to stop.
        ssize_t readsize = read (fd, &buf[0], blocksize);
        if (readsize == -1)
        {
            cout << get_datetime_string << "Read failure.  Errno: " << errno << endl;
            zero_reads = 10;
        }
        else if (readsize == 0)
        {
            cout << get_datetime_string << "Reached EOF." << endl;
            zero_reads++;
        }
        else
        {
            rd += readsize;
        }
    }       
    // Get the elapsed time.
    get_elapsed_time (&tv);

    // Report the number of bytes read.
    cout << get_datetime_string() << "Read " << rd << " bytes in " << tv.tv_sec << "." 
    << tv.tv_usec << " seconds, bytes per second " << bytes_per_second (&tv, rd) << endl;

    // Close the file.
    close (fd);

    // Set the function return status when all read operations have
    // been successful.
    if (zero_reads < 10)
    {
        status = true;
    }
}

  return status;

}

Eu portei este método de um trabalho feito anteriormente por outros, e não tenho certeza se este é um método válido de verificar a taxa de transferência para o SSD. Os resultados do teste, especialmente para a operação de leitura, não são realistas; eles são muito mais altos que o esperado. Fio sugere que a taxa de transferência deve ser de aproximadamente 500MB / s para leitura e gravação, mas isso testa a velocidade de gravação de 1 GB + / s e velocidades de leitura próximas a 8 GB / s

    
por John Frye 20.11.2017 / 15:00

1 resposta

0

Não está claro qual é a sua pergunta - você parece estar se perguntando "por que meus resultados não são realistas (e por que eles são mais rápidos que os de um fio)". Você não inclui o seu trabalho de fio, então é impossível dizer algo sobre isso :-( Eu também não sei o que o programa fsrw faz. Eu vou dar uma olhada no que resta:

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.

    
por 05.02.2018 / 12:22

Tags