Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Jun 2006 15:25:49 -0300 (ADT)
From:      "Marc G. Fournier" <scrappy@hub.org>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-stable@freebsd.org, Dmitry Morozovsky <marck@rinet.ru>
Subject:   Re: vmstat 'b' (disk busy?) field keeps climbing ...
Message-ID:  <20060626152345.M1114@ganymede.hub.org>
In-Reply-To: <20060626143038.GK79678@deviant.kiev.zoral.com.ua>
References:  <20060624221556.O30039@woozle.rinet.ru> <20060624152525.D1114@ganymede.hub.org> <20060625164752.H52500@woozle.rinet.ru> <20060625105843.O1114@ganymede.hub.org> <20060625211510.D52500@woozle.rinet.ru> <20060625154247.N1114@ganymede.hub.org> <20060626014210.P1114@ganymede.hub.org> <20060626014601.E1114@ganymede.hub.org> <20060626045547.GI79678@deviant.kiev.zoral.com.ua> <20060626021616.W1114@ganymede.hub.org> <20060626143038.GK79678@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

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 ... ?

Thx


On Mon, 26 Jun 2006, Kostik Belousov wrote:

> On Mon, Jun 26, 2006 at 02:20:12AM -0300, Marc G. Fournier wrote:
>> On Mon, 26 Jun 2006, Kostik Belousov wrote:
>>
>>> Yes, this looks like a deadlock. As I understand, that's on 6.1-STABLE ?
>>
>> Yes, kernel sources, it seems, from May 25th, according to my /usr/src
>> tree ...
>>
>>> BTW, do you use snapshots ?
>>
>> Not that I've explicitly enabled ...
>>
>>> I think that without ddb access, diagnose and debug the problem would be
>>> quite hard.
>>
>> Would it be a simple matter of:
>>
>> CTL-ALT-ESC
>> panic
>>
>> to get it to dump core?  Or would more be involved?  Would a core dump
>> even work?
> Core dumps are somewhat unconvenient in this situation. Better,
> sending report to me, follow my advise in
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
>

----
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?20060626152345.M1114>