Re: [PERFORM] Postgresql 9.0.6 Raid 5 or not please help.
Am 23.12.2011 08:05, schrieb Scott Marlowe: On Thu, Dec 22, 2011 at 11:18 PM, tuanhoanganh wrote: Thanks for your answer. But how performance between raid5 and one disk. One disk will usually win, 2 disks (in a mirror) will definitely win. RAID-5 has the highest overhead and the poorest performance, especially if it's degraded (1 drive out) that simple mirroring methods don't suffer from. But even in an undegraded state it is usually the slowest method. RAID-10 is generally the fastest with redundancy, and of course pure RAID-0 is fastest of all but has no redundancy. You should do some simple benchmarks with something like pgbench and various configs to see for yourself. For extra bonus points, break a mirror (2 disk -> 1 disk) and compare it to RAID-5 (3 disk -> 2 disk degraded) for performance. The change in performance for a RAID-1 to single disk degraded situation is usually reads are half as fast and writes are just as fast. For RAID-5 expect to see it drop by a lot. I'm not so confident that a RAID-1 will win over a single disk. When it comes to writes, the latency should be ~50 higher (if both disk must sync), since the spindles are not running synchronously. This applies to softraid, not something like a battery-backend raid controller of course. Or am I wrong here? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Postgresql 9.0.6 Raid 5 or not please help.
I'm not so confident that a RAID-1 will win over a single disk. When it comes to writes, the latency should be ~50 higher (if both disk must sync), since the spindles are not running synchronously. This applies to softraid, not something like a battery-backend raid controller of course. Or am I wrong here? Software RAID-1 in Linux, can read data in all disks and generally increase a lot the data rate in reads. In writes, for sure, the overhead is great compared with a single disk, but not too much. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Postgresql 9.0.6 Raid 5 or not please help.
On Fri, Dec 23, 2011 at 5:15 AM, alexandre - aldeia digital wrote: >> I'm not so confident that a RAID-1 will win over a single disk. When it >> comes to writes, the latency should be ~50 higher (if both disk must >> sync), since the spindles are not running synchronously. This applies to >> softraid, not something like a battery-backend raid controller of course. >> >> Or am I wrong here? >> > > Software RAID-1 in Linux, can read data in all disks and generally increase > a lot the data rate in reads. In writes, for sure, the overhead is great > compared with a single disk, but not too much. Exactly. Unless you spend a great deal of time writing data out to the disks, the faster reads will more than make up for a tiny increase in latency for the writes to the drives. As regards the other recommendation in this thread to use two mirror sets one for xlog and one for everything else, unless you're doing a lot of writing, it's often still a winner to just run one big 4 disk RAID-10. Of course the real winner is to put a hardware RAID controller with battery backed cache between your OS and the hard drives, then the performance of even just a pair of drives in RAID-1 will be quite fast. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Postgresql 9.0.6 Raid 5 or not please help.
Thanks for all. I change to RAID 1 and here is new pg_bench result: pgbench -h 127.0.0.1 -p 5433 -U postgres -c 10 -T 1800 -s 10 pgbench Scale option ignored, using pgbench_branches table count = 10 starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 query mode: simple number of clients: 10 number of threads: 1 duration: 1800 s number of transactions actually processed: 4373177 tps = 2429.396876 (including connections establishing) tps = 2429.675016 (excluding connections establishing) Press any key to continue . . . Tuan Hoang ANh On Fri, Dec 23, 2011 at 10:25 PM, Scott Marlowe wrote: > On Fri, Dec 23, 2011 at 5:15 AM, alexandre - aldeia digital > wrote: > >> I'm not so confident that a RAID-1 will win over a single disk. When it > >> comes to writes, the latency should be ~50 higher (if both disk must > >> sync), since the spindles are not running synchronously. This applies to > >> softraid, not something like a battery-backend raid controller of > course. > >> > >> Or am I wrong here? > >> > > > > Software RAID-1 in Linux, can read data in all disks and generally > increase > > a lot the data rate in reads. In writes, for sure, the overhead is great > > compared with a single disk, but not too much. > > Exactly. Unless you spend a great deal of time writing data out to > the disks, the faster reads will more than make up for a tiny increase > in latency for the writes to the drives. > > As regards the other recommendation in this thread to use two mirror > sets one for xlog and one for everything else, unless you're doing a > lot of writing, it's often still a winner to just run one big 4 disk > RAID-10. > > Of course the real winner is to put a hardware RAID controller with > battery backed cache between your OS and the hard drives, then the > performance of even just a pair of drives in RAID-1 will be quite > fast. > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >
Re: [PERFORM] Postgresql 9.0.6 Raid 5 or not please help.
On Fri, Dec 23, 2011 at 8:32 AM, tuanhoanganh wrote: > Thanks for all. I change to RAID 1 and here is new pg_bench result: > > pgbench -h 127.0.0.1 -p 5433 -U postgres -c 10 -T 1800 -s 10 pgbench > Scale option ignored, using pgbench_branches table count = 10 > starting vacuum...end. > transaction type: TPC-B (sort of) > scaling factor: 10 > query mode: simple > number of clients: 10 > number of threads: 1 > duration: 1800 s > number of transactions actually processed: 4373177 > tps = 2429.396876 (including connections establishing) > tps = 2429.675016 (excluding connections establishing) > Press any key to continue . . . Note that those numbers are really only possible if your drives are lying about fsync or you have fsync turned off or you have a battery backed caching RAID controller. I.e. your database is likely not crash-proof. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
