Spiky COMMIT results in performance slowdowns with Postgres 8.4

Question

We just installed performance monitoring on our web application, and we're seeing a spiky pattern in response times from our Postgres 8.4 server. The spikes correspond with significant slowdown in our web app. The time seems to taken up largely in "Postgres commit":

We're self-hosting Postgres 8.4.3 on Ubuntu 10.04, with essentially stock settings, on an Amazon EC2 c1.xlarge instance w/ EBS. Yes, I know that Postgres on EBS probably isn't the best setup. We plan to move to a newer Postgres DB on RDS later this year.

In the meantime, is there anything obvious that I should look at that might tame this spiky pattern?

Answer 1

It's hard to tell what exactly your graphs say. But commit is designed to be slow. By default, Postgres waits for changes to be written to disk before it lets commit return.

You can let commit complete before changes are written to disk with this option:

synchronous_commit = off

That should certainly help to spread the disk I/O required for commit over more time. The downside is that a server outage can cause completed transactions to be lost.