| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 20:04:50 |
| Message-ID: | 1185480291.5510.22.camel@ebony.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, 2007-07-26 at 15:44 -0400, Jignesh K. Shah wrote:
> BEAUTIFUL!!!
>
> Using the Patch I can now go upto 1300 users without dropping.. But now
> it still repeats at 1300-1350 users..
OK, can you try again with 16 and 32 buffers please? We need to know
how many is enough and whether this number needs to be variable via a
parameter, or just slightly larger by default. Thanks.
> I corrected the Lock Descriptions based on what I got from lwlock.h and
> retried the whole scalability again with profiling again.. This time it
> looks like the ProcArrayLock
That's what I would expect with that many users.
> Lock Id Mode Count
> XidGenLock Exclusive 1
> CLogControlLock Shared 2
> XidGenLock Shared 2
> WALWriteLock Exclusive 4
> WALInsertLock Exclusive 8
> CLogControlLock Exclusive 9
> ProcArrayLock Exclusive 9
...but as Tom mentioned, we need to do longer runs now so these counts
get to somewhere in the hundreds so we have some statistical validity.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jignesh K. Shah | 2007-07-26 21:17:55 | Re: User concurrency thresholding: where do I look? |
| Previous Message | Robert Lor | 2007-07-26 19:56:08 | Re: User concurrency thresholding: where do I look? |