Re: new server I/O setup
От | Matthew Wakeling |
---|---|
Тема | Re: new server I/O setup |
Дата | |
Msg-id | alpine.DEB.2.00.1001151113370.6195@aragorn.flymine.org обсуждение исходный текст |
Ответ на | Re: new server I/O setup (Scott Marlowe <scott.marlowe@gmail.com>) |
Ответы |
Re: new server I/O setup
|
Список | pgsql-performance |
On Thu, 14 Jan 2010, Scott Marlowe wrote: >> I've just received this new server: >> 1 x XEON 5520 Quad Core w/ HT >> 8 GB RAM 1066 MHz >> 16 x SATA II Seagate Barracuda 7200.12 >> 3ware 9650SE w/ 256MB BBU >> >> 2 discs in RAID 1 for OS + pg_xlog partitioned with ext2. >> 12 discs in RAID 10 for postgres data, sole partition with ext3. >> 2 spares > > I think your first choice is right. I use the same basic setup with > 147G 15k5 SAS seagate drives and the pg_xlog / OS partition is almost > never close to the same level of utilization, according to iostat, as > the main 12 disk RAID-10 array is. We may have to buy a 16 disk array > to keep up with load, and it would be all main data storage, and our > pg_xlog main drive pair would be just fine. The benefits of splitting off a couple of discs for WAL are dubious given the BBU cache, given that the cache will convert the frequent fsyncs to sequential writes anyway. My advice would be to test the difference. If the bottleneck is random writes on the 12-disc array, then it may actually help more to improve that to a 14-disc array instead. I'd also question whether you need two hot spares, with RAID-10. Obviously that's a judgement call only you can make, but you could consider whether it is sufficient to just have a spare disc sitting on a shelf next to the server rather than using up a slot in the server. Depends on how quickly you can get to the server on failure, and how important the data is. Matthew -- In the beginning was the word, and the word was unsigned, and the main() {} was without form and void...
В списке pgsql-performance по дате отправления: