Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 1B3EC9FB7E1 for ; Thu, 26 Jul 2007 11:40:27 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 95951-04 for ; Thu, 26 Jul 2007 11:40:16 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 3FC309FB285 for ; Thu, 26 Jul 2007 11:40:22 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id l6QEeGkb026826; Thu, 26 Jul 2007 10:40:16 -0400 (EDT) To: "Jignesh K. Shah" cc: Simon Riggs , Josh Berkus , pgsql-performance@postgresql.org, Alvaro Herrera Subject: Re: User concurrency thresholding: where do I look? In-reply-to: <46A8AFDF.3050804@sun.com> References: <200707190828.59088.josh@agliodbs.com> <200707191819.13899.josh@agliodbs.com> <15685.1184895926@sss.pgh.pa.us> <200707192138.39679.josh@agliodbs.com> <46A0FA31.2080208@sun.com> <12002.1184955831@sss.pgh.pa.us> <46A1055F.9010304@sun.com> <12445.1184958793@sss.pgh.pa.us> <46A11116.5030905@sun.com> <14909.1184962561@sss.pgh.pa.us> <46A1205B.8010205@sun.com> <15343.1184965054@sss.pgh.pa.us> <1185180668.4284.149.camel@ebony.site> <23848.1185199901@sss.pgh.pa.us> <1185201556.4284.243.camel@ebony.site> <25095.1185202498@sss.pgh.pa.us> <1185205663.4284.249.camel@ebony.site> <1185212261.4284.270.camel@ebony.site> <1545.1185214760@sss.pgh.pa.us> <46A7D5AD.9000706@sun.com> <13162.1185405865@sss.pgh.pa.us> <46A8AFDF.3050804@sun.com> Comments: In-reply-to "Jignesh K. Shah" message dated "Thu, 26 Jul 2007 10:29:51 -0400" Date: Thu, 26 Jul 2007 10:40:16 -0400 Message-ID: <26825.1185460816@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/364 X-Sequence-Number: 26048 "Jignesh K. Shah" writes: > The count is only for a 10-second snapshot.. Plus remember there are > about 1000 users running so the connection being profiled only gets > 0.01 of the period on CPU.. And the count is for that CONNECTION only. OK, that explains the low absolute levels of the counts, but if the counts are for a regular backend then there's still a lot of bogosity here. Backends won't be taking the CheckpointLock at all, nor do they take CheckpointStartLock in exclusive mode. The bgwriter would do that but it'd not be taking most of these other locks. So I think the script is mislabeling the locks somehow. Also, elementary statistics should tell you that a sample taken as above is going to have enormous amounts of noise. You should be sampling over a much longer period, say on the order of a minute of runtime, to have numbers that are trustworthy. regards, tom lane