Re: How to cripple a postgres server
От | Stephen Robert Norris |
---|---|
Тема | Re: How to cripple a postgres server |
Дата | |
Msg-id | 1022556496.2670.30.camel@ws12 обсуждение исходный текст |
Ответ на | Re: How to cripple a postgres server (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: How to cripple a postgres server
|
Список | pgsql-general |
On Tue, 2002-05-28 at 13:21, Tom Lane wrote: > Stephen Robert Norris <srn@commsecure.com.au> writes: > > On Tue, 2002-05-28 at 12:44, Tom Lane wrote: > >> Hmm, you mean if the 800 other connections are *not* idle, you can > >> do VACUUMs with impunity? If so, I'd agree we got a bug ... > > > Yes, that's what I'm saying. > > Fascinating. > > > I suspect the comment near the async_notify code explains the problem - > > where it talks about idle backends having to be woken up to clear out > > pending events... > > Well, we need to do that, but your report seems to suggest that that > code path isn't getting the job done completely --- my first guess is > that a new normal query has to arrive before a SIGUSR2'd backend is > completely happy again. Interesting. > > You didn't specify: what PG version are you running, and on what > platform? > > regards, tom lane Sorry, forgot that. PG 7.1 or 7.2 (both have the problem) on linux 2.2.x (x>=17) and 2.4.x (4 <= x <= 18). I've tried a variety of intel machines (and AMD machines) and managed to reproduce the same problem. To clarify my comments, I suspect the problem is that all 800 of the backends get the SIGUSR2 at the same time, and all wake up, causing the kernel scheduler to go mad trying to decide which one to schedule... If the connections aren't idle, the queue never fills up enough to require the signals... Stephen
Вложения
В списке pgsql-general по дате отправления: