Re: H/W RAID 5 on slower disks versus no raid on faster HDDs
От | Nikolaus Dilger |
---|---|
Тема | Re: H/W RAID 5 on slower disks versus no raid on faster HDDs |
Дата | |
Msg-id | 20021124194154.18989.h017.c001.wm@mail.dilger.cc.criticalpath.net обсуждение исходный текст |
Ответ на | H/W RAID 5 on slower disks versus no raid on faster HDDs ("Rajesh Kumar Mallah." <mallah@trade-india.com>) |
Ответы |
Re: H/W RAID 5 on slower disks versus no raid on faster HDDs
(David Gilbert <dgilbert@velocet.ca>)
|
Список | pgsql-admin |
Mallah, I agree with Chris. The fastest is to have an in memory database. Raid 0 (striping) will speed up both reading and writing since you have more available disk I/O bandwidth. SCSI320 in theory is twice as fast as SCSI160. But the bottleneck will be the throughput of the individual disks. 15,000 rpm of course will be faster than 10,000 rpm. More interesting then the rpm numbers itself are seek time and transfer rate. In a production environment I would always favor some kind of error protection. Either RAID 5 or RAID 1 (mirroring). A hardware RAID controller is faster than software RAID. For pure speed raw devices would be faster then file systems. However, PostgeSQL currently does not support them. Given your 2 choices b) should be faster. a) 3*18 GB 10,000 RPM Ultra160 Dual Channel SCSI controller + H/W Raid 5 b) 2*36 GB 15,000 RPM Ultra320 Dual Channel SCSI and no RAID Option b) can be improved by using striping. Save your money on the SCSI Ultra320 since the disk cant transfer enough data anyway and buy more memory instead. And finally good application design has a greater impact on performance than a little faster hardware. Regards, Nikolaus Dilger On Thu, 21 Nov 2002, Chris Ruprecht wrote: > > raid 0 (striping) spreads the load over multiple > spindels, the same way raid 5 > does. but raid 5 always needs to calculate parity and > write that to it's > parity drive. > > RPM isn't that critical, a lot depends on the machine, > the processor and the > memory (and the spped with which the processor can get > to the memory). I have > recently tested a lot of systems with some database > benchmarks we wrote here > at work. We're not running Postgres here at work, > sorry, these benchmarks are > of no use to Postgres ... > We we found is that a lot depends on motherboard > design, not so much on drive > speed. We got to stages where we allocated 1.8 GB of > RAM to shared memory for > the database server process, resulting in the entire > database being sucked > into memory. When doing reads, 100% of the data is > coming out the that > menory, and drive speed becomes irrelevant. > > From tests I did with Postgres on my boxes at home, I > can say: The more shared > memory you can throw at the server process, the better. > Under MacOS X I > wasn't able to allocate more than 3 MB, Under Linux, I > can allocate anything > I want to, so I usually start up the server with 256 > MB. The difference? A > process which takes 4 minutes under Linux, takes 6 > hours under MacOS - same > hardware, same drives, different memory settings. > > Best regards, > Chris > > On Thursday 21 November 2002 12:02, you wrote: > > Thanks Chris, > > > > does raid0 enhances both read/write both? > > > > does rpms not matter that much? > > > > regds > > mallah. > > > > On Thursday 21 November 2002 22:27, you wrote: > > > RAID 5 gives you pretty bad performance, a slowdown > of about 50%. For > > > pure performance, I'd use the 3 18 GB drives with > RAID 0. > > > > > > If you need fault tolerance, you could use RAID 0+1 > or 1+0 but you'd need > > > an even number of drives for that, of which half > would become 'usable > > > space'. > > > > > > Best regards, > > > Chris > > > > > > On Thursday 21 November 2002 11:45, you wrote: > > > > Hi folks, > > > > > > > > I have two options: > > > > 3*18 GB 10,000 RPM Ultra160 Dual Channel SCSI > controller + H/W Raid 5 > > > > and > > > > 2*36 GB 15,000 RPM Ultra320 Dual Channel SCSI and > no RAID > > > > > > > > Does anyone opinions *performance wise* the pros > and cons of above > > > > two options. > > > > > > > > please take in consideration in latter case its > higher RPM and better > > > > SCSI interface. > > > > > > > > > > > > > > > > Regds > > > > Mallah. > > -- > Network Grunt and Bit Pusher extraordinaire > > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > <a href="http://mail.dilger.cc/jump/http://www.postgresql.org/users-lounge/docs/faq.html">http://www.postgresql.org/users-lounge/docs/faq.html</a>
В списке pgsql-admin по дате отправления: