Date: Tue, 11 Oct 2011 14:14:07 -0700 From: Artem Belevich <art@freebsd.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: =?ISO-8859-1?Q?Micka=EBl_Maillot?= <mickael.maillot@gmail.com>, Christer Solskogen <christer.solskogen@gmail.com>, freebsd-stable@freebsd.org, Ivan Voras <ivoras@freebsd.org>, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: "High" cpu usage when using ZFS cache device Message-ID: <CAFqOu6i-Z=Chpr1EFYJde-r5BBJUjXOYitoMmw0%2BB%2BNorw1B3w@mail.gmail.com> In-Reply-To: <FB4879094B814504B6375DA71A28A808@multiplay.co.uk> References: <AANLkTinzwyhABYxzWknzRFzLCbcDSd3BU2kQ5tX_SSk-@mail.gmail.com> <20101116003029.GC79816@numachi.com> <AANLkTinfTgXzf7t3PtO2VAef7NSkKWc0RnGdpv=6_-Vj@mail.gmail.com> <ibtqvp$bfq$1@dough.gmane.org> <AANLkTi=tJ-Hf%2BrMqG0=tEzNV2jJW-B_7Yu_ftW4tAMqT@mail.gmail.com> <20101116125431.GA90475@icarus.home.lan> <AANLkTi=mAWYCnWbWbX9B9fa05iyC_pivu08v-%2BbOf75f@mail.gmail.com> <AANLkTi=p9U6gK=Z5GyrAEzU2tDqbx%2ByWY=4eTZ5-0CuF@mail.gmail.com> <AANLkTi=XwO0RrU9uY5CF5p%2Bb9co1yneXX7UR2JsF55bL@mail.gmail.com> <AANLkTiknP4D5aayotFQ1jFpmov9Vv50GnFdVaXXs39rL@mail.gmail.com> <AANLkTikjd5CgcC3TEhLYuBXGukP0mUCyHtY-FwfYqs1K@mail.gmail.com> <852472071289497FA806928D0B41D0FE@multiplay.co.uk> <CAFqOu6i507j1tksV7xDYXsgUhQfp=JiKSXVnQHqM3ZQWyozG6A@mail.gmail.com> <E8A49AB737A64476892290B5866595C4@multiplay.co.uk> <CAFqOu6jUzcHrZ=wT3xxaZYUd3aQERndHbPX2Kvxy=Vk1KkryEg@mail.gmail.com> <FB4879094B814504B6375DA71A28A808@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 11, 2011 at 1:17 PM, Steven Hartland <killing@multiplay.co.uk> wrote: >> It's a bummer. If you can build your own kernel cherry-picking >> following revisions may help with long-term stability: >> r218429 - fixes original overflow causing CPU hogging by l2arc feeding >> thread. It will keep you up and running for longer until you hit >> another overflow. If I remember correctly, it will hit you around >> 100-days of uptime. > > This is the main issue we have been keeping an eye out for as we've > seen it several times, we don't have too many machines with L2ARC so > was surprised to see this with just 26 days up time in this case. > >> Following changes were done after ZFSv28 import, so they will not >> apply directly to 8-RELEASE, but the idea applies to ZFSv15 as well. >> The changes should be easy to backport. >> >> r223412 - avoids more early overflows in time routines. >> r224647 - avoids time overflow in TXG processing. > > We already maintain a custom set of patches for our 8.2 installs so > shouldn't be an issue to add these so thanks for the info :) > > With all three should we expect no uptime overflow issues or still are > we still going to look at ~100 day reboots required? Those should get you through the known (to me) sources of LBOLT and clock_t related overflows. Can't say whether you'll run into some other problems. --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFqOu6i-Z=Chpr1EFYJde-r5BBJUjXOYitoMmw0%2BB%2BNorw1B3w>