Is the amount of memory used by the process significantly less than the reduction in free memory (8Mb vs 160Mb)?

Question

linux

Free memory is reduced by 160MB after the process is started, the process itself takes up only 8MB in memory. The process (openttd dedicaded server) is completely autonomous (it does not interact with other processes).
Before:
free -m
total used free shared buffers cached
Mem: 1000 777 222 0 0 0
-/+ buffers/cache: 777 222
Swap: 0 0 0
After:
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 RX-- OpenTD_1.2.3
0000000000AEE000 0 64 48 RW --- OpenTD_1.2.3
0000000000AFe000 0 588 584 RW --- [ANON]
000000001C66D000 0 2516 2516 RW [ anon ]
00002ba83f5a7000 0 100 0 rx-- 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 rwx-- libstdc++.so.6.0.13 0 --d-b++ st80f0f0
--d -b++ 00002ba83f0f0 .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---
0 fa03 52 0 rx-- libpthread-2.11.3.so
00002ba83faf2000 0 0 0 ----- libpthread-2.11.3.so
00002ba83fcf1000 0 4 4 r---- libpthread-2.11.3.so
[ anon
]
_
-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 rx-- 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.10 0070
2dba 16 16 rw--- [ anon ]
00002Ba8402DC000 0 16 0 RX-- 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
] ---------- ------ ------ ------ total kB 162884 8048 3952 top to (RES sort):
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 beamdata
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
09.46 plackup
32303 www-data 15 0 250m 32m 6364 S 0.3 3.3 17:54.92 mongod
24324 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 after (RES sort):
PID USER PR NI VIRT RESPU % S %C 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.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
It seems that the virtual memory of the process is located in the physical memory. But for example, java has a virtual memory size of 1360MB, but in reality it is used 173MB (which is the same as RES). However, with openttd, on the contrary, RES=8Mb and it takes 136Mb of physical space, why is it so, how to deal with it?

Answer 1

> openvz virtualization
This is what should have started. In OpenVZ, memory is somehow strangely considered, it considers all the virtual space that is allocated to the process. And since Linux programs usually allocate memory in a myriad of ways and without any logic, all of it is counted as busy. For example, if you have a multi-threaded program like Apache, say, of 20 threads, then in OpenVZ each thread immediately allocates 8 MB for the stack, and this is already considered as 160 MB of memory (while on a real piece of hardware 8 MB is only maximum size, but allocated as much as actually used, i.e. much less). At the same time, software developers, of course, did not count on such a scenario, and they are not taking any measures to reduce the allocated virtual space. And you have to arrange dances with ulimit in order to somehow improve the situation.
Here's an example: www.webhostingtalk.com/showthread.php?t=855618
I suggest you try a Xen-based virtual machine versus a physical machine for comparison. You will immediately have all the numbers in line. OpenVZ allows the host to sell more memory than they have in the server, and this is a very opaque thing. I do not recommend using this technique.

Answer 2

Some weird output from free: why does "-/+ buffers/cache" match "mem"?
Maybe it would be better to compare cat /proc/meminfo before and after?

Answer 3

Maybe the vanishing memory is some kind of ram disk? Those. The program creates some temporary files there.