From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Cc: | Katsuhiko Okano <okano(dot)katsuhiko(at)oss(dot)ntt(dot)co(dot)jp> |
Subject: | Re: CSStorm occurred again by postgreSQL8.2 |
Date: | 2006-08-08 03:16:53 |
Message-ID: | 20060808110913.50FA.ITAGAKI.TAKAHIRO@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
This is an additional information.
I wrote:
> If we want to resolve the probmen fundamentally, we might have to
> improve SubTrans using a better buffer management algorithm or so.
The above is maybe wrong. I checked each lwlock of pg_subtrans's buffers.
All lwlocks are uniformly acquired and I could not see any differences
among buffers. So the cause seems not to be a buffer management algorithm,
but just a lack of SLRU buffer pages.
NUM_SUBTRANS_BUFFERS is defined as 32 in HEAD. If we increase it,
we can avoid the old transaction problem for a certain time.
However, it doesn't help much on high-load -- for example, on a workload
with 2000 tps, we will use up 1000 pg_subtrans pages in 15 minites.
I suppose it is not enough for online and batch/maintenance mix.
Also, the simple scanning way in SLRU will likely cause another performance
issue when we highly increase the number of buffers. A sequential scanning
is used in SLRU, so it will not work well against many buffers.
I hope some cares in upper layer, snapshot, hitbits or something,
being discussed in the recent thread.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2006-08-08 04:56:27 | Re: proposal for PL packages for 8.3. |
Previous Message | Rod Taylor | 2006-08-08 02:23:27 | Re: "Constraint exclusion" is not general enough |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-08 17:26:25 | Re: PL instrumentation plugin support (i.e. PL/pgSQL debugger infrastructure) |
Previous Message | Bruce Momjian | 2006-08-08 01:23:26 | Re: [HACKERS] [PATCHES] log_statement output for protocol |