Размер core-dump

[Andrew]

Hello!

Хотел еще спросить про размер core-файла, т.к. недавно нарвался на
падение (которое кем-то уже описано в issur #4). Так вот - core-dump
имеет на моей машине размер аж 280 Mb, что уж как-то больно жирно. Я
понимаю, что nxweb вероятно адаптируется к обьему памяти (правда, у
меня стоит 4 GB всего), но нельзя-ли это где-то сконфигурировать. Если
можно, то где? А то немного сложно отлаживаться с такими корами.

[Yaroslav]

Погуглил насчет размера core-файла. Пишут, что он равен размеру памяти, занятой приложением (code, stack and heap). Т.е., никак особо не конфигурируется. Можно задать лимит, но это означает, что дамп получится обрезанным, т.е., нечитаемым. Лично у меня core от nxweb весит обычно порядка 6Мб. Но если открыть много соединений, то память, безусловно будет расти. Питон, если подключить, тоже увеличит потребление (у меня получается ~23Mb), равно как и ImageMagick на крупных картинках.

К доступному объему памяти nxweb никак не адаптируется. Использует ровно столько, сколько нужно для обработки поступающих соединений. Наверное стоило бы иметь конфигурируемый лимит на максимальное число одновременных соединений, но пока руки не дошли.

2013/3/12 Andrew <aje...@gmail.com>

--
Вы получили это сообщение, поскольку подписаны на группу nxweb-ru.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес nxweb-ru+u...@googlegroups.com.
Подробнее о функциях можно узнать на странице https://groups.google.com/groups/opt_out.

[Andrew]

Hello, Yaroslav!

On 12 мар, 21:18, Yaroslav <yaro...@gmail.com> wrote:
> Погуглил насчет размера core-файла. Пишут, что он равен размеру памяти,
> занятой приложением (code, stack and heap). Т.е., никак особо не
> конфигурируется. Можно задать лимит, но это означает, что дамп получится
> обрезанным, т.е., нечитаемым. Лично у меня core от nxweb весит обычно
> порядка 6Мб. Но если открыть много соединений, то память, безусловно будет
> расти. Питон, если подключить, тоже увеличит потребление (у меня получается
> ~23Mb), равно как и ImageMagick на крупных картинках.
>
> К доступному объему памяти nxweb никак не адаптируется. Использует ровно
> столько, сколько нужно для обработки поступающих соединений. Наверное
> стоило бы иметь конфигурируемый лимит на максимальное число одновременных
> соединений, но пока руки не дошли.

Да, обрезать дамп нет смысла, и он действительно равен обьему
занимаемой приложением
виртуальной памяти. Но в моем случае, даже при первом запуске, без
единого клиента
этот обьем равен 276 Мб(!). При том, что резидентной памяти занято
1328 килобайт, т.е.
чуть больше 1 Mb. Это значит, что память заказана, но реально не
использована.
Процесс содержит ~ 30 тредов.

Параметры при запуске такие:
NXWEB startup: pid=5408 net_threads=2 pg=4096 short=2 int=4 long=4
size_t=4 evt=32 conn=1092 req=164 td=1064

Хочется понять - так и должно быть, или в моей конфигурации какой-то
баг?

[Yaroslav]

Виртуалка у меня тоже большая. Но, вроде бы, это ни на чем не сказывается. И, опять же, вроде бы, не должна влиять на размер core. Размер core по идее должен соответствовать размеру RSS.

2013/3/13 Andrew <aje...@gmail.com>

[Andrew]

Hello, Yaroslav!

On 13 мар, 12:41, Yaroslav <yaro...@gmail.com> wrote:
> Виртуалка у меня тоже большая. Но, вроде бы, это ни на чем не сказывается.
> И, опять же, вроде бы, не должна влиять на размер core. Размер core по идее
> должен соответствовать размеру RSS.

Вот, выходит что нет. Нашел кое-какую информацию вот тут:
http://stackoverflow.com/questions/11734583/why-core-file-is-more-than-virtual-memory

Действительно, у меня чтоит значение 0x23 по умолчанию. Значит вся
виртуальная память
к которой даже ни разу не доступались, а только заказали - дампуется.

Ради теста написал программу из одного malloc() на 16 Mb. И все верно,
core дамп ровнехонько
16 метров и занял.

Отсюда я делаю вывод, что
либо
1. Где-то в коде nxweb напрямую заказана вся эта память.
либо
2. Какая-то из библиотэк подзаказывает память для своих нужд.

[Yaroslav]

Надо перепроверить, но сдается мне, что память, которую заняли с помощью malloc() уже совсем не виртуальная, а самая что ни есть RSS. malloc() - это вторичный аллокатор. Из ядра ОС память берется сначала с помощью mmap() или sbrk(), вот на этом этапе она еще чисто виртуальна, так как не занята ничем. Вопрос туманный. Точно могу сказать лишь одно, nxweb не аллоцирует сотни или даже десятки мегабайт памяти про запас. Наращивать виртуальную память могут библиотеки во главе с glibc.

2013/3/13 Andrew <aje...@gmail.com>

[Yaroslav]

Я наврал насчет того, что у меня core весит 6Мб. Был такой тоже, но он образовывался на самом старте при ошибке в коде инициализации. А сейчас специально спровоцировал - получилось 1.1Гб. Это сборка с питоном, ImageMagick, GNUTLS, zlib.

И это при том, что в топе показывает:

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                   

10261 ys        20   0 1735m  11m 6668 S   0.0  0.1   0:00.04 nxweb                                                     

т.е., виртуалка даже больше - 1735Мб.

Дело ясное, что дело темное. По правде сказать, меня все это мало волнует. Ради хорошего дампа мне и гигабайта диска не жалко. А реальной памяти nxweb потребляет мало (соответствует параметру RES/RSS).

2013/3/13 Yaroslav <yar...@gmail.com>

[Yaroslav]

В стандартной сборке есть специальный test-handler, который выводит в error_log статистику использования памяти malloc_stats(). Посмотрите ради любопытства:

curl -v 'http://localhost:8055/test?mstats'

curl -v 'http://localhost:8055/test?trim'

"trim" - он еще вызывает malloc_trim(1024) перед статистикой. Т.е., отдает системе все ранее запрошенные, но уже освободившиеся блоки памяти.

2013/3/13 Yaroslav <yar...@gmail.com>

[Andrew]

Hello, Yaroslav!

On 13 мар, 16:48, Yaroslav <yaro...@gmail.com> wrote:
> Я наврал насчет того, что у меня core весит 6Мб. Был такой тоже, но он
> образовывался на самом старте при ошибке в коде инициализации. А сейчас
> специально спровоцировал - получилось 1.1Гб. Это сборка с питоном,
> ImageMagick, GNUTLS, zlib.

Ok, я все перепроверил и понял вроде корень проблемы.
Разумеется, malloc() не функция системы, а лишь вызов libc, но даже он
не настолько зверский, чтобы комитить неиспользуемые страницы. Т.е.
если
вызвать после malloc() на тот же обьем еще и memset() то RSS
благополучно
сравняется с VSS. Что в общем-то логично.

Большой же отжор памяти обьясняестся тем, что каждый thread имеет
стек, и
в моем дистрибутиве это 8 Mb. Умножив на 34, как раз получаем 272
мегабайта + мелочевка.

Уменьшив размер стека по умолчанию до мегабайта, я сразу получил 40
мегабайт VSS.

[Sergey Shepelev]

Если это был первый malloc, который спровоцировал mmap/sbrk, её страницы не попадут в RSS до первой записи. malloc в неё не пишет, то есть память остаётся виртуальной. Если после malloc() сделать memset(p, 0, size) или любую другую запись в выделенную память, тут, конечно, страницы, в которые была запись, попадут в RSS.

P.S.: Очень рад, что проект развивается. Успехов и всего наилучшего.

[Andrew]

Hello, Yaroslav!

среда, 13 марта 2013 г., 16:48:33 UTC+1 пользователь Yaroslav написал:

Я наврал насчет того, что у меня core весит 6Мб. Был такой тоже, но он образовывался на самом старте при ошибке в коде инициализации. А сейчас специально спровоцировал - получилось 1.1Гб. Это сборка с питоном, ImageMagick, GNUTLS, zlib.

Возможно вы уже в курсе, но на всякий случай напишу тут...

Недавно (c GCC 4.6) появилась новая возможность - т.н. Split Stacks

(http://gcc.gnu.org/wiki/SplitStacks)

Что оно дает? По сути теперь можно заранее не заботиться о размере стека.

Он будет динамически расширен по мере надобности. Это делается опцией компиляцией

-fsplit-stack.

Например, если скомпилировать эту программу без опций и запустить с ulimit -s 64

#include <stdio.h> 

int main(int argc, char *argv[]) {

  char buffer[100000];

  printf("hello %p\n", &buffer); 

  return 0; 

}

то она очевидным образом выпадет на seg. fault.

Если же скомпилироваться с опцией -fsplit-stack, то программа

нормально отработает.

Таким образом это экономит обьем потребляемой ВИРТУАЛЬНОЙ памяти

и заодно решает мою начальную проблему с большим core dump-ом.

Собственно, я мог и раньше задать размер стека для thread-а в 64 kb

посредством ulimit -s 64, но раньше это могло привести к исчерпанию стека

и вылету thread-а на ошибку. Теперь же эта проблема решилась. 

Во всяком случае, пересобрав nxweb с этой опцией я успешно прогнал нужные мне тесты.

Как-то так. 

 

[Yaroslav]

Спасибо за полезную информацию.

Некоторое время назад вопрос про потребляемую память всплывал в англоязычной рассылке. Дело действительно в стеках. Когда тредов много, то под каждый отводится свой стек. И вот этот стек даже при равном размере в разных ОС может занимать совершенно разный объем RSS. У меня под Ubuntu RSS на стеки почти не расходуется, а на CentOS в этом плане караул. Я после того расследования сократил до нуля пул изначально стартующих "воркеров". Не всем они нужны, а когда понадобятся, будут созданы динамически.

--

Вы получили это сообщение, поскольку подписаны на группу "nxweb-ru".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес nxweb-ru+u...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Andrew]

Hello, Yaroslav!

понедельник, 31 марта 2014 г., 12:54:21 UTC+2 пользователь Yaroslav написал:

Спасибо за полезную информацию.

Некоторое время назад вопрос про потребляемую память всплывал в англоязычной рассылке. Дело действительно в стеках. Когда тредов много, то под каждый отводится свой стек. И вот этот стек даже при равном размере в разных ОС может занимать совершенно разный объем RSS. У меня под Ubuntu RSS на стеки почти не расходуется, а на CentOS в этом плане караул. Я после того расследования сократил до нуля пул изначально стартующих "воркеров". Не всем они нужны, а когда понадобятся, будут созданы динамически.

Ну, nx-web еще относительно экономно расходует thread-ы, по сравнению с некоторыми другими решениями. Когда же на каждое соединение создается свой thread а то и процесс, то получается вообще жесть.