{"id":95783,"date":"2020-10-03T13:42:02","date_gmt":"2020-10-03T11:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs"},"modified":"2020-10-03T13:42:02","modified_gmt":"2020-10-03T11:42:02","slug":"nastrojka-yadra-linux-dlya-glusterfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Konfiguracja j\u0105dra Linux dla GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Przek\u0142ad artyku\u0142u przygotowany przed rozpocz\u0119ciem kursu \u00abAdministrator Linux. Professional\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Konfiguracja<\/p>\n

Cyklicznie pojawiaj\u0105 si\u0119 pytania dotycz\u0105ce rekomendacji Gluster w sprawie konfiguracji j\u0105dra oraz czy jest to konieczne.<\/p>\n

Taka konieczno\u015b\u0107 wyst\u0119puje rzadko. W wi\u0119kszo\u015bci obci\u0105\u017ce\u0144 j\u0105dro dzia\u0142a bardzo dobrze. Cho\u0107 jest i druga strona. Historycznie j\u0105dro Linux ch\u0119tnie wykorzystuje du\u017c\u0105 ilo\u015b\u0107 pami\u0119ci, je\u015bli ma tak\u0105 mo\u017cliwo\u015b\u0107, w tym do buforowania jako podstawowego sposobu na zwi\u0119kszenie wydajno\u015bci.<\/a><\/noindex><\/p>\n

W wi\u0119kszo\u015bci przypadk\u00f3w dzia\u0142a to doskonale, lecz przy du\u017cym obci\u0105\u017ceniu mo\u017ce prowadzi\u0107 do problem\u00f3w. <\/p>\n

Posiadamy du\u017ce do\u015bwiadczenie w pracy z systemami, kt\u00f3re intensywnie wykorzystuj\u0105 pami\u0119\u0107, takimi jak CAD, EDA i podobnymi, kt\u00f3re zaczyna\u0142y dzia\u0142a\u0107 wolno przy wysokim obci\u0105\u017ceniu. Czasami napotykali\u015bmy problemy w Gluster. Uwa\u017cnie obserwuj\u0105c przez kilka dni zu\u017cycie pami\u0119ci i czas oczekiwania na dyski, zaobserwowali\u015bmy ich przeci\u0105\u017cenie, ogromne iowait, b\u0142\u0119dy j\u0105dra (kernel oops), zawieszenia itd. <\/p>\n

Ten artyku\u0142 jest wynikiem wielu eksperyment\u00f3w zwi\u0105zanych z konfiguracj\u0105 parametr\u00f3w przeprowadzonych w r\u00f3\u017cnych sytuacjach. Dzi\u0119ki tym parametrom nie tylko poprawi\u0142a si\u0119 og\u00f3lna responsywno\u015b\u0107, ale tak\u017ce znacznie ustabilizowa\u0142a si\u0119 praca klastra.<\/p>\n

W przypadku konfiguracji pami\u0119ci nale\u017cy przede wszystkim zwr\u00f3ci\u0107 uwag\u0119 na podsystem pami\u0119ci wirtualnej (VM, virtual memory), kt\u00f3ry ma wiele opcji, kt\u00f3re mog\u0105 wprowadzi\u0107 w zak\u0142opotanie.<\/p>\n

vm.swappiness<\/h4>\n

\nParametr vm.swappiness<\/code> okre\u015bla, jak bardzo j\u0105dro korzysta z swapu w por\u00f3wnaniu do pami\u0119ci operacyjnej. W kodzie \u017ar\u00f3d\u0142owym definiowany jest r\u00f3wnie\u017c jako \u201etendency to steal mapped memory\u201d (sk\u0142onno\u015b\u0107 do kradzie\u017cy pami\u0119ci mapowanej). Wysoka warto\u015b\u0107 swappiness oznacza, \u017ce j\u0105dro b\u0119dzie bardziej sk\u0142onne do wy\u0142adowania mapowanych stron. Niska warto\u015b\u0107 swappiness oznacza odwrotno\u015b\u0107: j\u0105dro b\u0119dzie mniej wy\u0142adowa\u0107 strony z pami\u0119ci. Innymi s\u0142owy, im wy\u017csza warto\u015b\u0107 vm.swappiness<\/code>, tym wi\u0119cej system b\u0119dzie korzysta\u0142 z swapu.<\/p>\n

