my personal page

Odwiedził mnie ostatnio stary znajomy. Ma na imię OOM killer i jest wyjątkowo uciążliwym typem. Jakiś czas temu zostaliśmy sobie przedstawieni przez kolegę Kernela i od tego momentu nie mogę się od tej nieciekawej znajomości uwolnić. Wspomniany gość nawiedza mnie w bardzo losowych i nieoczekiwanych momentach, wypowiada kilka zdań (które najczęściej są skrupulatnie logowane przez nadwornego skrybę – sysloga), a następnie sieje zniszczenie wśród znajdujących się w pobliżu procesów. Pół biedy, jeżeli za cel obierze jakieś testowe miejsce, do którego nikt poza mną nie zagląda i które nie jest źródłem dochodów dla moich Klientów. Wtedy bawimy się w kotka i myszkę (czasami nawet dość długo), aż w końcu któremuś z nas ta zabawa się nudzi i rozstajemy się w stanie zawieszenia broni. Ale czasami zdarza się tak, że kiler zaczyna majstrować przy produkcyjnych systemach. Oj, tego to ja bardzo nie lubię (głównie chyba dlatego, że lubię ciszę i spokój, a nerwowe maile i telefony związane z niedziałaniem systemu ten spokój skutecznie zaburzają) i w takich sytuacjach podejmuję aktywną walkę ze złem. A jak wiadomo, żeby pokonać wroga, trzeba go najpierw poznać…

Jądro Linuksa domyślnie skonfigurowane jest tak, aby być bardzo optymistycznie nastawionym do świata. Jeżeli jakiś proces chce zarezerwować dla siebie trochę pamięci, to bardzo często ją dostanie. Nawet wtedy, gdy system fizycznie aż takich możliwości nie ma. Dzieje się tak dzięki założeniu, że procesy alokują więcej pamięci, niż faktycznie wykorzystują, co z kolei prowadzi do marnowania cennych bajtów. A przecież wszyscy wiedzą, że bajtów marnować nie należy. Niestety, w pewnym momencie może nastąpić sytuacja, w której wspomniane procesy zaczynają używać całej przydzielonej im pamięci (dlaczego nie? przecież jądro im na to pozwoliło), a system nie ma gdzie tego wszystkiego pomieścić. I tu powstaje bardzo duży problem, któremu Linux stara się zaradzić wywołując proces OOM killera. Ten ostatni w sposób losowy(*) wybiera jakiś inny proces i go ubija, mając jednocześnie nadzieję, że taka operacja zwolni na tyle dużo pamięci, aby system mógł kontynuować pracę. Jednak nie zawsze się to udaje, a nawet jak się uda, to okazuje się, że trafiło na serwer SSH, a maszyna stoi kilkaset kilometrów od naszego aktualnego miejsca pobytu. Niezależnie od wyboru OOM killera, jego obecność zawsze jest niepokojąca i należy zrobić wszystko, aby jej zapobiec w przyszłości.

Szczęśliwie dla nas, nastąpił w historii rozwoju jądra moment, w którym kilku programistom się trochę nudziło i zaczęli kombinować, co można by było w zarządzaniu pamięcią zmienić. Wpadli oni na bardzo słuszny pomysł, że nie wszystkie systemy dobrze radzą sobie z wyrafinowanymi algorytmami przewidującymi rzeczywiste zużycie pamięci. Konsekwencją tego pomysłu było umożliwienie administratorowi zmiany domyślnego zachowania Linuksa za pomocą parametrów jądra. Wprawdzie do dyspozycji mamy tylko dwa takie parametry, jednak do większości zastosowań powinno to wystarczyć. Oto nasi bohaterowie:

• vm.overcommit_memory – parametr przyjmujący wartości 0, 1 lub 2. Wartość zerowa jest wartością domyślną i oznacza, że system będzie próbował oszacować ilość wolnej pamięci i na tej podstawie przydzielać ją procesom, które o to proszą. Jeżeli zmienimy ten parametr na jeden, to system będzie udawał, że ma nieskończoną ilość pamięci i rozdawał ją na lewo i prawo… aż wszystko padnie :-) Ostatnią możliwością jest wartość 2, określana jako „never overcommit”, która jest bezpośrednio związana z drugim parametrem:

• vm.overcommit_ratio – jeżeli poprzedni parametr ustawiliśmy na „2”, to tutaj definiujemy jak dużo pamięci system może przydzielić procesom. Jeżeli np. ustawimy tutaj wartość „80”, to procesy dostaną pamięć o rozmiarze partycji swap + 80% fizycznej pamięci RAM zainstalowanej w maszynie. Aha, można tu ustawić wielkości większe od 100, dzięki czemu system będzie w stanie zrobić overcommit, ale na naszych zasadach.

Najczęściej polecanymi ustawieniami tych parametrów, które mają nas zabezpieczyć przez szaleńczymi działaniami OOM killera są takie:

[root@ns ~]# sysctl -a | grep overcommit
vm.overcommit_memory = 2
vm.overcommit_ratio = 80
[root@ns ~]#

I faktycznie – jeżeli w systemie zaczyna buszować OOM killer i nie jest to sytuacja jednorazowa, takie zabezpieczenie wydaje się być niezłym rozwiązaniem. Należy jednak pamiętać, że nasze aplikacje nie są zbyt przewidywalne dla jądra systemu, co może być pierwszą oznaką tego, że zostały źle napisane i będzie z nimi więcej problemów. Na szczęście nie zawsze tak jest :-)

(*) – Tak naprawdę nie jest to zdarzenie losowe, a OOM killer ma dość zagmatwane algorytmy, za pomocą których wybiera swoją ofiarę. Jednak nie są one idealne, wobec czego wybór często okazuje się bardzo problematyczny.

I jeszcze jedno. Ponieważ każdy poważny artykuł albo wpis na blogu powinien mieć mnóstwo odnośników do źródeł wiedzy, a ja jakoś w treści mało linkowałem, to tutaj kilka ciekawych pozycji związanych z tematem:

• Zestawienie parametrów jądra Linuksa dla pamięci wirtualnej
• Opis mechanizmów zarządzania pamięcią w Linuksie
• Fajny artykuł z testami i ciekawymi komentarzami