Polecenia i narzędzia do sprawdzania zużycia RAM w Linux

Monitorowanie użycia RAM w Linux oznacza odpytywanie podsystemu pamięci jądra w celu pobrania metryk dotyczących alokacji pamięci fizycznej, wykorzystania swap oraz rozmiarów rezydentnych zestawów poszczególnych procesów. Najbardziej bezpośrednie metody wykorzystują wbudowane narzędzia — free, top, htop, ps, vmstat i smem — z których każde ujawnia inną warstwę hierarchii pamięci, od sum systemowych aż po proporcjonalny rozmiar zestawu (PSS) poszczególnych procesów.

Nadmierne obciążenie pamięci uruchamia mechanizm Linux Out-of-Memory (OOM) killer, który przymusowo kończy procesy w celu odzyskania RAM. Zrozumienie, które polecenia ujawniają które metryki — i co te metryki faktycznie oznaczają — to różnica między reaktywnym gaszeniem pożarów a proaktywnym zarządzaniem pojemnością. Ten przewodnik omawia wszystkie główne narzędzia, źródła danych jądra, z których korzystają, oraz przypadki brzegowe, które zaskakują nawet doświadczonych administratorów.

Dlaczego monitorowanie RAM ma znaczenie na serwerach Linux

Zarządzanie pamięcią w Linux jest celowo agresywne. Jądro wykorzystuje całą dostępną pamięć RAM jako pamięć podręczną stron (page cache) w celu przyspieszenia operacji I/O dysku, co oznacza, że system raportujący bliską zeru wolną pamięć niekoniecznie jest pod presją — może po prostu efektywnie korzystać z cache. Błędna interpretacja tego zachowania jest jednym z najczęstszych błędów przy odczytywaniu surowych wartości pamięci.

Kluczowe powody ciągłego monitorowania RAM:

• Zapobieganie OOM killerowi: Identyfikacja procesów pochłaniających pamięć, zanim jądro zakończy krytyczne usługi.
• Wykrywanie użycia swap: Intensywna aktywność swap (swapping) wskazuje na wyczerpanie RAM i powoduje poważne opóźnienia I/O.
• Diagnozowanie wycieków pamięci: Procesy ze stale rosnącym RSS w czasie sygnalizują wycieki na poziomie aplikacji.
• Planowanie pojemności: Dane trendów informują o decyzjach dotyczących skalowania pionowego lub redystrybucji obciążenia.
• Strojenie wydajności: Dostosowywanie vm.swappiness, huge pages i topologii NUMA wymaga bazowych danych pamięci.

W środowisku VPS Hosting, gdzie zasoby są współdzielone lub ograniczone przez limity hiperwizora, dokładne monitorowanie RAM jest szczególnie istotne — osiągnięcie limitu pamięci po cichu degraduje wydajność, zanim jakikolwiek alert zostanie wyzwolony.

Zrozumienie terminologii pamięci Linux

Przed uruchomieniem jakiegokolwiek polecenia musisz zrozumieć, co faktycznie reprezentują kolumny wyjściowe.

Kluczowa wskazówka: Zawsze używaj kolumny Available z free -h, a nie kolumny Free, oceniając czy system ma wystarczającą ilość RAM dla nowego obciążenia. Kolumna Free ignoruje możliwy do odzyskania cache, prowadząc do fałszywych alarmów.

Plik /proc/meminfo: Autorytatywne źródło

Każde narzędzie opisane w tym artykule odczytuje dane z /proc/meminfo, wirtualnego pliku utrzymywanego przez jądro w czasie rzeczywistym. Bezpośrednia inspekcja daje najbardziej szczegółowe dostępne dane:

cat /proc/meminfo

Kluczowe pola do obserwowania:

• MemTotal — całkowita użyteczna pamięć RAM
• MemFree — całkowicie bezczynna pamięć RAM
• MemAvailable — szacowana dostępna pamięć RAM dla nowych procesów
• Buffers — surowa pamięć podręczna bloków dyskowych
• Cached — pamięć podręczna stron dla plików
• SwapTotal / SwapFree — pojemność i dostępność swap
• Dirty — pamięć oczekująca na zapis na dysk (wysokie wartości wskazują na presję I/O)
• HugePages_Total / HugePages_Free — status alokacji huge pages
• Slab — pamięć podręczna struktur danych jądra (może znacznie rosnąć na zajętych serwerach NFS lub bazodanowych)