Du\u017ce korzystanie z swapu jest niepo\u017c\u0105dane, poniewa\u017c ogromne bloki danych s\u0105 \u0142adowane i wy\u0142adowywane z pami\u0119ci operacyjnej. Wiele os\u00f3b twierdzi, \u017ce warto\u015b\u0107 swapiness powinna by\u0107 wysoka, ale z mojego do\u015bwiadczenia wynika, \u017ce zwi\u0119kszenie wydajno\u015bci osi\u0105ga si\u0119 ustawiaj\u0105c j\u0105 na \u201e0\u201d.<\/p>\n

Wi\u0119cej informacji mo\u017cna znale\u017a\u0107 tutaj \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

Jednak\u017ce te ustawienia nale\u017cy stosowa\u0107 ostro\u017cnie i tylko po przetestowaniu konkretnej aplikacji. Dla aplikacji o du\u017cym obci\u0105\u017ceniu strumieniowym ten parametr nale\u017cy ustawi\u0107 na \u201e0\u201d. Ustawienie na \u201e0\u201d poprawia responsywno\u015b\u0107 systemu.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nTen parametr kontroluje pami\u0119\u0107 u\u017cywan\u0105 przez j\u0105dro do buforowania obiekt\u00f3w katalog\u00f3w i deskryptor\u00f3w indeks\u00f3w (dentry i inode).<\/p>\n

Przy domy\u015blnej warto\u015bci 100 j\u0105dro b\u0119dzie pr\u00f3bowa\u0107 zwolni\u0107 pami\u0119\u0107 podr\u0119czn\u0105 dentry i inode \u201esprawiedliwie\u201d wobec pagecache i swapcache. Zmniejszenie vfs_cache_pressure powoduje, \u017ce j\u0105dro zachowuje pami\u0119ci podr\u0119czne dentry i inode. Gdy warto\u015b\u0107 wynosi \u201e0\u201d, j\u0105dro nigdy nie b\u0119dzie oczyszcza\u0107 pami\u0119ci podr\u0119cznej dentry i inode z powodu niedoboru pami\u0119ci (memory pressure), co mo\u017ce \u0142atwo prowadzi\u0107 do b\u0142\u0119du out-of-memory. Zwi\u0119kszenie vfs_cache_pressure powy\u017cej 100 powoduje, \u017ce j\u0105dro priorytetowo traktuje usuwanie dentry i inode.<\/p>\n

Przy u\u017cyciu GlusterFS wielu u\u017cytkownik\u00f3w z du\u017c\u0105 ilo\u015bci\u0105 danych i wieloma ma\u0142ymi plikami mo\u017ce \u0142atwo u\u017cywa\u0107 znacz\u0105cej ilo\u015bci pami\u0119ci RAM na serwerze z powodu buforowania inode\/dentry, co mo\u017ce prowadzi\u0107 do spadku wydajno\u015bci, poniewa\u017c j\u0105dro musi przetwarza\u0107 struktury danych w systemie z 40 GB pami\u0119ci. Ustawienie tego parametru powy\u017cej 100 pomog\u0142o wielu u\u017cytkownikom osi\u0105gn\u0105\u0107 bardziej sprawiedliwe buforowanie i poprawi\u0107 responsywno\u015b\u0107 j\u0105dra.<\/p>\n

vm.dirty_background_ratio i vm.dirty_ratio<\/h4>\n

\nPierwszy parametr (vm.dirty_background_ratio<\/code>) okre\u015bla procent pami\u0119ci z brudnymi stronami, przy osi\u0105gni\u0119ciu kt\u00f3rego nale\u017cy rozpocz\u0105\u0107 t\u0142o zrzucanie brudnych stron na dysk. Dop\u00f3ki ten procent nie zostanie osi\u0105gni\u0119ty, strony nie s\u0105 zrzucane na dysk. A gdy zrzut si\u0119 zaczyna, odbywa si\u0119 to w tle, nie przerywaj\u0105c dzia\u0142aj\u0105cych proces\u00f3w. <\/p>\n

