Re: [PERFORM] Easy read-heavy benchmark kicking around?
Hi, Brian, Brian Hurt wrote: > So the question is: is there an easy to install and run, read-heavy > benchmark out there that I can wave at them to get them to fix the > problem? For sequential read performance, use dd. Most variants of dd I've seen output some timing information, and if not, do a "time dd if=/your/device of=/dev/null bs=1M" on the partition. Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PERFORM] Easy read-heavy benchmark kicking around?
On 11/8/06, Markus Schaber <[EMAIL PROTECTED]> wrote: Hi, Brian, Brian Hurt wrote: > So the question is: is there an easy to install and run, read-heavy > benchmark out there that I can wave at them to get them to fix the > problem? For sequential read performance, use dd. Most variants of dd I've seen output some timing information, and if not, do a "time dd if=/your/device of=/dev/null bs=1M" on the partition. we had a similar problem with a hitachi san, the ams200. Their performance group refused to admit the fact that 50mb/sec dd test was a valid performance benchmark and needed to be addressed. Yes, that was a HITACHI SAN, the AMS200, which hitachi's performance group claimed was 'acceptable performance'. This was the advice we got after swapping out all the hardware and buying an entitlement to redhat enterprise which we had to do to get them to talk to us. oh, the unit also lost a controller after about a week of operation...the unit being a HITACHI SAN, the AMS200. any questions? merlin p.s. we have had good experiences with the adtx. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] Easy read-heavy benchmark kicking around?
Merlin Moncure wrote: On 11/8/06, Markus Schaber <[EMAIL PROTECTED]> wrote: Hi, Brian, Brian Hurt wrote: > So the question is: is there an easy to install and run, read-heavy > benchmark out there that I can wave at them to get them to fix the > problem? For sequential read performance, use dd. Most variants of dd I've seen output some timing information, and if not, do a "time dd if=/your/device of=/dev/null bs=1M" on the partition. we had a similar problem with a hitachi san, the ams200. Their performance group refused to admit the fact that 50mb/sec dd test was a valid performance benchmark and needed to be addressed. > > [...] > oh, the unit also lost a controller after about a week of operation...the unit being a HITACHI SAN, the AMS200. any questions? Yes, one. What was that unit? ;-) -- Cosimo ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PERFORM] Which OS provides the _fastest_ PostgreSQL performance?
Jean-David Beyer wrote: > > Sure, some even read the entire cylinder. But unless the data are stored > contiguously, this does little good. The Linux ext2 and ext3 file systems > try to get more contiguity by allocating (IIRC) 8 blocks each time a write > needs space >From where do you recall this? It looks to me like managing the block reservation window seems like a pretty involved process - at first glance way more sophisticated than a hardcoded 8 blocks. http://www.gelato.unsw.edu.au/lxr/source/fs/ext3/balloc.c > (and gives the unused ones back when the file is closed for > writing). But for a dbms that uses much larger page and extent sizes, this > makes little difference. This is one of the reasons a modern dbms does its > own file system and uses only the drivers to run the disk. I'd have thought the opposite. The fact that old filesystems had pretty poor block reservation algorithms and even poorer readahead algorithms is one of the reasons historical dbms writers wrote their own filesystems in the past.If you're on a '90's VMS or Win9X/FAT - you have a lot to win by having your own filesystem. With more modern OS's, less so. > That way, the > DBMS can allocate the whole partition in a contiguous lump, if need be. There's nothing that special about a database file in that regard. You may win by having the database executable program be a continuous lump too - especially if lesser used pages of the executable get swapped out (which they should - if they're accessed less frequently than a database table that could use the RAM). ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PERFORM] Easy read-heavy benchmark kicking around?
Similar experiences with HP and their SmartArray 5i controller on Linux. The answer was: "this controller has won awards for performance! It can't be slow!", so we made them test it in their own labs an prove just how awfully slow it was. In the case of the 5i, it became apparent that HP had no internal expertise on Linux and their controllers, the driver was built by a third party that they didn't support and their performance people didn't deal with the 5i at all. In the end, all manner of benchmarks after you've purchased aren't a good substitute for the up front question: do you have documentation of the performance of your RAID controller on [Linux, Solaris, ...]? I would like everyone who purchases IBM, Dell, HP or Sun to demand that documentation - then perhaps we'd see higher quality drivers and hardware result. - Luke On 11/8/06 8:34 AM, "Merlin Moncure" <[EMAIL PROTECTED]> wrote: > On 11/8/06, Markus Schaber <[EMAIL PROTECTED]> wrote: >> Hi, Brian, >> >> Brian Hurt wrote: >> >>> So the question is: is there an easy to install and run, read-heavy >>> benchmark out there that I can wave at them to get them to fix the >>> problem? >> >> For sequential read performance, use dd. Most variants of dd I've seen >> output some timing information, and if not, do a "time dd >> if=/your/device of=/dev/null bs=1M" on the partition. > > we had a similar problem with a hitachi san, the ams200. Their > performance group refused to admit the fact that 50mb/sec dd test was > a valid performance benchmark and needed to be addressed. Yes, that > was a HITACHI SAN, the AMS200, which hitachi's performance group > claimed was 'acceptable performance'. This was the advice we got > after swapping out all the hardware and buying an entitlement to > redhat enterprise which we had to do to get them to talk to us. > > oh, the unit also lost a controller after about a week of > operation...the unit being a HITACHI SAN, the AMS200. > > any questions? > > merlin > > p.s. we have had good experiences with the adtx. > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
