4

У меня есть два узла (с 3 выделенными дисками данных в каждом), которые показывают резко различающиеся скорости записи. Их вывод 'hdparm' выглядит идентично, а вывод 'hdparm -t -T' сравним, но выполнение команды 'dd' в смонтированной файловой системе дает резко отличающиеся скорости записи. Использование «dd» для проверки скорости чтения снова дает аналогичные результаты.

Серверы и жесткие диски являются одинаковыми моделями, на обоих установлены одинаковые программные пакеты (мы используем chef для отправки пакетов в наш кластер).

Я ищу идеи для параметров или других тестов, которые могут помочь мне разобраться в несоответствии производительности. Похоже, что это на уровне OS / FS, но я не уверен, что еще посмотреть. Обе смонтированные файловые системы - EXT4 с noatime и user_xattr.

Быстрый сервер:

вывод hdparm -t -T :

/dev/sdb1:
 Timing cached reads:   2138 MB in  2.00 seconds = 1070.08 MB/sec
 Timing buffered disk reads:  232 MB in  3.02 seconds =  76.84 MB/sec

выписываю тестовый файл 4ГБ

$ dd bs=4K if=/dev/zero of=/mnt/vol1/test.file count=1M
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 40.1102 s, 107 MB/s
0.20user 10.91system 0:40.14elapsed 27%CPU (0avgtext+0avgdata 3472maxresident)k
16inputs+8388608outputs (1major+263minor)pagefaults 0swaps

Чтение этого файла с диска (и в /dev /null)

$ dd bs=4K of=/dev/null if=/mnt/vol1/test.file count=1M
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 53.3914 s, 80.4 MB/s
0.19user 5.80system 0:53.53elapsed 11%CPU (0avgtext+0avgdata 3488maxresident)k
8389872inputs+0outputs (2major+264minor)pagefaults 0swaps

Медленный узел:

вывод hdparm -t -T

/dev/sdc1:
 Timing cached reads:   1982 MB in  2.00 seconds = 991.27 MB/sec
 Timing buffered disk reads:  224 MB in  3.02 seconds =  74.16 MB/sec

$ dd bs=4K if=/dev/zero of=/mnt/vol1/test.file count=1M
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 98.1583 s, 43.8 MB/s
0.35user 17.58system 1:38.17elapsed 18%CPU (0avgtext+0avgdata 3456maxresident)k
8inputs+8388608outputs (0major+263minor)pagefaults 0swaps


$ dd bs=4k of=/dev/null if=/mnt/vol1/test.file count=1M
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 54.7789 s, 78.4 MB/s
0.25user 10.84system 0:54.92elapsed 20%CPU (0avgtext+0avgdata 3488maxresident)k
8389864inputs+0outputs (2major+263minor)pagefaults 0swaps
|источник

2 ответа2

1

Пытаться 

hdparm -i -I /dev/sda

Для обоих дисков и различий вывода, это должно показать вам, если есть настройки dma или lookahead, которые отличаются для обоих.

В зависимости от вашего дистрибутива, должно быть место для установки параметра hdparm, чтобы убедиться, что они совпадают.

Я бы также дважды проверил кабели. Это может быть просто один диск, это тоже плохо, вы можете проверить скорость умного ECC и тому подобное. 

/usr/sbin/smartctl -A -H /dev/sda
/usr/sbin/smartctl -a /dev/sda

Это то, что я использую, чтобы проверить смарт на моих дисках.

|источник
0

  1. Может диск плохой. Проверьте на ошибки. (также проверьте выходные данные, чтобы увидеть, действительно ли они одинаковы: модель, прошивка, размер и размер сектора)

    smartctl -a /dev /sdb smartctl -a /dev /sdc

    Если у вас есть ошибки, запустите короткий тест (занимает 2 минуты):

    smartctl -t short /dev /sdb

    Если тест пройден без ошибок, то снова запустите "long" вместо "short" (занимает часы).

    А затем, когда это будет сделано, снова проверьте «-a» и запишите нули на ваш диск в этом секторе, чтобы переместить их (это уничтожает данные! Будьте очень осторожны с тем, что вы положили в =, потому что это то, что перезаписывается на исходном уровне нулями).

    например. если размер вашего сектора 512, а LBA 555 плохая, введите эту команду (уничтожает данные!)

    дд если = /dev / ноль = /dev /sdb bs = 512 счет = 1 поиск = 555

    Я бы сделал более высокий подсчет, так что вам не нужно повторять тестирование и запись нулей так часто, так как плохие сектора обычно находятся рядом друг с другом. (уничтожает гораздо больше данных!)

    дд если = /dev / ноль = /dev /sdb bs = 512 счет = 500 поиск = 555

  2. Возможно, ваш расклад неправильный. Убедитесь, что все разделы начинаются с или после 63, и если размер вашего логического сектора меньше размера вашего физического сектора, убедитесь, что ваше выравнивание делится на физический размер / логический размер. Это должно сильно повлиять на скорость записи, но не сильно повлиять на скорость чтения / вовсе.

    например. если физический - 4096, а логический - 512, то ваш начальный сектор должен делиться на 8 (4096/512). А на некоторых дисках старт должен быть намного выше 63. На этих дисках я использую 252 в качестве первого начала раздела.

    И если вы используете SSD, вы также должны выровнять блок стирания. Безопасное число для выравнивания - это кратные 129024 (что соответствует требованию 63 на старых дисках, секторах 4096 байт [диски расширенного формата, такие как большинство дисков Seagate и WD Green), 1024 МБ на большинстве SSD и 2048 МБ на редких SSD)

    Также с SSD, если они кажутся медленными, вы должны стереть их с помощью предоставленных поставщиком инструментов, прежде чем использовать их, или использовать TRIM.

  3. Используйте правильное сравнение.

    Вы не можете писать тесты с dd, если вы не используете conv = fdatasync или другой метод. Дэвид Шварц предложил использовать «time dd ...», но если вы используете conv = fdatasync, он покажет вам правильное время и скорость в dd без необходимости пересчитывать его самостоятельно. Если у вас много ОЗУ или кеша записи, вы измеряете ОЗУ и диск, если не используете опцию типа conv = fdatasync. http://romanrm.ru/en/dd-benchmark

    например.

    dd bs = 4K, если = /dev / zero = = / mnt / vol1 / test.file count = 1M conv = fdatasync

  4. Используйте правильное сравнение. (часть 2)

    Многие файловые системы или диски будут работать ОЧЕНЬ по-разному при записи нулей. Вам нужно использовать случайные файлы для достижения наилучших результатов.

    например.

    первая копия в ОЗУ

    cp /somewhere/with/big/files/bigfile.iso /dev / shm

    запустить тест

    dd bs = 4K, если = /dev / shm / bigfile.iso из = / mnt / vol1 / test.file count = 1M conv = fdatasync

    или же

    подготовить случайный файл

    дд если = /dev / random of = /dev / shm / randfile bs = 1M count = 500

    запустить тест

    dd bs = 4K, если = /dev / shm / randfile из = / mnt / vol1 / test.file count = 1M conv = fdatasync

  5. Кроме того, если ваши диски на самом деле не одинаковы или имеют разные файловые системы, они будут работать по-разному с размером блока 4 КБ. Также протестируйте 128k и 1M.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .