Date: Wed, 17 Nov 2010 07:23:01 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Thierry Herbelot <thierry.herbelot@free.fr> Cc: FreeBSD virtualization mailing list <freebsd-virtualization@freebsd.org> Subject: Re: VIMAGE: Freed UMA keg was not empty Message-ID: <20101117072103.R24596@maildrop.int.zabbadoz.net> In-Reply-To: <201011170729.41894.thierry.herbelot@free.fr> References: <201011170627.28025.thierry.herbelot@free.fr> <20101117055208.S24596@maildrop.int.zabbadoz.net> <201011170729.41894.thierry.herbelot@free.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Nov 2010, Thierry Herbelot wrote:
Hi,
>> The problem has been present since day 1 and is still present up to
>> HEAD. This is about type stability and teardown. So far we are no
>> able to actually free TCP (and UDP in SVN) states as they might still
>> be accesses after "free". It's a general problem in the network stack
>> and has been implemented as a measure to circumvent panics in those
>> cases.
>>
>> I am not sure if that's actually what's biting you wrt to memory or
>> if it's something else. Unfortunately boot logs and kernel configs
>> don't help much; enable ddb and get show uma and show malloc reports
>> after the crash (or watch vmstat -z and vmstat -m) after every 50 jail
>> restarts. I might have some patches for a couple of things but cannot
>> (yet) help with the additional (duplicate) UMA zones showing up at
>> each iteration (for the -z case).
>
> The context for our problem is that VIMAGE jails are mant to be used "in
> production" for automated tests, thus are likely to be multiple on one
> physical host, and are likely to be started and stopped according to our
> needs.
>
> We have tried more "classical" virtualization solutions (qemu, kvm, ... ,
> normal jails with individual FIBs, ...) but only FreeBSD with VIMAGE seems to
> be the correct answer. (for other reasons, an i386 version of the kernel must
> be used)
>
> The point of my original email was to simplify the configuration for a test
> setup : any machine with the attached configuration file and the above
> sequence of commands creating and deleting jails, running in a loop, will
> eventually panic.
The thing you can do is start the jails persistent and then only
garbage collect proceses and network configuration manually and
reconfigure/restart things for the next iteration; you might still
leak network stack details between runs but if that's not a problem
for you the solution might work.
Regards,
Bjoern
--
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101117072103.R24596>