Napraw błąd „Nie można przydzielić pamięci” podczas aktualizacji systemu SLES

Aktualizacja SLES wydaje się postępować, a następnie terminal, instalator lub dziennik migracji zgłasza komunikat „Nie można przydzielić pamięci”. Sam komunikat nie dowodzi, że serwer potrzebuje więcej fizycznej pamięci RAM. Przyczyną awarii może być przeciążenie pamięci, limit maszyny wirtualnej lub usługi, brak lub nieużyteczność wymiany, albo samo środowisko aktualizacji. Najpierw zidentyfikuj proces i fazę aktualizacji, które spowodowały wygenerowanie komunikatu; bezpieczne rozwiązanie zależy od tych szczegółów.

Wersja ma znaczenie. Od października 2026 roku przewodnik SUSE po aktualizacji wersji głównej systemu SLES 16.0 opisuje system migracji dystrybucji, który uruchamia dedykowany obraz aktualizacji na żywo, podczas gdy migracje pakietów serwisowych SLES 15 korzystają ze sprawdzonego procesu migracji YaST lub Zypper. Nie należy stosować poprawki przeznaczonej do migracji pakietów serwisowych online do aktualizacji wersji głównej bez sprawdzenia procedury dla danego wydania. SUSE dokumentuje aktualną ścieżkę SLES 16 w swoim przewodniku aktualizacji SLES 16 .

1. Zanim cokolwiek zmienisz, zidentyfikuj fazę awarii

Zapisz pełny opis błędu, znacznik czasu, polecenie lub ekran, na którym wystąpił, oraz informację, czy system został ponownie uruchomiony z instalatorem lub obrazem migracji. „Nie można przydzielić pamięci” to ogólny błąd systemu operacyjnego, dlatego otaczające go wiersze są często bardziej przydatne niż sam komunikat.

• Przed rozpoczęciem transakcji pakietowej: proces rejestracji, repozytorium, przygotowania migracji lub instalacji może nie działać prawidłowo. Sprawdź pamięć systemu i procesów, a następnie przejrzyj odpowiednią usługę lub dziennik migracji.
• Podczas instalacji lub usuwania pakietów: Zypper i RPM mogły już zmienić system. Nie przerywaj procesu, nie restartuj ani nie uruchamiaj drugiego menedżera pakietów tylko dlatego, że postęp wydaje się powolny. Sprawdź konsolę i logi oraz poczekaj, aż obsługiwany proces migracji zakończy się lub osiągnie stan wyraźnej awarii.
• Po ponownym uruchomieniu komputera z obrazem aktualizacji: proces może działać w innym środowisku zasobów niż oryginalny system operacyjny. Obszar wymiany widoczny przed ponownym uruchomieniem nie jest dowodem na to, że obraz aktualizacji może go wykorzystać.

Sekwencja migracji SUSE SLES 16 obejmuje przygotowanie środowiska migracyjnego, montowanie systemów plików, konfigurację sieci, przygotowanie Zyppera, aktualizację pakietów, aktualizację programu rozruchowego i ponowne uruchomienie systemu. W instrukcji podano, że błąd przed rozpoczęciem aktualizacji przywraca system do stanu pierwotnego; nie oznacza to jednak, że każdy błąd podczas wymiany pakietów jest nieszkodliwy. Zachowaj logi i unikaj ręcznego odzyskiwania systemu, dopóki nie dowiesz się, który etap zakończył się niepowodzeniem.

2. Sprawdź pamięć RAM, swap i ostatnie wiadomości jądra

Jeśli oryginalny system SLES nadal działa lub dotarłeś do powłoki odzyskiwania, zacznij od sprawdzeń tylko do odczytu:

free -h
swapon --show
vmstat 1 5
ps -eo pid,comm,rss,%mem --sort=-rss | head -n 15

free -hPodsumowuje pamięć i przestrzeń wymiany. Skup się na dostępnej pamięci i przestrzeni wymiany, a nie tylko na kolumnie „wolna”: Linux wykorzystuje w przeciwnym razie bezczynną pamięć RAM jako pamięć podręczną. vmstatPomaga to sprawdzić, czy komputer stale stronicuje. Lista procesów może ujawnić bazę danych, usługę Java, kopię zapasową lub inne obciążenie zużywające pamięć podczas aktualizacji.

Poszukaj rekordów OOM jądra w czasie wystąpienia błędu:

sudo journalctl -k --since "30 minutes ago" |
  grep -i -E 'out of memory|oom|killed process'

