[devel] Поведение системы при исчерпании памяти

[devel] Поведение системы при исчерпании памяти

[Vitaly Lipatov]

Хотел поинтересоваться —  все десять лет, что я пользуюсь Linux,
наблюдаю одно и то же поведение: если программа начинает потреблять много 
памяти, то она поглощает всю свободную, потом начинается своппиннг, в этот 
момент система начинает тормозить, и если не успеть убить процесс, то система 
уходит в бесконечный своп (из которого может и выйдет минут через 30-40).
Когда-то я видел соотв. код в ядре, который достаточно наколенно определял 
виновника по ряду показателей (использование процессора, памяти и пр) и убивал 
его. Это действительно иногда происходит (видимо, елси ядро успевает 
среагировать).

Так вот, вопроса два: 

1. Действительно ли это общепринятая ситуация и все так с этим и живут?

Для сборки пакетов в связи с такими багами
https://bugzilla.altlinux.org/show_bug.cgi?id=25042
это тоже может быть актуально.

2. Есть ли мысли, что сделать с системой, чтобы она не позволяла так с собой 
обойтись?

-- 
Lav
Виталий Липатов
Россия, Санкт-Петербург. www.etersoft.ru
GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!

Re: [devel] Поведение системы при исчерпании памяти

[Konstantin Pavlov]

On Mon, Apr 04, 2011 at 06:38:00PM +0400, Vitaly Lipatov wrote:
> 2. Есть ли мысли, что сделать с системой, чтобы она не позволяла так с собой 
> обойтись?

Не использовать своп.

-- 
Konstantin Pavlov
VideoLAN team

Re: [devel] Поведение системы при исчерпании памяти

[Michael Shigorin]

On Mon, Apr 04, 2011 at 06:38:00PM +0400, Vitaly Lipatov wrote:
> 1. Действительно ли это общепринятая ситуация и все так с этим и живут?

Меня обычно устраивает -- на ноутбуках и десктопах своп обычно
<= RAM (для hibernate), на серверах памяти хватает.

> Для сборки пакетов в связи с такими багами
> https://bugzilla.altlinux.org/show_bug.cgi?id=25042
> это тоже может быть актуально.

Ну это всё-таки binutils фиксить надо, а не на OOM killer надеяться.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Поведение системы при исчерпании памяти

[Michael Shigorin]

On Mon, Apr 04, 2011 at 06:14:19PM +0300, I wrote:
> > Для сборки пакетов в связи с такими багами
> > https://bugzilla.altlinux.org/show_bug.cgi?id=25042
> > это тоже может быть актуально.
> Ну это всё-таки binutils фиксить надо, а не на OOM killer надеяться.

Или как подсказывает sr@,

overcommit_memory=2

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Поведение системы при исчерпании памяти

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

On Mon, Apr 04, 2011 at 06:38:00PM +0400, Vitaly Lipatov wrote:
> Хотел поинтересоваться —  все десять лет, что я пользуюсь Linux,
> наблюдаю одно и то же поведение: если программа начинает потреблять много 
> памяти, то она поглощает всю свободную, потом начинается своппиннг, в этот 
> момент система начинает тормозить, и если не успеть убить процесс, то система 
> уходит в бесконечный своп (из которого может и выйдет минут через 30-40).
> Когда-то я видел соотв. код в ядре, который достаточно наколенно определял 
> виновника по ряду показателей (использование процессора, памяти и пр) и убивал 
> его. Это действительно иногда происходит (видимо, елси ядро успевает 
> среагировать).
> 
> Так вот, вопроса два: 
> 
> 1. Действительно ли это общепринятая ситуация и все так с этим и живут?
> 
> Для сборки пакетов в связи с такими багами
> https://bugzilla.altlinux.org/show_bug.cgi?id=25042
> это тоже может быть актуально.
> 
> 2. Есть ли мысли, что сделать с системой, чтобы она не позволяла так с собой 
> обойтись?

Есть несколько способов лимитировать процессы и/или группы процессов по памяти.
Давно есть /etc/security/limits.conf (с некоторых пор еще и /etc/security/limits.d/),
у пользователей ovz есть ubc, ну и, наконец, теперь есть cgroups.

Можно еще поиграть с /proc/sys/vm/ на тему overcommit, см.
/usr/share/doc/kernel-doc-std-2.6.38/sysctl/vm.txt


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Поведение системы при исчерпании памяти

[REAL]

05.04.2011 05:06, Dmitry V. Levin пишет:
> Есть несколько способов лимитировать процессы и/или группы процессов по памяти.
> Давно есть /etc/security/limits.conf (с некоторых пор еще и /etc/security/limits.d/),
> у пользователей ovz есть ubc, ну и, наконец, теперь есть cgroups.