Zrozumienie /proc/meminfo pozwala interpretować dane wyjściowe każdego innego narzędzia z pełnym kontekstem.

Sprawdzanie RAM za pomocą polecenia free

free to najszybszy sposób na uzyskanie systemowego migawkowego widoku pamięci. Odczytuje dane bezpośrednio z /proc/meminfo i formatuje dane wyjściowe w czytelną dla człowieka tabelę.

Podstawowe użycie

free

Dane wyjściowe są domyślnie w kilobajtach. Użyj flag dla bardziej czytelnych formatów:

free -h        # Human-readable (MB/GB)
free -m        # Output in megabytes
free -g        # Output in gigabytes
free -s 5      # Refresh every 5 seconds (continuous monitoring)
free -h --si   # Use SI units (1000-based) instead of binary (1024-based)

Wyjaśnienie przykładowych danych wyjściowych

              total        used        free      shared  buff/cache   available
Mem:           15Gi       4.2Gi       1.1Gi       312Mi       9.8Gi       10.9Gi
Swap:         2.0Gi       128Mi       1.9Gi

W tym przykładzie system wydaje się mieć tylko 1,1 GB wolnej pamięci, ale 10,9 GB jest faktycznie dostępne dla nowych procesów, ponieważ jądro odzyska buff/cache na żądanie. To najważniejsza rzecz do zrozumienia w danych wyjściowych free.

Przypadek brzegowy: Użycie swap jako sygnał ostrzegawczy

Nawet niewielkie użycie swap (Swap: used > 0) na serwerze produkcyjnym wymaga zbadania. Oznacza to, że jądro już zdecydowało, że niektóre strony pamięci lepiej przechowywać na dysku niż w RAM — znak, że zestaw roboczy przekracza pamięć fizyczną.

Sprawdzanie RAM za pomocą polecenia top

top zapewnia stale aktualizowany, działający w czasie rzeczywistym widok wykorzystania zasobów systemowych, łącząc statystyki CPU i pamięci z posortowaną listą procesów.

top

Kluczowe pola pamięci w top

Na górze interfejsu top dwie linie pokazują statystyki pamięci:

MiB Mem :  16384.0 total,   1126.4 free,   4301.2 used,  10956.4 buff/cache
MiB Swap:   2048.0 total,   1920.0 free,    128.0 used.  11200.0 avail Mem

W tabeli procesów najbardziej istotne kolumny pamięci to:

• VIRT — rozmiar pamięci wirtualnej (odpowiednik VSZ)
• RES — rezydentna pamięć fizyczna (RSS)
• SHR — współdzielona część pamięci RES
• %MEM — procent całkowitej fizycznej pamięci RAM użytej

Przydatne polecenia interaktywne top

Uruchamianie top w trybie nieinteraktywnym

Do skryptowania i przechwytywania logów uruchom top w trybie wsadowym:

top -b -n 1 | head -30

Generuje to pojedynczą migawkę — przydatną dla skryptów monitorujących opartych na cron.

Sprawdzanie RAM za pomocą htop

htop to ulepszony, oparty na ncurses przeglądarka procesów, która prezentuje te same dane co top ze znacznie bardziej użytecznym interfejsem. Nie jest domyślnie instalowany w większości dystrybucji.

Instalacja

# Debian / Ubuntu
apt-get install htop

# RHEL / CentOS / AlmaLinux / Rocky Linux
yum install htop
# or on newer versions:
dnf install htop

# Alpine Linux
apk add htop

Co htop dodaje w porównaniu do top

