Śledź błędy pamięci aktualizacji SLES przed ponowną próbą

Jeśli podczas aktualizacji SLES zgłasza komunikat „Nie można przydzielić pamięci”, najpierw sprawdź, czy jądro zarejestrowało zdarzenie braku pamięci i czy pamięć RAM lub swap zostały wyczerpane. Wstrzymaj znane, nieistotne obciążenie lub zwiększ przypisaną pamięć maszyny wirtualnej dopiero po potwierdzeniu obciążenia, a następnie sprawdź, czy Zypper i RPM nie są już aktywne przed wznowieniem pierwotnej procedury aktualizacji.

Hipotetyczny przykład: wyobraź sobie maszynę wirtualną SLES 15, na której administrator uruchamia zaplanowaną aktualizację pakietu podczas działania dużego zadania wsadowego. Zypper zatrzymuje się z powodu błędu alokacji pamięci. Poniższy przykład ma charakter poglądowy, a nie jest raportem z rzeczywistego incydentu lub testu; użyj poleceń, aby zebrać dowody na własnym hoście, zanim wybierzesz rozwiązanie.

1. Sprawdź, czy serwer nadal jest aktualizowany

Nie restartuj, nie zamykaj procesów pakietów ani nie uruchamiaj drugiego polecenia aktualizacji tylko dlatego, że sesja SSH wyświetliła błąd. Połącz się ponownie w drugiej sesji i sprawdź, czy są aktywne procesy Zypper lub RPM:

pgrep -a 'zypper|rpm'

Jeśli proces pakietu nadal działa, odczekaj chwilę i sprawdź jego dane wyjściowe lub logi. Nie usuwaj plików blokady Zypper, gdy operacja pakietu jest aktywna. Jeśli żaden proces nie jest uruchomiony, zachowaj dokładny tekst błędu i zanotuj, kiedy wystąpił; ten znacznik czasu pomaga powiązać logi jądra i pakietu.

2. Potwierdź lub wyklucz obciążenie pamięci

Zbierz aktualną migawkę pamięci RAM i wymiany:

free -h
swapon --show
vmstat 1 5

W free -hsprawdź kolumnę available, nie tylko ilość oznaczoną free; Linux używa również pamięci RAM jako pamięci podręcznej. swapon --showRaportuje, czy istnieje wymiana i ile jest jej wykorzystane. W vmstat, powtarzające się wartości niezerowe sii sow ostatnich wierszach wskazują na aktywną wymianę; pierwszy wiersz to średnia od momentu uruchomienia, więc skup się na kolejnych wierszach.

Następnie poszukaj komunikatu o braku pamięci jądra (OOM) w miejscu wystąpienia awarii i przeczytaj dziennik Zyppera:

sudo journalctl -k -b --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'
sudo tail -n 80 /var/log/zypper.log

Rekord OOM-kill o nazwie RPM, Zypper lub inny proces wskazuje na rzeczywistą diagnostykę przeciążenia pamięci. Sam niski poziom „wolnej” pamięci RAM nie jest wystarczający: pamięć podręczną można odzyskać, a komunikat może również wynikać z limitu pamięci procesu lub usługi. Jeśli nie pojawi się żaden wpis OOM jądra, przed dodaniem pamięci hosta należy sprawdzić limity błędnego polecenia oraz ewentualne ograniczenia pamięci systemd lub kontenera. Dokładnej przyczyny nie można ustalić na podstawie samego komunikatu „Nie można przydzielić pamięci”.

3. Zmniejsz ciśnienie przed ponowną próbą

Wróć do hipotetycznej maszyny wirtualnej. Jeśli zadanie wsadowe zużywa pamięć, a system wykazuje ciągłą aktywność wymiany lub brak pamięci jądra (OOM), użyj obsługiwanej przez aplikację procedury wstrzymywania lub zatrzymywania. Nie zamykaj bazy danych, obciążenia SAP ani innej usługi stanowej bez wykonania kroków operatora. Sprawdź pamięć RAM i ponownie wykonaj wymianę po wstrzymaniu obciążenia.

Jeśli podczas normalnej konserwacji gościowi brakuje pamięci, zwiększ przydzieloną mu pamięć RAM za pośrednictwem obsługiwanego hiperwizora lub platformy sterowania w chmurze, a następnie sprawdź, czy system operacyjny widzi nową ilość. Dodanie pamięci wymiany może zapewnić tymczasową rezerwę, ale jest wolniejsze niż pamięć RAM i nie rozwiązuje problemu stałego zapotrzebowania na pamięć. Układ pamięci masowej w systemie SLES ma znaczenie: na przykład SUSE dokumentuje określone ograniczenia dotyczące plików wymiany w systemie Btrfs. Unikaj tworzenia lub zmiany rozmiaru pamięci wymiany podczas aktualizacji, chyba że sprawdzisz wymagania dotyczące systemu plików, migawki i platformy.

