Re: [GENERAL] table spaces

2013-03-13 Thread Scott Marlowe
On Wed, Mar 13, 2013 at 7:26 AM, Shaun Thomas wrote: > On 03/12/2013 05:49 PM, Gregg Jaskiewicz wrote: > >> So out of 6 disks then having 4 in Raid 1+0 configuration and other >> two in mirror for WAL. That's another option then for me to test. > > > That is an option, but it's not necessarily a g

Re: [GENERAL] table spaces

2013-03-13 Thread Shaun Thomas
On 03/13/2013 10:30 AM, Greg Jaskiewicz wrote: Is that SSD mixed in with other disks? Kinda. We chose a PCIe-based SSD (FusionIO). We have a RAID-10 for low-transaction and archived data. It worked for us, but it's pretty spendy. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite

Re: [GENERAL] table spaces

2013-03-13 Thread Greg Jaskiewicz
On 13 Mar 2013, at 13:26, Shaun Thomas wrote: > On 03/12/2013 05:49 PM, Gregg Jaskiewicz wrote: > >> So out of 6 disks then having 4 in Raid 1+0 configuration and other >> two in mirror for WAL. That's another option then for me to test. > > That is an option, but it's not necessarily a good

Re: [GENERAL] table spaces

2013-03-13 Thread John R Pierce
On 3/13/2013 6:26 AM, Shaun Thomas wrote: I have to tell you though, we had a server with twelve spindles three years ago, and it barely kept up with our transaction load. We had two hot spares, a RAID-1, and 8-disks in a RAID-10. Several pgbench tests back then showed that our RAID-10 could on

Re: [GENERAL] table spaces

2013-03-13 Thread Shaun Thomas
On 03/12/2013 05:49 PM, Gregg Jaskiewicz wrote: So out of 6 disks then having 4 in Raid 1+0 configuration and other two in mirror for WAL. That's another option then for me to test. That is an option, but it's not necessarily a good one. If all you have are six disks, you are probably better

Re: [GENERAL] table spaces

2013-03-13 Thread Alban Hertroys
On 12 March 2013 22:31, Gregg Jaskiewicz wrote: > Ok, > > So by that token (more drives the better), I should have raid 5 (or > whichever will work) with all 6 drives in it ? > Raid 5 is usually advised against, as in many scenarios it won't perform very well. For example, see: http://www.revsys

Re: [GENERAL] table spaces

2013-03-12 Thread Gregg Jaskiewicz
On 12 March 2013 21:59, John R Pierce wrote: > On 3/12/2013 2:31 PM, Gregg Jaskiewicz wrote: > >> I was basically under impression that separating WAL is a big plus. On >> top of that, having separate partition to hold some other data - will do >> too. >> But it sounds - from what you said - like

Re: [GENERAL] table spaces

2013-03-12 Thread John R Pierce
On 3/12/2013 2:31 PM, Gregg Jaskiewicz wrote: I was basically under impression that separating WAL is a big plus. On top of that, having separate partition to hold some other data - will do too. But it sounds - from what you said - like having all in single logical drive will work, because raid

Re: [GENERAL] table spaces

2013-03-12 Thread Gregg Jaskiewicz
Ok, So by that token (more drives the better), I should have raid 5 (or whichever will work) with all 6 drives in it ? I was thinking about splitting it up like this. I have 6 drives (and one spare). Combine them into 3 separate logical drives in mirrored configuration (for some hardware redundan

Re: [GENERAL] table spaces

2013-03-10 Thread Scott Marlowe
On Sun, Mar 10, 2013 at 6:23 AM, Gregg Jaskiewicz wrote: > > > > On 10 March 2013 02:19, Scott Marlowe wrote: >> >> First get a baseline for how things work with just pg_xlog on one >> small set (RAID 1 is often plenty) and RAID-10 on all the rest with >> all the data (i.e. base directory) there.

Re: [GENERAL] table spaces

2013-03-10 Thread Gregg Jaskiewicz
On 10 March 2013 02:19, Scott Marlowe wrote: > > First get a baseline for how things work with just pg_xlog on one > small set (RAID 1 is often plenty) and RAID-10 on all the rest with > all the data (i.e. base directory) there. With a fast HW RAID > controller this is often just about as fast as

Re: [GENERAL] table spaces

2013-03-09 Thread Scott Marlowe
On Sat, Mar 9, 2013 at 10:51 AM, Gregg Jaskiewicz wrote: > Performance related question. > With Linux (centos 6.3+), 64bit, ext4 in mind, how would you guys go about > distributing write load across disks. > > Lets say I have quite few disks, and I can partition them the way I want, in > mirror co

Re: [GENERAL] table spaces

2013-03-09 Thread Bèrto ëd Sèra
Hi Gregg yes, keep the indexes on a separate channel. Much depends on how the data is mapped and accessed, sometimes even distributing the data itself onto different spaces may do good. If you use a lot of logging (say you feed a massive pgFouine activity), you would want to have that on yet anot

[GENERAL] table spaces

2013-03-09 Thread Gregg Jaskiewicz
Performance related question. With Linux (centos 6.3+), 64bit, ext4 in mind, how would you guys go about distributing write load across disks. Lets say I have quite few disks, and I can partition them the way I want, in mirror configuration (to get some hardware failure resilience). Should I separ