From: | Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com> |
---|---|
To: | Frank Joerdens <frank(at)joerdens(dot)de> |
Cc: | pgsql-performance(at)postgresql(dot)org, Nic Ferrier <nic(at)woome(dot)com>, Avleen Vig <avleen(at)woome(dot)com>, Mike Rogers <mike(dot)rogers(at)woome(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: Full statement logging problematic on larger machines? |
Date: | 2009-03-11 23:59:06 |
Message-ID: | 1d4e0c10903111659x6c96e6cau33ee121ee29a48a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Mar 11, 2009 at 8:27 PM, Frank Joerdens <frank(at)joerdens(dot)de> wrote:
> This works much better but once we are at about 80% of peak load -
> which is around 8000 transactions per second currently - the server goes
> into a tailspin in the manner described above and we have to switch off full
> logging.
First, don't use log_duration = on + log_statement = 'all' to log all
the queries, use log_min_duration_statement=0, it's less verbose.
I don't know if the logging integrated into PostgreSQL can bufferize
its output. Andrew? If not, you should try syslog instead and see if
asynchronous logging with syslog is helping (you need to prefix the
path with a dash to enable asynchronous logging). You can also try to
send the logs on the network via udp (and also tcp if you have an
enhanced syslog-like).
Another option is to log the duration of every query but not the text.
We used to have this sort of configuration to gather comprehensive
statistics and slowest queries on highly loaded servers (it's not
perfect though but it can be an acceptable compromise):
log_duration = on
log_min_duration_statement = 100
--
Guillaume
From | Date | Subject | |
---|---|---|---|
Next Message | Jignesh K. Shah | 2009-03-12 00:51:56 | Re: Proposal of tunable fix for scalability of 8.4 |
Previous Message | Frank Joerdens | 2009-03-11 22:42:29 | Re: Full statement logging problematic on larger machines? |