Perché il mio accesso RAID1 è più lenta dell'accesso di scrittura?

Ho fatto alcuni test di performance semplici e sembra che la lettura dal mio RAID1 è più lenta di scrivere:

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 performance, ma questo risultato è ancora una sorpresa.

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

Il RAID1 è stato impostato con questo command:

 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 alless veloce come l'accesso alla scrittura, forse anche più veloce. La velocità di scrittura da 715 MByte / sec sembra essere vicino al limite di 6 GBit di un singolo connettore SAS / SATA. È forse un problema di configuration o cablaggio con il backplane SAS? La configuration del backplane SAS può essere interrogata con un command MegaRAID? Si prega di avvisare.

Aggiornare

Come affermato da poige e Peter, la prestazione di lettura più lenta del previsto è probabilmente causata dalla memorizzazione nella cache del sottosistema I / O di Linux.

Quando si usa la bandiera diretta nel command dd che 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 10% più lento rispetto alla velocità di scrittura. L'utilizzo di direct = diretto non ha influenzato la velocità di scrittura.

  • Il calcolo di IOPS per ZFS RAIDZ è diverso da quello che calcola IOPS per RAID5 e RAID6?
  • Perché scegliere un fornitore di storage Enterprise?
  • L'utilità di Windows Defrag segna la frammentazione correttamente su un sistema RAID?
  • Quali sono le buone opzioni per il cluster di file server?
  • Può essere inserito un disco rigido dello stesso formato in un vassoio di scambio rapido?
  • Creazione di dischi di size "dispari" in VmWare / Linux
  • Esistono unità a nastro SATA nella gamma nativa da 800GB a 1TB?
  • Raccomandazioni: configurare uno stack NAS 10GbE per la memorizzazione della virtualizzazione
  • 2 Solutions collect form web for “Perché il mio accesso RAID1 è più lenta dell'accesso di scrittura?”

    poige ha esattamente la destra sulla cache di scrittura, ma qui ci sono ulteriori dettagli.

    dd con zeri e utilizzando la cache di scrittura non è il modo giusto per il benchmark (a less che non si desideri testare la cache di scrittura ovviamente, probabilmente solo utile per un file system, per vedere quanto sincronizza metadati, crea nuovi file, ecc. ) (e probabilmente dd è sempre il tipo sbagliato del benchmark, ma funziona per un test di base)

    Suggerisco di utilizzare dd con alless 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 nulla. Alcuni smart hardware / software / firmware potrebbero utilizzare alcune scorciatoie se i dati sono così prevedibili come zeri. Ciò è particolarmente vero se c'è compressione che indovino che non utilizzi. Utilizza invece un file random in memory (ad esempio / dev / shm). l'urandom è lento, quindi è necessario scrivere da qualche parte temporaneamente per leggerlo di nuovo. Crea un file random di 50 MB:

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

    Leggete il file molte volte per scriverlo (qui uso il gatto per leggerlo 6 volte):

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

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

    La chiave della risposta alla tua domanda è leggere . Una volta, ho anche avuto modo di avere quel problema .

    IOW, per ottimizzare la lettura sequenziale, tutti i dischi dovrebbero essere coinvolti in modo permanente nell'Input.

    Quando si utilizza dd w / o directio (vedi man dd ), l'operazione di scrittura non viene eseguita immediatamente, ma passa attraverso la cache OS, quindi ha più probabilità di coinvolgere tutti i dischi in sequentialy e get la massima prestazione ansible.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.