Drugi parametr (vm.dirty_ratio<\/code>) okre\u015bla procent pami\u0119ci, kt\u00f3ry mo\u017ce by\u0107 zaj\u0119ty przez brudne strony, zanim rozpocznie si\u0119 wymuszone zwolnienie (forced flash). Po osi\u0105gni\u0119ciu tego progu wszystkie procesy staj\u0105 si\u0119 synchroniczne (blokowane), a ich kontynuacja pracy jest wstrzymywana, dop\u00f3ki \u017c\u0105dana operacja wej\u015bcia\/wyj\u015bcia nie zostanie faktycznie zako\u0144czona i dane nie trafi\u0105 na dysk. Przy intensywnym wej\u015bciu\/wyj\u015bciu prowadzi to do problem\u00f3w, poniewa\u017c brak jest buforowania danych, a wszystkie procesy zajmuj\u0105ce si\u0119 wej\u015bciem\/wyj\u015bciem s\u0105 blokowane w oczekiwaniu na wykonanie operacji. Prowadzi to do du\u017cej liczby zablokowanych proces\u00f3w, wysokiego obci\u0105\u017cenia, niestabilnej pracy systemu i s\u0142abej wydajno\u015bci.<\/p>\n

Zmniejszenie warto\u015bci tych parametr\u00f3w prowadzi do cz\u0119stszego zwalniania danych na dysk i ograniczania ich przechowywania w RAM. Mo\u017ce to pom\u00f3c systemom z du\u017c\u0105 ilo\u015bci\u0105 pami\u0119ci, w kt\u00f3rych normalne jest zwalnianie na dysk pami\u0119ci podr\u0119cznej stron o rozmiarze 45-90 GB, co prowadzi do ogromnego czasu oczekiwania dla aplikacji frontendowych, obni\u017caj\u0105c og\u00f3ln\u0105 responsywno\u015b\u0107 i interaktywno\u015b\u0107.<\/p>\n

\u201e1\u201d > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nPami\u0119\u0107 podr\u0119czna stron (page cache) to pami\u0119\u0107 podr\u0119czna, w kt\u00f3rej przechowywane s\u0105 dane plik\u00f3w i program\u00f3w wykonywalnych, a wi\u0119c strony z faktyczn\u0105 zawarto\u015bci\u0105 plik\u00f3w lub urz\u0105dze\u0144 blokowych. Ta pami\u0119\u0107 podr\u0119czna jest u\u017cywana do zmniejszenia liczby odczyt\u00f3w z dysku. Warto\u015b\u0107 \u201e1\u201d oznacza, \u017ce dla pami\u0119ci podr\u0119cznej u\u017cywanych jest 1% RAM, a operacji odczytu z dysku b\u0119dzie wi\u0119cej ni\u017c z RAM. Nie ma potrzeby zmieniania tego parametru, ale je\u015bli jeste\u015b paranoicznie nastawiony na kontrol\u0119 nad pami\u0119ci\u0105 podr\u0119czn\u0105 stron, mo\u017cesz z niego skorzysta\u0107.<\/p>\n