Jeśli błąd wystąpił wcześniej, zmień okno czasowe. Komunikat jądra wskazujący na zatrzymany proces świadczy o wystąpieniu zdarzenia braku pamięci; brak pasującego wiersza nie wyklucza wszystkich błędów alokacji. Jeśli aktualizacja odbywa się w oddzielnym środowisku produkcyjnym, sprawdź logi tego środowiska, o ile są dostępne, zamiast polegać wyłącznie na dzienniku starego systemu.

Sprawdź również, czy maszyna wirtualna, kontener lub jednostka systemd ma limit pamięci. Gość może mieć dostępną pamięć na hoście, ale nadal osiągać swój własny, skonfigurowany limit. W systemie SLES 16 firma SUSE dokumentuje cgroups v2 jako domyślną hierarchię kontroli zasobów i wyjaśnia, że ​​systemd może stosować limity zasobów. Sprawdź odpowiednią konfigurację maszyny wirtualnej lub MemoryMaxustawienia usługi zamiast losowo zwiększać globalne limity jądra. Zapoznaj się z przewodnikiem SUSE po grupach kontroli jądra w systemie SLES 16 .

3. Zmniejsz zużycie pamięci konkurującej i ponów próbę tylko w bezpiecznym punkcie

Jeśli pomiary wskazują, że obciążenie wykorzystuje większość dostępnej pamięci, zaplanuj okno konserwacyjne i zatrzymaj wszystkie nieistotne usługi przed ponowną próbą. Przykładami są aplikacje wymagające dużej ilości pamięci, zadania analityczne, testowe bazy danych i procesy tworzenia kopii zapasowych. Nie zatrzymuj bezmyślnie usług pamięci masowej, klastra ani aplikacji na hoście produkcyjnym; skorzystaj z udokumentowanej procedury wyłączania aplikacji i upewnij się, że jej zatrzymanie nie zakłóci pracy użytkowników ani zadania odzyskiwania.

W przypadku maszyny wirtualnej porównaj skonfigurowaną pamięć RAM gościa z pojemnością hosta i aktualnym zapotrzebowaniem innych gości. Jeśli gość ma zbyt mały rozmiar, zwiększ przypisaną mu pamięć, korzystając z metody obsługiwanej przez hiperwizor. Możliwość dodawania pamięci „na gorąco” zależy od hiperwizora, konfiguracji gościa i obciążenia; w razie potrzeby zaplanuj ponowne uruchomienie. W chmurze publicznej sprawdź rozmiar instancji i wszelkie limity pamięci specyficzne dla dostawcy.

Jeśli komunikat nadal się wyświetla, mimo że na komputerze jest dużo dostępnej pamięci RAM i nie ma rekordu OOM, sprawdź limity procesów. W przypadku wciąż działającego procesu, sprawdź go, /proc/PID/limitsużywając jego rzeczywistego identyfikatora. W przypadku narzędzia wspomagającego aktualizację zarządzanego przez systemd, sprawdź ustawienia zasobów jednostki. Limit może ograniczyć jeden proces, nawet gdy host ma wolną pamięć. Zmień limit tylko wtedy, gdy możesz zidentyfikować odpowiednie ustawienie i zrozumieć jego wpływ.

Po usunięciu zidentyfikowanego ograniczenia, wznów lub spróbuj ponownie tylko za pomocą metody aktualizacji obsługiwanej dla konkretnej wersji i ścieżki aktualizacji systemu SLES. W przypadku migracji z pakietem serwisowym SLES 15 należy skorzystać z udokumentowanego przepływu pracy migracji YaST lub Zypper. W przypadku migracji głównej wersji systemu SLES 16 należy postępować zgodnie z procedurą migracji dystrybucji SLES 16. Podręcznik SUSE dla systemu SLES 15 SP7 wyjaśnia przepływ pracy z pakietem serwisowym i obsługiwane wymagania wstępne dotyczące wycofania w dokumentacji aktualizacji online .

4. Rozważ dokładnie wymianę i nie traktuj jej jako rozwiązania „na ślepo”

Dodatkowa pamięć wymiany może zapewnić systemowi większy zapas pamięci wirtualnej, gdy obciążenie może stronicować pamięć, ale jest znacznie wolniejsza niż pamięć RAM. Jeśli maszyna i tak intensywnie korzysta z pamięci wymiany, dodanie większej ilości pamięci wymiany może znacznie spowolnić proces aktualizacji, nie rozwiązując problemu zbyt małej maszyny wirtualnej lub ograniczenia liczby izolowanych procesów. Najpierw sprawdź, czy pamięć wymiany istnieje i czy jest używana z swapon --show.free -h

