Poprawa wydajności wielościeżkowej SAS do JBOD w systemie Linux

Próbuję zoptymalizować konfigurację pamięci masowej na niektórych urządzeniach Sun w systemie Linux. Jakiekolwiek propozycje będą mile widziane.

Mamy następujący sprzęt:

• Sun Blade X6270
• 2 * kontrolery LSISAS1068E SAS
• 2 * Sun J4400 JBOD z 1 TB dysków (24 dyski na JBOD)
• Fedora Core 12
• Jądro wydania 2.6.33 z FC13 (wypróbowane również z najnowszym jądrem 2.6.31 z FC12, te same wyniki)

Oto arkusz danych dla sprzętu SAS:

http://www.sun.com/storage/storage_networking/hba/sas/PCIe.pdf

Korzysta z PCI Express 1.0a, 8x pasów. Przy przepustowości 250 MB / s na linię powinniśmy być w stanie wykonać 2000 MB / s na kontroler SAS.

Każdy kontroler może wykonać 3 Gb / s na port i ma dwa 4-portowe PHY. Łączymy oba PHY z kontrolera z JBOD. Tak więc między JBOD a kontrolerem mamy 2 PHY * 4 porty SAS * 3 Gb / s = 24 Gb / s przepustowości, czyli więcej niż przepustowość PCI Express.

Przy włączonym buforowaniu zapisu i podczas wykonywania dużych zapisów, każdy dysk może utrzymać około 80 MB / s (w pobliżu początku dysku). Z 24 dyskami oznacza to, że powinniśmy być w stanie wykonać 1920 MB / s na JBOD.

multipath {
  rr_min_io 100
  Uid 0
  ścieżka_grupa_policy multibus
  instrukcja powrotu po awarii
  path_selector "round-robin 0"
  priorytety rr_weight
  alias somealias
  no_path_retry queue
  tryb 0644
  gid 0
  Wwid
}

Próbowałem wartości 50, 100, 1000 dla rr_min_io, ale wydaje się, że nie robi to dużej różnicy.

Wraz z różnym rr_min_io próbowałem dodać pewne opóźnienie między uruchomieniem dd, aby uniemożliwić wszystkim pisanie na tym samym PHY w tym samym czasie, ale to nie miało znaczenia, więc myślę, że I / O są odpowiednio rozłożone.

Zgodnie z / proc / interrupts, kontrolery SAS używają schematu przerwań „IR-IO-APIC-fasteoi”. Z jakiegoś powodu tylko rdzeń 0 w maszynie obsługuje te przerwania. Mogę nieznacznie poprawić wydajność, przypisując oddzielny rdzeń do obsługi przerwań dla każdego kontrolera SAS:

echo 2> / proc / irq / 24 / smp_affinity
echo 4> / proc / irq / 26 / smp_affinity

Użycie dd do zapisu na dysku generuje „przerwania wywołania funkcji” (nie mam pojęcia, co to są), które są obsługiwane przez rdzeń # 4, więc też nie pozwalam innym procesom na ten rdzeń.

Uruchamiam 48 dd (po jednym na każdy dysk), przypisując je do rdzeni, które nie radzą sobie z takimi przerwaniami:

zestaw zadań -c somecore dd if = / dev / zero of = / dev / mapper / mpathx oflag = direct bs = 128M

oflag = direct zapobiega zaangażowaniu dowolnego bufora pamięci podręcznej.

Żaden z moich rdzeni nie wydaje się maksymalnie wykorzystany. Rdzenie zajmujące się przerwaniami są w większości bezczynne, a wszystkie pozostałe rdzenie czekają na We / Wy, jak można się spodziewać.

Cpu0: 0,0% us, 1,0% sy, 0,0% ni, 91,2% id, 7,5% wa, 0,0% hi, 0,2% si, 0,0% st
Cpu1: 0,0% us, 0,8% sy, 0,0% ni, 93,0% id, 0,2% wa, 0,0% hi, 6,0% si, 0,0% st
Cpu2: 0,0% us, 0,6% sy, 0,0% ni, 94,4% id, 0,1% wa, 0,0% hi, 4,8% si, 0,0% st
Cpu3: 0,0% us, 7,5% sy, 0,0% ni, 36,3% id, 56,1% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu4: 0,0% us, 1,3% sy, 0,0% ni, 85,7% id, 4,9% wa, 0,0% hi, 8,1% si, 0,0% st
Cpu5: 0,1% us, 5,5% sy, 0,0% ni, 36,2% id, 58,3% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu6: 0,0% us, 5,0% sy, 0,0% ni, 36,3% id, 58,7% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu7: 0,0% us, 5,1% sy, 0,0% ni, 36,3% id, 58,5% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu8: 0,1% us, 8,3% sy, 0,0% ni, 27,2% id, 64,4% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu9: 0,1% us, 7,9% sy, 0,0% ni, 36,2% id, 55,8% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu10: 0,0% us, 7,8% sy, 0,0% ni, 36,2% id, 56,0% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu11: 0,0% us, 7,3% sy, 0,0% ni, 36,3% id, 56,4% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu12: 0,0% us, 5,6% sy, 0,0% ni, 33,1% id, 61,2% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu13: 0,1% us, 5,3% sy, 0,0% ni, 36,1% id, 58,5% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu14: 0,0% us, 4,9% sy, 0,0% ni, 36,4% id, 58,7% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu15: 0,1% us, 5,4% sy, 0,0% ni, 36,5% id, 58,1% wa, 0,0% hi, 0,0% si, 0,0% st

Biorąc to wszystko pod uwagę, przepływność zgłaszana przez uruchomienie „dstat 10” wynosi 2200–2300 MB / s.

Biorąc pod uwagę powyższą matematykę, oczekiwałbym czegoś w zakresie 2 * 1920 ~ = 3600+ MB / s.

Czy ktoś ma pojęcie, dokąd poszła moja brakująca przepustowość?

Dzięki!

Ładne, dobrze przygotowane pytanie :)

Sam jestem człowiekiem szybkości i karmienia i myślę, że masz dość pieniędzy, żeby być szczerym. Spodziewałem się, że twoja przepustowość będzie niższa niż jest, ale myślę, że masz tam niewielką i oczekiwaną nieefektywność. Na przykład bardzo trudno jest magistrali PCIe cały czas uzyskać 100%, lepiej założyć niską ogólną stawkę 90%. Biorąc pod uwagę drgania, spowoduje to również, że PHY nie będą w 100% „karmione” przez cały czas, więc trochę tam tracisz, tak samo jak pamięć podręczna, dyski, przerwania niekontrolowane, planowanie IO itp. Zasadniczo to drobna nieefektywność razy drobna nieefektywność razy ... i tak dalej, kończy się to, że same przekraczają 5-10% oczekiwanych nieefektywności. Widziałem tego rodzaju rzeczy, gdy serwery HP DL rozmawiały z urządzeniami MSA SAS za pomocą W2K3, a następnie były NLB ” edytowane przez wiele kart sieciowych - wydaje się frustrujące, ale zrozumiałe. W każdym razie to moje 2c, przepraszam, że nie jest zbyt pozytywne.