Перед повторной попыткой отследите ошибки памяти при обновлении SLES.

Если во время обновления SLES сообщает об ошибке «Невозможно выделить память», сначала проверьте, зафиксировало ли ядро ​​событие нехватки памяти и не исчерпаны ли оперативная память или файл подкачки. Приостановите заведомо некритическую рабочую нагрузку или увеличьте объем памяти, выделенной виртуальной машине, только после подтверждения наличия нехватки памяти, затем убедитесь, что Zypper и RPM больше не активны, прежде чем возобновлять исходную процедуру обновления.

Гипотетический пример: представьте виртуальную машину SLES 15, где администратор запускает запланированное обновление пакета во время выполнения большого пакетного задания. Zypper останавливается с ошибкой выделения памяти. Приведенный ниже пример является иллюстративным, а не описанием реального инцидента или теста; используйте команды для сбора доказательств на вашем собственном хосте, прежде чем выбирать решение.

1. Проверьте, продолжается ли обновление сервера.

Не перезагружайте систему, не завершайте процессы пакетов и не запускайте вторую команду обновления только потому, что в сеансе SSH отобразилась ошибка. Подключитесь повторно в другом сеансе и проверьте наличие активных процессов Zypper или RPM:

pgrep -a 'zypper|rpm'

Если процесс обработки пакета все еще запущен, подождите немного и изучите его вывод или журналы. Не удаляйте файлы блокировки Zypper, пока активна операция обработки пакета. Если ни один процесс не запущен, сохраните точный текст ошибки и отметьте время ее возникновения; эта метка времени поможет сопоставить журналы ядра и пакета.

2. Подтвердите или исключите проблему перегрузки памяти.

Получите актуальный снимок оперативной памяти и файла подкачки:

free -h
swapon --show
vmstat 1 5

В таблице free -hпроверьте availableстолбец, а не только отмеченное значение free; Linux также использует оперативную память для кэширования. swapon --showТаблица сообщает, существует ли файл подкачки и сколько его используется. В таблице vmstatповторяющиеся ненулевые siзначения soв последних строках указывают на активную подкачку; первая строка представляет собой среднее значение с момента загрузки, поэтому сосредоточьтесь на последующих строках.

Затем найдите событие завершения работы ядра из-за нехватки памяти (OOM) вблизи места сбоя и прочитайте лог Zypper:

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

Запись об ошибке OOM-kill, указывающая на RPM, Zypper или другой процесс, подтверждает подлинную диагностику нехватки памяти. Низкий уровень «свободной» оперативной памяти сам по себе не является достаточным основанием: кэш может быть освобожден, а сообщение также может быть результатом ограничения памяти процессом или службой. Если запись об ошибке OOM в ядре отсутствует, проверьте ограничения команды, вызвавшей ошибку, и любые ограничения памяти systemd или контейнера, прежде чем добавлять память хоста. Точную причину невозможно определить только по фразе «Невозможно выделить память».

3. Снизьте давление перед повторной попыткой.

Вернитесь к гипотетической виртуальной машине. Если пакетное задание потребляет память, и система показывает устойчивую активность в файле подкачки или ошибку нехватки памяти ядра, используйте поддерживаемую приложением процедуру паузы или остановки. Не завершайте работу базы данных, рабочей нагрузки SAP или другой службы с сохранением состояния без выполнения соответствующих действий по завершению работы оператором. Проверьте оперативную память и файл подкачки еще раз после приостановки рабочей нагрузки.

Если во время обычного обслуживания гостевой системе не хватает памяти, увеличьте выделенный ей объем оперативной памяти через поддерживаемый гипервизор или плоскость управления облаком, а затем убедитесь, что операционная система видит новый объем. Добавление файла подкачки может обеспечить временный запас памяти, но это медленнее, чем увеличение оперативной памяти, и не решает проблему постоянной нехватки памяти. Структура хранилища SLES имеет значение: например, SUSE документирует конкретные ограничения для файлов подкачки в Btrfs. Избегайте создания или изменения размера файла подкачки во время обновления, если вы не проверили требования к файловой системе, снимкам и платформе.

Если записи об ошибке нехватки памяти отсутствуют, вместо этого исследуйте ограничение, применяемое к сбойному процессу. В SLES 15 проверьте настроенное ограничение памяти для рабочей нагрузки, управляемой systemd, заменив имя тестового модуля на имя затронутой службы:

sudo systemctl show example-batch.service -p MemoryMax

Сравните это значение с доступной памятью. Ограничение cgroup не будет устранено увеличением оперативной памяти виртуальной машины, если это ограничение также не будет соответствующим образом увеличено. В более старых пакетах обновлений проверьте название свойства в документации systemd для соответствующего выпуска.

4. Возобновите поддерживаемое обновление и проверьте его.

После завершения процесса сборки пакета проверьте /var/log/zypper.logпоследнее выполненное действие и все пакеты, сборка которых завершилась с ошибкой. Если RPM или Zypper сообщают о незавершенной транзакции, перед повторной попыткой следуйте инструкциям SUSE по восстановлению для этой конкретной ошибки. Не удаляйте файлы базы данных пакетов или блокировки вручную.

Используйте тот же путь обновления, который вы начали изначально. Плановое обслуживание пакетов и миграция на пакеты обновлений — это разные операции: SUSE описывает zypper patchустановку соответствующих выпущенных исправлений, в то время как для обновлений до пакетов обновлений и основных релизов существуют свои собственные поддерживаемые пути и подготовительные действия. Не переключайтесь zypper dupпросто в качестве временного решения. Для планового запуска обновления сначала проверьте транзакцию:

sudo zypper patch --dry-run

Если тестовый запуск показывает, что план действий жизнеспособен и память стабильна, запланируйте окно технического обслуживания и выполните соответствующую команду для вашей исходной задачи. Поддерживайте доступность SSH-сессии, отслеживайте процесс и проверьте результат после завершения:

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

Успешное восстановление означает завершение установки необходимых пакетов или миграции, корректное завершение работы Zypper и отсутствие новых событий нехватки памяти (OOM) во время выполнения. Если система загружается, но необходимо отменить миграцию пакета обновлений SLES, описанный в документации SUSE механизм отката Snapper применяется только при соблюдении его требований, включая поддерживаемый корневой каталог Btrfs и настроенные снимки. Не следует рассматривать откат как стандартную реакцию на неудачную установку пакета.

Когда следует остановиться и перейти к эскалации

Если ошибка повторяется после устранения нехватки памяти, процессы пакетов по-прежнему зависают или база данных RPM сообщает о повреждении, прекратите повторные попытки. Сохраните журнал Zypper, журнал ядра, информацию о продукте и уровне пакета обновлений, а также точную использованную команду. SUSE supportconfigможет собрать диагностические данные для обращения в службу поддержки. Описанные здесь шаги помогают отличить нехватку памяти от других сбоев выделения памяти; без полных журналов и конфигурации системы они не смогут определить дефект, специфичный для конкретного продукта.

Актуальную информацию о SLES 15 SP7 можно найти в утилитах мониторинга системы SUSE , справочнике по файлам журналов , руководстве по администрированию Zypper , требованиях к файлу подкачки и Btrfs , а также в онлайн-инструкциях по обновлению и откату . Команды и пути восстановления могут различаться в зависимости от пакета обновлений SLES, архитектуры, файловой системы, а также от того, выполняется ли задача установки исправлений или миграции релиза.