Тестирование чтения / записи SSD вручную

260
John Frye

Я пытаюсь вручную проверить скорость чтения и записи SSD через NVMe. Текущий метод, который я использую, это монтировать файловую систему на SSD и читать / записывать 20 ГБ в файл в этой файловой системе с размерами блоков 4 КБ, 32 КБ, 128 КБ, 215 КБ, 1 МБ, 64 МБ, 256 МБ и 1 ГБ во время записи. время начала чтения / записи и время завершения. Этот процесс вызывается из скрипта bash. Сценарий bash попытается запустить несколько «приложений», вызывая указанную ниже функцию n раз, каждый раз запуская процесс в фоновом режиме.

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

Вот функция чтения из исполняемого файла 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;  }

Я перенес этот метод из работы, ранее проделанной другими, и я действительно не уверен, является ли это допустимым методом проверки пропускной способности к SSD. Результаты теста, особенно для операции чтения, не являются реалистичными; они намного выше, чем ожидалось. Fio предполагает, что пропускная способность для чтения и записи должна составлять около 500 МБ / с, но в этом тесте скорость записи составляет 1 ГБ + / с, а скорость чтения - около 8 ГБ / с.

0
Я предполагаю, что это, вероятно, связано с кэшированием файлов операционной системой, а также с самим SSD, буферизующим данные. Точное измерение истинной пропускной способности SSD не будет легкой задачей. James P 6 лет назад 0
Было ощущение, что контроллер nvme кеширует. Просто хотел получить некоторую информацию. Кажется, что когда я запускаю 4 приложения и выполняю запись, когда я возвращаюсь к чтению, первое чтение из 4 приложений завершается очень быстро. Кеширование может объяснить это. не знаю, как обойти это, кроме как написать свой собственный драйвер. Это не было бы тривиальным John Frye 6 лет назад 0
Если вы записываете тестовые файлы на твердотельный накопитель и перезагружаетесь (с циклическим включением питания, чтобы быть на параноидальной стороне), то при первом чтении после перезагрузки ваши файлы не будут ни в каких буферах ... unmount / remount также должен позаботиться о любое кэширование на уровне ОС xenoid 6 лет назад 0
Я попытался размонтировать и перемонтировать в моем скрипте bash между чтением и записью. Было выдано сообщение об ошибке, в котором говорилось, что все еще существуют процессы, связанные с разделами SSD. Мне интересно, есть ли какой-нибудь способ в bash, чтобы попытаться выполнить эту операцию, пока она не будет успешной. John Frye 6 лет назад 0

1 ответ на вопрос

0
Anon

Непонятно, в чем ваш вопрос - вы, кажется, спрашиваете «почему мои результаты нереалистичны (и почему они быстрее, чем у fio?)» Вы не включаете свою работу с fio, поэтому об этом ничего не скажешь :-( Я также не знаю, что делает программа fsrw. Я попробую сделать то, что осталось:

Допустим, у нас есть только ваша программа и ядро ​​(это упрощение). Ваша программа выдает ошибки, и ядро ​​говорит: «Да, я их получил», как только оно помещает их в очередь во внутреннем буфере, что позволяет вашей программе продолжать работу. Только если этот внутренний буфер ядра слишком переполнен, ваша программа будет блокироваться при записи, пока не будет места для ее принятия. Это означает, что если программа записывает «небольшие» объемы данных в тихой системе, она никогда не будет ждать, пока диск будет обслуживать операции ввода-вывода - мы отделили ее от скорости диска с помощью буфера. Очевидно, что эта иллюзия может длиться так долго и зависит от того, насколько большой буфер, насколько он заполнен и т. Д.

Кроме того, если имеется неиспользуемая оперативная память, ядро ​​может использовать ее для кэширования частей дисков. Когда я записываю данные на диск, если есть место, данные, которые я пишу, будут не только буферизироваться и сбрасываться позже, но и сохраняться после завершения очистки на случай, если это потребуется позже. Вы можете увидеть этот эффект, написав файл, а затем проверив его бесплатно, и, как правило, вы увидите, что объем оперативной памяти уменьшился, поскольку части этого файла хранятся в кеше. Если я в конечном итоге получаю его из кеша Linux, то скорость, которую я достигаю, обычно близка к скорости оперативной памяти, а диск остается нетронутым (если вы знаете, как использовать iostat, вы заметите, что он не сообщает о каком-либо / большом количестве дисковых операций ввода / вывода). О, когда это происходит).

Так:

  • Нормальная запись ввода / вывода может быть буферизована
  • Обычный ввод / вывод может быть кэширован
  • Чтение кэшированных данных НАМНОГО быстрее, чем чтение некэшированных данных
  • Ваша программа чтения восприимчива к предыдущему пункту

Обратите внимание, что это упрощение. Я не рассмотрел такие вещи, как readahead или взаимодействия с файловой системой, почему вы fsyncи так далее.

Кроме того, блоки, когда ядро ​​отправляет их на диск, могут отличаться от размера, который ваша программа отправляет. Вы можете отправить ядру 16 x 4 Кбайт непрерывных записей, но ядро ​​может объединить их и отправить одну запись 64 Кбайт на диск. Обычно это полезно в реальной жизни, но вы должны знать об этом при проведении синтетического бенчмаркинга.

Таким образом, я думаю, что ваши результаты "нереалистичны", потому что вы получаете огромную выгоду от буферизации и кеширования Linux. Если ваша реальная рабочая нагрузка действительно такая, то скорость вашего SSD не является вашим узким местом, и более быстрые диски вам не сильно помогают (настолько реалистично это сложное слово)! Вы можете получить числа, близкие к цифрам самого SSD, убедившись, что размеры вашего набора данных во много (как минимум, в три) раза больше, чем размер общей памяти в вашей системе, или выполнив ввод / вывод, который не может быть буферизован или кэширован., Я не могу сказать, почему вы работаете медленнее, чем fio, потому что любой ответ на этот вопрос очень специфичен для fio, и никакая работа не была включена в вопрос.

Похожие вопросы