Re: Excess idle processes, leaking WAL logs?
От | Tom Lane |
---|---|
Тема | Re: Excess idle processes, leaking WAL logs? |
Дата | |
Msg-id | 6971.1167866007@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Excess idle processes, leaking WAL logs? ("Greg Cox" <ratness@hotmail.com>) |
Список | pgsql-novice |
"Greg Cox" <ratness@hotmail.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
В списке pgsql-novice по дате отправления: