Memoria angajată în Linux este mai mică decât se aștepta

Una dintre utilizarea memoriei serverului meu Linux este ciudată. Din câte știu, memoria Committed mai mare (Committed_AS în /proc/meminfo sau kbcommit în sar -r) decât memoria utilizată de aplicație este normală. Dar memoria angajată a serverului meu este semnificativ mică.

# cat /proc/meminfo
MemTotal: 32877480 kB
MemFree: 3511812 kB
Tampoane: 19364 kB
Memorate în cache: 12080112 kB
Schimbat în cache: 0 kB
Activ: 22658640 kB
Inactiv: 5906936 kB
Activ(anon): 16460116 kB
Inactiv(anon): 6652 kB
Activ(fișier): 6198524 kB
Inactiv(fișier): 5900284 kB
Inevitabil: 0 kB
Mblocat: 0 kB
Schimb total: 0 kB
Schimb gratuit: 0 kB
Murdar: 544 kB
Scriere inversă: 4 kB
AnonPagini: 16482208 kB
Cartografiat: 17228 kB
Shmem: 672 kB
Placă: 529344 kB
SRecuperabil: 460220 kB
Sunreclaim: 69124 kB
KernelStack: 12304 kB
PageTabele: 51412 kB
NFS_Instabil: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 16438740 kB
Committed_AS: 4484680 kB
VmallocTotal: 34359738367 kB
VmallocUtilizat: 66424 kB
VmallocChunk: 34359651996 kB
Hardware corupt: 0 kB
AnonHugePagini: 15376384 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Dimensiune mare a paginii: 2048 kB
DirectMap4k: 4096 kB
DirectMap2M: 2093056 kB
DirectMap1G: 31457280 kB

După cum puteți vedea, Committed_AS este de aproximativ 4,4 GB. Dar unul dintre procese folosește mai mult de 14 GB. Acest proces nu are niciun fișier mmaped sau nicio memorie partajată.

# pidstat -r 1 1
Linux 2.6.32-696.16.1.el6.x86_64 (appintprdsearch01) 23/08/21 _x86_64_ (8 CPU)

16:56:34 PID minflt/s majflt/s VSZ RSS %MEM Command
16:56:35 414 19476,24 0,00 17260248 14356476 43,67 isc_mc
# pmap -x 414 | egrep '^Adresa|^total'
Adresă Kbytes RSS Dirty Mode Mapping
total kB 17268588 14363848 14360208
# pmap -x 414 | grep anon | awk '{s+=$3} END {print s}'
14326736

Mă întreb de ce memoria utilizată a acestui proces nu afectează memoria comisă. Este ceva ce am pierdut?

# cat /etc/system-release
Red Hat Enterprise Linux Server versiunea 6.8 (Santiago)
# uname -r
2.6.32-696.16.1.el6.x86_64

Mulțumesc anticipat!!

EDITARE: Am încercat să arăt rezultatul complet pmap -x luat astăzi. dar are 758 de linii și depășește limita postului. Deci iată rezumatul. Și am aflat că paginile sale anon devin mai mari.

# pmap -x 414 | grep -vw anon
414: /usr/local/search/sf-1v530/bin/isc_mc -license /usr/local/search/sf-1v530/license/license.xml -conf ../config/config_mc.xml -pid /usr/local /search/sf-1v530/pid/isc_mc.pid -log /usr/local/search/sf-1v530/log/isc_mc
Adresă Kbytes RSS Dirty Mode Mapping
0000000000400000 4616 1720 0 r-x-- isc_mc
0000000000a81000 1304 716 20 rw--- isc_mc
0000003c54200000 128 108 0 r-x-- ld-2.12.so
0000003c54420000 4 4 4 r---- ld-2.12.so
0000003c54421000 4 4 4 rw--- ld-2.12.so
0000003c54600000 1576 584 0 r-x-- libc-2.12.so
0000003c5478a000 2048 0 0 ----- libc-2.12.so
0000003c5498a000 16 16 8 r---- libc-2.12.so
0000003c5498e000 8 8 8 rw--- libc-2.12.so
0000003c54a00000 92 72 0 r-x-- libpthread-2.12.so
0000003c54a17000 2048 0 0 ----- libpthread-2.12.so
0000003c54c17000 4 4 4 r---- libpthread-2.12.so
0000003c54c18000 4 4 4 rw--- libpthread-2.12.so
0000003c55600000 524 80 0 r-x-- libm-2.12.so
0000003c55683000 2044 0 0 ----- libm-2.12.so
0000003c55882000 4 4 4 r---- libm-2.12.so
0000003c55883000 4 4 4 rw--- libm-2.12.so
0000003c55a00000 84 16 0 r-x-- libz.so.1.2.3
0000003c55a15000 2044 0 0 ----- libz.so.1.2.3
0000003c55c14000 4 4 4 r---- libz.so.1.2.3
0000003c55c15000 4 4 4 rw--- libz.so.1.2.3
0000003c56600000 88 16 0 r-x-- libgcc_s-4.4.7-20120601.so.1
0000003c56616000 2044 0 0 ----- libgcc_s-4.4.7-20120601.so.1
0000003c56815000 4 4 4 rw--- libgcc_s-4.4.7-20120601.so.1
0000003c57200000 928 488 0 r-x-- libstdc++.so.6.0.13
0000003c572e8000 2048 0 0 ----- libstdc++.so.6.0.13
0000003c574e8000 28 28 28 r---- libstdc++.so.6.0.13
0000003c574ef000 8 8 8 rw--- libstdc++.so.6.0.13
00007ffdcbf56000 84 48 48 rw--- [ stivă ]
---------------- ------ ------ ------
total kB 18462068 15806748 15802956