W przypadku braku rekordów OOM należy sprawdzić limit obowiązujący dla procesu, który uległ awarii. W systemie SLES 15 należy sprawdzić skonfigurowany limit pamięci obciążenia zarządzanego przez systemd, zastępując nazwę przykładowej jednostki usługą, której dotyczy problem:

sudo systemctl show example-batch.service -p MemoryMax

Porównaj tę wartość z dostępną pamięcią. Limit cgroup nie zostanie naprawiony przez zwiększenie pamięci RAM maszyny wirtualnej, chyba że limit zostanie odpowiednio podniesiony. W przypadku starszych pakietów Service Pack należy sprawdzić nazwę właściwości w dokumentacji systemd danej wersji.

4. Wznów tę samą obsługiwaną aktualizację i ją zweryfikuj

Po zakończeniu procesu pakietowania sprawdź, /var/log/zypper.logczy ostatnio ukończono akcję i czy pakiety zostały nieudane. Jeśli RPM lub Zypper zgłosi niekompletną transakcję, przed ponowną próbą postępuj zgodnie ze wskazówkami odzyskiwania systemu SUSE dotyczącymi tego konkretnego błędu. Nie usuwaj ręcznie plików bazy danych ani blokad pakietów.

Użyj tej samej ścieżki aktualizacji, którą pierwotnie uruchomiłeś. Rutynowa konserwacja pakietów i migracja Service Packa to różne operacje: dokumenty SUSE zypper patchdotyczące instalowania odpowiednich wydanych poprawek, podczas gdy aktualizacje Service Packa i głównej wersji mają własne obsługiwane ścieżki i procedury przygotowawcze. Nie przełączaj się na tę opcję zypper duptylko po to, by obejść ograniczenia pamięci. W przypadku rutynowego uruchomienia poprawki, najpierw sprawdź transakcję:

sudo zypper patch --dry-run

Jeśli test pokaże rozsądny plan, a pamięć jest stabilna, zaplanuj okno konserwacji i uruchom odpowiednie polecenie dla pierwotnego zadania. Utrzymuj dostępną sesję SSH, monitoruj proces i sprawdź wynik później:

sudo tail -n 80 /var/log/zypper.log
sudo journalctl -k -b --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'

Pomyślne odzyskiwanie oznacza, że ​​zamierzone pakiety lub migracja zostały ukończone, Zypper zakończył działanie bez problemów i nie pojawiło się żadne nowe zdarzenie braku pamięci (OOM) podczas wykonywania operacji. Jeśli system jest bootowalny, ale sama migracja Service Packa SLES musi zostać cofnięta, udokumentowane wycofanie Snappera przez SUSE ma zastosowanie tylko wtedy, gdy spełnione są jego wymagania, w tym obsługiwany katalog główny Btrfs i skonfigurowane migawki. Nie należy traktować wycofania jako ogólnej odpowiedzi na nieudaną poprawkę pakietu.

Kiedy zatrzymać się i eskalować

Jeśli błąd powtarza się po usunięciu obciążenia pamięci, procesy pakietów nadal się zawieszają lub baza danych RPM zgłasza uszkodzenie, przerwij ponawianie prób. Zachowaj dziennik Zyppera, dziennik jądra, wersję produktu i Service Pack oraz dokładną nazwę użytego polecenia. Systemy SUSE supportconfigmogą gromadzić dane diagnostyczne na potrzeby zgłoszenia do pomocy technicznej. Poniższe kroki pomagają odróżnić obciążenie pamięci od innych błędów alokacji; nie są one w stanie określić usterki specyficznej dla produktu bez pełnych dzienników i konfiguracji systemu.

Aby uzyskać szczegółowe informacje o SLES 15 SP7, zapoznaj się z narzędziami do monitorowania systemu SUSE , informacjami o plikach dziennika , wskazówkami dotyczącymi administracji Zypperem , wymaganiami dotyczącymi wymiany i Btrfs oraz instrukcjami aktualizacji i przywracania online . Polecenia i ścieżki odzyskiwania mogą się różnić w zależności od pakietu Service Pack SLES, architektury, systemu plików oraz tego, czy zadanie dotyczy poprawek, czy migracji wersji.