From: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: 2 questions re RAID |
Date: | 2011-06-18 14:28:39 |
Message-ID: | 1B6429A2-AE8C-45DC-BDA7-16831CBC2021@elevated-dev.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Jun 17, 2011, at 11:23 PM, Greg Smith wrote:
> I guess you could call Highpoint a RAID manufacturer, but I wouldn't do so. They've released so many terrible problems over the years that it's hard to take the fact that they may have something reasonable you can buy now (the 43XX cards I think?) seriously.
Ah, I see. So they're on par with Apple's RAID controller instead of being the first step up.
> Atto is so Mac focused that you're not going to find much experience here, for the same reason you didn't get any response to your original question. Their cards are using the same Intel IO Processor (IOP) hardware as some known capable cards. For example, the ExpressSAS R348 is named that because it has an Intel 348 IOP. That's the same basic processor as on the medium sized Areca boards: http://www.areca.us/products/pcietosas1680series.htm So speed should be reasonable, presuming they didn't make any major errors in board design or firmware.
Good info. Didn't know about their focus, because the last time I dealt with them was so many years ago they still had a significant focus on Windows, or so it seemed to me at the time. Focus on Mac says nothing about the firmware on the card, but it should bode well for the driver.
> The real thing you need to investigate is whether the write cache setup is done right, and whether monitoring is available in a way you can talk to. What you want is for the card to run in write-back mode normally, degrading to write-through when the battery stops working well. If you don't see that sort of thing clearly documented as available, you really don't want to consider their cards.
Well, right up front in their marketing materials they make a major point about cache protection, how important it is, how good it is, using ultracapacitor+flash over batteries (on some of their controllers). So they have awareness & intent; competence and follow-through of course are not assured by marketing materials. (Also they talk about background scanning of drives for defects.) And it looks like they offer all of: GUI setup/monitoring that runs on OS X, command-line setup/monitoring that runs on OS X, SNMP...
> You're basically asking "if I don't write to the database, does the fact that write performance on RAID5 is slow matter?" When asked that way, sure, it's fine. If after applying the write cache to help, your write throughput requirements don't ever exceed what a single disk can provide, than maybe RAID5 will be fine for you. Make sure you keep shared_buffers low though, because you're not going to be able to absorb a heavy checkpoint sync on RAID5.
Yes, basically I wanted to confirm that's what I was actually asking ;-) The only circumstance under which I could see overflowing the card's write cache is during migrations. So my choice then really is better performance during rare migrations vs being able to lose any 2 drives out of 4 (RAID6). Which is OK, since neither choice is really bad--having been burned by bad disk runs before, I'll probably go for safety. (FYI this is not my only margin for failure. Two geographically-distributed WAL-streaming replicas with low-end RAID1 are the next line of defense. Followed by, god forbid I should ever have to use them, daily dumps.)
Thanks for all the info. I guess about all I have remaining to do is sanity-check my beliefs about disk I/O.
--
Scott Ribe
scott_ribe(at)elevated-dev(dot)com
http://www.elevated-dev.com/
(303) 722-0567 voice
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-06-18 17:12:34 | Re: While converting the Master to Standby , FATAL: timeline 2 of the primary does not match recovery target timeline 1 |
Previous Message | Alpha Beta | 2011-06-18 14:00:38 | Re: Functional dependencies |