Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Jun 2006 22:44:18 +0200
From:      Max Laier <max@love2party.net>
To:        freebsd-stable@freebsd.org
Cc:        Kostik Belousov <kostikbel@gmail.com>, Dmitry Morozovsky <marck@rinet.ru>
Subject:   Re: vmstat 'b' (disk busy?) field keeps climbing ...
Message-ID:  <200606262244.25505.max@love2party.net>
In-Reply-To: <20060626152345.M1114@ganymede.hub.org>
References:  <20060624221556.O30039@woozle.rinet.ru> <20060626143038.GK79678@deviant.kiev.zoral.com.ua> <20060626152345.M1114@ganymede.hub.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2370705.8AxEAmrMA8
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
=20
likely you are *short* on memory.  In order to relieve the pressure=20
program .text pages are free'ed and need to be refetched from disc whenever=
=20
the respective code is being executed.

If you allow every vServer to run its own mySQL with all the libaries etc i=
t's=20
clear what is killing you!  Add more memory or make sure that .text pages c=
an=20
be reused by several processes.  As far as I understand vServer will all se=
e=20
a different source and thus not share buffers or the like.

> 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/ke=
rn
> >eldebug-deadlocks.html
>
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.or=
g)
> Email . scrappy@hub.org                              MSN . scrappy@hub.org
> Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart2370705.8AxEAmrMA8
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)

iD8DBQBEoEcpXyyEoT62BG0RAqJpAJ9/lLsU3ewtvmkBDuUaSsb8c2goBACeMm/8
+yp3mPugokzxfwzm9Y7z4mg=
=QYef
-----END PGP SIGNATURE-----

--nextPart2370705.8AxEAmrMA8--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606262244.25505.max>