Re: How to cripple a postgres server

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: How to cripple a postgres server
Дата
Msg-id 295.1022559884@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: How to cripple a postgres server  (Stephen Robert Norris <srn@commsecure.com.au>)
Ответы Re: How to cripple a postgres server  (Stephen Robert Norris <srn@commsecure.com.au>)
Re: How to cripple a postgres server  (Curt Sampson <cjs@cynic.net>)
Re: How to cripple a postgres server  (Stephen Robert Norris <srn@commsecure.com.au>)
Список pgsql-general
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

В списке pgsql-general по дате отправления:

Предыдущее
От: Stephen Robert Norris
Дата:
Сообщение: Re: How to cripple a postgres server
Следующее
От: Ron Snyder
Дата:
Сообщение: Re: Invalid length of startup packet