\u201edeadline\u201d > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nPlanista wej\u015bcia\/wyj\u015bcia (I\/O scheduler) to komponent j\u0105dra Linux, kt\u00f3ry obs\u0142uguje kolejki odczyt\u00f3w i zapis\u00f3w. Teoretycznie dla inteligentnego kontrolera RAID lepiej jest u\u017cywa\u0107 \u201enoop\u201d, poniewa\u017c Linux nic nie wie o fizycznej geometrii dysku, wi\u0119c efektywniej jest pozwoli\u0107 kontrolerowi, kt\u00f3ry dobrze zna geometri\u0119 dysku, na jak najszybsze przetworzenie \u017c\u0105dania. Jednak wydaje si\u0119, \u017ce \u201edeadline\u201d poprawia wydajno\u015b\u0107. Wi\u0119cej informacji o planistach mo\u017cna znale\u017a\u0107 w dokumentacji dotycz\u0105cej kodu \u017ar\u00f3d\u0142owego j\u0105dra Linux: linux\/Documentation\/block\/*osched.txt<\/code>. A tak\u017ce zauwa\u017cy\u0142em wzrost przepustowo\u015bci odczytu podczas mieszanych operacji (wiele operacji zapis\u00f3w).<\/p>\n

\u201e256\u201d > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nLiczba zapyta\u0144 wej\u015bcia\/wyj\u015bcia w buforze przed ich przekazaniem do planera. Rozmiar wewn\u0119trznej kolejki niekt\u00f3rych kontroler\u00f3w (queue_depth) jest wi\u0119kszy ni\u017c nr_requests planera wej\u015bcia\/wyj\u015bcia, przez co planer ma ma\u0142e szanse na prawid\u0142owe priorytetyzowanie i wykonanie scalania zapyta\u0144. W przypadku planner\u00f3w deadline i CFQ lepiej, gdy nr_requests jest 2 razy wi\u0119kszy od wewn\u0119trznej kolejki kontrolera. Scalanie i reorganizacja zapyta\u0144 pomagaj\u0105 planowi by\u0107 bardziej responsywnym przy du\u017cym obci\u0105\u017ceniu.<\/p>\n

echo \u00ab16\u00bb > \/proc\/sys\/vm\/page-cluster<\/h4>\n

\nParametr page-cluster zarz\u0105dza liczb\u0105 stron, kt\u00f3re s\u0105 zapisywane w swapie za jednym razem. W powy\u017cszym przyk\u0142adzie warto\u015b\u0107 ustawia si\u0119 na \u201e16\u201d w zgodzie z rozmiarem stripa (stripe size) RAID wynosz\u0105cym 64 KB. Nie ma to sensu przy swappiness = 0, ale je\u015bli ustawi\u0142e\u015b swappiness na 10 lub 20, u\u017cycie tej warto\u015bci pomo\u017ce Ci, gdy rozmiar stripa RAID wynosi 64 KB.<\/p>\n

blockdev \u2014setra 4096 \/dev\/<<\/code>devname><\/code> (-sdb, hdc lub dev_mapper)<\/h4>\n

\nDomy\u015blne ustawienia urz\u0105dze\u0144 blokowych dla wielu kontroler\u00f3w RAID cz\u0119sto prowadz\u0105 do s\u0142abej wydajno\u015bci. Dodanie powy\u017cszej opcji ustawia wst\u0119pne odczyty na 4096 * 512-bajtowych sektor\u00f3w. Przynajmniej w przypadku operacji strumieniowych zwi\u0119ksza to pr\u0119dko\u015b\u0107, nape\u0142niaj\u0105c podr\u0119czn\u0105 pami\u0119\u0107 podr\u0119czn\u0105 dysku dzi\u0119ki wst\u0119pnym odczytom w okresie, w kt\u00f3rym j\u0105dro przygotowuje wej\u015bcie\/wyj\u015bcie. W pami\u0119ci podr\u0119cznej mog\u0105 znajdowa\u0107 si\u0119 dane, kt\u00f3re zostan\u0105 za\u017c\u0105dane przy nast\u0119pnym odczycie. Zbyt du\u017ce wst\u0119pne odczyty mog\u0105 zabi\u0107 losowe wej\u015bcie\/wyj\u015bcie dla du\u017cych plik\u00f3w, je\u015bli wykorzystuje ono potencjalnie przydatny czas dysku lub \u0142aduje dane poza cach'em.<\/p>\n

Oto kilka dodatkowych zalece\u0144 na poziomie systemu plik\u00f3w. Ale nie zosta\u0142y one jeszcze przetestowane. Upewnij si\u0119, \u017ce tw\u00f3j system plik\u00f3w zna rozmiar stripa i liczb\u0119 dysk\u00f3w w macierzy. Na przyk\u0142ad, \u017ce jest to macierz raid5 z rozmiarem stripa 64K z sze\u015bcioma dyskami (w rzeczywisto\u015bci z pi\u0119cioma, poniewa\u017c jeden dysk jest u\u017cywany do parzysto\u015bci). Te zalecenia s\u0105 oparte na teoretycznych za\u0142o\u017ceniach i zebrane z r\u00f3\u017cnych blog\u00f3w\/artyk\u00f3w ekspert\u00f3w RAID.<\/p>\n

-> ext4 fs, 5 dysk\u00f3w, 64K stripe, jednostki w blokach 4K\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 dysk\u00f3w, 64K stripe, jednostki w sektorach 512-bajtowych\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nW przypadku du\u017cych plik\u00f3w mo\u017cna rozwa\u017cy\u0107 zwi\u0119kszenie wymienionych powy\u017cej rozmiar\u00f3w pasm.<\/p>\n
UWAGA!<\/b> Wszystko, co zosta\u0142o opisane powy\u017cej, jest skrajnie subiektywne dla niekt\u00f3rych typ\u00f3w aplikacji. Ten artyku\u0142 nie gwarantuje poprawy wydajno\u015bci bez wcze\u015bniejszego przetestowania odpowiednich aplikacji przez u\u017cytkownika. Nale\u017cy go stosowa\u0107 tylko w przypadku potrzeby poprawy og\u00f3lnej responsywno\u015bci systemu lub gdy rozwi\u0105zuje aktualne problemy.<\/p>\n
Dodatkowe materia\u0142y:<\/h4>\n
<\/p>\n