Date: Mon, 26 Jun 2006 18:55:17 -0300 (ADT) From: "Marc G. Fournier" <scrappy@hub.org> To: Max Laier <max@love2party.net> Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-stable@freebsd.org, Dmitry Morozovsky <marck@rinet.ru> Subject: Re: vmstat 'b' (disk busy?) field keeps climbing ... Message-ID: <20060626185437.I1114@ganymede.hub.org> In-Reply-To: <200606262244.25505.max@love2party.net> References: <20060624221556.O30039@woozle.rinet.ru> <20060626143038.GK79678@deviant.kiev.zoral.com.ua> <20060626152345.M1114@ganymede.hub.org> <200606262244.25505.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Jun 2006, Max Laier wrote: > On Monday 26 June 2006 20:25, Marc G. Fournier wrote: >> I think I might have found *at least* one of the problems, and that being >> the excessively high blocked states while ps isn't finding anything ... >> >> MySQL >> >> We just recently started allowing clients to run a MySQL server *within* >> their vServer ... in a drastic move, I just shut them all down on pluto, >> and blocked drop'd from ~86 down to 5 in a matter of moments ... >> restarting them all has it climbing once more, being up around 22 already >> ... >> >> I'm going to go with that theory for now, and keep an eye on things ... >> >> Just curious as to why, even with -H, its not showing any blocked states >> within ps though ... ? > > The "blocked" column shows also processes that have objects "paging". > Most likely you are *short* on memory. In order to relieve the pressure > program .text pages are free'ed and need to be refetched from disc > whenever the respective code is being executed. 'k, but shouldn't the OS be doing any swapping, if this was the case? I'm getting <1M of swappage when the blocked pages are really high ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060626185437.I1114>