Re: How to cripple a postgres server
От | Stephen Robert Norris |
---|---|
Тема | Re: How to cripple a postgres server |
Дата | |
Msg-id | 1022565807.2670.51.camel@ws12 обсуждение исходный текст |
Ответ на | Re: How to cripple a postgres server (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On Tue, 2002-05-28 at 14:24, Tom Lane wrote: > Stephen Robert Norris <srn@commsecure.com.au> writes: > > One big difference, though, is that with the vacuum problem, the CPU > > used is almost all (99%) system time; loading up the db with lots of > > queries increases user time mostly, with little system time... > > Hmm, that's a curious point; leaves one wondering about possible kernel > bugs. > > > In any event, it seems a bug that merely having connections open causes > > this problem! They aren't even in transactions... > > If the problem is that you've launched far more backends than the system > can really support, I'd have no hesitation in writing it off as user > error. "Idle" processes are not without cost. But at this point > I can't tell whether that's the case, or whether you're looking at a > genuine performance bug in either Postgres or the kernel. > > Can you run strace (or truss or kernel-call-tracer-of-your-choice) on > the postmaster, and also on one of the putatively idle backends, so > we can see some more data about what's happening? > > regards, tom lane I wonder if it's a problem with a second SIGUSR2 arriving before the first is finished? It seems much easier to trigger the effect with more rapid vacuums than with a delay (even accounting for the reduced number of vacuums occurring). Stephen
Вложения
В списке pgsql-general по дате отправления: