Tłumaczenie artykułu zostało przygotowane w przeddzień rozpoczęcia kursu .
Od czasu do czasu tu i ówdzie pojawiają się pytania dotyczące zaleceń Glustera dotyczących strojenia jądra i tego, czy jest taka potrzeba.
Taka potrzeba pojawia się rzadko. W przypadku większości obciążeń jądro działa bardzo dobrze. Chociaż jest pewien minus. Historycznie jądro Linuksa było skłonne zużywać dużo pamięci, jeśli tylko nadarzyła się taka możliwość, w tym buforowanie jako główny sposób poprawy wydajności.
W większości przypadków działa to dobrze, ale przy dużym obciążeniu może prowadzić do problemów.
Mamy duże doświadczenie z systemami intensywnie korzystającymi z pamięci, takimi jak CAD, EDA i tym podobne, które zaczęły zwalniać pod dużym obciążeniem. Czasami w Gluster napotykaliśmy problemy. Po uważnej obserwacji użycia pamięci i opóźnień dysku przez wiele dni, otrzymaliśmy ich przeciążenie, ogromne iowait, błędy jądra (kernel oops), zawieszanie się itp.
Ten artykuł jest wynikiem wielu eksperymentów strojenia przeprowadzonych w różnych sytuacjach. Dzięki tym parametrom poprawiła się nie tylko ogólna responsywność, ale także znacznie ustabilizował się klaster.
Jeśli chodzi o dostrajanie pamięci, pierwszą rzeczą, na którą należy zwrócić uwagę, jest podsystem pamięci wirtualnej (VM, pamięć wirtualna), który ma dużą liczbę opcji, które mogą wprowadzić w błąd.
vm.zamiana
Parametr vm.swappiness określa, jak bardzo jądro używa wymiany (swap, stronicowania) w porównaniu z pamięcią RAM. Jest to również zdefiniowane w kodzie źródłowym jako „tendencja do kradzieży zmapowanej pamięci”. Wysoka zamiana oznacza, że jądro będzie bardziej skłonne do zamiany zmapowanych stron. Niska wartość wymiany oznacza coś przeciwnego: jądro będzie mniej stronicować z pamięci. Innymi słowy, im wyższa wartość vm.swappiness, tym częściej system będzie używał zamiany.
Duże użycie zamiany jest niepożądane, ponieważ ogromne bloki danych są ładowane i rozładowywane do pamięci RAM. Wiele osób twierdzi, że wartość wymiany powinna być duża, ale z mojego doświadczenia wynika, że ustawienie jej na „0” prowadzi do lepszej wydajności.
Możesz przeczytać więcej tutaj -
Ale znowu te ustawienia należy stosować ostrożnie i dopiero po przetestowaniu konkretnej aplikacji. W przypadku mocno obciążonych aplikacji strumieniowych ten parametr powinien być ustawiony na „0”. Po zmianie na „0” poprawia się szybkość reakcji systemu.
vm.vfs_cache_ciśnienie
To ustawienie kontroluje pamięć zużywaną przez jądro do buforowania katalogu i obiektów i-węzłów (dentry i i-węzeł).
Przy domyślnej wartości 100 jądro spróbuje zwolnić pamięć podręczną dentry i i-węzłów na „sprawiedliwych” zasadach do pamięci podręcznej stronicowania i pamięci podręcznej wymiany. Zmniejszenie vfs_cache_pressure powoduje, że jądro zachowuje pamięć podręczną dentry i i-węzłów. Gdy wartość wynosi „0”, jądro nigdy nie opróżni pamięci podręcznej dentry i i-węzłów ze względu na presję pamięci, co może łatwo doprowadzić do błędu braku pamięci. Zwiększenie vfs_cache_pressure powyżej 100 powoduje, że jądro nadaje priorytet dentry i opróżnianiu i-węzłów.
Podczas korzystania z GlusterFS wielu użytkowników z dużymi ilościami danych i wieloma małymi plikami może z łatwością wykorzystywać znaczną ilość pamięci RAM na serwerze ze względu na buforowanie i-węzłów/dentry, co może prowadzić do obniżenia wydajności, ponieważ jądro musi przetwarzać struktury danych w systemie z 40 GB pamięci. Ustawienie tej wartości powyżej 100 pomogło wielu użytkownikom osiągnąć bardziej sprawiedliwe buforowanie i lepszą responsywność jądra.
vm.dirty_background_ratio i vm.dirty_ratio
Pierwszy parametr (vm.dirty_background_ratio) określa procent pamięci z brudnymi stronami, po osiągnięciu którego konieczne jest rozpoczęcie opróżniania brudnych stron w tle na dysk. Dopóki ten procent nie zostanie osiągnięty, żadne strony nie są usuwane na dysk. A kiedy reset się rozpocznie, działa w tle bez przerywania uruchomionych procesów.
Drugi parametr (vm.dirty_ratio) określa procent pamięci, który może być zajęty przez brudne strony przed rozpoczęciem wymuszonego flashowania. Po osiągnięciu tego progu wszystkie procesy stają się synchroniczne (zablokowane) i nie mogą kontynuować, dopóki żądane operacje we/wy nie zostaną faktycznie zakończone, a dane znajdą się na dysku. W przypadku dużych operacji we/wy powoduje to problem, ponieważ nie ma buforowania danych, a wszystkie procesy wykonujące operacje we/wy są blokowane w oczekiwaniu na operacje we/wy. Prowadzi to do dużej liczby zawieszonych procesów, dużego obciążenia, niestabilności systemu i niskiej wydajności.
Zmniejszenie tych ustawień powoduje, że dane są częściej usuwane na dysk i nie są przechowywane w pamięci RAM. Może to pomóc systemom z dużą ilością pamięci, w których opróżnianie 45-90 GB pamięci podręcznej stron na dysk jest normalne, co powoduje ogromne opóźnienia dla aplikacji front-end, zmniejszając ogólną responsywność i interaktywność.
„1” > /proc/sys/vm/pagecache
Pamięć podręczna stron to pamięć podręczna, która przechowuje dane plików i programów wykonywalnych, to znaczy są to strony z rzeczywistą zawartością plików lub urządzeń blokowych. Ta pamięć podręczna służy do zmniejszenia liczby odczytów dysku. Wartość „1” oznacza, że 1% pamięci RAM jest używane na cache i będzie więcej odczytów z dysku niż z RAM. Zmiana tego ustawienia nie jest konieczna, ale jeśli masz obsesję na punkcie kontrolowania pamięci podręcznej strony, możesz z niej skorzystać.
„termin” > /sys/block/sdc/queue/scheduler
Harmonogram we/wy to składnik jądra Linuksa, który obsługuje kolejki odczytu i zapisu. Teoretycznie lepiej jest użyć „noop” dla inteligentnego kontrolera RAID, ponieważ Linux nie wie nic o fizycznej geometrii dysku, więc wydajniej jest pozwolić kontrolerowi, który dobrze zna geometrię dysku, przetworzyć żądanie tak szybko, jak to możliwe. możliwy. Ale wygląda na to, że „termin” poprawia wydajność. Możesz przeczytać więcej o programach planujących w dokumentacji kodu źródłowego jądra Linuksa: linux/Documentation/block/*osched.txt. Zauważyłem również wzrost przepustowości odczytu podczas operacji mieszanych (wiele operacji zapisu).
"256" > /sys/block/sdc/queue/nr_requests
Liczba żądań we/wy w buforze przed przekazaniem ich do programu planującego. Rozmiar wewnętrznej kolejki niektórych kontrolerów (queue_depth) jest większy niż nr_requests programu planującego wejścia/wyjścia, więc program planujący wejścia/wyjścia ma niewielkie szanse na prawidłowe ustalenie priorytetów i połączenie żądań. W przypadku harmonogramów terminów i CFQ lepiej jest, gdy nr_requests jest 2-krotnością wewnętrznej kolejki kontrolera. Scalanie i zmiana kolejności żądań pomaga programowi planującemu szybciej reagować przy dużym obciążeniu.
echo "16" > /proc/sys/vm/page-cluster
Parametr klastra stron kontroluje liczbę stron zapisywanych jednocześnie do wymiany. W powyższym przykładzie wartość jest ustawiona na „16” zgodnie z rozmiarem paska RAID wynoszącym 64 KB. Nie ma to sensu z swapiness = 0, ale jeśli ustawisz swapiness na 10 lub 20, użycie tej wartości pomoże ci, gdy rozmiar paska RAID wynosi 64 KB.
blockdev --setra 4096 /dev/<nazwa dewelopera> (-sdb, hdc lub dev_mapper)
Domyślne ustawienia urządzeń blokowych dla wielu kontrolerów RAID często skutkują fatalną wydajnością. Dodanie powyższej opcji ustawia odczyt z wyprzedzeniem dla sektorów 4096 * 512 bajtów. Przynajmniej w przypadku operacji przesyłania strumieniowego prędkość jest zwiększana poprzez wypełnienie wbudowanej pamięci podręcznej dysku odczytem z wyprzedzeniem w okresie używanym przez jądro do przygotowania wejścia/wyjścia. Pamięć podręczna może zawierać dane, które będą wymagane przy następnym odczycie. Zbyt duże pobieranie z wyprzedzeniem może zabić losowe operacje we/wy dla dużych plików, jeśli zużywa potencjalnie użyteczny czas dysku lub ładuje dane poza pamięć podręczną.
Poniżej znajduje się kilka dodatkowych zaleceń na poziomie systemu plików. Ale jeszcze ich nie przetestowano. Upewnij się, że twój system plików zna rozmiar paska i liczbę dysków w macierzy. Na przykład, że jest to 5-kilometrowa macierz stripe raid64 składająca się z sześciu dysków (właściwie pięciu, ponieważ jeden dysk jest używany do parzystości). Zalecenia te opierają się na założeniach teoretycznych i zostały opracowane na podstawie różnych blogów/artykułów ekspertów RAID.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))W przypadku dużych plików rozważ zwiększenie podanych powyżej rozmiarów pasków.
UWAGA Wszystko opisane powyżej jest bardzo subiektywne w przypadku niektórych typów aplikacji. Ten artykuł nie gwarantuje żadnych ulepszeń bez uprzedniego przetestowania powiązanych aplikacji przez użytkowników. Powinien być używany tylko wtedy, gdy jest to konieczne do poprawy ogólnej responsywności systemu lub jeśli rozwiązuje bieżące problemy.
Dodatkowe materiały:
Czytaj więcej
Źródło: www.habr.com