From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Greg Cox" <ratness(at)hotmail(dot)com> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Excess idle processes, leaking WAL logs? |
Date: | 2007-01-03 23:13:27 |
Message-ID: | 6971.1167866007@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
"Greg Cox" <ratness(at)hotmail(dot)com> writes:
> In the 3 days since it died, I've been watching it and, once again, the
> processes are climbing slowly again. They're idle postgres processes,
> fairly evenly distributed against the app servers, and more interestingly,
This isn't a postgres bug, it's a problem in your application code; it's
not closing sessions it doesn't need. Possibly a problem in a
connection-pooling layer?
> I looked in the 7.4 docs about WAL. checkpoint_timeout is 300,
> checkpoint_segments is 8, plenty of space in pg_xlog, but there's 18 files
> in there, some a few hours old, which I would suspect would not be the case
> if it were checkpointing properly.
No, that doesn't sound out of line. The steady state is to have about
2 * checkpoint_segments + 1 WAL files. You might have one or so more
than I'd have expected but that's not enough to evidence a problem.
If you are concerned about whether checkpoints are really happening,
use pg_controldata to keep an eye on the last-checkpoint time in
pg_control.
I concur with the other comment that you really ought to be on 7.4.latest
but that's not going to magically fix your connection-pooling issue.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2007-01-04 05:51:36 | Re: INSERT Return Value? |
Previous Message | Brandon Aiken | 2007-01-03 22:26:52 | Re: Excess idle processes, leaking WAL logs? |