Re: limiting performance impact of wal archiving.
От | Jeff |
---|---|
Тема | Re: limiting performance impact of wal archiving. |
Дата | |
Msg-id | 4E5280E4-18CF-41AC-AAF6-F6F3ACB47BA1@torgo.978.org обсуждение исходный текст |
Ответ на | Re: limiting performance impact of wal archiving. (Laurent Laborde <kerdezixe@gmail.com>) |
Список | pgsql-performance |
On Nov 10, 2009, at 10:53 AM, Laurent Laborde wrote: > On Tue, Nov 10, 2009 at 4:48 PM, Kevin Grittner > <Kevin.Grittner@wicourts.gov> wrote: >> Laurent Laborde <kerdezixe@gmail.com> wrote: >> >>> BTW, if you have any idea to improve IO performance, i'll happily >>> read it. We're 100% IO bound. >> >> At the risk of stating the obvious, you want to make sure you have >> high quality RAID adapters with large battery backed cache configured >> to write-back. > > Not sure how "high quality" the 3ware is. > /c0 Driver Version = 2.26.08.004-2.6.18 > /c0 Model = 9690SA-8I > /c0 Available Memory = 448MB I'll note that I've had terrible experience with 3ware controllers and getting a high number of iops using hardware raid mode. If you switch it to jbod and do softraid you'll get a large increase in iops - which is the key metric for a db. I've posted previously about my problems with 3ware. as for the ssd comment - I disagree. I've been running ssd's for a while now (probably closing in on a year by now) with great success. A pair of intel x25-e's can get thousands of iops. That being said the key is I'm running the intel ssds - there are plenty of absolutely miserable ssds floating around (I'm looking at you jmicron based disks!) Have you gone through the normal process of checking your query plans to ensure they are sane? There is always a possibility a new index can vastly reduce IO. -- Jeff Trout <jeff@jefftrout.com> http://www.stuarthamm.net/ http://www.dellsmartexitin.com/
В списке pgsql-performance по дате отправления: