| gabriel rosenkoetter on Thu, 10 Apr 2003 16:52:07 -0400 |
|
On Wed, Apr 09, 2003 at 09:52:47PM -0400, Chris Hedemark wrote: > care of his developers) "We have not heard of problems with PostgreSQL > but if you will give us access to a PostgreSQL box, we will work with Now, it is good to see a software vendor say they'll support something... but would any company really want to give the vendor access to an internal DB server? Shouldn't the *vendor* have a lab of their own? It's kind of a moot point in this case; the company in question is married to the product in question by existing deployment, so if that company wants to use Postgres with that product, they have to play along. In any case, working a vendor through fixing their product is all well and good... but if you've got a short time to delivery, you go use what they cooperate with and go on with life. > SAN storage would have been nicer than local disk but I'm not going to > cry over it now. Actually, it would have been less nice. Linux has no volume manager than can do dynamic multi-pathing (Veritas's latest release *might* be able to; not that it matters much since those systems only have one 64-bit, 66 MHz PCI slot, the rest clocked at 33 MHz), which means that since we're talking about 1 Gb FC-AL you max out around 90 MB/s (FC-AL doesn't have as much overhead as Ethernet, especially since we're talking about a switched, not a true AL environment, but it's still got networking-type overhead), and you're probably lucky if you can get that much for more than a split-second peak. Seeing 50 MB/s average would be lucky. Whereas the vendor-bolted-on SCSI cards on that (IBM xSeries 345) system are (really good!) Ultra320 and talking to a RAID 10 array across 6 Ultra160 disks. I'm not sitting here testing it, but we should be seeing in the vicinity of 100 MB/s sustained data transfer for straight reads and writes. Modulo the ext3 stupidities in RHAS 2.1, but you'd get that if you were using SAN anyway. > Kernel tuning figures were, as best as I can tell, > pulled verbatim from examples given in an Oracle whitepaper and not > tuned to the server in question. What kernel parameters... SHMMAX? I don't know that that really matters. Does sapdb really need special things done for it? More importantly, does Postgres?[1] (Beyond the fact that Postgres would really rather be running on FreeBSD...) > One of the production PostgreSQL servers was configured by someone to > have more shared memory available than actual physical memory. Hmmm. Well, actually, that was before it was less the two (bad) DIMMs sitting in my desk drawer (or maybe just one of them? Don't recall if these are 1 GB a piece or 512 MB). And I'm the moron that didn't drop the number back down. Sorry! :^> > production systems that currently run against PostgreSQL. If > PostgreSQL is going to eat with the dogs for its poor performance, at > least it should be because of true product suckage and not poor > configuration. Postgres's poor performance isn't just a tuning issue. In fact, it's mostly not a tuning issue. It's mostly a (historical, don't know if it's still the case) completely braindamaged (lack of) optimization of SQL statements. Oracle kicks everything else's ass at doing this. Postgres sucks worse than sapdb, last I heard, for the kinds of queries Barry describes. I'd be glad to know that wasn't true any more... but if it is, no amount of SHMMAX tweaking is going to fix the underlying lack of code optimization. It'd be like building everything in a system statically with -O0 with gcc targeting a 64-bit, big-endian architecture. Performance would suck no matter how many cycles you ran the processor at. -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgpnLLgPN8np1.pgp
|
|