Nawet na najlepiej utrzymanych partycjach LPAR zdarzają się błędy krytyczne (system crash), których nie przewidzisz. Gdy system nagle „leży”, masz dwie opcje: albo wróżysz z fusów, albo otwierasz zrzut pamięci. Bez danych z System Dump analiza RCA to czysta spekulacja, a IBM Support nie pomoże bez twardych danych. Sercem diagnostyki w takiej sytuacji jest System Dump.
Czym jest System Dump?
System Dump to proces, w którym jądro systemu AIX w momencie awarii zapisuje zawartość pamięci operacyjnej (RAM) na dedykowane urządzenie. W przeciwieństwie do standardowych logów, dump zawiera surowy obraz struktur jądra, stosów procesów oraz rejestrów procesora z chwili wystąpienia błędu.
Bez poprawnego zrzutu analiza RCA opiera się na domysłach. Pełny dump pozwala inżynierom wsparcia (np. IBM Support) zidentyfikować, czy przyczyną był błąd w sterowniku, wyciek pamięci w rozszerzeniu jądra (kernel extension), czy usterka sprzętowa.
Rodzaje Dumpa: Traditional vs. FW-Assisted
Mechanizm zrzutu ewoluował wraz z architekturą POWER:
- Traditional System Dump: Za wykonanie zrzutu odpowiada uszkodzone jądro systemu.
⚠️ Uwaga: Jeśli awaria dotyczy podsystemu I/O, jądro może nie być w stanie zapisać danych na dysk. - Firmware-Assisted Dump (FW-assisted): Dostępny od procesorów POWER6. W momencie crashu jądro przekazuje kontrolę do Hypervisora (PHYP). Partycja jest restartowana, ale zawartość RAM zostaje zachowana. Zrzut jest zapisywany po restarcie systemu przy użyciu sprawnych sterowników, co daje niemal stuprocentową pewność zapisu danych.
Weryfikacja obecnych ustawień
Bieżącą konfigurację sprawdzisz poleceniem: sysdumpdev -l
primary /dev/lg_dumplv
secondary /dev/sysdumpnull
copy directory /var/adm/ras
forced copy flag FALSE
always allow dump TRUE
dump compression ON
type of dump fw-assisted
full memory dump disallow
Kluczowe parametry:
- primary: Podstawowe urządzenie zrzutu. Rekomendowane jest użycie dedykowanego wolumenu (np.
/dev/lg_dumplv). - secondary: Urządzenie zapasowe. Zazwyczaj ustawiane na
/dev/sysdumpnull. - forced copy flag: Określa, czy system ma wymusić kopiowanie zrzutu do katalogu wskazanego w
copy directorypo restarcie. Jeśli parametr toFALSE, a w docelowej lokalizacji zabraknie miejsca, dump może zostać utracony. - dump compression: Od AIX 6.1 domyślnie ON. Kompresja jest niezbędna, by zrzut zmieścił się na mniejszym wolumenie logicznym.
- type of dump:
fw-assisted(zalecany) lubtraditional.
Zapomnij o /dev/hd6 (Paging Space)
Wielu adminów wciąż zostawia konfigurację, gdzie zrzut ląduje w przestrzeni wymiany. To błąd wysokiego ryzyka.
Dlaczego? Paging space jest krytyczny dla AIX-a natychmiast po starcie. Jeśli tam wyląduje dump, system zacznie go nadpisywać swoimi procesami, zanim w ogóle zdążysz pomyśleć o jego skopiowaniu. Efekt? Uszkodzony, nieczytelny zrzut i brak szans na diagnozę.
Zasada jest prosta: Zawsze twórz dedykowany wolumen (np. lg_dumplv) typu dump. Miejsce na dysku jest dziś tanie – czas przy awarii już nie.
System „wisi” i nie odpowiada? Dociśnij go ręcznie
Zdarza się najgorszy scenariusz to taki w, którym System nie reaguje na pingi ani SSH, ale samoczynnie się nie restartuje. Wtedy nie masz wyjścia – musisz wymusić zrzut ręcznie, żeby dowiedzieć się, co go „zakleszczyło”.
Masz dwie drogi, zależnie od tego, co jeszcze dycha:
- Przez HMC (Najpewniejsza metoda): Gdy partycja nie odpowiada, uderzaj prosto do Hypervisora.
- Z GUI:
Operations -> Restart -> Dump. - Z CLI:
chsysstate -m ManagedSystem -r lpar -n LPARname -o dumprestart
- Z poziomu powłoki (jeśli terminal jeszcze dycha):
Użyj polecenia:sysdumpstart -p(zrzut na primary device) lubsysdumpstart -s(zrzut na secondary device)
⚠️ Ważna uwaga: Cierpliwość popłaca Musisz mieć świadomość, że restart z wymuszeniem dumpa trwa odczuwalnie dłużej niż „twardy reset” (zrzucenie gigabajtów RAM-u na dysk wymaga czasu). Jednak ten dodatkowy czas to Twoja jedyna polisa ubezpieczeniowa. Zwykły restart przy zwisie to bezpowrotna strata szansy na diagnozę. Ręczne wywołanie dumpa to jedyny sposób, żeby „wyciągnąć” przyczynę problemów na światło dzienne i upewnić się, że problem nie wróci jutro o tej samej porze.
Zmiana ustawień i tworzenie przestrzeni
Ustawienia można łatwo dostosować poleceniem sysdumpdev np:
| Ustawienie | Polecenie zmiany |
| Primary device | sysdumpdev -P -p /dev/lg_dumplv |
| Secondary device | sysdumpdev -P -s /dev/sysdumpnull |
| type of dump | sysdumpdev -t traditional sysdumpdev -t fw-assisted |
| full memory dump | sysdumpdev -f allow sysdumpdev -f disallow |
Jak stworzyć dedykowaną przestrzeń w dwóch krokach?
- Stwórz LV o typie dump w rootvg:
mklv -y lg_dumplv -t dump rootvg 16 - Ustaw nowe urządzenie na stałe:
sysdumpdev -P -p /dev/lg_dumplv
Obliczanie wymaganego miejsca
Ile miejsca właściwie potrzebujesz? Sprawdzisz to poleceniem: sysdumpdev -e
# sysdumpdev -e
Estimated dump size in bytes: 1443406806Kiedy robić weryfikację? Najlepiej w szczycie obciążenia systemu i po każdym dołożeniu RAM-u. AIX sam sprawdza wymaganą wielkość dump device w crontaba roota jest wpis dotyczacy dumpcheck:
0 15 * * * /usr/lib/ras/dumpcheck >/dev/null 2>&1
Dzięki temu system raz na dobę sam sprawdzi dostępną przestrzeń. Pamiętaj tylko, że moment wykonania crona nie zawsze pokryje się z pikiem obciążenia. Jeśli w errpt wyłapiesz wpis: “dumpcheck: The largest dump device is too small”, nie zwlekaj – powiększ wolumen przez extendlv.
Pamiętaj: dumpcheck bywa ryzykownym optymistą
Skrypt ten bazuje na wynikach sysdumpdev -l, ale ma jedną istotną cechę: jeśli masz włączoną kompresję (dump compression ON), dumpcheck z góry zakłada, że dane skurczą się o równe 50%. W efekcie dzieli wymagany wynik przez pół i na tej podstawie ocenia, czy masz dość miejsca.
Pobieranie danych do analizy
Gdy system już wstanie, musisz zebrać komplet danych dla IBM Support. Najszybciej zrobisz to narzędziem snap lub savecore.
Użycie snap -ac wygeneruje skompresowaną paczkę ze zrzutem i logami. Ważna uwaga: paczka diagnostyczna potrafi sporo ważyć. Jeśli masz za mało miejsca w /tmp (domyślna lokalizacja), użyj przełącznika -d, aby skierować plik wynikowy do innego, większego systemu plików: snap -ac -d /sciezka/do/duzego/fs
Dlaczego to w ogóle ważne?
Narzędzia takie jak nmon czy Grafana świetnie pokazują wydajność, ale przy krytycznym zatrzymaniu systemu są bezużyteczne. W klasycznych logach często nie zobaczysz nic podejrzanego, bo błąd wydarzył się głęboko w kodzie jądra.
To właśnie wtedy kluczowe stają się dane ze zrzutu pamięci. Spójrz na te przykłady APAR-ów:
Informacje zawarte w tych poprawkach wskazują na konkretne błędy w kodzie, których nie wyłapiesz żadnym zewnętrznym narzędziem monitoringu. Prawidłowa konfiguracja dumpa zajmuje kilka minut i wymaga ułamka przestrzeni dyskowej. To śmiesznie niski koszt w porównaniu do wielogodzinnego przestoju i czekania na kolejną awarię tylko po to, by w końcu spróbować postawić diagnozę. Bez zapisanego dumpa, RCA często kończy się na domysłach.