Skip site navigation (1) Skip section navigation (2)

Full statement logging problematic on larger machines?

From: Frank Joerdens <frank(at)joerdens(dot)de>
To: pgsql-performance(at)postgresql(dot)org
Cc: Nic Ferrier <nic(at)woome(dot)com>, Avleen Vig <avleen(at)woome(dot)com>, Mike Rogers <mike(dot)rogers(at)woome(dot)com>
Subject: Full statement logging problematic on larger machines?
Date: 2009-03-11 19:27:10
Message-ID: 7d10d2df0903111227g2e40e742g5992cba5158dd4d2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
Greetings. We're having trouble with full logging since we moved from
an 8-core server with 16 GB memory to a machine with double that
spec and I am wondering if this *should* be working or if there is a
point on larger machines where logging and scheduling seeks of
background writes - or something along those lines; it might be a
theory - doesn't work together any more?

The box in question is a Dell PowerEdge R900 with 16 cores and 64 GB
of RAM (16 GB of shared buffers allocated), and a not-so-great

root(at)db04:~# lspci|grep RAID
19:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS
1078 (rev 04)

controller with 8 10k rpm disks in RAID 1+0 (one big filesystem),
running Ubuntu Hardy with kernel version

root(at)db04:~# uname -a
Linux db04 2.6.24-22-server #1 SMP Mon Nov 24 20:06:28 UTC 2008 x86_64 GNU/Linux

Logging to the disk array actually stops working much earlier; at
off-peak time we have around 3k transactions per second and if we set
log_statement = all, the server gets bogged down immediately: Load,
context switches, and above all mean query duration shoot up; the
application slows to a crawl and becomes unusable.

So the idea came up to log to /dev/shm which is a default ram disk on
Linux with half the available memory as a maximum size.

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.

This is a problem because we can't do proper query analysis any more.

How are others faring with full logging on bigger boxes?

Regards,

Frank

Responses

pgsql-performance by date

Next:From: Scott CareyDate: 2009-03-11 19:28:56
Subject: Re: random_page_cost vs ssd?
Previous:From: AndrejDate: 2009-03-11 19:04:17
Subject: Re: random_page_cost vs ssd?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group