Error out of memory astra linux

Избегайте разрыва приложений linux-out-of-memory

Я обнаружил, что иногда в моем Linux-устройстве не хватает памяти, и он начинает срывать случайные процессы, чтобы справиться с этим.

Мне интересно, что администраторы делают, чтобы избежать этого? Является ли единственное реальное решение для увеличения объема памяти (поможет ли только подкачка?), Или есть более эффективные способы установки программного обеспечения, чтобы избежать этого? (т.е. квоты или что-то такое?).

Чтобы восстановить некое подобие здравомыслия в управлении вашей памятью:

Эти настройки приведут к тому, что Linux будет вести себя традиционным образом (если процесс запрашивает больше памяти, чем доступно, malloc () завершится с ошибкой, и ожидается, что процесс, запрашивающий память, справится с этой ошибкой).

Сервер, который обычно испытывает ошибки OOM (Out-Of-Memory), а затем, помимо опции sysctl менеджера VM (виртуальной памяти) в ядрах Linux, это не очень хорошая вещь.

Увеличение объема подкачки (виртуальной памяти, которая была выгружена на диск диспетчером памяти ядра) поможет, если текущие значения будут низкими, и использование включает в себя множество задач, каждый из которых имеет такой большой объем памяти, а не одну или несколько обрабатывает каждый запрос огромного объема доступной виртуальной памяти (RAM + swap).

Для многих приложений, выделяющих более двух раз (в 2 раза) объем оперативной памяти в качестве подкачки, снижается отдача от улучшений. В некоторых больших вычислительных симуляциях это может быть приемлемо, если замедление скорости терпимо.

С оперативной памятью (ECC или нет), которая должна быть достаточно доступной для скромных объемов, например, 4-16 ГБ, я должен признать, что я не испытывал этой проблемы сам в течение длительного времени

Без специфики приложений (например, базы данных, сервера сетевых услуг, обработки видео в реальном времени) и использования сервера (мало опытных пользователей, 100–1000 соединений пользователя / клиента), я не могу придумать какие-либо общие рекомендации в отношении работы с проблема ООМ.

Увеличение объема физической памяти не может быть эффективным ответом при любых обстоятельствах.

Это наш сервер, когда он был здоров:

