Skip site navigation (1) Skip section navigation (2)

Re: User concurrency thresholding: where do I look?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: User concurrency thresholding: where do I look?
Date: 2007-07-26 14:40:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
"Jignesh K. Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> 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

In response to


pgsql-performance by date

Next:From: Joshua D. DrakeDate: 2007-07-26 14:47:08
Subject: Re: disk filling up
Previous:From: Mark LewisDate: 2007-07-26 14:37:23
Subject: Re: disk filling up

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group