ServerLoft: почему на машине с SSD /dev/sdb становится в 5 раз медленнее, даже после замены диска?

Question

[DmitryKoterov]

История совершенно мистическая: после "наливки" ОС на сервер (HP ProLiant DL320E, 2 Samsung SSD 840 PRO Series 256G DXM05B0Q, Ubuntu Server 12.04) диск /dev/sdb становится в 5 раз медленнее, чем /dev/sda. При этом если заменить sdb на свежий и перезагрузиться, то он становится быстрым, но после новой переналивки сервера с нуля - все снова-здорова (эту процедуру проделывали дважды, т.е. 2 раза заменяли диск). На сервере RAID-1, но он на момент теста отключен, да и вообще - сервер загружается в recovery mode (по сети, с одного и того же образа, который попадает на RAM-диск).

Более того, если в момент, когда sdb - медленный, поменять местами sda и sdb, то медленным становится sda! Т.е. явно оно где-то запоминает, какой диск "должен быть" медленным. После замены sda на свежий и переналивки - опять sdb медленный.

Материнскую плату тоже заменяли (дважды). Что может такое это быть?

<sup># hdparm -t /dev/sd?
/dev/sda:
Timing buffered disk reads: 1576 MB in 3.00 seconds = 524.82 MB/sec
/dev/sdb:
Timing buffered disk reads: 322 MB in 3.01 seconds = 107.02 MB/sec
# cat /proc/mdstat
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
unused devices:
# cat /dev/sda | pv > /dev/null
59GB 0:00:05 [531MB/s] ]
# cat /dev/sdb | pv > /dev/null
68MB 0:00:05 [137MB/s]

The whole history:
- sdb was slow
- you replaced sdb with the new SSD
- it remained slow
- you replaced the whole hardware around
- it became fast, but after the restoration it became slow again
- you replaced the whole hardware around the disks again
- sdb remained slow
- you swapped sda and sdb
- sda became slow! so the slowness was tied to a particular SSD
- you replaced sda with the new SSD, you removed the 2nd NIC
- sda became fast and sdb remained fast! I saw it!!!
- I executed the "Restore" procedure
- sdb became slow, sda remained fast</sup>

Comments

[Chromium58]

а что говорит dmesg?

[DmitryKoterov]

Вот, кстати, один-в-один мой случай: serverfault.com/questions/547083/various-problems-...

Но только там человеку помогла замена дисков. А в моем случае тот диск, который был быстрым, стал медленным после переналивки ОС (т.е. "испортился"?).

[DmitryKoterov]

Вот dmesg сразу же после загрузки в recovery mode с эталонного имиджа по сети: pastebin.com/Hdz0KAbu - я ничего подозрительного про диски не заметил там... А что там должно быть, на что обратить внимание?

[DmitryKoterov]

Так-так... Похоже, скорость sdb восстановилась сама собой. Что я сделал: я запустил
dd if=/dev/sdb of=/dev/null bs=1G count=50
(т.е. прочитал вникуда 50Г данных с начала диска). После этого и hdparm, и dd, и даже cat | pv показывают одинаковую скорость у обоих дисков, в том числе после перезаргузки машины (!).

Может такое быть, что внутри SSD есть какой-то кэш, который этим чтением 50Г заполнился, после чего диск стал работать быстро? Или какой-нибудь фоновой процесс "чистки перышек" внутри самого SSD успокоился, когда я прочитал первые 50Г? (Чтение первых 10Г, кстати, не помогало точно: только когда я прочитал 50Г, диск ожил обратно).

[DmitryKoterov]

Решил провести еще раз чистый эксперимент: опять запустил наливку ОС. Когда она налилась, смотрю - RAID синкается со скоростью 4МБ/с (очень медленно), при этом на машине LA=1 и диск /dev/sdb не то что тормозит - он просто ползает:

# hdparm -t /dev/sd?
/dev/sda:
Timing buffered disk reads: 1564 MB in 3.00 seconds = 521.24 MB/sec
/dev/sdb:
Timing buffered disk reads: 4 MB in 4.46 seconds = 919.22 kB/sec

А ведь он только час назад разогнался до 500 МБ/с, после того, как я с него прочитал 50Г! И еще до этого он замечательно жил в роли /dev/sda, а когда его переставили на место sdb - начались вот такие фокусы (причем фокусы старого sdb в этот же момент перенеслись на sda, так что это не корзина виновата, или не только корзина). Ну что же это такое-то. Не пользуйтесь никогда самсунговскими SSD-контроллерами, это просто ужас какой-то.

[DmitryKoterov]

BTW I've found one interesting effect:

# mdadm /dev/md2 --fail /dev/sdb4
# mdadm /dev/md2 --remove /dev/sdb4
# mdadm --add /dev/md2 /dev/sdb4
# echo 500000 > /proc/sys/dev/raid/speed_limit_min
# sleep 60
# cat /proc/mdstat
...shows speed=19274K/sec

Then at the same time, at the second console:

# cat /dev/sdb > /dev/null
- or -
# dd if=/dev/sdb of=/dev/null bs=1M count=1000 skip=200000

You return to the previous console:

# cat /proc/mdstat
...shows speed=52285K/sec

So when I read from sdb, resync speed improves greatly.

Maybe it's some aspect of power saving? How could reading of sdb correlate with RAID resync speed?

[DmitryKoterov]

Еще отключение NCQ немного улучшает ситуацию:
echo 1 > /sys/block/sdb/device/queue_depth
Сразу же скорость синка RAID возрастает до 50 МБ/с (это все равно мало, конечно, но влияние есть).

Answer 1

[DmitryKoterov]

Suddenly the solution appeared to be:
hdparm -W 1 /dev/sdb

This turns on internal write caching in SSD. RAID1 resync speed increased greatly with this option (from 20 MB/s to 350 MB/s), "iostat 1" also shows the increased throughput, so it's not a fake.

I've also been experimenting with disabling/enabling write caching (-W0/-W1) at a machine in Hetzner with Intel SSDs. Turning off write caching (-W0) reproduces the same effect of overall slowdown and slow RAID1 resync. Turning it back on restores everything back.