Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 0A526650058 for ; Fri, 22 Aug 2008 09:01:27 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 70986-05 for ; Fri, 22 Aug 2008 09:01:02 -0300 (ADT) X-Greylist: delayed 00:08:19.36453 by SQLgrey-1.7.6 Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by postgresql.org (Postfix) with ESMTP id 0A4E66500D9 for ; Fri, 22 Aug 2008 09:01:06 -0300 (ADT) Received: by hyperion.scode.org (Postfix, from userid 1001) id 2711C23C451; Fri, 22 Aug 2008 13:52:44 +0200 (CEST) Date: Fri, 22 Aug 2008 13:52:44 +0200 From: Peter Schuller To: pgsql-performance@postgresql.org Subject: Identifying the nature of blocking I/O Message-ID: <20080822115243.GA10981@hyperion.scode.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200808/279 X-Sequence-Number: 31160 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [for the purpose of this post, 'blocking' refers to an I/O operation taking a long time for reasons other than the amount of work the I/O operation itself actually implies; not to use of blocking I/O calls or anything like that] Hello, I have a situation in which deterministic latency is a lot more important than throughput. I realize this is a hugely complex topic and that there is inteaction between many different things (pg buffer cache, os buffer cache, raid controller caching, wal buffers, storage layout, etc). I already know several things I definitely want to do to improve things. But in general, it would be very interesting to see, at any given moment, what PostgreSQL backends are actually blocking on from the perspective of PostgreSQL. So for example, if I have 30 COMMIT:s that are active, to know whether it is simply waiting on the WAL fsync or actually waiting on a data fsync because a checkpoint is being created. or similarly, for non-commits whether they are blocking because WAL buffers is full and writing them out is blocking, etc. This would make it easier to observe and draw conclusions when tweaking different things in pg/the os/the raid controller. Is there currently a way of dumping such information? I.e., asking PG "what are backends waiting on right now?". --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiuqIsACgkQDNor2+l1i33DjQCfc6eUxXo4C5Tif7/0mCiN1ujw 75UAnRB63+zGKOOyOb0btIsdRUv2DlNN =SNaJ -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--