Spiky COMMIT results in performance slowdowns with Postgres 8.4
-
26-09-2020 - |
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?
Solution
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.