[PERFORM] Linux/PostgreSQL scalability issue - problem with 8 cores

Hi all, we have a PostgreSQL dedicated Linux server with 8 cores (2xX5355). We came accross a strange issue: when running with all 8 cores enabled approximatly once a minute (period differs) the system is very busy for a few seconds (~5-10s) and we don't know why - this issue don't show up wh

[PERFORM] Commit takes a long time.

Using Postgresql 8.1.10 every so often I get a transaction that takes a while to commit. I log everything that takes over 500ms and quite reguallly it says things like 707.036 ms statement: COMMIT Is there anyway to speed this up? Peter Childs

Re: [PERFORM] Commit takes a long time.

Hello On 03/01/2008, Peter Childs <[EMAIL PROTECTED]> wrote: > Using Postgresql 8.1.10 every so often I get a transaction that takes a > while to commit. > > I log everything that takes over 500ms and quite reguallly it says things > like > > 707.036 ms statement: COMMIT > > Is there anyway to spe

Re: [PERFORM] Linux/PostgreSQL scalability issue - problem with 8 cores

Hi Jakub, I do have a similar server (from DELL), which performance well with our PostgreSQL application. I guess the peak in context switches is the only think you can see. Anyhow, I think it is you're LISTEN/NOTIFY approach which cause that behaviour. I guess all backends do listen to the same

Re: [PERFORM] Commit takes a long time.

"Peter Childs" <[EMAIL PROTECTED]> writes: > Using Postgresql 8.1.10 every so often I get a transaction that takes a > while to commit. > I log everything that takes over 500ms and quite reguallly it says things > like > 707.036 ms statement: COMMIT AFAIK there are only two likely explanations f

Re: [PERFORM] Linux/PostgreSQL scalability issue - problem with 8 cores

Jakub Ouhrabka <[EMAIL PROTECTED]> writes: > we have a PostgreSQL dedicated Linux server with 8 cores (2xX5355). We > came accross a strange issue: when running with all 8 cores enabled > approximatly once a minute (period differs) the system is very busy for > a few seconds (~5-10s) and we don'

Re: [PERFORM] Linux/PostgreSQL scalability issue - problem with 8 cores

Hi Tom, > Interesting. Maybe you could use oprofile to try to see what's > happening? It sounds a bit like momentary contention for a spinlock, > but exactly what isn't clear. ok, we're going to try oprofile, will let you know... > Perhaps. Have you tried logging executions of NOTIFY to see

Re: [PERFORM] Linux/PostgreSQL scalability issue - problem with 8 cores

Hi Sven, > I guess all backends do listen to the same notification. Unfortunatelly no. The backends are listening to different notifications in different databases. Usually there are only few listens per database with only one exception - there are many (hundreds) listens in one database but

Re: [PERFORM] Linux/PostgreSQL scalability issue - problem with 8 cores

Jakub Ouhrabka wrote: > > - do an UNLISTEN if possible > > Yes, we're issuing unlistens when appropriate. You are vacuuming pg_listener periodically, yes? Not that this seems to have any relationship to your problem, but ... -- Alvaro Herrerahttp://www.CommandPr

Re: [PERFORM] Linux/PostgreSQL scalability issue - problem with 8 cores

Alvaro, >>> - do an UNLISTEN if possible >> Yes, we're issuing unlistens when appropriate. > > You are vacuuming pg_listener periodically, yes? Not that this seems > to have any relationship to your problem, but ... yes, autovacuum should take care of this. But looking forward for multiple-wor