Estou trazendo para o ServerFault um problema que está me atormentando há mais de 6 meses. Eu tenho um servidor CentOS 6 (64 bits) com um array RAID-1 de software md com 2 x SSDs Samsung 840 Pro (512 GB).
Problemas:
- Problemas graves de velocidade de gravação:
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
-
Ao fazer o acima (ou qualquer outra cópia maior), a carga aumenta para valores inacreditáveis (mesmo acima de 100) indo de ~ 1.
-
Ao fazer o acima, também notei resultados muito estranhos do 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
E ele fica assim até que ele realmente grave o arquivo no dispositivo (fora da troca / cache / memória).
O problema é que o segundo SSD no array tem svctm e aguarda aproximadamente 100 vezes maior que o segundo.
- Por alguma razão, o desgaste é diferente entre os 2 membros da matriz
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
O primeiro SSD tem um desgaste de 6%, enquanto o segundo SSD tem um desgaste de 30% !!
É como se o segundo SSD no array funcionasse pelo menos 5 vezes mais do que o primeiro, conforme comprovado pela primeira iteração do iostat (as médias desde a reinicialização):
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
- O que eu tentei:
Eu atualizei o firmware para DXM05B0Q (seguindo relatórios de melhorias dramáticas para 840Ps após esta atualização).
Eu procurei por "hard resetting link" no dmesg para verificar problemas de cabo / backplane, mas nada.
Eu verifiquei o alinhamento e acredito que eles estão alinhados corretamente (limite de 1MB, listando abaixo)
Eu verifiquei / proc / mdstat e o array é ótimo (segunda listagem abaixo).
root [~]# 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
root [~]# 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:
- Execução de um teste de leitura com o hdparm
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
- Mas veja o que acontece se eu adicionar --direct
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
Ambos os testes aumentam, mas o / dev / sdb dobra, enquanto o / dev / sda aumenta, talvez, 20%. Eu só não sei o que fazer com isso.
- Como sugerido pelo Sr. Wagner, fiz outro teste de leitura com o dd desta vez e confirma o teste hdparm:
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
Portanto, o sda é 3 vezes mais rápido que o sdb. Ou talvez o sdb também esteja fazendo algo diferente do que o sda faz. Existe alguma maneira de descobrir se o sdb está fazendo mais do que o que o sda faz?
Mais uma vez, conforme sugerido pelo Sr. Wagner, troquei os dois SSDs. E como ele pensou que aconteceria, o problema mudou de sdb para sda. Então eu acho que vou RMA um dos SSDs. Eu me pergunto se a gaiola pode ser problemática.
O que há de errado com essa matriz? Por favor ajude!