IRC log for #fredlug on 20071214

04:26.07*** join/#fredlug plarsen (n=plarsen@72-255-9-126.client.stsn.net)
05:05.55*** join/#fredlug nombyte (n=nomb@c-71-62-193-105.hsd1.va.comcast.net)
05:37.57sticksterWow, people are on late tonight!
05:53.58nombyteim always up late
06:03.16sticksterNot me.
06:03.20nombyte;d
06:03.24sticksterTomorrow is a day off though
06:03.27nombytenice
06:03.33sticksterBut I'm about done with work for tonight
06:03.45nombyteits always nice to relax
06:06.42sticksterG'night!
06:30.57plarsennight ;)
12:35.43*** join/#fredlug nombyte (n=nomb@c-71-62-193-105.hsd1.va.comcast.net) [NETSPLIT VICTIM]
14:09.45*** join/#fredlug plarsen (n=plarsen@208.176.91.226.ptr.us.xo.net)
14:09.58plarsengood morning!
14:13.55*** join/#fredlug jsmith_ (i=jsmith@nat/digium/x-1c8f5b4c40d7c9f1)
15:15.34sticksterwoohoo!
15:39.17*** join/#fredlug jsmith (i=jsmith@nat/digium/x-feac43641f867c03)
15:56.09plarsenstickster: well, your suggestions didn't work; sorry :)
15:56.14plarsenBut nice try ;)
15:56.56sticksterSo I'm sure this has somethng to do with the OOM-killer in the 2.6 kernel
15:58.12sticksterplarsen: But that PDF link I gave you probably has the answer buried in it somewhere.  It sounds like your low memory is being exhausted.
15:58.35sticksterplarsen: Do those machines have the "lm" flag in their /proc/cpuinfo?
16:01.00plarsenstickster: well, that's the issue. I don't see a memory exhaustion on the OOM dump. Do you?
16:01.09sticksterNope.
16:01.34sticksterplarsen: How about that "lm" flag?
16:01.35plarsenyep - both (dual) cpu's have lom
16:01.37plarsenlm*
16:01.45sticksterplarsen: So they could be running 64-bit then.
16:02.04plarsenthose are 64 bit processors; however these VMs are set for 32.
16:02.13plarsenThe kernel is NOT a 64 bit kernel
16:02.32sticksterSo these are guests having the problem?
16:02.37plarsenBesides this stuff WORKED for months without a hickup
16:02.42plarsenyes
16:02.51plarsenI think it's a VMware issue
16:02.54plarsenbut I'm not sure
16:02.56sticksterI'm pretty sure that's the case.
16:03.11sticksterThis turned up a LOT of googlejuice, so you're not alone.
16:03.25sticksterWhat VMWare Server are you running?
16:03.29plarsenESX 3
16:05.59sticksterSo give the rundown:  Host RAM, Guest RAM
16:06.11sticksterHost OS, Guest OS
16:06.34sticksterplarsen: I think I missed some of those details before.
16:10.40plarsenESX is not reporting memory exhaustion. Host 13GB, Guest 4GB.
16:10.45plarsenHost OS = ESX
16:10.51plarsenGuest OS = RHES4
16:11.42sticksterI haven't ever run ESX -- it provides its own kernel and the rest of the OS stack on its own?
16:14.07plarsenyup
16:14.11sticksterInteresting!
16:14.13plarsenThat's the point of it.
16:14.31sticksterhttp://losalamos.redhawk.org/index.php/content/view/65/9/
16:15.03sticksterI know that link is for 64-bit, but you should check it out anyway.
16:16.18sticksterhttp://www.vmware.com/resources/techresources/531
16:16.57plarsenInteresting ... well, the note itself doesn't mention 64bit; and if you look at the OOM DMA is the only one where the flag all_unreclaimable is set for yes
16:17.32plarsenLast one is way old ;)
16:30.00plarsenhmmmm - looks like it slows down the VMs when you enable the memory gab
16:33.15sticksterThe one other thing that I saw that might be applicable was resetting the kernel's overcommit policy to "2" or "don't do it when it would exceed the ratio in overcommit_ratio."
16:33.28sticksterYou might want to back out of any other changes and see how that affects performance.
16:33.59plarsenall the /proc/sys/vm changes have been "cleared"
16:34.11sticksterRight-o then
17:32.37plarsenwell, it's been holding up for 45 minutes now ;)
17:53.45plarsenDamn - I jinxed it!!!
18:52.46*** join/#fredlug jsmith (i=jsmith@nat/digium/x-09adf725cf47c940)
20:23.16*** join/#fredlug nombyte (n=nomb@c-71-62-193-105.hsd1.va.comcast.net)
22:23.20*** join/#fredlug jsmith (i=jsmith@nat/digium/x-c6dc1ada2a38ae9e)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.