Re: VIMAGE: Freed UMA keg was not empty

2010-11-18 Thread Bjoern A. Zeeb

On Wed, 17 Nov 2010, Thierry Herbelot wrote:


As promised, here are the full logs (in attachment)

This is a serial console log showing the command loop that triggers the bug on
a debug kernel and ensuing DDB session.

the obvious problem line is :
 routetbl 2684   303890K 3469

(further tests showed an increase of the routetbl malloc zone by 4MBytes for
each vnet jail creation/destruction cycle)


Hmm, I had fixed that (somewhere).  I'll see where the patch went. You
are on 8.1-RELEASE or -STABLE?

/bz

--
Bjoern A. Zeeb  Welcome a new stage of life.
ks Going to jail sucks -- bz All my daemons like it!
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org


Re: kern/147950: [vimage] [carp] VIMAGE + CARP = kernel crash

2010-11-18 Thread bz
Synopsis: [vimage] [carp] VIMAGE + CARP = kernel crash

Responsible-Changed-From-To: bz-freebsd-virtualization
Responsible-Changed-By: bz
Responsible-Changed-When: Thu Nov 18 10:55:27 UTC 2010
Responsible-Changed-Why: 
Move it back to the list for the moment.  Easier to have all
open problems at one single point.

http://www.freebsd.org/cgi/query-pr.cgi?pr=147950
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org


Re: VIMAGE: Freed UMA keg was not empty

2010-11-18 Thread Thierry Herbelot
Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net a écrit
 On Wed, 17 Nov 2010, Thierry Herbelot wrote:
  As promised, here are the full logs (in attachment)
  
  This is a serial console log showing the command loop that triggers the
  bug on a debug kernel and ensuing DDB session.
  
  the obvious problem line is :
   routetbl 2684   303890K 3469
  
  (further tests showed an increase of the routetbl malloc zone by 4MBytes
  for each vnet jail creation/destruction cycle)
 
 Hmm, I had fixed that (somewhere).  I'll see where the patch went. You
 are on 8.1-RELEASE or -STABLE?

This will be for a -release, thus 8.1 for now, but we will switch to 8.2 ASAP

Thanks

TfH
 
 /bz
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org


Re: VIMAGE: Freed UMA keg was not empty

2010-11-18 Thread Bjoern A. Zeeb

On Thu, 18 Nov 2010, Thierry Herbelot wrote:


Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net a écrit

On Wed, 17 Nov 2010, Thierry Herbelot wrote:

As promised, here are the full logs (in attachment)

This is a serial console log showing the command loop that triggers the
bug on a debug kernel and ensuing DDB session.

the obvious problem line is :
 routetbl 2684   303890K 3469

(further tests showed an increase of the routetbl malloc zone by 4MBytes
for each vnet jail creation/destruction cycle)


Hmm, I had fixed that (somewhere).  I'll see where the patch went. You
are on 8.1-RELEASE or -STABLE?


This will be for a -release, thus 8.1 for now, but we will switch to 8.2 ASAP


Well wait; I am not sure the changes are in SVN at all.  I'll get back
to you.

/bz

--
Bjoern A. Zeeb  Welcome a new stage of life.
ks Going to jail sucks -- bz All my daemons like it!
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org


Re: VIMAGE: Freed UMA keg was not empty

2010-11-18 Thread Thierry Herbelot
Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net a écrit
 On Thu, 18 Nov 2010, Thierry Herbelot wrote:
  Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net a écrit
  
  On Wed, 17 Nov 2010, Thierry Herbelot wrote:
  As promised, here are the full logs (in attachment)
  
  This is a serial console log showing the command loop that triggers the
  bug on a debug kernel and ensuing DDB session.
  
  the obvious problem line is :
   routetbl 2684   303890K 3469
  
  (further tests showed an increase of the routetbl malloc zone by
  4MBytes for each vnet jail creation/destruction cycle)
  
  Hmm, I had fixed that (somewhere).  I'll see where the patch went. You
  are on 8.1-RELEASE or -STABLE?
  
  This will be for a -release, thus 8.1 for now, but we will switch to 8.2
  ASAP
 
 Well wait; I am not sure the changes are in SVN at all.  I'll get back
 to you.

OK for us : we are still in the process of deploying the solution, but still 
we will test any patch you can forward ;-)

TfH
 
 /bz
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org


Re: VIMAGE: Freed UMA keg was not empty

2010-11-18 Thread Dan
Brandon Gooch jamesbrandongo...@... writes:

 
 On Wed, Nov 17, 2010 at 7:17 AM, Bjoern A. Zeeb
 bzeeb-li...@... wrote:
  On Wed, 17 Nov 2010, Marko Zec wrote:
 
  Actually, we never seriously discussed or revisited the issue with
  separate
  UMA pools for each vnet instance.
 
  My original motivation when O introduced separate UMA pools was primarily
  in
  making it easier to spot resource leaks, and to prove the correctness of
  the
  whole VIMAGE / VNET thing.  Having more or less achieved those goals,
  perhaps
  the time has come to move on.  Having said that, and given that the
  current
  VIMAGE resource allocation model is far from being optimal (a lot of
  memory
  sits reserved but 99% unused, and cannot be reclaimed later on vnet
  teardown), perhaps it's time that we reconsider using unified UMA pools.
 
  I think there is a misunderstanding here;  it can be 
reclaimed by the
  time we have the teardown properly sorted out and 
it will immediately
  help normal non-VIMAGE systems under memory 
pressure as well.
  The problem is that, at least for TCP (and UDP in one special case as
  I found after lots of testing), we are no there yet.
 
  After that, when it comes to resource usage, I am still wondering how
  trasz' resource limits will plug into that.  By the time we can see
  those coming together we should be able to decide whether to go left
  or right.
 
 
 I've been running into this memory exhaustion as well, having a need
 to stop and start my VIMAGE jails frequently.
 
 I'm confident that the proper solution will be worked out, but I
 wonder what sort of time-frame we may be looking at -- is VIMAGE
 expected to be production by 9.0-RELEASE? Also, does anyone know the
 current status of trasz's work (which I believe is to be completed
 December of this year)? I hope it's still on schedule :)
 
 -Brandon
 


Hey there,

I have been experiencing a similar problem.  I am running 
Freebsd8.1 64bit Release and after closing 
my server application I come across 

this type of message
Freed UMA keg was not empty (672 items).  Lost 4 pages of 
memory

The more virtual nodes I use the more of these message I have.  
Someone told me this does not mean 
anything but after reading this it seems I should be worried.  
It does show up in my log files as well.
I wonder if running a fsck will resolve any issues after I 
have this problem?  Hopefully we can find a 
solution because I rely on my application heavily.  

Thanks,

Dan



___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org


Re: VIMAGE: Freed UMA keg was not empty

2010-11-18 Thread Bjoern A. Zeeb

On Thu, 18 Nov 2010, Dan wrote:

Hi,


I have been experiencing a similar problem.  I am running
Freebsd8.1 64bit Release and after closing
my server application I come across

this type of message
Freed UMA keg was not empty (672 items).  Lost 4 pages of
memory

The more virtual nodes I use the more of these message I have.
Someone told me this does not mean
anything but after reading this it seems I should be worried.
It does show up in my log files as well.
I wonder if running a fsck will resolve any issues after I
have this problem?  Hopefully we can find a
solution because I rely on my application heavily.


No, fsck will not help you anything; this is a memory (RAM) not a disk
storage/file system problem.

/bz

--
Bjoern A. Zeeb  Welcome a new stage of life.
ks Going to jail sucks -- bz All my daemons like it!
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org