OpenVZ Forum


Home » Mailing lists » Users » Committed_AS = 4TB
Committed_AS = 4TB [message #12697] Mon, 07 May 2007 13:27 Go to next message
Jan Tomasek is currently offline  Jan Tomasek
Messages: 44
Registered: December 2006
Member
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/
Re: Committed_AS = 4TB [message #12721 is a reply to message #12697] Tue, 08 May 2007 08:38 Go to previous messageGo to next message
Jan Tomasek is currently offline  Jan Tomasek
Messages: 44
Registered: December 2006
Member
Vasily Tarasov wrote:
> 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.

It's loooong. :) I put it on web:

http://staff.cesnet.cz/~semik/HWnodeUBC

--
-----------------------
Jan Tomasek aka Semik
http://www.tomasek.cz/
Re: Committed_AS = 4TB [message #12723 is a reply to message #12697] Tue, 08 May 2007 08:46 Go to previous message
Vasily Tarasov is currently offline  Vasily Tarasov
Messages: 1345
Registered: January 2006
Senior Member
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?
>
Previous Topic: strange problem with quota when try to install using rpm
Next Topic: Re: [Fwd: Re: strange problem with quota when try to install using rpm] *SOLVED*
Goto Forum:
  


Current Time: Wed Apr 24 07:29:19 GMT 2024

Total time taken to generate the page: 0.01379 seconds