Количество памяти занятой процессом значительно меньше чем уменьшение свободной памяти (8Мб vs 160Мб)?

Question

[Caiiiycuk]

Свободная память уменьшаяется на 160Мб после запуска процесса, сам процесс заниамет в памяти всего 8Мб. Процесс (openttd dedicaded server) полностью автономен (он не взаимодействует с другими процессами).


До:


free -m
total used free shared buffers cached
Mem: 1000 777 222 0 0 0
-/+ buffers/cache: 777 222
Swap: 0 0 0



После:


free -m
total used free shared buffers cached
Mem: 1000 913 86 0 0 0
-/+ buffers/cache: 913 86
Swap: 0 0 0



Process map:


pmap 18428 -x
18428: /var/www/ttd-server/openttd_1.2.3 -s null -m null -x -c /var/www/ttd-server/configuration/preload/openttd.cfg -D
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 0 2948 0 r-x-- openttd_1.2.3
0000000000aee000 0 64 48 rw--- openttd_1.2.3
0000000000afe000 0 588 584 rw--- [ anon ]
000000001c66d000 0 2516 2516 rw--- [ anon ]
00002ba83f5a7000 0 100 0 r-x-- ld-2.11.3.so
00002ba83f5c5000 0 256 256 rw--- [ anon ]
00002ba83f7c4000 0 4 4 r---- ld-2.11.3.so
00002ba83f7c5000 0 4 4 rw--- ld-2.11.3.so
00002ba83f7c6000 0 4 4 rw--- [ anon ]
00002ba83f7c7000 0 380 0 r-x-- libstdc++.so.6.0.13
00002ba83f8bd000 0 0 0 ----- libstdc++.so.6.0.13
00002ba83fabd000 0 28 28 r---- libstdc++.so.6.0.13
00002ba83fac4000 0 8 8 rw--- libstdc++.so.6.0.13
00002ba83fac6000 0 4 4 rw--- [ anon ]
00002ba83fadb000 0 52 0 r-x-- libpthread-2.11.3.so
00002ba83faf2000 0 0 0 ----- libpthread-2.11.3.so
00002ba83fcf1000 0 4 4 r---- libpthread-2.11.3.so
00002ba83fcf2000 0 4 4 rw--- libpthread-2.11.3.so
00002ba83fcf3000 0 8 8 rw--- [ anon ]
00002ba83fcf8000 0 112 0 r-x-- libm-2.11.3.so
00002ba83fd78000 0 0 0 ----- libm-2.11.3.so
00002ba83ff78000 0 4 4 r---- libm-2.11.3.so
00002ba83ff79000 0 4 4 rw--- libm-2.11.3.so
00002ba83ff7a000 0 460 0 r-x-- libc-2.11.3.so
00002ba8400d3000 0 0 0 ----- libc-2.11.3.so
00002ba8402d2000 0 16 16 r---- libc-2.11.3.so
00002ba8402d6000 0 4 4 rw--- libc-2.11.3.so
00002ba8402d7000 0 16 16 rw--- [ anon ]
00002ba8402dc000 0 16 0 r-x-- libgcc_s.so.1
00002ba8402f2000 0 0 0 ----- libgcc_s.so.1
00002ba8404f1000 0 4 4 rw--- libgcc_s.so.1
00002ba8404f2000 0 104 104 rw--- [ anon ]
00002ba848565000 0 284 284 rw--- [ anon ]
00007fff900e4000 0 44 44 rw--- [ stack ]
00007fff901fd000 0 8 0 r-x-- [ anon ]
ffffffffff600000 0 0 0 ----- [ anon ]
---------------- ------ ------ ------
total kB 162884 8048 3952



