Zrobiłem kilka prostych testów wydajności i wydaje się, że czytanie z mojego RAID1 jest wolniejsze niż pisanie:

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

Rozumiem, że dd nie jest narzędziem do testowania wydajności, ale ten wynik jest nadal niespodzianką.

System został zbudowany przez dostawcę i ma płytę główną Supermicro z 16 GB pamięci RAM. Kontroler RAID to MegaRAID 9271-8i z 1 GB pamięci podręcznej. Na płycie montażowej SAS-933EL1 znajduje się 8 dysków SAS o pojemności 2 TB. Nie jestem pewien co do okablowania, jedno złącze kontrolera idzie do płyty montażowej SAS, drugie do dwóch dysków SATA, na których jest zainstalowany system operacyjny.

RAID1 został skonfigurowany za pomocą tego polecenia:

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

Spodziewałbym się, że dostęp do odczytu jest co najmniej tak szybki jak dostęp do zapisu, a może nawet szybszy. Szybkość zapisu 715 MB / s wydaje się być bliska granicy 6 GBit pojedynczego złącza SAS / SATA. Czy to może problem z konfiguracją lub okablowaniem płyty montażowej SAS? Czy można zapytać o konfigurację płyty montażowej SAS za pomocą polecenia MegaRAID? Proszę doradź.

Aktualizacja

Jak zauważają poige i Peter, wolniejsza niż oczekiwano wydajność odczytu jest prawdopodobnie spowodowana buforowaniem podsystemu we / wy Linux.

Gdy używam flagi bezpośredniej w poleceniu dd, otrzymuję

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

co jest znacznie lepsze, ale wciąż o 10% wolniejsze niż prędkość zapisu. Użycie oflag = direct nie wpłynęło na szybkość zapisu.

poige ma rację co do pamięci podręcznej zapisu, ale oto więcej szczegółów.

dd z zerami i używanie pamięci podręcznej zapisu nie jest właściwym sposobem na test porównawczy (chyba że chcesz oczywiście przetestować pamięć podręczną zapisu, co prawdopodobnie jest przydatne tylko dla systemu plików, aby zobaczyć, ile synchronizuje metadane, tworzy nowe pliki itp. ) (i prawdopodobnie dd jest zawsze niewłaściwym typem testu porównawczego, ale działa w przypadku bardzo podstawowego testu)

Sugeruję użycie dd z przynajmniej jedną z następujących opcji:

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.

I też nie używaj zera. Niektóre inteligentne urządzenia / oprogramowanie / oprogramowanie układowe mogą używać niektórych skrótów, jeśli dane są tak przewidywalne jak zera. Jest to szczególnie prawdziwe, jeśli istnieje kompresja, której, jak sądzę, nie używasz. Zamiast tego użyj losowego pliku w pamięci (takiego jak / dev / shm). Urandom jest powolny, więc musisz go gdzieś tymczasowo zapisać, aby przeczytać go ponownie. Utwórz losowy plik 50 MB:

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

Przeczytaj plik wiele razy, aby go zapisać (tutaj używam cat, aby go przeczytać 6 razy):

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

rm /dev/shm/randfile

Należy również pamiętać, że odczyty raid1 są najszybsze przy operacjach równoległych, więc dyski mogą być używane niezależnie. Prawdopodobnie nie jest wystarczająco inteligentny, aby koordynować dyski, aby odczytać różne części tej samej operacji z różnymi dyskami.

Kluczem do odpowiedzi na twoje pytanie jest wcześniejsze przeczytanie . Pewnego razu zdarzyło mi się mieć ten problem .

IOW, dla optymalnej wydajności sekwencyjnego odczytu wszystkie dyski powinny być na stałe zaangażowane w Input.

Gdy używasz ddw / o directio(patrz man dd), operacja zapisu nie jest wykonywana natychmiast, ale przechodzi przez pamięć podręczną systemu operacyjnego, więc ma większe szanse na sekwencyjne zaangażowanie wszystkich dysków i osiągnięcie maksymalnej możliwej wydajności.