From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: stuck spin lock with many concurrent users |
Date: | 2001-06-21 09:59:49 |
Message-ID: | 20010621185949J.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> > I have seen problems with extremely many concurrent users.
> > I run pgbench:
>
> > pgbench -c 1000 -t 1 test
>
> > And I get stuck spin lock errors. This is 100% reproducable (i.e. I
> > have nerver succeeded in pgbench -c 1000).
>
> Is it actually stuck, or just timing out due to huge contention?
> You could try increasing the timeout intervals in s_lock.c to
> make sure.
I believe it's an actual stuck. From s_lock.c:
#define DEFAULT_TIMEOUT (100*1000000) /* default timeout: 100 sec */
So even if there are 1000 contentions, 100 sec should be enough (100
msec for each backend).
> If it is stuck, on which lock(s)?
How can I check it? In that situation, it's very hard to attacth a
debugger to the backend process. 1000 backends consum all CPU time.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Kirkwood | 2001-06-21 10:01:29 | Re: Backup and Recovery |
Previous Message | Colin Strickland | 2001-06-21 09:55:59 | RE: Universal admin frontend |