top до (сортировка RES):


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15801 www-data 17 0 1320m 173m 4036 S 1.3 17.4 0:54.75 java
1518 ejabberd 15 0 99684 54m 3724 S 0.0 5.5 18:05.64 beam
7917 www-data 15 0 124m 47m 2204 S 0.0 4.8 0:02.43 plackup
8039 www-data 15 0 123m 46m 2204 S 0.0 4.7 0:02.38 plackup
32439 www-data 15 0 116m 42m 2812 S 0.0 4.2 0:42.54 plackup
29708 mysql 15 0 170m 38m 7556 S 0.0 3.9 187:51.36 mysqld
32247 www-data 15 0 141m 38m 3376 S 0.0 3.8 0:08.01 plackup
6025 www-data 15 0 176m 37m 4532 S 0.0 3.7 0:06.17 php-cgi
3248 www-data 15 0 172m 33m 4544 S 0.0 3.4 0:10.55 php-cgi
3591 www-data 15 0 123m 32m 3080 S 0.0 3.3 9:09.46 plackup
32303 www-data 15 0 250m 32m 6364 S 0.3 3.3 17:54.92 mongod
24324 send2me 16 0 53340 14m 3088 S 0.0 1.5 0:03.00 perl
26584 bind 25 0 93800 11m 2352 S 0.0 1.1 0:00.17 named
20045 root 15 0 110m 9288 6876 S 0.0 0.9 2:18.20 ispmgr
15574 www-data 18 0 144m 9168 5732 S 0.0 0.9 0:00.07 php-cgi
30220 www-data 15 0 37420 9148 2936 S 0.0 0.9 1:29.11 websockify.py
9935 root 16 0 83864 3688 2856 S 0.0 0.4 0:00.02 sshd



top после (сортировка RES):


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15801 www-data 17 0 1320m 173m 4036 S 1.3 17.4 0:53.77 java
1518 ejabberd 15 0 99684 54m 3724 S 0.0 5.5 18:05.62 beam
7917 www-data 15 0 124m 47m 2204 S 0.0 4.8 0:02.42 plackup
8039 www-data 15 0 123m 46m 2204 S 0.0 4.7 0:02.37 plackup
32439 www-data 15 0 116m 42m 2812 S 0.0 4.2 0:42.54 plackup
29708 mysql 15 0 170m 38m 7556 S 0.0 3.9 187:51.34 mysqld
32247 www-data 15 0 141m 38m 3376 S 0.0 3.8 0:08.01 plackup
6025 www-data 15 0 176m 37m 4532 S 0.0 3.7 0:06.17 php-cgi
3248 www-data 15 0 172m 33m 4544 S 0.0 3.4 0:10.55 php-cgi
3591 www-data 15 0 123m 32m 3080 S 0.0 3.3 9:09.44 plackup
32303 www-data 15 0 250m 32m 6364 R 0.3 3.3 17:54.61 mongod
24324 send2me 16 0 53340 14m 3088 S 0.0 1.5 0:03.00 perl
26584 bind 25 0 93800 11m 2352 S 0.0 1.1 0:00.17 named
20045 root 15 0 110m 9288 6876 S 0.0 0.9 2:18.19 ispmgr
15574 www-data 18 0 144m 9168 5732 S 0.0 0.9 0:00.07 php-cgi
30220 www-data 15 0 37420 9148 2936 S 0.0 0.9 1:29.11 websockify.py

18428 www-data 16 0 151m 8048 4096 R 0.0 0.8 0:00.30 openttd_1.2.3

9935 root 16 0 83864 3688 2856 S 0.0 0.4 0:00.02 sshd



Кажется что виртуальная память процесса распологается в физической памяти. Но например, у java размер виртуальной памяти 1360Мб, а реально она используется 173Мб (что совпадает с RES). Однако с openttd наоборот, RES=8Мб а занимает 136Мб физической, почему так, как бороться?

Comments

[Caiiiycuk]

Виртуализация openvz.
openttd server скомпилирован в однопоточном режиме.

caiiiycuk@zoo:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 128
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

[Caiiiycuk]

На реальном железе такой проблемы нет

Answer 1

[egorinsk]

> Виртуализация openvz

