2013-02-28 2 views
1

La mémoire système est consommée par ~ 140 Mo après l'exécution du processus, mais le processus n'a pris que ~ 8 Mo. Ce processus (openttd dedicaded server) est complètement autonome (ne communique pas avec d'autres processus).La mémoire consommée et la mémoire de processus ne correspondent pas (140 Mo contre 8 Mo)

Avant

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

Après

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

Carte du processus

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 avant (trié par 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 après (trié par 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 

On dirait que la mémoire virtuelle de processus situé dans la mémoire physique, mais pourquoi? Par exemple, le processus java a 1320 Mo de mémoire virtuelle mais ne consomme que 173 Mo de réel (mathématiquement avec RES), mais le processus openttd a RES = 8 Mo mais consomme 136 Mo de mémoire réelle. Qu'est-ce que cela signifie?

UPD.

Mon serveur est basé sur OpenVZ. Openttd compilé en mode mono-threadé

Sur le vrai PC il n'y a pas de problème.

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 
+0

Est-ce que openttd est attaché à un bloc de mémoire partagée? –

+0

Je ne pense pas, parce que les sources d'openttd n'ont aucun appel aux fonctions de shm *. Peut-être que je manque quelque chose. – caiiiycuk

+0

tout mmap? Le processus est-il attaché à un fichier dans/dev/shm? –

Répondre

0

Il y a un problème dans le modèle de mémoire de OpenVZ. Quand j'appelle malloc (128 * 1024 * 1024) sur PC, la mémoire libre totale n'est pas consommée ou consommée un peu car elle n'est pas vraiment utilisée par l'application. Mais si j'appelle malloc sous OpenVZ, il consomme immédiatement 128 Mo de mémoire libre. Donc, lors de la programmation pour OpenVZ, vous ne devriez pas préallouer un énorme espace de mémoire qui ne sera pas utilisé.

Questions connexes