[Users] Committed_AS = 4TB

Jan Tomasek jan at tomasek.cz
Mon May 7 09:27:08 EDT 2007


Hello,

my system have Committed_AS: 4253406264 kB, it is not causing any
problems (except of munin which is draving just line on zero). I found
this explanation:

# Committed_AS: An estimate of how much RAM you would need to make a
99.99% guarantee that there never is OOM (out of memory) for this
workload. Normally the kernel will overcommit memory. That means, say
you do a 1GB malloc, nothing happens, really. Only when you start USING
that malloc memory you will get real memory on demand, and just as much
as you use. So you sort of take a mortgage and hope the bank doesn't go
bust. Other cases might include when you mmap a file that's shared only
when you write to it and you get a private copy of that data. While it
normally is shared between processes. The Committed_AS is a guesstimate
of how much RAM/swap you would need worst-case.

http://www.redhat.com/advice/tips/meminfo.html

I'm having troubles to identify who allocated that much memory.

> top - 15:16:17 up 29 days,  5:02,  2 users,  load average: 7.01, 6.83, 6.66
> Tasks: 460 total,   7 running, 452 sleeping,   1 stopped,   0 zombie
> Cpu(s):  0.2%us,  1.4%sy, 76.0%ni, 22.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   8303004k total,  8146708k used,   156296k free,   334560k buffers
> Swap: 24579440k total,      196k used, 24579244k free,  6876788k cached
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                  
> 16430 semik     10 -10 1215m 1.0g 1.0g S    2 13.1 133:56.51 vmware-vmx                                                
> 10950 root      18   0 1199m  66m 5784 S    0  0.8   0:39.85 java                                                      
> 16463 semik      7 -10  533m 428m 410m S    1  5.3  58:29.35 vmware-vmx                                                
> 16446 semik      5 -10  391m 280m 266m S    5  3.5 245:58.27 vmware-vmx                                                
>  2575 www-data  21   0  225m 2936 1448 S    0  0.0   0:00.00 apache2                                                   
>  2577 www-data  21   0  225m 2928 1452 S    0  0.0   0:00.00 apache2                                                   
> 11128 25        24   0 96916  10m 2068 S    0  0.1   0:02.29 named      

rest of process have virt. mem size <<100MB.

My system has 8GB of physical RAM. Runing 2.6.18-028stab023 and VMware
Server - that might be source but... VMware workstation is not causing
this (tested on other system). Meminfo:

staj# cat /proc/meminfo
MemTotal:      8303004 kB
MemFree:        154140 kB
Buffers:        334616 kB
Cached:        6877772 kB
SwapCached:          0 kB
Active:        4035760 kB
Inactive:      3536216 kB
HighTotal:     7470840 kB
HighFree:       132144 kB
LowTotal:       832164 kB
LowFree:         21996 kB
SwapTotal:    24579440 kB
SwapFree:     24579244 kB
Dirty:             732 kB
Writeback:           0 kB
AnonPages:      359868 kB
Mapped:        1814360 kB
Slab:           464916 kB
PageTables:       9756 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:  28730940 kB
Committed_AS: 4253406264 kB
VmallocTotal:   118776 kB
VmallocUsed:     42692 kB
VmallocChunk:    75716 kB

and vzmemcheck:

> staj:/etc# vzmemcheck -v
> Output values in %
> veid        LowMem  LowMem     RAM MemSwap MemSwap   Alloc   Alloc   Alloc
>               util  commit    util    util  commit    util  commit   limit
> 233003        0.15    1.31    0.03    0.01    0.09    0.01    0.09    0.66
> 233250        1.26   11.88    0.49    0.12    0.20    0.40    0.20   38.39
> 233104        0.14   10.67    0.03    0.01    0.18    0.01    0.18   38.37
> 233103        0.17   10.67    0.03    0.01    0.18    0.01    0.18   38.37
> 233107        0.17   10.67    0.03    0.01    0.18    0.01    0.18   38.37
> 233106        0.16   10.67    0.03    0.01    0.18    0.01    0.18   38.37
> 233105        0.16   10.67    0.03    0.01    0.18    0.01    0.18   38.37
> 233102        0.18   10.67    0.03    0.01    0.18    0.01    0.18   38.37
> 233101        0.18   10.67    0.03    0.01    0.18    0.01    0.18   38.37
> 233009        0.42    9.13    0.11    0.03    0.17    0.05    0.17   38.36
> 233249        0.92   10.67    0.60    0.15    0.18    1.52    0.18   38.37
> 222119        0.44   10.67    0.12    0.03    0.18    0.05    0.18   38.37
> 233008        1.22    9.13    1.01    0.26    0.17    3.85    0.17   38.36
> 233006        1.11   10.67    1.34    0.34    0.18    0.37    0.18   38.37
> 222121        0.17    9.13    0.03    0.01    0.17    0.01    0.17   38.36
> 192002        0.24    4.64    0.04    0.01    0.12    0.01    0.12   38.31
> -------------------------------------------------------------------------
> Summary:      7.09  151.91    3.97    1.00    2.73    6.35    2.73  576.18


Does anybody know how to explain that 4TB?

-- 
-----------------------
Jan Tomasek aka Semik
http://www.tomasek.cz/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://openvz.org/pipermail/users/attachments/20070507/cde8f29c/signature.bin


More information about the Users mailing list