• Kolorowe paski pamięci rozróżniające używaną pamięć, bufory i cache na pierwszy rzut oka
• Poziomy i pionowy widok drzewa procesów (F5)
• Obsługa myszy do klikania i przewijania
• Wielokrotny wybór do zbiorczego zarządzania procesami
• Wbudowane wyszukiwanie (F3) i filtrowanie (F4) bez zapamiętywania skrótów klawiszowych
• Bezpośrednie wyświetlanie dostępnej pamięci w widocznym miejscu w nagłówku

Legenda kolorów paska pamięci htop

Wskazówka dla zaawansowanych: W htop naciśnij F2 (Setup) > Display Options > włącz „Show CPU frequency” i „Detailed CPU time” dla pełniejszego obrazu obok danych pamięci.

Sprawdzanie RAM za pomocą polecenia ps

ps (status procesu) odpytuje tabelę procesów jądra i może być sortowany oraz filtrowany w celu identyfikacji największych konsumentów pamięci w danym momencie.

Sortowanie procesów według zużycia pamięci

ps aux --sort=-%mem

Wyjaśnienie kolumn wyjściowych

Praktyczne polecenia jednolinijkowe

Pokaż 10 procesów zużywających najwięcej pamięci z czytelnym dla człowieka wyjściem:

ps aux --sort=-%mem | head -11

Pokaż użycie pamięci dla konkretnej nazwy procesu (np. Apache):

ps aux | grep apache2 | awk '{sum += $6} END {print sum/1024 " MB"}'

Sumuje to wartości RSS wszystkich procesów roboczych apache2 — kluczowe dla zrozumienia rzeczywistego śladu wieloprocesowych serwerów WWW.

Ważne zastrzeżenie: ps pokazuje RSS, który podwójnie liczy współdzielone biblioteki. Jeśli 20 procesów roboczych Apache każdy mapuje tę samą bibliotekę współdzieloną o rozmiarze 50 MB, ps raportuje 1 000 MB użycia biblioteki współdzielonej dla wszystkich, podczas gdy rzeczywisty koszt fizyczny wynosi tylko 50 MB. Użyj smem dla dokładnego rozliczenia.

Sprawdzanie RAM za pomocą smem

smem to najdokładniejsze narzędzie do rozliczania pamięci per-proces dostępne w Linux, ponieważ raportuje PSS (Proportional Set Size) — pamięć współdzielona jest dzielona proporcjonalnie między wszystkie procesy, które ją mapują, eliminując problem podwójnego liczenia właściwy narzędziom opartym na RSS.

Instalacja

# Ubuntu / Debian
apt-get install smem

# CentOS / RHEL 7
yum install smem

# RHEL 8+ / AlmaLinux / Rocky Linux
dnf install smem

# Alternatively, install via pip
pip install smem

Podstawowe użycie

smem

Przydatne opcje smem

smem -r              # Sort by RSS (descending)
smem -s pss -r       # Sort by PSS (most accurate, descending)
smem -u              # Aggregate by user
smem -m              # Show system-wide memory map
smem -p              # Show percentages instead of raw KB
smem -k              # Show values in KB
smem -t              # Show totals row
smem --pie name      # Generate a pie chart (requires matplotlib)
smem -P apache2      # Filter by process name pattern

PSS vs RSS: Dlaczego to ma znaczenie

Rozważmy serwer z 10 procesami roboczymi Node.js, z których każdy współdzieli bibliotekę runtime V8 o rozmiarze 100 MB:

• RSS na proces: 200 MB (100 MB współdzielone + 100 MB prywatne)
• Łączny raportowany RSS: 2 000 MB
• PSS na proces: 110 MB (10 MB udział ze 100 MB + 100 MB prywatne)
• Łączny raportowany PSS: 1 100 MB
• Faktycznie używana fizyczna pamięć RAM: 1 100 MB

RSS zawyża użycie prawie 2-krotnie w tym scenariuszu. Przy podejmowaniu decyzji o skalowaniu na Dedicated Server, użycie PSS z smem daje rzeczywisty obraz sytuacji.

Sprawdzanie RAM za pomocą vmstat

vmstat (statystyki pamięci wirtualnej) zapewnia szerszy widok aktywności pamięci, swap, I/O i CPU, co czyni go idealnym do diagnozowania systemowej presji pamięci, a nie problemów poszczególnych procesów.

