| 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: | 26825.1185460816@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2007-07-26 14:47:08 | Re: disk filling up |
| Previous Message | Mark Lewis | 2007-07-26 14:37:23 | Re: disk filling up |