А у меня другой вопрос. Иногда при отладке непонятно, кем убить 
отлаживаемый процесс, просто gdb ограничивается немногословностью 
насчёт того, что убит child process. Как бы отследить, из-за чего и 
кем именно он убивается?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Поведение системы при исчерпании памяти

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Tue, Apr 05, 2011 at 10:48:45AM +0700, REAL wrote:
> 05.04.2011 05:06, Dmitry V. Levin пишет:
> >Есть несколько способов лимитировать 
> >процессы и/или группы процессов по 
> >памяти.
> >Давно есть /etc/security/limits.conf (с некоторых 
> >пор еще и /etc/security/limits.d/),
> >у пользователей ovz есть ubc, ну и, наконец, 
> >теперь есть cgroups.
> 
> А у меня другой вопрос. Иногда при 
> отладке непонятно, кем убить 
> отлаживаемый процесс, просто gdb 
> ограничивается немногословностью 
> насчёт того, что убит child process. Как бы 
> отследить, из-за чего и кем именно он 
> убивается?

gdb располагает соответствующей информацией.
Попробуйте выудить ее из него.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Поведение системы при исчерпании памяти

[REAL]

05.04.2011 14:23, Dmitry V. Levin пишет:
>> А у меня другой вопрос. Иногда при
>> отладке непонятно, кем убить
>> отлаживаемый процесс, просто gdb
>> ограничивается немногословностью
>> насчёт того, что убит child process. Как бы
>> отследить, из-за чего и кем именно он
>> убивается?
>
> gdb располагает соответствующей информацией.
> Попробуйте выудить ее из него.

Вот я и спрашиваю, как это сделать. backtrace ничего не показывает, 
естественно.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Поведение системы при исчерпании памяти

[Anton Farygin]

04.04.2011 18:38, Vitaly Lipatov пишет:
> 2. Есть ли мысли, что сделать с системой, чтобы она не позволяла так с собой
> обойтись?
>

overcommit настроить.

У меня на ноуте сейчас
vm.overcommit_memory = 1

Re: [devel] Поведение системы при исчерпании памяти

[Anton Farygin]

04.04.2011 19:28, Michael Shigorin пишет:
> On Mon, Apr 04, 2011 at 06:14:19PM +0300, I wrote:
>>> Для сборки пакетов в связи с такими багами
>>> https://bugzilla.altlinux.org/show_bug.cgi?id=25042
>>> это тоже может быть актуально.
>> Ну это всё-таки binutils фиксить надо, а не на OOM killer надеяться.
>
> Или как подсказывает sr@,
>
> overcommit_memory=2

2 это чревато, у меня Gnome с такой настройкой не загружается вообще.

Re: [devel] Поведение системы при исчерпании памяти

[Vitaly Lipatov]

В сообщении от Понедельник 04 апреля 2011 Konstantin Pavlov написал(a):
> On Mon, Apr 04, 2011 at 06:38:00PM +0400, Vitaly Lipatov wrote:
> > 2. Есть ли мысли, что сделать с системой, чтобы она не позволяла так с
> > собой обойтись?
> 
> Не использовать своп.
Да конечно. Без свопа примерно такая же ситуация. Похоже, что начинает 
подгружаться с диска каждая страница памяти, на которой идёт выполнения кода 
:)


-- 
Lav
Виталий Липатов
Россия, Санкт-Петербург. www.etersoft.ru
GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!

Re: [devel] Поведение системы при исчерпании памяти

[Vitaly Lipatov]

В сообщении от Вторник 05 апреля 2011 Dmitry V. Levin написал(a):
...
> Есть несколько способов лимитировать процессы и/или группы процессов по
> памяти. Давно есть /etc/security/limits.conf (с некоторых пор еще и
> /etc/security/limits.d/), у пользователей ovz есть ubc, ну и, наконец,
> теперь есть cgroups.
Ну это никак не меняет ситуацию в общем-то. Собрать несколько процессов, чтобы 
кончилась память, не так и сложно. Хотя, когда я пробовал ограничить, у меня 
получалось это только на уровне виртуальной памяти, а wine, например, 
резервирует для себя 2,6Гб адресного пространства, и если ему поставить 
предел, он просто не запустится...

> 
> Можно еще поиграть с /proc/sys/vm/ на тему overcommit, см.
> /usr/share/doc/kernel-doc-std-2.6.38/sysctl/vm.txt
Да, видимо, я смотрел в сторону чего-то такого... Буду пробовать.
http://catap.ru/blog/2009/05/05/about-memory-overcommit-memory/


Но суть в том, что по умолчанию наши системы идут незащищёнными от 
элементарной проблемы — нехватки памяти.

-- 
Lav
Виталий Липатов
Россия, Санкт-Петербург. www.etersoft.ru
GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!