Aceasta este dimensiunea sortată a hărții anon și numărul acesteia.

# pmap -x 414 | grep -w anon | awk '{s[$2]++} END {pentru (x în s) {printare x,s[x]}}' | fel
-rnk 1
254728 1
225520 1
197220 1
196608 1
131480 2
131072 2
124008 1
65740 3
65536 142
65532 5
65528 3
65524 2
65520 1
65512 2
65508 2
65504 3
65500 3
65488 2
65484 5
65480 2
65476 1
65464 2
65456 1
65452 1
65448 2
65440 4
65436 3
65432 3
65428 2
65424 1
65420 28
65412 1
65404 1
65400 1
65372 1
65192 1
65188 1
64804 1
64636 1
63940 1
63912 1
63792 1
63584 1
63408 1
63400 2
63244 1
63008 2
63004 1
61996 1
61848 1
61792 1
61624 1
60976 1
59940 1
58276 1
57736 1
55992 1
52348 1
51212 1
50084 1
40840 1
24696 1
15452 1
14324 1
13188 1
10396 1
10240 1
9544 1
7800 1
7260 1
7064 1
5596 1
4560 1
3912 1
3744 1
3688 1
3540 1
3216 1
2532 1
2528 2
2292 1
2136 2
2128 1
1952 1
1744 1
1624 1
1596 1
1024 169
900 1
732 1
348 1
344 1
164 1
136 1
132 1
124 1
116 28
112 1
108 2
104 3
100 3
96 4
88 2
84 2
80 1
72 2
60 1
56 2
52 5
48 2
36 3
32 3
28 2
24 2
16 3
12 2
8 4
4 179

EDIT: Am solicitat asistență pentru clienți la Redhat. Mă tem că nu pot primi niciun răspuns deoarece RHEL6 a fost EOSed. Oricum voi posta aici rezultatul.

Jumătate din memoria acestei gazde este în pagini private.Cea mai mare parte este procesul pe care l-ați identificat. Committed_AS relativ scăzut la 14% din MemTotal înseamnă că încă nu se utilizează prea mult pentru datele reale.

Sistemele de operare sunt leneșe. Linux nu va atinge toți cei 14 GB solicitați de acest program. În schimb, deoarece acest procesor x86 acceptă pagini de 2 MB și 1 GB, Linux atribuie mai multe dintre acestea acestui proces și pretinde că sunt complet zero. Înștiințare DirectMap afișând multe pagini hardware de 1 GB. HugePages poate fi configurat în mod explicit de către administrator, dar acel meminfo arată zero dintre cele configurate.

Doar această alocare necesită foarte puțină memorie fizică, deci Committed_AS începe jos. Dacă și când aplicația le completează cu date reale, aceasta va crește.

În ceea ce privește planificarea capacității, în acest moment această gazdă are în prezent multă memorie. Memoria anon și partajată este limitată la jumătate, 36% stocată în cache pentru acces rapid la fișiere și câțiva GB liberi și neutilizați pentru a satisface cerințele de alocare imediată a memoriei. Și, desigur Committed_AS mult sub MemTotal

Chiar dacă alocările de memorie ale aplicației se potrivesc cu dimensiunea gazdei, aflați de ce a fost dimensionată în acest fel. Dacă aceasta este o bază de date în memorie dimensionată pentru creșterea viitoare, ar putea avea sens. Sau poate 32 GB este VM-ul tău mediu / serverul fizic de dimensiuni mici, supradimensionarea poate fi mai ușoară din punct de vedere operațional.