[Users] Committed_AS = 4TB

Vasily Tarasov vtaras at openvz.org
Tue May 8 04:46:02 EDT 2007


Hello,

For me it seems to be strange too... Can you, please, post the output
of /proc/user_beancounters here in order to see which VE allocates so
much memory.

Thanks,
Vasily.

On Mon, 2007-05-07 at 15:27 +0200, Jan Tomasek wrote:
> 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?
> 
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://openvz.org/mailman/listinfo/users



More information about the Users mailing list