Re: [GENERAL] Recomended FS
Maybe it is a little late to be posting on this thread - but I was doing pgbench runs with a Raid 0 ATA system and thought the results might be interesting. So here they are : pgbench -c 5 -t 1000 -s 5, median of 3 runs on a Dual PIII 700 512Mb 2x7200 RPM ATA 133 Promise TX200 (same method / Pg configuration parameters as Scott's): 2 disk Raid0 W0 66 tps 2 disk Raid0 W1 220 tps I was expecting a slightly better result for W0 (write caching off), mind you the point could be made that you get about half the performance of the SCSI system - for about half the price. And the W1 result - that's fast, when (or if) that little power saving capacitor arrives for these drives we could see performance, reliability *and* economy regards Mark scott.marlowe wrote: MachineA Config1: 141 tps MachineB Config1 W0: 60 tps MachineB Config1 W1: 112 tps MachineA Config2: 101 tps MachineB Config2 W0: 44 tps MachineB Config2 W1: 135 tps ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Recomended FS
Really solid microcode actually reads the sectors just written and confirms the write at the hardware level by comparing it with what is in the controller memory. It then returns with a successfull confirmation or an error if differences were detected. Any data storage device controller, disk, memory stick, whatever that does not follow this fundamental common sense protocol is not reliable and should not be used, period! Perhaps the IDE designers have folded to management pressure and tried to make their drives seem faster by not taking the time to actually confirm the write at the hardware level. I don't know, but it looks like this may be a possiblity. Lynn Quoting scott.marlowe [EMAIL PROTECTED]: On Sat, 25 Oct 2003, James Moe wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Oct 2003 16:24:17 +1300, Mark Kirkwood wrote: I would conclude that it not *always* the case that power failure renders the database unuseable. I have just noticed a similar posting from Scott were he finds the cache enabled case has a dead database after power failure. Other posts have noted that SCSI never fails under this condition. Apparently SCSI drives sense an impending power loss and flush the cache before power completely disappears. Speed *and* reliability. Hm. Actually, it would appear that the SCSI drives simply don't lie about fsync. I.e. when they tell the OS that they wrote the data, they wrote the data. Some of them may have caching flushing with lying about fsync built in, but the performance looks more like just good fsyncing to me. It's all a guess without examining the microcode though... :-) Of course, anyone serious about a server would have it backed up with a UPS and appropriate software to shut the system down during an extended power outage. This just leaves people tripping over the power cords or maliciously pulling the plugs. Or a CPU frying, or a power supply dying, or a motherboard failure, or a kernel panic, or any number of other possibilities. Admittedly, the first line of defense is always good backups, but it's nice knowing that if one of my CPUs fry, I can pull it, put in the terminator / replacement, and my whole machine will likely come back up. But anyone serious about a server will also likely be running on SCSI as well as on a UPS. We use a hosting center with 3 UPS and a Diesel generator, and we still managed to lose power about a year ago when one UPS went haywire, browned out the circuits of the other two, and the diesel generator's switch burnt out. Millions of dollars worth of UPS / high reliability equipment, and a $50 switch brought it all down. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Recomended FS
scott.marlowe wrote: Was there a performance difference in the set with write cache on or off? Yes - just in the process of a little study concerning this - I will post some preliminary results soon cheers Mark ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Recomended FS
On Sat, 25 Oct 2003, James Moe wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Oct 2003 16:24:17 +1300, Mark Kirkwood wrote: I would conclude that it not *always* the case that power failure renders the database unuseable. I have just noticed a similar posting from Scott were he finds the cache enabled case has a dead database after power failure. Other posts have noted that SCSI never fails under this condition. Apparently SCSI drives sense an impending power loss and flush the cache before power completely disappears. Speed *and* reliability. Hm. Actually, it would appear that the SCSI drives simply don't lie about fsync. I.e. when they tell the OS that they wrote the data, they wrote the data. Some of them may have caching flushing with lying about fsync built in, but the performance looks more like just good fsyncing to me. It's all a guess without examining the microcode though... :-) Of course, anyone serious about a server would have it backed up with a UPS and appropriate software to shut the system down during an extended power outage. This just leaves people tripping over the power cords or maliciously pulling the plugs. Or a CPU frying, or a power supply dying, or a motherboard failure, or a kernel panic, or any number of other possibilities. Admittedly, the first line of defense is always good backups, but it's nice knowing that if one of my CPUs fry, I can pull it, put in the terminator / replacement, and my whole machine will likely come back up. But anyone serious about a server will also likely be running on SCSI as well as on a UPS. We use a hosting center with 3 UPS and a Diesel generator, and we still managed to lose power about a year ago when one UPS went haywire, browned out the circuits of the other two, and the diesel generator's switch burnt out. Millions of dollars worth of UPS / high reliability equipment, and a $50 switch brought it all down. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Recomended FS
On Fri, 24 Oct 2003, Scott Chapman wrote: On Friday 24 October 2003 16:23, scott.marlowe wrote: Right, but NONE of the benchmarks I've seen have been with IDE drives with their cache disabled, which is the only way to make them reliable under postgresql should something bad happen. but thanks for the benchmarks, I'll look them over. I don't recall seeing anyone explain how to disable caching on a drive in this thread. Did I miss that? 'Would be useful. I'm running a 3Ware mirror of 2 IDE drives. Scott Each OS has it's own methods, and some IDE RAID cards don't give you direct access to the drives to enable / disable write cache. On Linux you can disable write cache like so: hdparm -W0 /dev/hda back on: hdparm -W1 /dev/hda ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Recomended FS
On Sun, 26 Oct 2003, Mark Kirkwood wrote: Got to going this today, after a small delay due to the arrival of new disks, So the system is 2x700Mhz PIII, 512 Mb, Promise TX2000, 2x40G ATA-133 Maxtor Diamond+8 . The relevent software is Freebsd 4.8 and Postgresql 7.4 Beta 2. Two runs of 'pgbench -c 50 -t 100 -s 10 bench' with a power cord removal after about 2 minutes were performed, one with hw.ata.wc = 1 (write cache enabled) and other with hw.ata.wc = 0 (disabled). In *both* cases the Pg server survived - i.e it came up, performed automatic recovery. Subsequent 'vacuum full' and further runs of pgbench completed with no issues. Sweet. It may be that the promise is turning off the cache, or that the new generation of IDE drives is finally reporting fsync correctly. Was there a performance difference in the set with write cache on or off? I would conclude that it not *always* the case that power failure renders the database unuseable. But it usually is if write cache is enabled. I have just noticed a similar posting from Scott were he finds the cache enabled case has an dead database after power failure. It seems that it's a question of how *likely* is it that the database will survive/not survive a power failure... The other interesting possibility is that Freebsd with soft updates helped things remain salvageable in the cache enabled case (as some writes *must* be lost at power off in this case) Free BSD may be the reason here. If it's softupdates are ordered in the right way, it may be that even with write caching on, the drives do the right thing under BSD. Time to get out my 5.0 disks and start playing with my test server. Thanks for the test! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Recomended FS
scott.marlowe [EMAIL PROTECTED] writes: Sweet. It may be that the promise is turning off the cache, or that the new generation of IDE drives is finally reporting fsync correctly. Was there a performance difference in the set with write cache on or off? Check out this thread. It seems the ATA standard does not include any way to make fsync work properly without destroying performance. At least on linux even that much is impossible without disabling caching entirely as the operation required isn't exposed to user-space. There is some hope for the future though. http://www.ussg.iu.edu/hypermail/linux/kernel/0310.2/0163.html The other interesting possibility is that Freebsd with soft updates helped things remain salvageable in the cache enabled case (as some writes *must* be lost at power off in this case) Free BSD may be the reason here. If it's softupdates are ordered in the right way, it may be that even with write caching on, the drives do the right thing under BSD. Time to get out my 5.0 disks and start playing with my test server. Thanks for the test! I thought soft updates applied only to directory metadata changes. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Recomended FS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Oct 2003 16:24:17 +1300, Mark Kirkwood wrote: I would conclude that it not *always* the case that power failure renders the database unuseable. I have just noticed a similar posting from Scott were he finds the cache enabled case has a dead database after power failure. Other posts have noted that SCSI never fails under this condition. Apparently SCSI drives sense an impending power loss and flush the cache before power completely disappears. Speed *and* reliability. Hm. Of course, anyone serious about a server would have it backed up with a UPS and appropriate software to shut the system down during an extended power outage. This just leaves people tripping over the power cords or maliciously pulling the plugs. - -- jimoe at sohnen-moe dot com pgp/gpg public key: http://www.keyserver.net/en/ -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0 OS/2 for non-commercial use Comment: PGP 5.0 for OS/2 Charset: cp850 wj8DBQE/m2PQsxxMki0foKoRAjsOAJ0ed1MV8FcWcALoxIJk66wn40EEvwCfVTPB n/rxejkV2upgeZmoy3yipes= =fDes -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Recomended FS
On Sat, Oct 25, 2003 at 11:04:00PM -0700, James Moe wrote: Other posts have noted that SCSI never fails under this condition. Apparently SCSI drives sense an impending power loss and flush the cache before power completely disappears. Speed *and* reliability. Hm. I understood it differently. Postgresql has WAL to deal with this situation. This issue that it only works as long as the drive doesn't lie about which blocks have been written and which are merely in cache. Apparently IDE disks lie and SCSI disks don't. It may be a protocol thing. The other alternative is battery backed memory. i.e. keep the blocks in memory hoping that power will return to the drive before it fails. Some RAID cards do this. Another thing is that 3ware RAID controllers stick a SCSI interface in front of the IDE drives, so perhaps it has more scope to deal with this issue. Remember, when power fails the first thing that happens is the system cancels any DMA tranfer in progress as memory is the part most sensative to power fluctuations. Of course, anyone serious about a server would have it backed up with a UPS and appropriate software to shut the system down during an extended power outage. This just leaves people tripping over the power cords or maliciously pulling the plugs. If you start adding up the points of failure it's quite a lot. But you should be able to proof the system against even malicious tampering. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ All that is needed for the forces of evil to triumph is for enough good men to do nothing. - Edmond Burke The penalty good people pay for not being interested in politics is to be governed by people worse than themselves. - Plato pgp0.pgp Description: PGP signature
Re: [GENERAL] Recomended FS
On Friday 24 October 2003 16:23, scott.marlowe wrote: Right, but NONE of the benchmarks I've seen have been with IDE drives with their cache disabled, which is the only way to make them reliable under postgresql should something bad happen. but thanks for the benchmarks, I'll look them over. I don't recall seeing anyone explain how to disable caching on a drive in this thread. Did I miss that? 'Would be useful. I'm running a 3Ware mirror of 2 IDE drives. Scott ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Recomended FS
On Tue, Oct 21, 2003 at 11:42:50 +0200, Ben-Nes Michael [EMAIL PROTECTED] wrote: what about mirroring only ? raid 1 ? I always thought that raid 1 is the fastest, am I true ? If you have more than two disks than mirroring plus striping can be faster. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Recomended FS
Got to going this today, after a small delay due to the arrival of new disks, So the system is 2x700Mhz PIII, 512 Mb, Promise TX2000, 2x40G ATA-133 Maxtor Diamond+8 . The relevent software is Freebsd 4.8 and Postgresql 7.4 Beta 2. Two runs of 'pgbench -c 50 -t 100 -s 10 bench' with a power cord removal after about 2 minutes were performed, one with hw.ata.wc = 1 (write cache enabled) and other with hw.ata.wc = 0 (disabled). In *both* cases the Pg server survived - i.e it came up, performed automatic recovery. Subsequent 'vacuum full' and further runs of pgbench completed with no issues. I would conclude that it not *always* the case that power failure renders the database unuseable. I have just noticed a similar posting from Scott were he finds the cache enabled case has an dead database after power failure. It seems that it's a question of how *likely* is it that the database will survive/not survive a power failure... The other interesting possibility is that Freebsd with soft updates helped things remain salvageable in the cache enabled case (as some writes *must* be lost at power off in this case) regards Mark scott.marlowe wrote: OK, but here's the real test. As the postgres user, run 'pgbench -i', then after that runs, run 'pgbench -c 50 -t 100'. While it's running and settled (pg aux|grep postgres|wc -l should show a number of ~54 or so.) pull the plug. Wait for the hard drives to spin down, then plug it back in and power it one. With SCSI you will still have a coherent database. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Recomended FS
- Original Message - From: Shridhar Daithankar [EMAIL PROTECTED] To: Ben-Nes Michael [EMAIL PROTECTED] Cc: Nick Burrett [EMAIL PROTECTED]; postgresql [EMAIL PROTECTED] Sent: Monday, October 20, 2003 3:06 PM Subject: Re: [GENERAL] Recomended FS Ben-Nes Michael wrote: I'm saying: don't expect your DB performance to come on leaps and bounds just because you changed to a different filesystem format. If you've got speed problems then it might help to look elsewhere first. I dont expect miracles :) but still i have to choose one,so why shouldnt i choose the one which best fit ? All things being equal, you should optimise your application design and database tuning before you choose file system. If a thing works well for you, with a better file system it will just work better. That's the point. I agree, but still ill have to choose an FS, does the list have any opinion on what FS to choose ? Shridhar ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Recomended FS
Ben-Nes Michael wrote: - Original Message - From: Nick Burrett [EMAIL PROTECTED] Ben-Nes Michael wrote: But still the greatest question is what FS to put on ? I heard Reiesref can handle small files very quickly. Switching from ext3 to reiserfs for our name servers reduced the time taken to load 110,000 zones from 45 minutes to 5 minutes. However for a database, I don't think you can really factor this type of stuff into the equation. The performance benefits you get from different filesystem types are going to be small compared to the modifications that you can make to your database structure, queries and applications. The actual algorithms used in processing the data will be much slower than the time taken to fetch the data off disk. So you say the FS has no real speed impact on the SB ? In my pg data folder i have 2367 files, some big some small. I'm saying: don't expect your DB performance to come on leaps and bounds just because you changed to a different filesystem format. If you've got speed problems then it might help to look elsewhere first. -- Nick Burrett Network Engineer, Designer Servers Ltd. http://www.dsvr.co.uk ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Recomended FS
Ben-Nes Michael wrote: But still the greatest question is what FS to put on ? I heard Reiesref can handle small files very quickly. Switching from ext3 to reiserfs for our name servers reduced the time taken to load 110,000 zones from 45 minutes to 5 minutes. However for a database, I don't think you can really factor this type of stuff into the equation. The performance benefits you get from different filesystem types are going to be small compared to the modifications that you can make to your database structure, queries and applications. The actual algorithms used in processing the data will be much slower than the time taken to fetch the data off disk. -- Nick Burrett Network Engineer, Designer Servers Ltd. http://www.dsvr.co.uk ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Recomended FS
Peter Childs wrote: On Mon, 20 Oct 2003, Shridhar Daithankar wrote: A fast HD with a good RAID controller. Subject to budget, SCSI are beter buy than IDE. So does hardware SCSI RAID. I hate asking this again. But WHY? OK.. There are only few SCSI disks that I have handled so take it with grain of salt. 1. SCSI bus can share bandwidth much better than IDE disks. Put two IDE disks on same channel and two SCSI disks. See which combo performs better. 2. Unconfirmed SCSI disks are idividually tested and IDEs are sampled. Makes a big difference in reliability. I know for some people IDE disks do not crash at all but majority think SCSI are more reliable than IDEs. 3. SCSI disks have Tag commands and things alike, that makes them better at handling load. Technically, if you don't know the load, SCSI would make a better choice. If you know your load very well and it is predictive, IDE might be a choice. I would personally prefer IDE disk array with hardware RAID controller because I can put it in my home machine, unlike SCSI. But every developer I have asked around here, says that IDE performance starts dropping once you hit real world load. Shridhar ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Recomended FS (correction)
Mark Kirkwood wrote: I should have said that I was using Freebsd 4.8 with write caching off. write caching *on* - I got myself confused about what the value 1 means ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Recomended FS
On Wed, 22 Oct 2003, Joshua D. Drake wrote: I believe that 3ware have a non blocking implementation of ATA RAID - I intend to sell the Promise and obtain a 3ware in the next month of so and test this out. I use 3Ware exclusively for my ATA-RAID solutions. The nice thing about them is that they are REAL hardware RAID and the use the SCSI layer within Linux so you address them as a standard SCSI device. Also their support is in the kernel... no wierd, experimental patching. On a Dual 2000 Athlon MP I was able to sustain 50MB/sec over large copys (4+ gigs). Very, Very happy with them. Do they survive the power plug pulling test I was talking about elsewhere in this thread? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Recomended FS
Its worth checking - isn't it ? I appeciate that you may have performed such tests previously - but as hardware and software evolve its often worth repeating such tests (goes away to do the suggested one tonight). Note that I am not trying to argue away the issue about write caching - it *has* to increase the risk of database corruption following a power failure, however if your backups are regular and reliable this may be a risk worth taking to achieve acceptable performance at a low price. regards Mark scott.marlowe wrote: Assuming that the caching was on, I'm betting your database won't survive a power plug pull in the middle of transactions like the test I put up above. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Recomended FS
Mark Kirkwood wrote: Its worth checking - isn't it ? I appeciate that you may have performed such tests previously - but as hardware and software evolve its often worth repeating such tests (goes away to do the suggested one tonight). Note that I am not trying to argue away the issue about write caching - it *has* to increase the risk of database corruption following a power failure, however if your backups are regular and reliable this may be a risk worth taking to achieve acceptable performance at a low price. Sure, but how many people are taking that risk and not knowing it! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Recomended FS
Some sort of ATA Raid is probably worth considering - e.g. I am experimenting with a system using 2 ATA-66 Seagates + 1 Promise TX2000 The disks themselves give fairly poor performance when attached to the std IDE channels : sequential write 15Mb/s sequential read 20Mb/s But attached to the Promise card using RAID 0 do considerably better: sequential write 52Mb/s sequential read 52MB/s Now you would probably not use RAID 0 for a real system (unless you had good backups), but the difference is interesting Note that even including the card, this is a very cheap setup. (I have not gotten around to testing random read and writes, but if anybody is interested I can test this and supply figures) regards Mark Steve Crawford wrote: Talk about timing...this article posted today seems quite apropos (spoiler: SCSI beats IDE): http://hardware.devchannel.org/hardwarechannel/03/10/20/1953249.shtml?tid=20tid=38tid=49 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Recomended FS
On Mon, Oct 20, 2003 at 08:09:34AM -0400 I heard the voice of Jeff, and lo! it spake thus: insured shipping. But yeah, new scsi is quite expensive, but it can be worth it... IMHO scsi is to be used in a raid, not alone. No one disk can saturate the bw offered. (both ide and scsi). The difference is that IDE *HAS* to be able to saturate the bus (which it can't, of course; show me an IDE drive that pushes even 66MB/sec off the platter) for the bus speed to matter, since IDE doesn't support disconnection. Multiple SCSI drives can be stuffing data over the SCSI channel all at once. They don't have to be RAID'd, they can be different filesystems accessed in parallel. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Recomended FS
Hi! -Ursprüngliche Nachricht- Von: Shridhar Daithankar [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 21. Oktober 2003 08:08 An: [EMAIL PROTECTED] Betreff: Re: [GENERAL] Recomended FS Can you compare ogbench results for the RAID and single IDE disks? It would be great if you could turn off write caching of individual drives in RAID and test it as well. One thing I can say from previous experiences is that the type of RAID does matter quite a lot. RAID5, even with a quite expensive Adaptec SCSI-hardware-controller, is not always the best solution for a database, particularly if there's a lot of INSERTs and UPDATEs going on. If you're not too dependant on raw storage size, your best bet is to use the space-consuming RAID0+1 instead; the reasoning behind this is probably that on RAID5 the controller has to calculate the parity-data for every write-access, on RAID0+1 it just mirrors and distributes the data, reducing overall load on the controller and making use of more spindles and two-channel-SCSI. We're hosting some DB-intensive websites (12M impressions/month) on two PostgreSQL-servers (one DELL Poweredge 6400, 4xPentium III [EMAIL PROTECTED], 2GB RAM, 4x18GB SCSI in RAID0+1, 1 hot-spare and one Dell Poweredge 6650, 4x Intel [EMAIL PROTECTED], 4GB RAM, 4x36 GB SCSI in RAID0+1, 1 hot-spare) and when I switched the 5-disc-RAID5-config over to a 4-disc-RAID0+1 plus one hotspare, I noticed system-load dropping by a very considerable amount. I haven't got any benchmark-figures to show off though, it's just experiences from a realworld application. Regards Markus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Recomended FS
On Tue, 21 Oct 2003, Markus Wollny wrote: Hi! -Ursprüngliche Nachricht- Von: Shridhar Daithankar [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 21. Oktober 2003 08:08 An: [EMAIL PROTECTED] Betreff: Re: [GENERAL] Recomended FS Can you compare ogbench results for the RAID and single IDE disks? It would be great if you could turn off write caching of individual drives in RAID and test it as well. One thing I can say from previous experiences is that the type of RAID does matter quite a lot. RAID5, even with a quite expensive Adaptec SCSI-hardware-controller, is not always the best solution for a database, particularly if there's a lot of INSERTs and UPDATEs going on. If you're not too dependant on raw storage size, your best bet is to use the space-consuming RAID0+1 instead; the reasoning behind this is probably that on RAID5 the controller has to calculate the parity-data for every write-access, on RAID0+1 it just mirrors and distributes the data, reducing overall load on the controller and making use of more spindles and two-channel-SCSI. Theory vs. real life. In Theory, RAID5 is faster because less data have to be written to disk. But it's true, many RAID5 controllers don't have enough CPU power. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Recomended FS
Theory vs. real life. In Theory, RAID5 is faster because less data have to be written to disk. But it's true, many RAID5 controllers don't have enough CPU power. I think it might not be just CPU-power of the controller. For RAID0+1 you just have two disc-I/O per write-access: writing to the original set and the mirror-set. For RAID5 you have three additional disc-I/O-processes: 1. Read the original data block, 2. read the parity block (and calculate the new parity block, which is not a disk I/O), 3. write the updated data block and 4. write the updated parity block. Thus recommendations by IBM for DB/2 and several Oracle-consultants state that RAID5 is the best compromise for storage vs. transaction speed, but if your main concern is the latter, you're always best of with RAID0+1; RAID0+1 does indeed always and reproducably have better write performance that RAID0+1 and read-performance is almost always also slightly better. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Recomended FS
what about mirroring only ? raid 1 ? I always thought that raid 1 is the fastest, am I true ? I don't really need more then 3GB data and I have two 36GB HD. so I don't need lvl 0 nor lvl 5 unless raid 1 is slower. -- Canaan Surfing Ltd. Internet Service Providers Ben-Nes Michael - Manager Tel: 972-4-6991122 Fax: 972-4-6990098 http://www.canaan.net.il -- - Original Message - From: Markus Wollny [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 11:00 AM Subject: Re: [GENERAL] Recomended FS Theory vs. real life. In Theory, RAID5 is faster because less data have to be written to disk. But it's true, many RAID5 controllers don't have enough CPU power. I think it might not be just CPU-power of the controller. For RAID0+1 you just have two disc-I/O per write-access: writing to the original set and the mirror-set. For RAID5 you have three additional disc-I/O-processes: 1. Read the original data block, 2. read the parity block (and calculate the new parity block, which is not a disk I/O), 3. write the updated data block and 4. write the updated parity block. Thus recommendations by IBM for DB/2 and several Oracle-consultants state that RAID5 is the best compromise for storage vs. transaction speed, but if your main concern is the latter, you're always best of with RAID0+1; RAID0+1 does indeed always and reproducably have better write performance that RAID0+1 and read-performance is almost always also slightly better. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Recomended FS
On Tuesday 21 October 2003 11:26, Mark Kirkwood wrote: (I have not gotten around to testing random read and writes, but if anybody is interested I can test this and supply figures) Can you compare ogbench results for the RAID and single IDE disks? It would be great if you could turn off write caching of individual drives in RAID and test it as well. I think for lot of databases IDE RAID could be a good compramise. Just remember its not the best out there. So use it when you have good backups..:-) Shridhar ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Recomended FS
On Tue, 21 Oct 2003, Ben-Nes Michael wrote: what about mirroring only ? raid 1 ? I always thought that raid 1 is the fastest, am I true ? I don't really need more then 3GB data and I have two 36GB HD. so I don't need lvl 0 nor lvl 5 unless raid 1 is slower. Raid 1 should not be slower than raid 5. hence Raid 0 Write = Deciede which disk, Write Read = Deciede Which disk, Read Raid 1 Write = Write Disk 1, Write Dist 2 Read = Read (Don't matter which one) Raid 5 Write = Write Disk 1, Write Disk 2, Calc Check Sum, Write Disk 3 Read = Read Disk 1, Read Disk 2, Regenate Data. Peter Childs -- Canaan Surfing Ltd. Internet Service Providers Ben-Nes Michael - Manager Tel: 972-4-6991122 Fax: 972-4-6990098 http://www.canaan.net.il -- - Original Message - From: Markus Wollny [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 11:00 AM Subject: Re: [GENERAL] Recomended FS Theory vs. real life. In Theory, RAID5 is faster because less data have to be written to disk. But it's true, many RAID5 controllers don't have enough CPU power. I think it might not be just CPU-power of the controller. For RAID0+1 you just have two disc-I/O per write-access: writing to the original set and the mirror-set. For RAID5 you have three additional disc-I/O-processes: 1. Read the original data block, 2. read the parity block (and calculate the new parity block, which is not a disk I/O), 3. write the updated data block and 4. write the updated parity block. Thus recommendations by IBM for DB/2 and several Oracle-consultants state that RAID5 is the best compromise for storage vs. transaction speed, but if your main concern is the latter, you're always best of with RAID0+1; RAID0+1 does indeed always and reproducably have better write performance that RAID0+1 and read-performance is almost always also slightly better. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Recomended FS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 21 Oct 2003 18:56:52 +1300, Mark Kirkwood wrote: Note that even including the card, this is a very cheap setup. Yes, this is the single advantage of IDE vs SCSI. If the price of the storage system is the *only* consideration, IDE is the way to go. SCSI has a long history of providing sustained throughput for server systems. IDE has a short history of providing very cheap storage for desktops. - -- jimoe at sohnen-moe dot com pgp/gpg public key: http://www.keyserver.net/en/ -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0 OS/2 for non-commercial use Comment: PGP 5.0 for OS/2 Charset: cp850 wj8DBQE/lT/NsxxMki0foKoRAvQMAKDKcQipqioww6aVc+kbCXUAdLtLUwCfe2Wo Zdkcklqi45qBXpRsznne3QE= =H19u -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Recomended FS
On Monday 20 October 2003 10:28 am, scott.marlowe wrote: On Mon, 20 Oct 2003, Peter Childs wrote: On Mon, 20 Oct 2003, Shridhar Daithankar wrote: A fast HD with a good RAID controller. Subject to budget, SCSI are beter buy than IDE. So does hardware SCSI RAID. I hate asking this again. But WHY? What SCSI gain in spinning at 15000RPM and larger buffers. They lose in Space, and a slower bus. I would like to see some profe. Sorry. SCSI beats IDE hands down for databases, and for one reason above all the rest. They don't generally lie about fsync. Talk about timing...this article posted today seems quite apropos (spoiler: SCSI beats IDE): http://hardware.devchannel.org/hardwarechannel/03/10/20/1953249.shtml?tid=20tid=38tid=49 Cheers, Steve ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Recomended FS
This site: http://fsbench.netnation.com/ has some decent generic file system benchmarks that may help with your decision. On Mon, 2003-10-20 at 10:32, Murthy Kambhampaty wrote: You'd be well served if you could benchmark several filesystems and see which one gives the best performance (talk about a loaded term) for your application. Having said that, however, I'd recommend XFS for its combination of performance and userspace tools (particularly xfsdump and xfs_freeze). Cheers, Murthy -Original Message- From: Ben-Nes Michael [mailto:[EMAIL PROTECTED] Sent: Monday, October 20, 2003 04:48 To: postgresql Subject: [GENERAL] Recomended FS Hi I'm upgrading the DB sever hardware and also the Linux OS. My Questions are: 1. What is the preferred FS to go with ? EXT3, Reiseref, JFS, XFS ? ( speed, efficiency ) 2. What is the most importent part in the Hardware ? fast HD, alot of mem, or maybe strong cpu ? Thanks in Advance -- Canaan Surfing Ltd. Internet Service Providers Ben-Nes Michael - Manager Tel: 972-4-6991122 Fax: 972-4-6990098 http://www.canaan.net.il -- ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Best Regards, Mike Benoit ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Recomended FS
Hi Ben, You asked so here's my take on the subject, but I've gotta say that you can't go far wrong with reading Bruce Momjian's paper at: http://www.ca.postgresql.org/docs/momjian/hw_performance/ But with that aside. 1. Unless your doing major league DB stuff, the FS should make more than marginal difference, if it's Journaled then it's good. You can take all the time benchmarking that you want, just be sure your ROI is worth the time you invest. My favourite fs is Reiser, but in the cold light of day, ext3 is supported in more places. My first choice is Reiser, since I used it even when it was "unstable" on production servers and it never let me down. I often use one or the other. 2. Bruce's article really is good for this question, but in a nutshell you need to get as much of the DB as close to the CPU as possible. As with any serious application, you can't beat a good L1/L2 cache, then plenty of RAM/Memory ... DBs yum RAM, the more the merrier. Lastly fast and wide disc access, remember disk access will be the slowest part of the system, and in an ideal world you'd fit nearly all of your DB in RAM if it was practical and safe. You'd probably gain more from taking the time to really ensure that your DB is designed flawlessly, and all your indexes are where they're needed. All of the basics come into play, but a well built RDBMS system is greater than the sum of its parts. For further reading check out: http://www.argudo.org/postgresql/soft-tuning.html It all adds up!!. Good Luck Tony. Ben-Nes Michael wrote: Hi I'm upgrading the DB sever hardware and also the Linux OS. My Questions are: 1. What is the preferred FS to go with ? EXT3, Reiseref, JFS, XFS ? ( speed, efficiency ) 2. What is the most importent part in the Hardware ? fast HD, alot of mem, or maybe strong cpu ? Thanks in Advance -- Canaan Surfing Ltd. Internet Service Providers Ben-Nes Michael - Manager Tel: 972-4-6991122 Fax: 972-4-6990098 http://www.canaan.net.il -- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Recomended FS
Ben-Nes Michael writes: 1. What is the preferred FS to go with ? EXT3, Reiseref, JFS, XFS ? ( speed, efficiency ) PostgreSQL might work better on simple file systems, so you avoid making the head run all over the place for writing its own log and the PostgreSQL log. Some have even suggested FAT for the data files. Good bets for improving performance are putting the WAL logs and the indexes not on the same spindle as the table files. Of course, certain RAID configurations achieve a similar effect. 2. What is the most importent part in the Hardware ? fast HD, alot of mem, or maybe strong cpu ? Lots of memory, so you can cache a large fraction of the data in memory. A good hard disk, if you do a lot of updates and/or your memory is not big enough to cache most of the data. CPU is not as important. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
