Perché l'accesso in lettura RAID1 è più lento dell'accesso in scrittura?


10

Ho fatto alcuni semplici test delle prestazioni e sembra che la lettura dal mio RAID1 sia più lenta della scrittura:

root@dss0:~# for i in 1 2 3; do dd if=/dev/zero of=/dev/sda bs=1048576 count=131072; done
137438953472 bytes (137 GB) copied, 192.349 s, 715 MB/s
137438953472 bytes (137 GB) copied, 192.851 s, 713 MB/s
137438953472 bytes (137 GB) copied, 193.026 s, 712 MB/s
root@dss0:~# for i in 1 2 3; do dd if=/dev/sda of=/dev/null bs=1048576 count=131072; done
137438953472 bytes (137 GB) copied, 257.201 s, 534 MB/s
137438953472 bytes (137 GB) copied, 255.522 s, 538 MB/s
137438953472 bytes (137 GB) copied, 259.945 s, 529 MB/s

Capisco che dd non è uno strumento di test delle prestazioni, ma questo risultato è ancora una sorpresa.

Il sistema è stato costruito dal venditore e ha una scheda madre Supermicro con 16 GByte RAM. Il controller RAID è un MegaRAID 9271-8i con 1 GB di cache. Esistono 8 dischi SAS da 2 TByte su un backplane SAS-933EL1. Non sono sicuro del cablaggio, un connettore del controller va al backplane SAS, l'altro va a due dischi SATA che contengono il sistema operativo.

Il RAID1 è stato impostato con questo comando:

root@dss0:~# /opt/MegaRAID/MegaCli/MegaCli64 -CfgLdAdd -r1 [8:0,8:1,8:2,8:3,8:4,8:5,8:6,8:7] WB NORA Direct -a0
Adapter 0: Created VD 0
Adapter 0: Configured the Adapter!!
Exit Code: 0x00

root@dss0:~# /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -LALL -aALL
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 7.275 TB
Sector Size         : 512
Is VD emulated      : No
Mirror Data         : 7.275 TB
State               : Optimal
Strip Size          : 256 KB
Number Of Drives    : 8
Span Depth          : 1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
PI type: No PI
Is VD Cached: No
Exit Code: 0x00

Mi aspetto che l'accesso in lettura sia almeno veloce quanto l'accesso in scrittura, forse anche più veloce. La velocità di scrittura di 715 MByte / sec sembra essere vicina al limite di 6 GBit di un singolo connettore SAS / SATA. È forse un problema di configurazione o di cablaggio con il backplane SAS? È possibile eseguire una query sulla configurazione del backplane SAS con un comando MegaRAID? Si prega di avvisare.

Aggiornare

Come spiegato da Poige e Peter, le prestazioni di lettura più lente del previsto sono probabilmente causate dalla memorizzazione nella cache del sottosistema I / O Linux.

Quando uso la bandiera diretta nel comando dd ottengo

root@dss0:~# dd if=/dev/sda of=/dev/null bs=1048576 count=131072 iflag=direct
137438953472 bytes (137 GB) copied, 199.862 s, 688 MB/s

che è molto meglio ma ancora più lento del 10% rispetto alla velocità di scrittura. L'uso di oflag = direct non ha influito sulla velocità di scrittura.


Risposta semplice: la lettura richiede l'attesa dei risultati, la scrittura no.
David Schwartz,

Risposte:


8

poige ha esattamente ragione sulla cache di scrittura, ma qui ci sono maggiori dettagli.

dd con zeri e l'uso della cache di scrittura non è il modo giusto per eseguire il benchmark (a meno che tu non voglia testare la cache di scrittura ovviamente, che è probabilmente utile solo per un file system, per vedere quanto sincronizza i metadati, crea nuovi file, ecc. ) (e probabilmente dd è sempre il tipo sbagliato di benchmark, ma funziona per un test molto semplice)

Ti suggerisco di usare dd con almeno una delle seguenti opzioni:

conv=fdatasync -> this will make it flush to disk before finishing and calculating speed
oflag=direct   -> this will make it skip the OS cache but not the disk cache
conv=sync      -> more like skipping the disk cache too, but not really ... just flushing it every block or something like that.

E non usare neanche zero. Alcuni hardware / software / firmware intelligenti potrebbero utilizzare alcune scorciatoie se i dati sono così prevedibili come zeri. Ciò è particolarmente vero se esiste una compressione che suppongo tu non stia utilizzando. Invece, usa un file casuale in memoria (come / dev / shm). urandom è lento, quindi devi scriverlo temporaneamente da qualche parte per leggerlo di nuovo. Crea un file casuale da 50 MB:

dd if=/dev/urandom of=/dev/shm/randfile bs=1M count=50

Leggi il file più volte per scriverlo (qui uso cat per leggerlo 6 volte):

dd if=<(cat /dev/shm/randfile{,,,,,}) of= ... conv=fdatasync

rm /dev/shm/randfile

Inoltre, tieni presente che le letture di raid1 sono più veloci con operazioni parallele, quindi i dischi possono essere utilizzati in modo indipendente. Probabilmente non è abbastanza intelligente coordinare i dischi per leggere parti diverse della stessa operazione con dischi diversi.


10

La chiave per la risposta alla tua domanda è read-ahead . C'era una volta anche questo problema .

IOW, per prestazioni di lettura sequenziali ottimali tutti i dischi dovrebbero essere coinvolti in modo permanente nell'Input.

Quando si utilizza ddw / o directio(vedi man dd), l'operazione di scrittura non viene eseguita immediatamente, ma passa attraverso la cache del sistema operativo, quindi ha più possibilità di coinvolgere tutti i dischi in sequenza e ottenere le massime prestazioni possibili.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.