Linux - dostrajanie sprzętowego kontrolera RAID w świecie rzeczywistym (scsi i cciss)

Większość systemów Linux, którymi zarządzam, zawiera sprzętowe kontrolery RAID (głównie HP Smart Array ). Wszystkie działają pod kontrolą RHEL lub CentOS.

Szukam dostrajania w świecie rzeczywistym, aby pomóc zoptymalizować wydajność konfiguracji, które zawierają sprzętowe kontrolery RAID z dyskami SAS (Smart Array, Perc, LSI itp.) Oraz pamięć podręczną z podtrzymaniem bateryjnym lub flash. Załóżmy RAID 1 + 0 i wiele wrzecion (4+ dyski).

Spędzam dużo czasu na dostrajaniu ustawień sieci Linux dla aplikacji o niskim opóźnieniu i handlu finansowego. Ale wiele z tych opcji jest dobrze udokumentowanych (zmiana buforów wysyłania / odbierania, modyfikowanie ustawień okna TCP itp.). Co robią inżynierowie po stronie magazynu?

Historycznie wprowadziłem zmiany w elemencie windującym harmonogramowanie we / wy , ostatnio zdecydowałem się na harmonogramy deadlinei noop, aby poprawić wydajność w swoich aplikacjach. W miarę rozwoju wersji RHEL zauważyłem również, że zmieniły się również domyślne ustawienia dla urządzeń blokowych SCSI i CCISS. Z czasem wpłynęło to na zalecane ustawienia podsystemu pamięci. Minęło trochę czasu, odkąd widziałem jakieś wyraźne rekomendacje. I wiem, że domyślne ustawienia systemu operacyjnego nie są optymalne. Na przykład wydaje się, że domyślny bufor odczytu z wyprzedzeniem 128 kb jest bardzo mały dla wdrożenia na sprzęcie klasy serwerowej.

W poniższych artykułach opisano wpływ na wydajność zmiany pamięci podręcznej z wyprzedzeniem i wartości nr_requests na kolejki bloków.

http://zackreed.me/articles/54-hp-smart-array-p410-controller-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array-p400-with -linux-dlaczego-tuning-naprawdę-ważne
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

Na przykład są to sugerowane zmiany dla kontrolera RAID HP Smart Array:

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

Co jeszcze można niezawodnie dostroić, aby poprawić wydajność pamięci?
Szczególnie szukam opcji sysctl i sysfs w scenariuszach produkcyjnych.

Przekonałem się, że kiedy musiałem dostroić się do mniejszych opóźnień w stosunku do przepustowości, obniżyłem nr_requests z jego wartości domyślnej (do zaledwie 32). Pomysł, że mniejsze partie oznaczają mniejsze opóźnienia.

Również dla read_ahead_kb odkryłem, że w przypadku sekwencyjnych odczytów / zapisów zwiększenie tej wartości zapewnia lepszą przepustowość, ale przekonałem się, że ta opcja naprawdę zależy od obciążenia i wzorca we / wy. Na przykład w systemie bazy danych, który ostatnio dostroiłem, zmieniłem tę wartość, aby dopasować rozmiar pojedynczej strony db, co pomogło zmniejszyć opóźnienia odczytu. Zwiększenie lub zmniejszenie powyżej tej wartości okazało się w moim przypadku zaszkodzić wydajności.

Jeśli chodzi o inne opcje lub ustawienia blokowania kolejek urządzeń:

max_sectors_kb = Ustawiłem tę wartość, aby dopasować to, co sprzęt pozwala na pojedynczy transfer (sprawdź wartość pliku max_hw_sectors_kb (RO) w sysfs, aby zobaczyć, co jest dozwolone)

nomerges = umożliwia wyłączenie lub dostosowanie logiki wyszukiwania dla scalania żądań io. (wyłączenie tego może zaoszczędzić ci kilka cykli procesora, ale nie widziałem żadnej korzyści przy zmianie tego na moje systemy, więc zostawiłem to domyślne)

