Wstęp
Monitorowanie zajętości pamięci RAM jest kluczowym aspektem administracji systemami operacyjnymi i wydaje się, że umiejętność właściwej interpretacji wyników narzędzi systemowych jest czymś, czym powinien się odznaczać każdy specjalista zarządzający systemami. W praktyce jednak, bardzo często dochodzi do dyskusji między specjalistami IT, a dodatkowe zasoby RAM bywają dodawane niepotrzebnie. Skąd się biorą te błędy w interpretacji i jak powinno się monitorować pamięć? O tym chciałbym napisać w niniejszym artykule.
Temat związany z pamięcią RAM w systemie AIX, jest dość skomplikowany, dlatego chciałbym się skupić na zagadnieniu w mojej ocenie najbardziej praktycznym i podstawowym, czyli odpowiedzią na pytanie „Ile w danym systemie jest dostępnej pamięci RAM?”
Oczywiście szczegóły dotyczące zajętej pamięci są również bardzo ważne, jednak chcę aby artykuł ułatwił zrozumienie jedynie podstawowej interpretacji i był wstępem oraz zachętą do poszukiwania wiedzy na poziomie eksperckim w dalszym etapie.
Skąd wynikają nieporozumienia?
Najczęstszy problem z interpretacją wolnej pamięci wynika z tego, że wiele osób patrzy na wartość „Free” w wynikach takich narzędzi jak svmon, NMON, TOPAS itp.
Czy „Free” nie oznacza właśnie wolnej pamięci? Oczywiście oznacza, jednak należy być świadomym faktu, że system AIX stara się dostępnej pamięci nie marnować, dlatego zazwyczaj jej znaczna część jest wykorzystana jako Filesystem Cache.
Różne narzędzia mogą prezentować dostępną pamięć w nieco inny sposób. Przykładowo system monitoringu Zabbix, w starej już dosyć wersji 2.4 prezentował pamięć określaną jako „available” dokładnie tak samo jak „free”, ale od wersji 3.0 do obecnej, prezentuje wartość „available” jako „free + cached”. Jeśli korzystasz z jakiegoś systemu monitoringu, warto zasięgnąć do dokumentacji tego oprogramowania, by dowiedzieć się co odzwierciedlają poszczególne nazwy i jak mają się do wartości widocznych z poziomu systemu operacyjnego.
Czym jest Filesystem Cache?
Filesystem Cache jest mechanizmem, który służy do buforowania danych z przestrzeni dyskowej do pamięci RAM, dzięki czemu, operacje I/O (wejścia/wyjścia) są znacząco przyspieszone. Dane nie muszą być tak często odczytywane i zapisywane na przestrzeni dyskowej, która jak wiadomo jest znacznie wolniejsza niż pamięć RAM.
Warto zauważyć, że Filesystem Cache nie jest czymś, co zabiera pamięć naszej aplikacji lub bazie danych, ponieważ w momencie zapotrzebowania np. procesów aplikacji na pamięć, system AIX dynamicznie ją zwalnia.
Ogólnie mówiąc, nie powinniśmy się martwić tym że Filesystem Cache stanowi duży obszar naszej pamięci – to oznacza że ta pamięć pracuje na rzecz przyspieszenia operacji I/O (wejścia – wyjścia).
Na poniższym wykresie jest prezentowana zajętość pamięci RAM. Ciemnoniebieski kolor oznacza pamięć zajętą, jasnoniebieski Filesystem Cache, a czarny (do żółtej linii) oznacza Free.
Widać w tym przypadku, że pamięć zajęta (Used), stanowi mniejszość całego RAM-u przypisanego do LPAR-a. W szerszym zakresie czasowym można zauważyć że poziom Filesystem Cache’u dynamicznie wzrasta i maleje. W przypadku gdy administrator spojrzy na wartość Free, o godzinie 3:00 może zacząć panikować i próbować rozszerzyć przypisane zasoby RAM do LPAR-a, bojąc się że np. aplikacja lada moment przestanie działać wskutek wysycenia pamięci. Tak się jednak w tej sytuacji nie stanie. Jeśli system monitoringu wywołuje alerty wskutek mierzenia wartości „Free”, w sytuacji pokazanej na wykresie, takie alerty będą się pojawiać i znikać. W zależności od działania konkretnej aplikacji lub np. uruchamiania backupów, dynamika wzrostu i zwalniania Filesystem Cache może się znacząco różnić.
Jak interpretować wartości prezentowane przez popularne narzędzia administracyjne?
Narzędzi do monitorowania stanu systemu AIX jest wiele, ale chciałbym w tym artykule wyróżnić te, które w mojej ocenie są dość często używane.
Na zajętą pamięć składa się wiele pojęć (real system, real user, real process, pinned, itd), jednak by możliwie prosto wytłumaczyć zagadnienie, skupiam się w tym artykule jedynie na wolnej pamięci.
SVMON
Polecenie svmon -G -O unit=auto pozwala wyświetlić wartości dotyczące używanej pamięci jako „human-readable”, czyli odpowiednio w jednostkach KB/MB/GB/TB.
Do LPAR-a jest przypisane 20GB pamięci. Jeśli chcemy się dowiedzieć ile mamy pamięci rzeczywistej wolnej pamięci, powinniśmy patrzeć na pozycję „free”, oznaczoną żółtym kolorem. Jeśli chcemy wiedzieć ile mamy dostępnej pamięci z włącznie z Filesystem Cache, powinniśmy patrzeć na pozycję „available”, oznaczoną zielonym kolorem.
TOPAS
Topas w systemie AIX można potraktować jako pewnego rodzaju odpowiednik narzędzia top, popularnego w dystrybucjach Linuxa. Narzędzie uruchomione bez żadnych parametrów, wyświetli nam ekran taki jak zaprezentowany poniżej (sekcja dotycząca pamięci RAM została wyróżniona żółtym kolorem). Administratorzy często do oceny zajętości pamięci uruchamiają właśnie ekran domyślny tego narzędzia. Czy słusznie? Wg. mnie pomaga to w pewnym stopniu na oszacowanie, ale może to być też zbyt duże uproszczenie. Z wyjaśnieniem co dokładnie określa %Comp, %Noncomp i %Client, odsyłam do sekcji MEMORY w dokumentacji: https://www.ibm.com/docs/en/aix/7.3.0?topic=t-topas-command)
Domyślny ekran Topas nie pokazuje nam wprost wolnej pamięci, (a przecież miało być prosto), dlatego żeby ułatwić sobie życie, proponuję wcisnąć klawisz „M” lub uruchomić polecenie topas z parametrem -M ($ topas -M), czyli w opcji „Memory topology panel”.
Ekran narzędzia w tym trybie, pokaże nam wartości FREE oraz FILECACHE w jednostkach human-readable, więc dostępną pamięć można wyliczyć dodając te dwie wartości do siebie (FREE + FILECACHE).
NMON
Narzędzie NMON (Nigel’s Monitor) w trybie interaktywnym, po wciśnięciu klawisza M (Memory) prezentuje poniższy ekran:
Wielu specjalistów IT, gdy widzi wartość Used na poziomie powyżej 95% doświadcza przyspieszenia bicia serca, dlatego należy wziać głęboki wdech i spokojnie spojrzeć w pozycję po prawej stronie ekranu, gdzie jest podany FileSystemCache (numperm).
Jeśli dodamy Free (3.8%) i numperm (57.9%) do siebie, otrzymamy dostępną pamięć, czyli 61,7%.
(po opis pozostałych wartości dotyczących pamięci w narzędziu NMON odsyłam do dokumentacji: https://www.ibm.com/docs/en/aix/7.2.0?topic=tool-memory-statistics)
Grafana + NIMON/NJMON
Najbardziej wg mnie wartościową formą monitorowania dostępności pamięci jest rejestrowanie statystyk w dłuższej perspektywie czasowej, dzięki czemu można je prezentować w formie wykresów. Dostępna pamięć może być wartością bardzo zmienną, więc diagnoza administratora w stylu „ten system ma mnóstwo wolnej pamięci” po crashu aplikacji i zwolnieniu tej pamięci w wyniku zatrzymania procesów raczej nie będzie zbyt wartościowa. Warto mieć możliwość obserwowania stanu systemu nie tylko w aktualnym momencie, ale również widzieć co działo się wcześniej i tym samym mieć szerszy kontekst i móc wyciągać korelacje z innymi zdarzeniami lub wykresami utylizacji zasobów.
Sądzę że wykres taki jak poniżej, jest bardzo czytelny i na tym konkretnym przykładzie pozwala łatwo zobaczyć duży udział FilesystemCache w całej przestrzeni RAM. Patrząc jedynie na wartość Real free, łatwo można byłoby błędnie ocenić, że system potrzebuje pilnego dodania pamięci RAM.
W kolejnej części artykułu postaram się przedstawić gotowy przykład takiego panelu do wykorzystania w Grafanie.
Poniższy wykres pokazuję jako przykład, gdy obserwacja utylizacji pamięci przez dłuższy okres może pomóc nam wykryć sytuację wycieku pamięci (memory leak). Zdarzają się sytuacje gdy pamięć jest „zjadana” przez jakiś proces wskutek błędu deweloperskiego, przez wiele tygodni lub miesięcy, aż doprowadzi do wysycenia pamięci. „Kropla drąży skałę”, dlatego zdecydowanie warto obserwować utylizację pamięci i ustawiać progi alertowania.
Czy można dostosować wykorzystanie FSCache?
W zależności od przeznaczenia serwera, można dostosować tuning wykorzystania Filesystem Cache, m. in. za pomocą parametrów dla Virtual Memory Managera
- minperm%
- maxperm%
- maxclient%
- lru_file_repage
Zalecane jest pozostawienie domyślnych parametrów, jednak mogą się pojawić przypadki, gdy nie będą one optymalne. Warto sugerować się rekomendacjami dostawcy oprogramowania do działania którego konfigurujemy system AIX, w szczególności w przypadku baz danych. Przykładem może być m. in. baza Oracle, ponieważ może wykorzystywać własny mechanizm cache’owania (zazwyczaj parametr lru_file_repage jest wtedy ustawiane z domyślnego ustawienia 1 na 0) i dublowanie funkcjonalności cache nie będzie mieć sensu.
Gdzie szukać bardziej szczegółowych informacji?
Ta publikacja w założeniu miała być możliwie prosta, krótka i zrozumiała. Jeśli szukasz bardziej szczegółowych informacji dotyczących zarządzania pamięcią i wykorzystania narzędzi, zdecydowanie polecam zapoznać się z poniższymi pozycjami w formie PDF.
AIX 7.3
- AIX Version 7.3: Performance management: https://www.ibm.com/docs/en/ssw_aix_73/pdf/performance_pdf.pdf
- AIX Version 7.3: Performance Tools Guide and Reference: https://www.ibm.com/docs/en/ssw_aix_73/pdf/performancetools_pdf.pdf
AIX 7.2
- AIX Version 7.2: Performance management: https://www.ibm.com/docs/en/ssw_aix_72/pdf/performance_pdf.pdf
- AIX Version 7.2: Performance Tools Guide and Reference: https://www.ibm.com/docs/en/ssw_aix_72/pdf/performancetools_pdf.pdf
Podsumowanie
Celem napisania tego artykułu było ułatwienie interpretacji i sprawdzenie wolnej przestrzeni RAM w możliwie prosty sposób. Mam nadzieję że tekst był dla Ciebie pomocny i nie oberwie mi się od ekspertów za zbyt duże uproszczenia 🙂
Zagadnienia takie jak SWAP i składowe zajętej pamięci pozostawiłem do opisania w kolejnej, nieco bardziej zawiłej publikacji 🙂