vmstat 2 10    # Report every 2 seconds, 10 times

Kluczowe kolumny pamięci

Krytyczny sygnał: Niezerowe wartości si (swap-in) i so (swap-out) w działającym strumieniu vmstat wskazują na aktywny swapping — definitywny znak wyczerpania pamięci. Nawet sporadyczne skoki so mogą powodować skoki opóźnień aplikacji rzędu setek milisekund.

Sprawdzanie RAM za pomocą sar (System Activity Reporter)

sar z pakietu sysstat rejestruje historyczne dane pamięci, umożliwiając retrospektywną analizę — czego narzędzia działające w czasie rzeczywistym nie mogą zapewnić.

Instalacja

apt-get install sysstat    # Debian/Ubuntu
yum install sysstat        # CentOS/RHEL

Użycie

sar -r 1 5          # Memory stats every 1 second, 5 times
sar -r -f /var/log/sysstat/sa$(date +%d)   # Today's historical data
sar -S 1 5          # Swap statistics

sar jest nieoceniony przy odpowiadaniu na pytania takie jak „Czy o 3 w nocy wystąpił skok pamięci, który spowodował awarię aplikacji?” — pytanie, na które żadne narzędzie działające w czasie rzeczywistym nie może odpowiedzieć po fakcie.

Sprawdzanie RAM za pomocą /proc/<PID>/status i /proc/<PID>/smaps

Do głębokiej analizy per-proces jądro udostępnia szczegółowe mapy pamięci bezpośrednio w /proc.

Szybkie sprawdzenie pamięci per-proces

cat /proc/$(pgrep nginx | head -1)/status | grep -E "VmRSS|VmPeak|VmSize|VmSwap"

Przykład danych wyjściowych:

VmPeak:   512340 kB
VmSize:   498120 kB
VmRSS:    102400 kB
VmSwap:        0 kB

• VmPeak — szczytowy rozmiar pamięci wirtualnej kiedykolwiek osiągnięty przez ten proces
• VmRSS — bieżący rozmiar rezydentnego zestawu
• VmSwap — ile z tego procesu zostało przeniesione do swap

Szczegółowa mapa pamięci z smaps

cat /proc/$(pgrep mysql | head -1)/smaps | grep -E "^(Size|Rss|Pss|Shared|Private)"

Ujawnia to każde mapowanie pamięci (sterta, stos, biblioteki współdzielone, mapowania anonimowe) z indywidualnymi wartościami RSS i PSS — najbardziej szczegółowy widok pamięci dostępny bez profilera.

Porównanie narzędzi: Wybór właściwego polecenia

Praktyczne przepływy pracy monitorowania

Przepływ pracy 1: Szybka triage (poniżej 60 sekund)

free -h                          # Step 1: Is Available memory critically low?
vmstat 1 5                       # Step 2: Is active swapping occurring?
ps aux --sort=-%mem | head -15   # Step 3: Which processes are the top consumers?

Przepływ pracy 2: Identyfikacja wycieku pamięci

# Watch a specific process's RSS grow over time
watch -n 5 'ps -o pid,rss,vsz,comm -p $(pgrep your_app)'

# Or use smem with repeated snapshots
while true; do smem -P your_app -t; sleep 30; done

Przepływ pracy 3: Historyczna analiza po incydencie

sar -r -f /var/log/sysstat/sa$(date +%d --date='yesterday')

Przepływ pracy 4: Skrypt automatycznego alertowania

#!/bin/bash
THRESHOLD=90
USED_PCT=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')
if [ "$USED_PCT" -gt "$THRESHOLD" ]; then
    echo "ALERT: RAM usage at ${USED_PCT}% on $(hostname)" | mail -s "Memory Alert" admin@example.com
fi

Ten skrypt można umieścić w zadaniu cron dla ciągłego automatycznego monitorowania — praktyczna konieczność na każdym produkcyjnym VPS z cPanel lub serwerze bare-metal.

Zaawansowane: Parametry strojenia pamięci jądra