rq_affinity = Jeszcze tego nie próbowałem, ale oto wyjaśnienie z dokumentacji jądra

Jeśli ta opcja ma wartość „1”, warstwa blokowa przeprowadzi migrację realizacji wniosków do „grupy” procesora, która pierwotnie przesłała żądanie. W przypadku niektórych obciążeń zapewnia to znaczną redukcję cykli procesora z powodu efektów buforowania.
W przypadku konfiguracji pamięci masowej, które muszą zmaksymalizować rozkład przetwarzania ukończenia, ustawienie tej opcji na „2” wymusza uruchomienie procesu uzupełniającego na żądającym jednostce centralnej (z pominięciem logiki agregacji „grupy”) ”

harmonogram = powiedziałeś, że próbowałeś terminu i noop. Testowałem zarówno noop, jak i termin, ale znalazłem wygraną w testach, które ostatnio przeprowadziłem dla serwera bazy danych.

NOOP działał dobrze, ale dla naszego serwera bazy danych nadal byłem w stanie osiągnąć lepszą wydajność, dostosowując harmonogram terminów.

Opcje harmonogramu terminów znajdującego się w / sys / block / {sd, cciss, dm -} * / queue / iosched /:

fifo_batch = coś w rodzaju nr_requests, ale specyficzne dla harmonogramu. Ogólna reguła jest zmniejszana w celu zmniejszenia opóźnień lub zwiększenia przepustowości. Kontroluje wielkość partii żądań odczytu i zapisu.

write_expire = ustawia czas wygaśnięcia partii zapisu domyślnie 5000ms. Po raz kolejny zmniejszenie tej wartości zmniejsza opóźnienie zapisu, a zwiększenie wartości zwiększa przepustowość.

read_expire = ustawia czas wygaśnięcia dla partii odczytu domyślnie 500ms. Obowiązują tutaj te same zasady.

front_merges = Zwykle wyłączam to i domyślnie jest włączone. Nie widzę potrzeby, aby program planujący marnował cykle procesora, próbując scalić żądania We / Wy.

writes_starved = ponieważ termin jest zorientowany na odczyty, tutaj domyślnym jest przetworzenie 2 partii odczytu przed przetworzeniem partii zapisu. Uważam, że domyślna wartość 2 jest odpowiednia do mojego obciążenia pracą.

Przede wszystkim wszystko zależy od obciążenia pracą.

read_ahead_kbmoże ci pomóc, jeśli naprawdę pomocne jest wcześniejsze odczytanie dużej ilości danych z jakiegoś pliku, na przykład podczas przesyłania strumieniowego wideo. Czasami może cię to bardzo zranić. Tak, domyślnie 128 KB może brzmieć jak małe, ale przy wystarczającej współbieżności zaczyna brzmieć jak duże! Z drugiej strony, z serwerem takim jak serwer kodujący wideo, który konwertuje tylko filmy z jednego formatu na inny, może być bardzo dobrym pomysłem.

nr_requests, gdy zostanie przekroczony, może łatwo zalać kontroler RAID, co ponownie obniża wydajność.

W prawdziwym świecie musisz obserwować opóźnienia . Jeśli jesteś podłączony do sieci SAN, przyjrzeć się iostat, sarczy cokolwiek chcesz użyć, i sprawdzić, czy czasy serwisowe żądanie I / O są przez dach. Oczywiście pomaga to również w przypadku dysków lokalnych: jeśli opóźnienia są bardzo bardzo duże, rozważ zmniejszenie ustawień windy we / wy przez obniżenie wartości max_requests i innych ustawień.

FYI read_ahead_kbi blockdev --setrato tylko różne sposoby ustawienia tego samego ustawienia przy użyciu różnych jednostek (kB vs sektory):

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

Więc…

blockdev --setra 65536 /dev/cciss/c0d0

w twoim przykładzie nie ma efektu.