Linux pokazuje niewiele całkowicie wolnego RAM-u, ale komputer działa sprawnie. Czy pamięć jest już pełna? Niekoniecznie: system wykorzystuje część zasobu do przyspieszania dostępu do plików. Ważniejsze od samej kolumny free jest to, ile pamięci można udostępnić aplikacjom oraz czy w czasie pracy pojawia się rzeczywista presja.
Zacznij od pomiaru całego systemu, potem znajdź procesy i obserwuj je podczas zadania powodującego problem. Nie czyść cache tylko po to, żeby uzyskać ładniejszy wskaźnik. Nie testuj też kości RAM na podstawie samego wysokiego zużycia: zajętość i błędy sprzętowe to osobne kwestie.
Odczytaj free i patrz na available
free -hOpcja -h przedstawia wartości w czytelnych jednostkach. W wierszu Mem zobaczysz całkowitą pamięć dostępną systemowi, użycie, wolną pamięć, dane współdzielone, bufory/cache i oszacowanie available. Układ oraz sposób wyliczania części pól mogą zależeć od wersji narzędzia.
Free opisuje pamięć aktualnie niewykorzystaną. Available szacuje zasób, który może zostać przeznaczony dla nowych aplikacji bez konieczności użycia swapu. Uwzględnia możliwość odzyskania części cache, ale nie zakłada, że cała pamięć podręczna może zostać od razu zwolniona.
Przykład: przy około 8 GiB pamięci system może pokazać tylko kilkaset MiB free, a kilka GiB available. To nie jest automatyczny dowód niedoboru. Inaczej wygląda sytuacja, w której available przez dłuższy czas jest małe, aplikacje przestają reagować i trwa intensywna wymiana danych ze swapem.
Wartość total nie musi zgadzać się dokładnie z sumą nominalnej pojemności modułów. Część zasobu jest zarezerwowana lub niedostępna dla tego raportu. Jeśli różnica jest duża, sprawdź wykrywanie sprzętu osobno, zamiast odejmować cache od wyniku i nazywać go utraconą pamięcią.
Aby porównać odczyty bez ręcznego powtarzania, możesz wykonać trzy próbki w odstępach dwóch sekund:
free -h -s 2 -c 3Zrób pomiar przed uruchomieniem używanego programu i w jego trakcie. Zapisz moment wczytania projektu lub otwarcia wielu kart. Krótka seria jest punktem startowym; przy narastającym problemie potrzebujesz dłuższej obserwacji zwykłego zadania.
Znajdź procesy, ale nie sumuj bezkrytycznie RSS
Listę największych procesów według pamięci rezydentnej możesz uzyskać tak:
ps -eo pid,comm,rss,%mem --sort=-rss | head -n 11Wynik zawiera nagłówek i do dziesięciu procesów. PID identyfikuje proces, comm pokazuje nazwę polecenia, RSS ilość pamięci rezydentnej raportowaną w kilobajtach, a %MEM jej udział względem fizycznej pamięci. To inne jednostki niż automatycznie dopasowane pola free -h.
Nie utożsamiaj RSS z całkowicie prywatną pamięcią programu. Procesy mogą współdzielić strony, więc dodanie wszystkich wartości może policzyć część zasobu kilka razy. Przeglądarka również może składać się z wielu procesów. Jedna linia nie zawsze oznacza całkowite zużycie całej aplikacji.
Największy proces nie musi być wadliwy. Edytor otwierający duży projekt powinien zużyć więcej niż pusty terminal. Sprawdź zmianę po rozpoczęciu zadania, po jego zakończeniu i po zamknięciu dokumentu. Samo pozostawienie pewnej ilości pamięci po pracy nie dowodzi wycieku: program może zachowywać cache do kolejnego użycia.
Nie kończ procesu tylko po numerze z wcześniejszego zrzutu. PID może się zmienić, a wymuszone zakończenie aplikacji może utracić niezapisaną pracę. Zacznij od jej normalnego zamknięcia, ustawień, dodatków i powtarzalnego testu. Przy przeglądarce pomoże ograniczenie pamięci używanej przez karty i rozszerzenia.
Sprawdź, czy swap jest aktywnie używany podczas spowolnienia
vmstat 1 5Polecenie pokazuje pięć raportów. W standardowym użyciu pierwszy wiersz pokazuje uśrednioną od startu aktywność, np. CPU i wymiany; kolejne odnoszą się do wskazanych odstępów. Pola opisujące aktualne ilości pamięci oraz procesy są bieżące także w pierwszym raporcie. Przy analizie si i so nie traktuj więc pierwszego wiersza jak pomiaru ostatniej sekundy.
Kolumny si i so dotyczą danych przenoszonych ze swapu i do swapu. Obserwuj je razem z available oraz reakcją programów. Samo istnienie zajętego swapu nie oznacza, że komputer teraz intensywnie wymienia dane. Mogły pozostać tam strony z wcześniejszego okresu pracy.
Jeśli podczas przełączania aplikacji występuje ciągła wymiana, mało dostępnej pamięci i wyraźne opóźnienie, sprawdź liczbę uruchomionych zadań oraz wielkość projektów. Nie wyłączaj swapu na próbę, gdy pamięci już brakuje. Nie zmieniaj od razu parametrów jądra tylko po to, żeby jedna kolumna pokazywała zero.
Gdy komputer zwalnia bez takiego obrazu, sprawdź inne ograniczenie. Wysokie użycie procesora i czekanie na dysk mogą przypominać niedobór RAM. Pomocny będzie poradnik wyszukiwania procesów obciążających CPU, oceniony w tym samym czasie co pomiar pamięci.
Znikający proces i kontenery wymagają dodatkowego kontekstu
Jeśli aplikacja została zakończona przez mechanizm OOM, stan pamięci po zdarzeniu może już wyglądać znacznie lepiej. Sprawdź logi jądra i aplikacji z chwili zakończenia, uwzględniając dostępne uprawnienia. Nie uznawaj samej poprawy wskaźnika po zniknięciu programu za rozwiązanie przyczyny.
Usługa albo kontener może mieć limit pamięci niższy niż zasób całego komputera. Wolny RAM hosta nie wyklucza osiągnięcia limitu danej grupy procesów. Sprawdź konfigurację i statystyki używanego środowiska. Nie porównuj raportu z wnętrza kontenera z limitem hosta bez ustalenia, co narzędzie rzeczywiście pokazuje.
Do decyzji o rozbudowie zachowaj odczyty z normalnego zadania, listę procesów i czas wystąpienia problemu. Najpierw usuń niepotrzebne obciążenie lub rozpoznaj narastające zużycie konkretnej aplikacji. Gdy sprzęt zgłasza błędy lub ulega losowym awariom, wykonaj osobną diagnostykę poprawności RAM. Większa pojemność i sprawność modułu rozwiązują różne problemy.