Po zidentyfikowaniu presji pamięci, te parametry sysctl bezpośrednio wpływają na zachowanie:

# View current swappiness (default: 60)
sysctl vm.swappiness

# Reduce swap tendency (recommended for databases: 10)
sysctl -w vm.swappiness=10

# Increase dirty page write-back aggressiveness
sysctl -w vm.dirty_ratio=15
sysctl -w vm.dirty_background_ratio=5

# Drop page cache manually (use with caution on production)
sync; echo 3 > /proc/sys/vm/drop_caches

Wyjaśnienie vm.swappiness: Wartość 60 oznacza, że jądro zacznie swappować, gdy RAM jest wykorzystany w 40%. W przypadku serwerów bazodanowych (MySQL, PostgreSQL, Redis) ustawienie tego na 10 utrzymuje dane w RAM znacznie dłużej, dramatycznie redukując opóźnienia I/O. W przypadku systemów desktopowych lub systemów z ograniczoną pamięcią RAM, wartość domyślna jest bardziej odpowiednia.

Typowe pułapki i błędne interpretacje

Pułapka 1: Panika z powodu niskiej „wolnej” pamięci

Jak wyjaśniono wcześniej, Linux celowo używa wolnej pamięci RAM jako cache. System z 200 MB wolnej pamięci, ale 8 GB dostępnej jest zdrowy. Zawsze czytaj kolumnę Available.

Pułapka 2: Sumowanie RSS w celu oszacowania całkowitego użycia pamięci

Sumowanie wartości RSS ps dla wszystkich procesów zazwyczaj przekroczy całkowitą fizyczną pamięć RAM z powodu podwójnego liczenia bibliotek współdzielonych. Użyj smem -t dla dokładnej sumy systemowej.

Pułapka 3: Ignorowanie cache Slab

Na zajętych klientach NFS lub serwerach z wieloma małymi plikami, alokator Slab jądra może zużywać gigabajty pamięci RAM. Sprawdź cat /proc/meminfo | grep Slab — ta pamięć jest technicznie możliwa do odzyskania, ale nie pojawia się w narzędziach na poziomie procesów.

Pułapka 4: Mylenie VSZ z faktycznym użyciem pamięci

Aplikacja Java może pokazywać 4 GB VSZ, ale tylko 512 MB RSS. VSZ obejmuje pliki mapowane w pamięci, zarezerwowaną ale niezaalokowaną stertę oraz biblioteki współdzielone — z których większość nigdy nie jest faktycznie ładowana do fizycznej pamięci RAM.

Pułapka 5: Przeoczenie pamięci w konteneryzowanych obciążeniach

Wewnątrz kontenera Docker, free pokazuje całkowitą pamięć hosta, a nie limit cgroup kontenera. Użyj cat /sys/fs/cgroup/memory/memory.usage_in_bytes i cat /sys/fs/cgroup/memory/memory.limit_in_bytes dla dokładnych metryk na poziomie kontenera.

Konfigurowanie trwałego monitorowania RAM

W środowiskach produkcyjnych polecenia punktowe są niewystarczające. Rozważ te podejścia dla ciągłej widoczności:

• sysstat z cron: Umożliwia automatyczne zbieranie historycznych danych sar.
• Prometheus + Node Exporter: Pobiera metryki /proc/meminfo i udostępnia je dla dashboardów Grafana.
• Netdata: Monitorowanie w czasie rzeczywistym bez konfiguracji z granularnością per-sekundową i wbudowanym wykrywaniem anomalii pamięci.
• Zabbix lub Nagios: Alertowanie klasy enterprise z konfigurowalnymi progami pamięci i politykami eskalacji.

Przy uruchamianiu obciążeń na infrastrukturze GPU Hosting, monitoruj również VRAM GPU obok systemowej pamięci RAM — nvidia-smi --query-gpu=memory.used,memory.free --format=csv zapewnia równoważne metryki dla pamięci GPU.

W środowiskach hostingu WWW zarządzanych przez VPS Control Panels, większość paneli zawiera wbudowane wykresy pamięci — ale zazwyczaj odpytują co 1–5 minut i nie wykryją krótkotrwałych skoków, które vmstat lub sar by uchwyciły.

