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.

  • Server stand alone ottimizzato per server singolo vs vm in esecuzione su VMWare
  • Migliori impostazioni della cache Mysql per il server MySQL dedicato a 8 GB di RAM utilizzando solo Innodb (database 5 GB)
  • LSI 9285-8e e Supermicro SC837E26-RJBOD1 duplicati ID dell'involucro e numbers di slot
  • La misurazione di SSD si consuma dietro il controller LSI MegaRAID?
  • MegaCli: Ottieni il nome del dispositivo / dev / sd * per un'unità logica
  • performance di basso io di kvm
  • 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.

  • Prestazioni RAID improvvisamente lente
  • MegaCLI Media Count di errore
  • Come dice Linux a una scheda LSI Megaraid per scorrere la cache prima di spegnere?
  • Ripristina il numero di errori MegaCLI
  • StorCLI: storcli show e "Hlth: Opt": quanto esaustivo è questo?
  • Ora per gestire un LSI 9261-8i in vSphere 4.1, o una buona scheda RAID alternativa?
  • 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.