Re: [PERFORM] inferior SCSI performance
> "CB" == Christopher Browne <[EMAIL PROTECTED]> writes: CB> Unfortunately, while there are companies hawking SSDs, they are in the CB> "you'll have to talk to our salescritter for pricing" category, which CB> means that they must be ferociously expensive. :-(. You ain't kidding. Unfortunately, one of the major vendors just went belly up (Imperial Technology) so pricing probably won't get any better anytime soon. Perhaps one of these days I'll try that experiment on my SSD... ;-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ ---(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: [PERFORM] inferior SCSI performance
Andrew Sullivan wrote: Yes. If and only if you have a battery-backed cache. I know of no IDE drives that have that, but there's nothing about the spec which makes it impossible. http://www.ussg.iu.edu/hypermail/linux/kernel/0103.0/1084.html Relevant section: Maybe that is why there is a vender disk-cache dump zone on the edge of the platters...just maybe you need to buy your drives from somebody that does this and has a predictive sector stretcher as the energy from the inertia by the DC three-phase motor executes the dump. Ever wondered why modern drives have open collectors on the databuss? Maybe to disconnect the power draw so that the motor now generator provides the needed power to complete the data dump... SEEMS to imply that some IDE drives at least have enough power left after power's off to store the write-cached data to disk. The rest of the email's not very reassuring, though, but note that this email's two years old. Anyone want to test? :) -- Linux homer 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux 4:30pm up 280 days, 8:00, 8 users, load average: 6.05, 6.01, 6.02 pgp0.pgp Description: PGP signature
Re: [PERFORM] inferior SCSI performance
> > Unfortunately, while there are companies hawking SSDs, they are in the > > "you'll have to talk to our salescritter for pricing" category, which > > means that they must be ferociously expensive. :-(. > > the cheapest I found was the one with external backup power was ~1.8k$ > for 2GB PCI device > > http://www.cdw.com/shop/search/Results.aspx?key=platypus&x=0&y=0 That is pretty neat. > An external 16GB one with battery backup and > write-t-small-ide-drives-on-power-failure was ~25k$ And they scale up from there. This company has one that goes up to 1TB RAM. 4.5kW power consumption? I hate to see what kind of heat that thing generates. http://www.imperialtech.com/pdf/MRSpec_021803.pdf I have no idea what price the monster unit is, but someone described the price of one of the *lesser* units as "made me physically ill". So I can only imagine. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] inferior SCSI performance
Christopher Browne kirjutas K, 01.10.2003 kell 19:21: > > The FS-related result appeared surprising, as the "stories" I had > heard suggested that JFS hadn't been particularly heavily tuned on > Linux, whereas XFS was supposed to be the "speed demon." Gentoo linux recommends XFS only for SAN+fibre channel + good ups for anything but database use ;) > It is entirely possible that the result I saw was one that would > reverse partially or even totally on a system LACKING that cache. XFS > might "play better" when we're cacheless; the (perhaps only fabled) > demerits of JFS being more than totally hidden if we add the cache. > > What I find disappointing is that it isn't possible to get SSD cards > that are relatively inexpensive. A similarly fabulous performance > increase _ought_ to be attainable if you could stick pg_xlog and > pg_clog on a 256MB (or bigger!) battery-backed SSD, ideally one that > plugs into a PCI slot. For really cheap and for small-size transactions you could experiment with USB2 memory sticks (some of them claim 34MB/s write speed), perhaps in striped/mirrored configuration. You would just need something counting writes in the driver layer to alert you when you are reaching the x00k "writes" limit and have to plug in new sticks :) OTOH, articles I found through quick googling suggest only 2.4MB/s write and 7MB/s read speeds for USB 2.0 memory sticks, so the 34MB is proably just sales pitch and refers to bus speed, not actual write speed ;( > Unfortunately, while there are companies hawking SSDs, they are in the > "you'll have to talk to our salescritter for pricing" category, which > means that they must be ferociously expensive. :-(. the cheapest I found was the one with external backup power was ~1.8k$ for 2GB PCI device http://www.cdw.com/shop/search/Results.aspx?key=platypus&x=0&y=0 An external 16GB one with battery backup and write-t-small-ide-drives-on-power-failure was ~25k$ - Hannu ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] inferior SCSI performance
[EMAIL PROTECTED] (Andrew Sullivan) writes:
> On Wed, Oct 01, 2003 at 07:14:32AM -0600, scott.marlowe wrote:
>> FYI, on a Dual PIV2800 with 2 gig ram and a single UDMA 80 gig hard drive,
>> I from 420 tps to 22 tps when I disable write caching. WOW. A factor of
>> about 20 times slower. (pgbench -c 4 -t 100)
>
> That's completely consistent with tests Chris Browne has done here on
> cache-enabled and cache-disabled boxes that we have.
>
> It's a _really_ big difference. The combination of battery-backed
> write cache on your controller plus a real good UPS is quite possibly
> the number one thing you can do to improve performance. For what
> it's worth, I can't see how this is something special about Postgres:
> even raw-filesystem type systems have to make sure the disk actually
> has the data, and a write cache is bound to be a big help for that.
Indeed.
When I ran the tests, I found that JFS was preferable to XFS and ext3
on Linux on the machine with the big battery backed cache. (And the
side-effect that it was getting yes, probably about 20x the
performance of systems without the cache.)
The FS-related result appeared surprising, as the "stories" I had
heard suggested that JFS hadn't been particularly heavily tuned on
Linux, whereas XFS was supposed to be the "speed demon."
It is entirely possible that the result I saw was one that would
reverse partially or even totally on a system LACKING that cache. XFS
might "play better" when we're cacheless; the (perhaps only fabled)
demerits of JFS being more than totally hidden if we add the cache.
What I find disappointing is that it isn't possible to get SSD cards
that are relatively inexpensive. A similarly fabulous performance
increase _ought_ to be attainable if you could stick pg_xlog and
pg_clog on a 256MB (or bigger!) battery-backed SSD, ideally one that
plugs into a PCI slot.
This should have the further benefit of diminishing the amount of
mechanical activity going on, as WAL activity would no longer involve
ANY i/o operations.
Unfortunately, while there are companies hawking SSDs, they are in the
"you'll have to talk to our salescritter for pricing" category, which
means that they must be ferociously expensive. :-(.
--
output = ("cbbrowne" "@" "libertyrms.info")
Re: [PERFORM] inferior SCSI performance
On Wed, Oct 01, 2003 at 07:14:32AM -0600, scott.marlowe wrote: > FYI, on a Dual PIV2800 with 2 gig ram and a single UDMA 80 gig hard drive, > I from 420 tps to 22 tps when I disable write caching. WOW. A factor of > about 20 times slower. (pgbench -c 4 -t 100) That's completely consistent with tests Chris Browne has done here on cache-enabled and cache-disabled boxes that we have. It's a _really_ big difference. The combination of battery-backed write cache on your controller plus a real good UPS is quite possibly the number one thing you can do to improve performance. For what it's worth, I can't see how this is something special about Postgres: even raw-filesystem type systems have to make sure the disk actually has the data, and a write cache is bound to be a big help for that. A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] inferior SCSI performance
On Wed, 1 Oct 2003, Andrew Sullivan wrote: > On Wed, Sep 17, 2003 at 04:46:00PM -0400, Michael Adler wrote: > > So the quesiton is whether it is ever sensible to use write-caching and > > expect comparable persistence. > > Yes. If and only if you have a battery-backed cache. I know of no > IDE drives that have that, but there's nothing about the spec which > makes it impossible. FYI, on a Dual PIV2800 with 2 gig ram and a single UDMA 80 gig hard drive, I from 420 tps to 22 tps when I disable write caching. WOW. A factor of about 20 times slower. (pgbench -c 4 -t 100) ---(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: [PERFORM] inferior SCSI performance
On Wed, Sep 17, 2003 at 04:46:00PM -0400, Michael Adler wrote: > So the quesiton is whether it is ever sensible to use write-caching and > expect comparable persistence. Yes. If and only if you have a battery-backed cache. I know of no IDE drives that have that, but there's nothing about the spec which makes it impossible. A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x110 ---(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: [PERFORM] inferior SCSI performance
On Wed, 17 Sep 2003, Tom Lane wrote: > Michael Adler <[EMAIL PROTECTED]> writes: > > I have been experimenting with a new Seagate Cheetah 10k-RPM SCSI to > > compare with a cheaper Seagate Barracuda 7200-RPM IDE (each in a > > single-drive configuration). The Cheetah definately dominates the generic > > IO tests such as bonnie++, but fares poorly with pgbench (and other > > postgresql operations). > > It's fairly common for ATA drives to be configured to lie about write > completion (ie, claim write-complete as soon as data is accepted into > their onboard RAM buffer), whereas SCSI drives usually report write > complete only when the data is actually down to disk. The performance > differential may thus be coming at the expense of reliability. If you > run Postgres with fsync off, does the differential go away? Yes, they both perform equally at about 190 tps with fsync off. The culprit turns out to be write-caching on the IDE drive. It is enabled by default, but can be disabled with "hdparm -W0 /dev/hdx". After it is disabled, the tps are proportional to rpms. There's an (2001) Linux thread on this if anyone is interested: http://www.ussg.iu.edu/hypermail/linux/kernel/0103.0/0331.html So the quesiton is whether it is ever sensible to use write-caching and expect comparable persistence. Thanks, Michael Adler ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PERFORM] inferior SCSI performance
Michael Adler <[EMAIL PROTECTED]> writes: > I have been experimenting with a new Seagate Cheetah 10k-RPM SCSI to > compare with a cheaper Seagate Barracuda 7200-RPM IDE (each in a > single-drive configuration). The Cheetah definately dominates the generic > IO tests such as bonnie++, but fares poorly with pgbench (and other > postgresql operations). It's fairly common for ATA drives to be configured to lie about write completion (ie, claim write-complete as soon as data is accepted into their onboard RAM buffer), whereas SCSI drives usually report write complete only when the data is actually down to disk. The performance differential may thus be coming at the expense of reliability. If you run Postgres with fsync off, does the differential go away? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