Jeśli chcesz dodać partycję wymiany, skorzystaj z procedury SUSE dla swojej wersji systemu SLES i systemu plików. Zachowaj szczególną ostrożność w przypadku systemu Btrfs: SUSE dokumentuje ograniczenia dotyczące plików wymiany w systemie Btrfs i stwierdza, że ​​nie można utworzyć migawki, gdy plik wymiany w źródłowym podwoluminie jest aktywny. Ponieważ system SLES często korzysta z migawek Snapper do odzyskiwania systemu, nie twórz i nie aktywuj ogólnego pliku wymiany na migawkowanym podwoluminie głównym w trakcie aktualizacji. Lepiej dodać pamięć RAM lub użyć poprawnie skonfigurowanej partycji wymiany albo obsługiwanej lokalizacji po sprawdzeniu układu pamięci masowej i planu odzyskiwania. Szczegóły dotyczące konkretnego systemu plików można znaleźć w przewodniku po pamięci masowej SLES 15 SP7 firmy SUSE .

Nie zmieniaj vm.overcommit_memory, nie wyłączaj programu OOM Killer ani nie uruchamiaj dowolnego polecenia czyszczenia jako pierwszej odpowiedzi. Takie zmiany mogą ukryć symptom, zdestabilizować obciążenia lub utrudnić odzyskiwanie. Najpierw zbierz dowody i skorzystaj ze wskazówek dotyczących ustawień firmy SUSE lub dostawcy aplikacji, jeśli logi wskazują na specjalistyczną konfigurację pamięci.

5. Odzyskaj, jeśli aktualizacja została zatrzymana po rozpoczęciu zmian w pakiecie

Przed podjęciem decyzji o ponownym uruchomieniu aktualizacji należy sprawdzić, czy menedżer pakietów jest nadal aktywny i czy narzędzie migracji zgłosiło ostateczną awarię. Jeśli aktualizacja zatrzymała się po rozpoczęciu zmian w pakietach, należy zapisać pełne dane wyjściowe dziennika i zapoznać się z dokumentacją odzyskiwania dla danej wersji. Nie należy uruchamiać poleceń zypper dup, zypper migration, migracji YaST ani RPM jednocześnie.

W systemie SLES 15 SP7 firma SUSE dokumentuje wycofanie pakietu Service Pack, gdy głównym systemem plików jest Btrfs, a migawki Snapper są włączone. Procedura wycofania wymaga zidentyfikowania i przetestowania migawki sprzed migracji, a następnie trwałego wycofania; nie jest to uniwersalna metoda naprawy każdego błędu aktualizacji. Migracja do wersji głównej w systemie SLES 16 przebiega zgodnie z innym procesem, dlatego należy skorzystać z bieżących instrukcji dotyczących aktualizacji i odzyskiwania, zamiast zakładać, że procedura SLES 15 ma zastosowanie. Jeśli system ma krytyczne znaczenie dla firmy, nie ma przetestowanej kopii zapasowej lub migracja nie powiedzie się podczas wymiany pakietów, przed podjęciem próby ręcznej naprawy pakietów należy zgłosić się do pomocy technicznej SUSE.

6. Przed wznowieniem normalnej pracy sprawdź system

Gdy aktualizacja zgłosi ukończenie i serwer uruchomi się normalnie, sprawdź wydanie systemu operacyjnego i rejestrację, a następnie sprawdź spójność pakietu i obciążenie, które pierwotnie ujawniło problem:

cat /etc/os-release
sudo SUSEConnect --status
sudo zypper verify
free -h
swapon --show

Użyj polecenia package-verification obsługiwanego przez Twoją wersję SLES. Jeśli zypper verifyjest ono niedostępne lub zachowuje się inaczej w Twojej wersji, zapoznaj się zypper helpz podręcznikiem administratora tej wersji. Sprawdź logi aplikacji i jądra pod kątem nowych błędów, upewnij się, że usługi są sprawne oraz monitoruj pamięć i wymianę podczas ładowania. Przed zamknięciem okna konserwacji sprawdź, czy obsługiwany cel aktualizacji został zainstalowany oraz czy rejestracja i repozytoria serwera znajdują się w oczekiwanym stanie.

Skuteczna naprawa oznacza coś więcej niż tylko znikający komunikat o błędzie: migracja SLES kończy się z użyciem obsługiwanej ścieżki, komputer uruchamia się do oczekiwanej wersji, pakiety i rejestracja są sprawdzane, a normalne obciążenia działają bez powtarzających się zdarzeń braku pamięci (OOM). Jeśli komunikat „Nie można przydzielić pamięci” pojawia się pomimo niskiego obciążenia pamięci, wystarczającej ilości pamięci wymiany i braku limitu zasobów, należy zachować dokładne dane dziennika i procesu – to one pozwalają odróżnić błąd aktualizacji od problemu z pojemnością.