Привожу на ServerFault проблему, которая мучает меня уже 6+ месяцев. У меня есть сервер CentOS 6 (64-разрядный) с массивом программного обеспечения md raid-1 с двумя твердотельными накопителями Samsung 840 Pro (512 ГБ).
Проблемы:
root [~]# time dd if=arch.tar.gz of=test4 bs=2M oflag=sync 146+1 records in 146+1 records out 307191761 bytes (307 MB) copied, 23.6788 s, 13.0 MB/s real 0m23.680s user 0m0.000s sys 0m0.932s
При выполнении вышеупомянутого (или любой другой более крупной копии) нагрузка резко возрастает до невероятных значений (даже более 100) с ~ 1.
При выполнении вышеуказанного я также заметил очень странные результаты iostat:
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 1589.50 0.00 54.00 0.00 13148.00 243.48 0.60 11.17 0.46 2.50 sdb 0.00 1627.50 0.00 16.50 0.00 9524.00 577.21 144.25 1439.33 60.61 100.00 md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md2 0.00 0.00 0.00 1602.00 0.00 12816.00 8.00 0.00 0.00 0.00 0.00 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
И он остается таким, пока он не запишет файл на устройство (из подкачки / кеша / памяти).
Проблема в том, что второй SSD в массиве имеет svctm и await примерно в 100 раз больше второго.
root [~]# smartctl --attributes /dev/sda | grep -i wear 177 Wear_Leveling_Count 0x0013 094% 094 000 Pre-fail Always - 180 root [~]# smartctl --attributes /dev/sdb | grep -i wear 177 Wear_Leveling_Count 0x0013 070% 070 000 Pre-fail Always - 1005
У первого SSD износ 6%, а у второго SSD износ 30% !!
Это похоже на то, что второй SSD в массиве работает как минимум в 5 раз сильнее, чем первый, что было доказано первой итерацией iostat (средние значения с момента перезагрузки):
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 10.44 51.06 790.39 125.41 8803.98 1633.11 11.40 0.33 0.37 0.06 5.64 sdb 9.53 58.35 322.37 118.11 4835.59 1633.11 14.69 0.33 0.76 0.29 12.97 md1 0.00 0.00 1.88 1.33 15.07 10.68 8.00 0.00 0.00 0.00 0.00 md2 0.00 0.00 1109.02 173.12 10881.59 1620.39 9.75 0.00 0.00 0.00 0.00 md0 0.00 0.00 0.41 0.01 3.10 0.02 7.42 0.00 0.00 0.00 0.00
корень [~] # fdisk -ul / dev / sda Disk /dev/sda: 512.1 GB, 512110190592 bytes 255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00026d59 Device Boot Start End Blocks Id System /dev/sda1 2048 4196351 2097152 fd Linux raid autodetect Partition 1 does not end on cylinder boundary. /dev/sda2 * 4196352 4605951 204800 fd Linux raid autodetect Partition 2 does not end on cylinder boundary. /dev/sda3 4605952 814106623 404750336 fd Linux raid autodetect корень [~] # fdisk -ul / dev / sdb Disk /dev/sdb: 512.1 GB, 512110190592 bytes 255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0003dede Device Boot Start End Blocks Id System /dev/sdb1 2048 4196351 2097152 fd Linux raid autodetect Partition 1 does not end on cylinder boundary. /dev/sdb2 * 4196352 4605951 204800 fd Linux raid autodetect Partition 2 does not end on cylinder boundary. /dev/sdb3 4605952 814106623 404750336 fd Linux raid autodetect
/ proc / mdstat root # cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb2[1] sda2[0] 204736 blocks super 1.0 [2/2] [UU] md2 : active raid1 sdb3[1] sda3[0] 404750144 blocks super 1.0 [2/2] [UU] md1 : active raid1 sdb1[1] sda1[0] 2096064 blocks super 1.1 [2/2] [UU] unused devices:
root [~]# hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 664 MB in 3.00 seconds = 221.33 MB/sec root [~]# hdparm -t /dev/sdb /dev/sdb: Timing buffered disk reads: 288 MB in 3.01 seconds = 95.77 MB/sec
root [~]# hdparm --direct -t /dev/sda /dev/sda: Timing O_DIRECT disk reads: 788 MB in 3.01 seconds = 262.08 MB/sec root [~]# hdparm --direct -t /dev/sdb /dev/sdb: Timing O_DIRECT disk reads: 534 MB in 3.02 seconds = 176.90 MB/sec
Оба теста увеличиваются, но / dev / sdb удваивается, а / dev / sda увеличивается примерно на 20%. Я просто не знаю, что с этим делать.
root [/home2]# dd if=/dev/sda of=/dev/null bs=1G count=10 10+0 records in 10+0 records out 10737418240 bytes (11 GB) copied, 38.0855 s, 282 MB/s root [/home2]# dd if=/dev/sdb of=/dev/null bs=1G count=10 10+0 records in 10+0 records out 10737418240 bytes (11 GB) copied, 115.24 s, 93.2 MB/s
Так что sda в 3 раза быстрее sdb. Или, может быть, sdb делает что-то еще помимо того, что делает sda. Есть ли способ узнать, делает ли sdb больше, чем sda?
Опять же, как предложил г-н Вагнер, я поменял 2 твердотельных накопителя местами. И как он думал, это произойдет, проблема переместилась с sdb на sda. Так что я думаю, что я RMA один из SSD. Интересно, может ли клетка быть проблемной.
Что не так с этим массивом? Пожалуйста помоги!
Что ж, в конце концов, я думаю, что выяснил, по крайней мере, большую часть проблемы: один из SSD в массиве работал очень плохо. Я прочитал достаточно отчетов о плохой производительности mdraid в отношении твердотельных накопителей Samsung 840 Pro, но этот диск работал очень плохо, даже когда использовался сам по себе. На данный момент я исправил это, выполнив безопасное стирание рассматриваемого SSD с помощью hdparm. Производительностью похвастаться нечего, но она намного ближе к приличной, чем раньше: около 210-220 МБ / с при чтении и около 130-150 МБ / с при записи (по сравнению с 5-10 МБ / с при записи ранее). Обратите внимание, это на SATA2, максимальная скорость которого составляет около 240 МБ / с.
В завершение я хотел бы поблагодарить господина Вагнера, чей совет поменять диски оказался полезным.
В заключение, если у вас есть проблемы с производительностью SSD, подумайте о безопасном стирании! Обратите внимание, что безопасное стирание - это не то же самое, что и форматирование.