Утечка памяти на VPS

[GoogleCodeExporter]

Без понятия почему, но на одном VPS у меня 
мангуст течет:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
user1    17732  252  0.9 124844  1272 ?        Sl   04:24 2751:07 ./mongoose

Он там используется только мной, я раз в час 
получаю файл, размером
примерно 20-40 мегабайт.
Также один эффект, что закачка wget-ом 
замирает и дальше не идет, пока не
оборвешь соединение и не перестартанешь с 
опцией продолжения.
У меня нсколько десятков VPS с такими же 
задачами, такое наблюдаю только здесь.
То есть это не совсем утечка, память-то 
виртуальная, но проблема в том, что
половина провайдеров используют ее для 
расчета ресурсов памяти.

What version of the product are you using? On what operating system?
~# cat /etc/debian_version
5.0.2
32-битный

Могу предоставить любую другую инфу, 
только скажите что именно

Original issue reported on code.google.com by alrond on 29 Jul 2009 at 7:47

• Merged into: #92

[GoogleCodeExporter]

Какая версия Мангуста?

Original comment by valenok on 29 Jul 2009 at 8:02

[GoogleCodeExporter]

Блин, забыл написать, с SVN-a от 25 июля

Original comment by alrond on 29 Jul 2009 at 8:09

[GoogleCodeExporter]

252% CPU? похоже на busy loop.
Можно ли собрать мангуст так (с debug info):
   COPT="-g -O0" make linux

% ulimit -c unlimited
% ./mongoose

Когда он залипнет на отдаче контента, 
послать ему SIGABRT
% kill -ABRT <pid>

С получившейся коркой сделать следующее:
% gdb mongoose core
(gdb) thread apply all bt

А то что выведется переслать сюда?

Original comment by valenok on 29 Jul 2009 at 8:18

[GoogleCodeExporter]

Да, желательно сделать sync до текущей 
версии. Там несущественные изменения, но
хочется работать с последней версией.

Original comment by valenok on 29 Jul 2009 at 8:19

[GoogleCodeExporter]

также могу пересобрать там с любыми дебаг 
опциями и запустить любые тесты.
Интересно, что процессор тоже напрягался - 
252%, 2751:07 время работы. Хотя запущен
был меньше суток.
Сейчас перегрузил и поскачивал небольшие 
одномегабайтные файлы - все нормально, VSZ в
пределах 22МБ, нагрузки на проц нет, обрывов 
при скачивании тоже нет. Посмотрю, когда
файлы станут побольше.

Original comment by alrond on 29 Jul 2009 at 8:19

[GoogleCodeExporter]

В общем удалось воспроизвести, 
действительно это работает с большими 
файлами.
Вот выдача от корки(процесс мангуста был 
32720):
Thread 3 (process 32721):
#0  0xb7f48007 in select () from /lib/libc.so.6
#1  0x08053fc3 in ?? ()
#2  0x00000005 in ?? ()
#3  0xb7e8134c in ?? ()
#4  0x00000000 in ?? ()

Thread 2 (process 7274):
#0  0xb7fce9ae in send () from /lib/libpthread.so.0
#1  0x0804ae19 in ?? ()
#2  0x00000003 in ?? ()
#3  0xb7442f2c in ?? ()
#4  0x00002000 in ?? ()
#5  0x00000000 in ?? ()

Thread 1 (process 32720):
#0  0xb7f190ac in nanosleep () from /lib/libc.so.6
#1  0xb7f18ed0 in sleep () from /lib/libc.so.6
#2  0x08054a41 in ?? ()
#3  0x00000000 in ?? ()

Original comment by alrond on 29 Jul 2009 at 8:52

[GoogleCodeExporter]

Original comment by valenok on 27 Nov 2009 at 5:17

• Changed state: Duplicate