Tom Lane wrote:
Brian Hurt <> writes:

Is this a bug in postgres?
Well, if you'd provide enough info for someone else to reproduce it, we
could have a look.
Hello- I just wanted to close the book on this problem. I first noticed
the problem when long copies kept slowing down. It turns out it wasn't
a problem with Postgresql at all, as I recreated it with bonnie++ (which
explains the long silence on this issue). After doing a lot of
sustained I/O, we see I/O wait times climb until we're getting virtually
no I/O performance at all, and it doesn't matter if it's Postgresql or
bonnie++ doing the I/O. iostat would report that we'd be doing only
2MB/sec, and we'd be seeing 90%+ iowait percentages in atop or top. So
our solution is to fix out I/O subsystem. We're replacing the expensive
TLA SAN storage device with a low end Fibre Channel raid (which we were
going to do anyways, as even at it's best, the TLA SAN wasn't
impressive), upgrading from an old 2.4 linux kernel to a newer 2.6
kernel, changing the I/O Scheduler to deadline, and upgrading the server
hardware. Some combination of the above solves the problem.

Hopefully no one has been lying awake worrying about this problem :-),
but I wanted to close it out, and to leave a permanent record in the
archives for the next person who has this problem.


Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 3 | next ›
Discussion Overview
grouppgsql-novice @
postedOct 22, '07 at 7:44p
activeNov 26, '07 at 4:09p

2 users in discussion

Brian Hurt: 2 posts Tom Lane: 1 post



site design / logo © 2021 Grokbase