Techniczna macierz decyzyjna: Które narzędzie kiedy używać

Lista kontrolna kluczowych wniosków

• Zawsze sprawdzaj pamięć Available z free -h, a nie kolumnę Free, aby ocenić rzeczywisty margines.
• Użyj vmstat 1 5 aby potwierdzić lub wykluczyć aktywny swapping przed eskalacją dochodzenia.
• Używaj smem -s pss -r zamiast ps aux --sort=-%mem gdy potrzebujesz dokładnych wartości pamięci per-proces — szczególnie na serwerach z wieloma procesami współdzielącymi biblioteki.
• Zainstaluj sysstat na każdym serwerze produkcyjnym natychmiast po jego uruchomieniu, aby umożliwić historyczne zbieranie danych sar.
• Ustaw vm.swappiness=10 trwale w /etc/sysctl.conf na serwerach bazodanowych, aby zminimalizować użycie swap.
• Sprawdź /proc/meminfo pod kątem wartości Slab i Dirty, gdy standardowe narzędzia nie wyjaśniają obserwowanej presji pamięci.
• W przypadku konteneryzowanych obciążeń, odczytuj pliki pamięci cgroup — a nie free — dla dokładnych limitów i użycia.
• W środowiskach współdzielonego hostingu lub VPS, ustal bazowe wartości pamięci podczas normalnej pracy, aby anomalie były natychmiast rozpoznawalne.

—

Często zadawane pytania

Jaka jest różnica między pamięcią „free” a „available” w Linux?

„Free” to pamięć RAM bez żadnego bieżącego użycia. „Available” to realistyczne oszacowanie pamięci, która może być przydzielona nowym procesom bez wyzwalania swappingu — obejmuje możliwy do odzyskania page cache i bufory. Na zdrowym serwerze Linux „free” jest często bliskie zeru, podczas gdy „available” pozostaje wysokie. Zawsze używaj „available” do oceny pojemności.

Dlaczego suma wartości RSS wszystkich procesów przekracza całkowitą fizyczną pamięć RAM?

RSS (Resident Set Size) liczy pamięć współdzieloną — taką jak biblioteki współdzielone — raz na każdy proces, który ją mapuje. Jeśli 50 procesów każdy mapuje bibliotekę współdzieloną o rozmiarze 100 MB, łączna suma RSS rośnie o 4 900 MB ponad rzeczywisty koszt fizyczny. Użyj smem z raportowaniem PSS, aby wyeliminować to podwójne liczenie.

Jak znaleźć, który proces uruchomił Linux OOM killer?

Uruchom dmesg | grep -i "oom|killed process" lub journalctl -k | grep -i oom. Jądro rejestruje dokładną nazwę procesu, PID i statystyki pamięci w momencie zdarzenia kill, w tym oom_score wszystkich ocenianych procesów.

Co wskazuje wysokie użycie swap i jak poważne to jest?

Utrzymujące się użycie swap oznacza, że zestaw roboczy systemu przekracza fizyczną pamięć RAM. Jądro kompensuje to przez stronicowanie danych na dysk, co jest zazwyczaj 100–1 000 razy wolniejsze niż dostęp do RAM. Nawet umiarkowana aktywność swap powoduje mierzalne opóźnienia aplikacji. Jest to definitywny sygnał do zmniejszenia zużycia pamięci, zwiększenia RAM lub redystrybucji obciążeń.

Czy mogę monitorować użycie RAM wewnątrz kontenera Docker za pomocą standardowych poleceń Linux?

Standardowe polecenia takie jak free wewnątrz kontenera pokazują całkowitą pamięć RAM hosta, a nie limit cgroup kontenera. Dla dokładnych metryk na poziomie kontenera, odczytaj /sys/fs/cgroup/memory/memory.usage_in_bytes dla bieżącego użycia i /sys/fs/cgroup/memory/memory.limit_in_bytes dla skonfigurowanego limitu. Alternatywnie użyj docker stats <container_name> z hosta dla sformatowanego widoku.