Re: How to cripple a postgres server
От | Stephen Robert Norris |
---|---|
Тема | Re: How to cripple a postgres server |
Дата | |
Msg-id | 1022558619.3344.40.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:57, Tom Lane wrote: > Stephen Robert Norris <srn@commsecure.com.au> writes: > > My reading of the code was that the signals didn't get delivered unless > > the queue got too full, and that entries on the queue are created by the > > vacuum (and other stuff) and processed when a backend does something, > > thus the queue never gets too full. > > Good point. And certainly the async-notify code (which scans through > pg_listener) is a lot more expensive than is needed just to respond to > an SInval-queue-full condition; that looks to be a quick hack that was > inserted without thought to performance. But I don't think we quite > understand this issue yet. If your system can support 800 simultaneous > useful queries then it shouldn't have a problem with 800 simultaneous > scans of an empty pg_listener table. > > I'll ask again: is your system sized to support 800 *simultaneous* > user queries? (One query per second on 800 connections is hardly > the same thing.) > > regards, tom lane I'm not sure; it can certainly do >1k queries/second through 800 simultaneous connections (about 1/connection second), but it's hard to find enough machines to load it up that much... 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... In any event, it seems a bug that merely having connections open causes this problem! They aren't even in transactions... Stephen
Вложения
В списке pgsql-general по дате отправления: