Received: from localhost (uranus.hub.org [200.46.204.60]) by postgresql.org (Postfix) with ESMTP id DCEE99FB33A for ; Fri, 3 Nov 2006 12:14:57 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.60]) (amavisd-new, port 10024) with ESMTP id 64051-10 for ; Fri, 3 Nov 2006 12:14:55 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from heaven.kostyrka.org (h1634.serverkompetenz.net [81.169.154.44]) by postgresql.org (Postfix) with ESMTP id 0C11A9FB337 for ; Fri, 3 Nov 2006 12:14:54 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by heaven.kostyrka.org (Postfix) with ESMTP id B09924FBE4; Fri, 3 Nov 2006 17:14:52 +0100 (CET) Received: from heaven.kostyrka.org ([127.0.0.1]) by localhost (heaven.kostyrka.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06577-08; Fri, 3 Nov 2006 17:14:52 +0100 (CET) Received: from [192.168.1.9] (85-124-81-107.dynamic.xdsl-line.inode.at [85.124.81.107]) by heaven.kostyrka.org (Postfix) with ESMTP id 4B4974FB1C; Fri, 3 Nov 2006 17:14:52 +0100 (CET) Subject: Re: Context switch storm From: Andreas Kostyrka To: Richard Huxton Cc: creimer@brturbo.com.br, pgsql-performance@postgresql.org In-Reply-To: <454B5461.4030802@archonet.com> References: <454B3B75.6@archonet.com> <454B5461.4030802@archonet.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NWnsc2+p+SbdaUqz3BCA" Date: Fri, 03 Nov 2006 17:16:31 +0100 Message-Id: <1162570591.16439.21.camel@andi-lap> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200611/52 X-Sequence-Number: 21822 --=-NWnsc2+p+SbdaUqz3BCA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Am Freitag, den 03.11.2006, 14:38 +0000 schrieb Richard Huxton: > creimer@brturbo.com.br wrote: > >> If you can keep your numbers of clients down below the critical=20 > >> level, you should find the overall workload is fine. > >=20 > > We have at about 600 connections. Is this a case to use a connection > > pool (pg_pool) system? >=20 > Possibly - that should help. I'm assuming that most of your queries are=20 > very short, so you could probably get that figure down a lot lower.=20 > You'll keep the same amount of queries running through the system, just=20 > queue them up. that have=20 Ah, yes, now that you mention, avoid running many queries with a similiar timing behaviour, PG8 seems to have a lock design that's very bad for the memory architecture of the Xeons. So running SELECT * FROM table WHERE id=3D1234567890; from 600 clients in parallel can be quite bad than say a complicated 6-way join :( Andreas >=20 > > And why this happens only with 8.0 and 8.1 and not with the 7.4? >=20 > Not sure. Maybe 8.x is making more intensive use of your memory,=20 > possibly with a change in your plans. >=20 --=-NWnsc2+p+SbdaUqz3BCA Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBFS2tfHJdudm4KnO0RAsetAKCdxg6JvlVfVYA8ExMfr7w/1lQmrQCfVy59 8X7mUE3+hs8bBVOWEGZoByc= =Zm+7 -----END PGP SIGNATURE----- --=-NWnsc2+p+SbdaUqz3BCA--