Когда он работал плохо (и до того, как мы настроили overcommit_memory с 50 на 90, мы увидели бы поведение с vmcom, работающим более 50G, процессы взрыва oom-killer каждые несколько секунд, и нагрузка продолжала радикально подпрыгивать из-за взрыва дочерних процессов NFSd и воссоздан на постоянной основе.

Недавно мы дублировали случаи, когда многопользовательские терминальные серверы Linux чрезмерно перерасходовали выделение виртуальной памяти, но на самом деле очень мало запрашиваемых страниц используется.

Хотя не рекомендуется следовать этому точному маршруту, мы изменили overcommit-memory со значения по умолчанию от 50 до 90, что уменьшило некоторые проблемы. Нам пришлось переместить всех пользователей на другой сервер терминалов и перезапустить, чтобы увидеть все преимущества.

Если ваша проблема в том, что вам просто не хватает памяти для запуска необходимых вам сервисов, есть только три решения:

Уменьшите объем памяти, используемой вашими службами, ограничив кэширование и тому подобное

Создайте большую область обмена. Это будет стоить вам производительности, но может выиграть время.

Источник

Настраиваем Out-Of-Memory Killer в Linux для PostgreSQL

Когда в Linux сервер базы данных непредвиденно завершает работу, нужно найти причину. Причин может быть несколько. Например, SIGSEGV — сбой из-за бага в бэкенд-сервере. Но это редкость. Чаще всего просто заканчивается пространство на диске или память. Если закончилось пространство на диске, выход один — освободить место и перезапустить базу данных.

Out-Of-Memory Killer

Когда у сервера или процесса заканчивается память, Linux предлагает 2 пути решения: обрушить всю систему или завершить процесс (приложение), который съедает память. Лучше, конечно, завершить процесс и спасти ОС от аварийного завершения. В двух словах, Out-Of-Memory Killer — это процесс, который завершает приложение, чтобы спасти ядро от сбоя. Он жертвует приложением, чтобы сохранить работу ОС. Давайте сначала обсудим, как работает OOM и как его контролировать, а потом посмотрим, как OOM Killer решает, какое приложение завершить.

Одна из главных задач Linux — выделять память процессам, когда они ее просят. Обычно процесс или приложение запрашивают у ОС память, а сами используют ее не полностью. Если ОС будет выдавать память всем, кто ее просит, но не планирует использовать, очень скоро память закончится, и система откажет. Чтобы этого избежать, ОС резервирует память за процессом, но фактически не выдает ее. Память выделяется, только когда процесс действительно собирается ее использовать. Случается, что у ОС нет свободной памяти, но она закрепляет память за процессом, и когда процессу она нужна, ОС выделяет ее, если может. Минус в том, что иногда ОС резервирует память, но в нужный момент свободной памяти нет, и происходит сбой системы. OOM играет важную роль в этом сценарии и завершает процессы, чтобы уберечь ядро от паники. Когда принудительно завершается процесс PostgreSQL, в логе появляется сообщение:

Выбор процесса

Выполнив все эти проверки, OOM изучает оценку ( oom_score ). OOM назначает oom_score каждому процессу, а потом умножает это значение на объем памяти. У процессов с большими значениями больше шансов стать жертвами OOM Killer. Процессы, связанные с привилегированным пользователем, имеют более низкую оценку и меньше шансов на принудительное завершение.

Идентификатор процесса Postgres — 3813, поэтому в другой оболочке можно получить оценку, используя этот параметр ядра oom_score :

Принудительное завершение процесса

Как контролировать OOM-Killer

Чтобы отключить OOM-Killer, укажите значение 0 в этой же команде:

Результат этой команды сохранится не навсегда, а только до первой перезагрузки. Если нужно больше постоянства, добавьте эту строку в файл /etc/sysctl.conf :

Если установить значение 0, то когда закончится память, kernel panic не будет.

Если установить значение 1, то когда закончится память, случится kernel panic.

Для нее можно указывать следующие значения:

Источник

RPi3: out of memory error when loading Linux with UEFI+GRUB since start.elf 4.19.93 #1341

Description

Ever since the release of start.elf from commit [dc56225 — kernel: Bump to 4.19.93], attempts to boot vanilla Debian 10.3 Linux through UEFI + GRUB result in the following:

With start.elf from the previous commit [f3a973d — kernel: Bump to 4.19.89], which was released on the same day, the issue does not occur.

All subsequent releases of start.elf since 2020.01.06 produce the same issue.

This is very problematic for people trying to use the official EDK2 UEFI firmware (releases of which can be found here) as we currently always embed the latest version of start.elf which means our most recent release is affected.

To reproduce

To reproduce the issue you need to install vanilla Debian in UEFI mode, which can be carried out by following this guide or this similar guide from the Raspberry Pi forums.

You will probably want to use the files from release 1.14 to carry out the Debian/GRUB installation, since it is unaffected, before replacing start.elf on the SD card.

Expected behaviour

start.elf should not result in GRUB running out of memory and behave in the same manner as it did before the 2020.01.06 start.elf update.

System

As mentioned above, this issue manifests itself when using a fully updated vanilla Debian 10.3 on a Raspberry Pi 3 B+:

The text was updated successfully, but these errors were encountered:

There isn’t an obvious change between those points that might have caused a problem for Grub, We aren’t Grub users, let alone Grub experts, so you need to take this up with the Grub devs. If they can explain what has changed (from the viewpoint of Grub) then we have a chance of fixing it.

Thanks for replying.

We’ll be trying to investigate this from another angle (for now we’ve just reverted to using last know «good» versions of start.elf and fixup.dat in the archives we release, since it also seems that fixup.dat is also responsible for part of the issue), but we were hoping you guys might provide some insight as to what might have changed, such as an increased buffer allocation from the blobs or something, that could provide some hints.

At this stage, we’re kind of expecting any GRUB investigation to turn out with «Yes, there’s just less left over memory with recent start.elf and fixup.dat than there used to be before», at which stage we’ll have no choice but to come back to you again.

I’ll try to instrument GRUB to get a more detailed report for the cause of the error, but I would still invite you to take a second look at what might have changed between December and January in start.elf and fixup.dat that may adversely affect memory usage.

How is GRUB working out how much RAM is available? Can’t you get it to display its view of the start and end of RAM?

Okay. Up to this issue, we were always downloading the most recent version from this repo, so they should always have matched, but that’s good to know!

How is GRUB working out how much RAM is available? Can’t you get it to display its view of the start and end of RAM?

That’s what I’ll be trying to instrument. It may be a while before I’m able to do that though.

Actually, your note on fixup.dat and startup.elf needing to match made me re-test the files from our problematic archive, just to make sure that I did properly extract both and wasn’t testing with unmatched files, and I can’t seem to replicate the issue.

So it would look like I might have been testing with an unmatched pair and ran into the 128MB RAM issue.

I’m going to run some more tests to make sure, and close the issue if I can confirm that it was just due to bad testing.

I suggest that the «Out of memory» error reporting (or general diagnostics) be extended to include the RAM limits, if possible.

Источник

Предотвращаем переполнение оперативной памяти (OOM) в Linux

Я уверен, что каждый пользователь в своей жизни хоть раз сталкивался с явлением переполнения оперативной памяти или OOM (Out Of Memory). Все помнят как это происходит: система встаёт раком колом, ядро начинает грузить свопом жёсткий диск на 100%, хорошо если можно хоть курсором двигать, хотя это уже делу не поможет. В этом случае помогает только перезагрузка. А ведь мы же только Libre Office с Chromium на 2 ГБ ОЗУ запустили! Не понятно, почему ядро Linux так плохо справляется с переполнением оперативки, но с этим явлением можно успешно бороться своими силами и при минимуме накладных затрат.

В борьбе с явлением OOM нам поможет Nohang — демон для GNU/Linux, предотвращающий наступление явления переполнения оперативной памяти устройства путём принудительного завершения «прожорливого» процесса.

Принцип работы

Nohang в виде демона постоянно находится в оперативной памяти устройства (потребляет

10 Мб ОЗУ) и следит за свободным количеством оперативной памяти и своп-раздела. Как только наступает условие явной нехватки ОЗУ и свопа (эти параметры указываются в конфигурационном файле приложения) Nohang принудительно завершает «жирное» приложение, вызвавшее нехватку оперативной памяти устройства.

В качестве примера — скриншот окна монитора ресурсов KDE, на котором отображена работа демона Nohang.

На среднем графике видны факты наступления состояния OOM (переполнения памяти) ОЗУ компьютера, на котором производился эксперимент. Оперативная память накачивалась бесполезными пустыми данными с помощью команды:

Осторожно! Выполнение данной команды может привести (и без установленных утилит вроде Nohang — 100% приведёт) к переполнению оперативной памяти устройства и его зависанию, сколько бы ОЗУ в нём не было установлено!

Как видно, после первой попытки своп заполнился на 100% (в качестве свопа использовался раздел zRam) так же, как и ОЗУ, после чего Nohang прибивает процесс tail и оперативная память снова освобождается, возвращаясь к значению свободного места, которое имела до начала эксперимента. Интересно то, что своп остаётся заполненным практически на 100%, но при следующих попытках исчерпать всю доступную ОЗУ это не приводит к зависанию всей системы, и Nohang снова завершает прожорливый процесс tail, освобождаю ОЗУ. По субъективным ощущениям для пользователя, происходит кратковременное подтормаживание системы на пару секунд, после чего контроль над системой возвращается без каких-либо проблем. В общем — сказка!

Установка Nohang в различных дистрибутивах Linux

Так как не все, как я, используют в своей работе Arch Linux, рассмотрим процесс установки Nohang для всех самых популярных дистрибутивов.

Arch Linux, Manjaro Linux

Debian GNU/Linux, Ubuntu, Linux Mint

Устанавливаем из Github:

Если уведомления на рабочем столе не нужны, заменяем «sudo make install-desktop» на «sudo make install»

Fedora, RHEL, openSUSE

Настройка

Все параметры Nohang настраиваются в конфигурационном файле

В принципе, всё можно оставить как есть, параметры по-умолчанию там оптимальны для любой конфигурации железа.

Включение оповещений на рабочем столе

Чтобы включить всплывающие оповещения о нехватке ОЗУ и завершении приложений Nohang, нужно в файле конфигурации изменить следующие параметры на значение «True» чтобы получилось вот так:

После чего сохранить изменения в конфигурационном файле и перезапустить Nohang для применения новой конфигурации:

Проверка

Проверяем состояние демона Nohang:

Статус работы должен быть указан зелёным цветом:

Если так — Nohang запущен и работает нормально, можно приступать к экспериментам.

Сохраняем все несохранённые данные во всех приложениях, делаем резервные копии важных данных!

Это я на всякий случай 😏 Что ж, инициируем процесс накачки оперативной памяти пустыми данными:

И смотрим что из этого получится 😀 По идее, вы можете почувтвовать непродолжительный дискомфорт, проявляющийся в зависании системы на несколько секунд, после чего Nohang должен отработать по tail и управление системы вернётся в ваши руки. А точнее, скорее всего так и произойдёт, что можно будет считать успешным достижением поставленной цели.

Источник

Как отключить Out of memory или oom-killer в CentOS / RHEL

Что такое OOM Killer?

Убийца OOM, включенный по умолчанию, является механизмом самозащиты, использующим ядро Linux при сильном использовании памяти.

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

Если виртуальная память (VM) не может выделять память и не может поменять ее в используемой памяти, киллер может начать убивать текущие процессы из памяти в пользовательском пространстве. он пожертвует одним или несколькими процессами, чтобы освободить память для системы, когда все остальное не удастся.

Если у вас есть строка, как показано ниже в / var / log / messages:

Отключение OOM-KILLER в CentOS / RHEL

В Red Hat Enterprise Linux 5 и 6 нет возможности полностью отключить OOM-KILLER. См. Следующий раздел для настройки работы OOM-KILLER в RHEL 5 и RHEL 6.

Можно определить, какие процессы будут убиты путем корректировки оценки oom_killer.

В / proc / PID / есть два инструмента с метками oom_adj и oom_score.

Это значение используется для вычисления «плохого» процесса с использованием алгоритма, который также учитывает, как долго процесс был запущен, среди других факторов.

Чтобы увидеть текущий счет oom_killer, просмотрите oom_score для процесса.

oom_killer сначала уничтожит процессы с наивысшими баллами.

В этом примере настраивается oom_score процесса с помощью PID 12465, чтобы уменьшить вероятность того, что oom_killer убьет его.

В приведенном ниже примере oom_score возвращает значение 0, указывая, что этот процесс не будет убит.

Установка «overcommit_memory» на 2, позволяет вам быть точным в отношении избыточной памяти.

Оно указывает, что ядро никогда не будет выполнять адресное пространство, большее, чем пространство подкачки, и фракцию «overcommit_ratio» физической памяти.

Когда использование памяти попадает в этот номер, больше не должно быть никаких ассигнований.

Committed_AS в / proc / meminfo показывает текущий объем памяти в системе.

Заключение

Out of Memory (OOM) относится к вычислительному состоянию, в котором выделена вся доступная память, включая пространство подкачки.

Обычно это приведет к panic error и остановке системы.

Хотя OOM нельзя полностью отключить в CentOS / RHEL 5,6; он может быть настроен на то, чтобы определить, какие процессы будут убиты, отрегулировав счет oom_killer.

Источник

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

Я уверен, что каждый пользователь в своей жизни хоть раз сталкивался с явлением переполнения оперативной памяти или OOM (Out Of Memory). Все помнят как это происходит: система встаёт раком колом, ядро начинает грузить свопом жёсткий диск на 100%, хорошо если можно хоть курсором двигать, хотя это уже делу не поможет. В этом случае помогает только перезагрузка. А ведь мы же только Libre Office с Chromium на 2 ГБ ОЗУ запустили! Не понятно, почему ядро Linux так плохо справляется с переполнением оперативки, но с этим явлением можно успешно бороться своими силами и при минимуме накладных затрат.

В борьбе с явлением OOM нам поможет Nohang — демон для GNU/Linux, предотвращающий наступление явления переполнения оперативной памяти устройства путём принудительного завершения «прожорливого» процесса.

Принцип работы

Nohang в виде демона постоянно находится в оперативной памяти устройства (потребляет ~10 Мб ОЗУ) и следит за свободным количеством оперативной памяти и своп-раздела. Как только наступает условие явной нехватки ОЗУ и свопа (эти параметры указываются в конфигурационном файле приложения) Nohang принудительно завершает «жирное» приложение, вызвавшее нехватку оперативной памяти устройства.

В качестве примера — скриншот окна монитора ресурсов KDE, на котором отображена работа демона Nohang.

На среднем графике видны факты наступления состояния OOM (переполнения памяти) ОЗУ компьютера, на котором производился эксперимент. Оперативная память накачивалась бесполезными пустыми данными с помощью команды:

Как видно, после первой попытки своп заполнился на 100% (в качестве свопа использовался раздел zRam) так же, как и ОЗУ, после чего Nohang прибивает процесс tail и оперативная память снова освобождается, возвращаясь к значению свободного места, которое имела до начала эксперимента. Интересно то, что своп остаётся заполненным практически на 100%, но при следующих попытках исчерпать всю доступную ОЗУ это не приводит к зависанию всей системы, и Nohang снова завершает прожорливый процесс tail, освобождаю ОЗУ. По субъективным ощущениям для пользователя, происходит кратковременное подтормаживание системы на пару секунд, после чего контроль над системой возвращается без каких-либо проблем. В общем — сказка!

Установка Nohang в различных дистрибутивах Linux

Так как не все, как я, используют в своей работе Arch Linux, рассмотрим процесс установки Nohang для всех самых популярных дистрибутивов.

Arch Linux, Manjaro Linux

pacaur -S nohang-git
sudo systemctl enable --now nohang

Debian GNU/Linux, Ubuntu, Linux Mint

Устанавливаем из Github:

git clone https://github.com/hakavlad/nohang.git
cd nohang
sudo make install-desktop
sudo make systemd

Если уведомления на рабочем столе не нужны, заменяем «sudo make install-desktop» на «sudo make install»

Fedora, RHEL, openSUSE

sudo dnf copr enable atim/nohang
sudo dnf install nohang
sudo systemctl enable --now nohang

Настройка

Все параметры Nohang настраиваются в конфигурационном файле

/etc/nohang/nohang.conf

В принципе, всё можно оставить как есть, параметры по-умолчанию там оптимальны для любой конфигурации железа.

Включение оповещений на рабочем столе

Чтобы включить всплывающие оповещения о нехватке ОЗУ и завершении приложений Nohang, нужно в файле конфигурации изменить следующие параметры на значение «True» чтобы получилось вот так:

post_action_gui_notifications = True
low_memory_warnings_enabled = True

После чего сохранить изменения в конфигурационном файле и перезапустить Nohang для применения новой конфигурации:

sudo systemctl restart nohang.service

Проверка

Проверяем состояние демона Nohang:

sudo systemctl status nohang.service

Статус работы должен быть указан зелёным цветом:

Active: active (running)

Если так — Nohang запущен и работает нормально, можно приступать к экспериментам.

Это я на всякий случай 😏 Что ж, инициируем процесс накачки оперативной памяти пустыми данными:

И смотрим что из этого получится 😀 По идее, вы можете почувтвовать непродолжительный дискомфорт, проявляющийся в зависании системы на несколько секунд, после чего Nohang должен отработать по tail и управление системы вернётся в ваши руки. А точнее, скорее всего так и произойдёт, что можно будет считать успешным достижением поставленной цели.

Так же можно установить более легковесный менеджер OOM — Earlyoom.

Hi,
I’m unable to get a working linuxmint-21-cinnamon-64bit system on my Dell XPS 9550.
The USB boots and installs just fine, but when I try to start the installed system I get the out of memory message.
From what I can tell from the info and links in the release notes, that info is about how to get the USB to boot, and not so much the installed system.

There’s mentioning about the problem is coming from grub and ubuntu, but the strange thing is that I replaced a working install of Ubuntu 22.04 with this unbootable one.

Any suggestion on how to get Linux Mint 21 up and running?

System:    Host: neptune Kernel: 5.10.0-16-amd64 x86_64 bits: 64 Desktop: KDE Plasma 5.20.5 Distro: Neptune 7.5 (faye) 
Machine:   Type: Laptop System: Dell product: XPS 15 9550 v: N/A serial: <superuser required> 
           Mobo: Dell model: 0N7TVV v: A01 serial: <superuser required> UEFI: Dell v: 1.14.0 date: 02/13/2020 
Battery:   ID-1: BAT0 charge: 27.1 Wh condition: 27.3/84.0 Wh (33%) 
CPU:       Info: Quad Core model: Intel Core i7-6700HQ bits: 64 type: MT MCP L2 cache: 6 MiB 
           Speed: 800 MHz min/max: 800/3500 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 8: 800 
Graphics:  Device-1: Intel HD Graphics 530 driver: i915 v: kernel 
           Device-2: NVIDIA GM107M [GeForce GTX 960M] driver: nouveau v: kernel 
           Device-3: Sunplus Innovation Integrated_Webcam_HD type: USB driver: uvcvideo 
           Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting unloaded: fbdev,vesa resolution: 2560x1440~60Hz 
           OpenGL: renderer: Mesa Intel HD Graphics 530 (SKL GT2) v: 4.6 Mesa 20.3.5 
Audio:     Device-1: Intel 100 Series/C230 Series Family HD Audio driver: snd_hda_intel 
           Sound Server: ALSA v: k5.10.0-16-amd64 
Network:   Device-1: Broadcom BCM43602 802.11ac Wireless LAN SoC driver: brcmfmac 
           IF: wlp2s0 state: up mac: 44:1c:a8:e2:19:fb 
           IF-ID-1: mpqemubr0 state: down mac: 52:54:00:5a:db:ea 
Bluetooth: Device-1: Broadcom BCM20703A1 Bluetooth 4.1 + LE type: USB driver: btusb 
           Report: ID: hci0 state: up running bt-v: 2.1 address: 44:1C:A8:E2:19:FC 
Drives:    Local Storage: total: 953.87 GiB used: 702.29 GiB (73.6%) 
           ID-1: /dev/nvme0n1 vendor: Toshiba model: THNSN51T02DU7 NVMe 1024GB size: 953.87 GiB 
Partition: ID-1: / size: 47.76 GiB used: 29.01 GiB (60.7%) fs: ext4 dev: /dev/nvme0n1p5 
           ID-2: /boot/efi size: 496 MiB used: 192.3 MiB (38.8%) fs: vfat dev: /dev/nvme0n1p1 
           ID-3: /home size: 31.42 GiB used: 14.45 GiB (46.0%) fs: ext4 dev: /dev/nvme0n1p6 
Swap:      Alert: No Swap data was found. 
Sensors:   System Temperatures: cpu: 61.5 C mobo: N/A gpu: nouveau temp: 43.0 C 
           Fan Speeds (RPM): cpu: 3716 fan-2: 3695 
Info:      Processes: 269 Uptime: 1h 15m Memory: 31.18 GiB used: 4.15 GiB (13.3%) Shell: Bash inxi: 3.3.01