C этого и надо было начинать. В OpenVZ как-то странно считается память, там считается все виртуальное пространство, которое выделено процессу. А поскольку линуксовые программы обычно выделяют память в несметном количестве и без всякой логики, вся она учитывается как занятая. Например, если у вас есть многопоточная программа вроде Апача, допустим, из 20 потоков, то в OpenVZ каждый поток сразу выделяет под стек 8 Мб, и это уже считается как 160 Мб памяти (в то время как на реальной железке 8 Мб — это лишь максимальный размер, а выделяется столько, сколько по факту использовано, т.е. намного меньше). При этом разработчики программ, естественно, на такой сценарий не рассчитывали, и никаких мер по снижению выделяемого виртуального пространства не предпринимают. И вам приходится устраивать пляски с ulimit, чтобы хоть как-то улучшить ситуацию.

Вот например: www.webhostingtalk.com/showthread.php?t=855618

Я вам советую попробовать для сравнения виртуальную машину на основе Xen или физическую машину. У вас сразу все цифры придут в соответствие. OpenVZ позволяет хостеру продавать больше памяти, чем у него есть в сервере, и это очень непрозрачная вещь. Не советую использовать эту технологию.

Comments

[Caiiiycuk]

Спасибо за ответ. Но у меня однопоточный сервер, а ulimit стоит 128kb. OpenVZ на год проплачен так что сменить не получится. Зато есть исходный код, в который я могу поправить только не могу понять в чем затык.

caiiiycuk@zoo:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 128
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

[Caiiiycuk]

Вы правы на реальной машине такой проблемы нет, свободная память уменьшаяется на 4Мб. Неужели ничего нельзя сделать? На какие участки кода стоит обратить внимание?

[egorinsk]

Это может быть дело не только в вашем коде, а, например, какая-нибудь из библиотек выделяет себе при инициализации эти виртуальные 160 мегабайт. У вас в выводе pmap во второй колонке нули, если вы знаете, как их отобразить, тогда можно было бы и посмотреть, кто именно забирает это пространство.

Или альтернативный вариант — отладка — отслеживайте системные вызовы через утилиту strace или подобную и смотрите, в какой момент и кто выделяет память, или запускайте программу в режиме отладки пошагово и следите за выделением памяти, или поставьте перехват на функции выделения памяти (mmap, brk, что еще?) и следите, в какой момент она выделяется.

[Caiiiycuk]

Нашел проблемное место, — кэш карты. Проблема была в одной строчке malloc(128 * 1024 * 1024)
Вы оказались правы, на реальной машине после вызова malloc реальная свободная память практически не уменьшается в размерах. В то время как на OpenVZ отъедаются те самые 128мб. Спасибо большое за помощь, а с OpenVZ нужно съезжать.

Answer 2

[jcmvbkbc]

Какой-то стрёмный вывод у free: почему "-/+ buffers/cache" совпадает с «mem»?
Может лучше было бы сравнить cat /proc/meminfo до и после?

Comments

[egorinsk]

> почему "-/+ buffers/cache" совпадает с «mem»

Очевидно, потому, что buffers/cache = 0. Хотя не очень понятно, как автор добился такого эффекта.

[jcmvbkbc]

Да, похоже на работу в initramfs

[Caiiiycuk]

Виртуализация openvz поэтому buffers/cache = 0.

[jcmvbkbc]

А в /proc/meminfo вы таки заглянуть не хотите?

[Caiiiycuk]

До

MemTotal:      1024000 kB
MemFree:        228192 kB
LowTotal:      1024000 kB
LowFree:        228192 kB
Hugepagesize:     2048 kB

Остальное по нулям.

После

MemTotal:      1024000 kB
MemFree:         87912 kB
LowTotal:      1024000 kB
LowFree:         87912 kB
Hugepagesize:     2048 kB

Остальное по нулям.

[jcmvbkbc]

Даа, печальная картина.

Answer 3

[egorinsk]

Может, исчезающая память — это какой-нибудь ram disk? Т.е. программа создает там временные файлы какие-нибудь.

Comments

[Caiiiycuk]

Не замечено такого и shared memory не алоцируется и не используется.