* [devel] Поведение системы при исчерпании памяти
@ 2011-04-04 14:38 Vitaly Lipatov
2011-04-04 14:41 ` Konstantin Pavlov
` (3 more replies)
0 siblings, 4 replies; 12+ messages in thread
From: Vitaly Lipatov @ 2011-04-04 14:38 UTC (permalink / raw)
To: ALT Linux Team development discussions
Хотел поинтересоваться — все десять лет, что я пользуюсь 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!
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [devel] Поведение системы при исчерпании памяти
2011-04-04 14:38 [devel] Поведение системы при исчерпании памяти Vitaly Lipatov
@ 2011-04-04 14:41 ` Konstantin Pavlov
2011-04-05 14:12 ` Vitaly Lipatov
2011-04-04 15:14 ` Michael Shigorin
` (2 subsequent siblings)
3 siblings, 1 reply; 12+ messages in thread
From: Konstantin Pavlov @ 2011-04-04 14:41 UTC (permalink / raw)
To: devel
On Mon, Apr 04, 2011 at 06:38:00PM +0400, Vitaly Lipatov wrote:
> 2. Есть ли мысли, что сделать с системой, чтобы она не позволяла так с собой
> обойтись?
Не использовать своп.
--
Konstantin Pavlov
VideoLAN team
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [devel] Поведение системы при исчерпании памяти
2011-04-04 14:41 ` Konstantin Pavlov
@ 2011-04-05 14:12 ` Vitaly Lipatov
0 siblings, 0 replies; 12+ messages in thread
From: Vitaly Lipatov @ 2011-04-05 14:12 UTC (permalink / raw)
To: ALT Linux Team development discussions
В сообщении от Понедельник 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!
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [devel] Поведение системы при исчерпании памяти
2011-04-04 14:38 [devel] Поведение системы при исчерпании памяти Vitaly Lipatov
2011-04-04 14:41 ` Konstantin Pavlov
@ 2011-04-04 15:14 ` Michael Shigorin
2011-04-04 15:28 ` Michael Shigorin
2011-04-04 22:06 ` Dmitry V. Levin
2011-04-05 7:58 ` Anton Farygin
3 siblings, 1 reply; 12+ messages in thread
From: Michael Shigorin @ 2011-04-04 15:14 UTC (permalink / raw)
To: ALT Linux Team development discussions
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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [devel] Поведение системы при исчерпании памяти
2011-04-04 14:38 [devel] Поведение системы при исчерпании памяти Vitaly Lipatov
2011-04-04 14:41 ` Konstantin Pavlov
2011-04-04 15:14 ` Michael Shigorin
@ 2011-04-04 22:06 ` Dmitry V. Levin
2011-04-05 3:48 ` REAL
2011-04-05 17:16 ` Vitaly Lipatov
2011-04-05 7:58 ` Anton Farygin
3 siblings, 2 replies; 12+ messages in thread
From: Dmitry V. Levin @ 2011-04-04 22:06 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [devel] Поведение системы при исчерпании памяти
2011-04-04 22:06 ` Dmitry V. Levin
@ 2011-04-05 3:48 ` REAL
2011-04-05 7:23 ` Dmitry V. Levin
2011-04-05 17:16 ` Vitaly Lipatov
1 sibling, 1 reply; 12+ messages in thread
From: REAL @ 2011-04-05 3:48 UTC (permalink / raw)
To: ALT Linux Team development discussions
05.04.2011 05:06, Dmitry V. Levin пишет:
> Есть несколько способов лимитировать процессы и/или группы процессов по памяти.
> Давно есть /etc/security/limits.conf (с некоторых пор еще и /etc/security/limits.d/),
> у пользователей ovz есть ubc, ну и, наконец, теперь есть cgroups.
А у меня другой вопрос. Иногда при отладке непонятно, кем убить
отлаживаемый процесс, просто gdb ограничивается немногословностью
насчёт того, что убит child process. Как бы отследить, из-за чего и
кем именно он убивается?
--
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [devel] Поведение системы при исчерпании памяти
2011-04-05 3:48 ` REAL
@ 2011-04-05 7:23 ` Dmitry V. Levin
2011-04-05 7:31 ` REAL
0 siblings, 1 reply; 12+ messages in thread
From: Dmitry V. Levin @ 2011-04-05 7:23 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [devel] Поведение системы при исчерпании памяти
2011-04-05 7:23 ` Dmitry V. Levin
@ 2011-04-05 7:31 ` REAL
0 siblings, 0 replies; 12+ messages in thread
From: REAL @ 2011-04-05 7:31 UTC (permalink / raw)
To: ALT Linux Team development discussions
05.04.2011 14:23, Dmitry V. Levin пишет:
>> А у меня другой вопрос. Иногда при
>> отладке непонятно, кем убить
>> отлаживаемый процесс, просто gdb
>> ограничивается немногословностью
>> насчёт того, что убит child process. Как бы
>> отследить, из-за чего и кем именно он
>> убивается?
>
> gdb располагает соответствующей информацией.
> Попробуйте выудить ее из него.
Вот я и спрашиваю, как это сделать. backtrace ничего не показывает,
естественно.
--
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [devel] Поведение системы при исчерпании памяти
2011-04-04 22:06 ` Dmitry V. Levin
2011-04-05 3:48 ` REAL
@ 2011-04-05 17:16 ` Vitaly Lipatov
1 sibling, 0 replies; 12+ messages in thread
From: Vitaly Lipatov @ 2011-04-05 17:16 UTC (permalink / raw)
To: ALT Linux Team development discussions
В сообщении от Вторник 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!
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [devel] Поведение системы при исчерпании памяти
2011-04-04 14:38 [devel] Поведение системы при исчерпании памяти Vitaly Lipatov
` (2 preceding siblings ...)
2011-04-04 22:06 ` Dmitry V. Levin
@ 2011-04-05 7:58 ` Anton Farygin
3 siblings, 0 replies; 12+ messages in thread
From: Anton Farygin @ 2011-04-05 7:58 UTC (permalink / raw)
To: ALT Linux Team development discussions
04.04.2011 18:38, Vitaly Lipatov пишет:
> 2. Есть ли мысли, что сделать с системой, чтобы она не позволяла так с собой
> обойтись?
>
overcommit настроить.
У меня на ноуте сейчас
vm.overcommit_memory = 1
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-04-05 17:16 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-04 14:38 [devel] Поведение системы при исчерпании памяти Vitaly Lipatov
2011-04-04 14:41 ` Konstantin Pavlov
2011-04-05 14:12 ` Vitaly Lipatov
2011-04-04 15:14 ` Michael Shigorin
2011-04-04 15:28 ` Michael Shigorin
2011-04-05 7:58 ` Anton Farygin
2011-04-04 22:06 ` Dmitry V. Levin
2011-04-05 3:48 ` REAL
2011-04-05 7:23 ` Dmitry V. Levin
2011-04-05 7:31 ` REAL
2011-04-05 17:16 ` Vitaly Lipatov
2011-04-05 7:58 ` Anton Farygin
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git