Re: Big copy slowdown - Mailing list pgsql-novice

From Brian Hurt
Subject Re: Big copy slowdown
Date
Msg-id 474AEF96.6020509@janestcapital.com
Whole thread Raw
In response to Re: Big copy slowdown  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-novice
Tom Lane wrote:
Brian Hurt <bhurt@janestcapital.com> 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.

Brian



pgsql-novice by date:

Previous
From: "Phillip Smith"
Date:
Subject: Re: Update field value
Next
From: "Григорий Никоноров"
Date:
Subject: psql: FATAL: Ident authentication failed for user "jira"