Re: Full statement logging problematic on larger machines? - Mailing list pgsql-performance

From Frank Joerdens
Subject Re: Full statement logging problematic on larger machines?
Date
Msg-id 7d10d2df0903201247r7ff71d1bsf655176a86ca5be4@mail.gmail.com
Whole thread Raw
In response to Re: Full statement logging problematic on larger machines?  (Frank Joerdens <frank@joerdens.de>)
Responses Re: Full statement logging problematic on larger machines?  (Frank Joerdens <frank@joerdens.de>)
List pgsql-performance
On Thu, Mar 12, 2009 at 1:38 PM, Frank Joerdens <frank@joerdens.de> wrote:
> On Thu, Mar 12, 2009 at 1:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> [...]
>> You could try changing _IOLBF
>> to _IOFBF near the head of postmaster/syslogger.c and see if that helps.

The patched server is now running on live, and we'll be watching it
over the weekend with

log_duration = off
log_min_duration_statement = 1000
log_statement = 'ddl'

and then run a full logging test early next week if there are no
problems with the above settings.

Can you explain again what the extent of multiplexed messages I'll
have to expect is? What exactly is the substance of the tradeoff?
Occasionally the server will write the same line twice? Don't really
follow why ...

And the next problem is that now unfortunately the entire comparison
is obfuscated and complicated by a release we did on Monday which has
had a strange effect: Quite extreme load average spikes occurring
frequently that do not seem to impact query speed - not much anyway or
if they do then in a random intermittent manner that's not become
apparent (yet) - CPU usage is actually marginally down, locks
significantly down, and all other relevant metrics basically unchanged
like context switches and memory usage profile. Now, it *seems* that
the extra load is caused by idle (sic!) backends (*not* idle in
transaction even) consuming significant CPU when you look at htop. I
don't have a theory as to that right now. We use pgbouncer as a
connection pooler. What could make idle backends load the server
substantially?

Regards,

Frank

pgsql-performance by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Need help with one query
Next
From: Joe Uhl
Date:
Subject: Re: High CPU Utilization