| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Eric Comeau <ecomeau(at)signiant(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org, mladen(dot)gogala(at)vmsinfo(dot)com, Kathryn Smith <Kathryn(dot)Smith(at)signiant(dot)com> |
| Subject: | Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT] |
| Date: | 2010-10-19 14:25:34 |
| Message-ID: | 9954.1287498334@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Eric Comeau <ecomeau(at)signiant(dot)com> writes:
> Okay - I'm starting to see other stmts other than just commits taking
> longer than 5 secs sometimes as well now - stress test has been running
> for 3 days now...some commits 17 and 15 secs ouch...
If it's not just commits then some of the stranger theories go away.
I think you're almost certainly looking at overstressed disk.
It'd be worth your while to turn on checkpoint logging and see if
the slow operations occur during checkpoints. If so, you might be
able to ameliorate things by tweaking the checkpoint parameters
to spread out checkpoint I/O load some more. But the bottom line
here is that you haven't got much headroom between your application's
needs and the max throughput available from your disk. Better disk
hardware will be the only real cure.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-10-19 14:36:09 | Re: odd postgresql performance (excessive lseek) |
| Previous Message | Mladen Gogala | 2010-10-19 14:22:42 | Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why? |