Re: [PERFORM] Help specifying new machine
Tom, This is really interesting. We had previously seen some evidence that the Xeon sucks at running Postgres, but I thought that the issues only materialized with multiple CPUs (because what we were concerned about was the cost of transferring cache lines across CPUs). AFAICS this test is using single CPUs. Maybe there is more going on than we realized. Aside from the fact that the Xeon architecture is a kludge? Intel really screwed up the whole Xeon line through some bad architectural decisions, and instead of starting over from scratch, patched the problem. The result has been sub-optimal Xeon performance for the last two years. This is why AMD is still alive. Better efficiency, lower cost. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PERFORM] Help specifying new machine
You're not going to be able to get a Dual Athlon MP for the same price as a single Xeon. A few years back, this was the case because Xeon CPUs MBs had a huge premium over Athlon. This is no longer true mainly because the number of people carrying Athlon MP motherboards has dropped down drastically. Go to pricewatch.com and do a search for 760MPX -- you get a mere 8 entries. Not surprisingly because who would not want to spend a few pennies more for a much superior Dual Opteron? The few sellers you see now just keep stuff in inventory for people who need replacement parts for emergencies and are willing to pay up the nose because it is an emergency. I saw pricewatch.com and you're right. I looked for some benchmarks, and I would know if I'm right on: - Dual Opteron 246 have aproximately the same performance of a Dual Xeon 3Gh (Opteron a little better) - Opteron system equal or cheeper than Xeon system. As I'm not a hardware expert I would know if my impressions were right. Thanx, Raoul ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PERFORM] Help specifying new machine
On Wed, 2004-08-18 at 11:18, Raoul Buzziol wrote: You're not going to be able to get a Dual Athlon MP for the same price as a single Xeon. A few years back, this was the case because Xeon CPUs MBs had a huge premium over Athlon. This is no longer true mainly because the number of people carrying Athlon MP motherboards has dropped down drastically. Go to pricewatch.com and do a search for 760MPX -- you get a mere 8 entries. Not surprisingly because who would not want to spend a few pennies more for a much superior Dual Opteron? The few sellers you see now just keep stuff in inventory for people who need replacement parts for emergencies and are willing to pay up the nose because it is an emergency. I saw pricewatch.com and you're right. I looked for some benchmarks, and I would know if I'm right on: - Dual Opteron 246 have aproximately the same performance of a Dual Xeon 3Gh (Opteron a little better) - Opteron system equal or cheeper than Xeon system. For PostgreSQL, Opteron might be a touch worse than Xeon for single processor, little better for Dual, and a whole heck of a bunch better for Quads -- but this depends on your specific work load as memory bound, cpu bound, lots of float math, etc. work loads will perform differently. In general, an Opteron is a better bet simply because you can shove more ram onto it (without workarounds), and you can't beat an extra 8GB ram on an IO bound database (consider your datasize in 1 year). ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PERFORM] Help specifying new machine
You're not getting much of a bump with this server. The CPU is incrementally faster -- in the absolutely best case scenario where your queries are 100% cpu-bound, that's about ~25%-30% faster. What about using Dual Athlon MP instead of a Xeon? Would be much less expensive, but have higher performance (I think). You're not going to be able to get a Dual Athlon MP for the same price as a single Xeon. A few years back, this was the case because Xeon CPUs MBs had a huge premium over Athlon. This is no longer true mainly because the number of people carrying Athlon MP motherboards has dropped down drastically. Go to pricewatch.com and do a search for 760MPX -- you get a mere 8 entries. Not surprisingly because who would not want to spend a few pennies more for a much superior Dual Opteron? The few sellers you see now just keep stuff in inventory for people who need replacement parts for emergencies and are willing to pay up the nose because it is an emergency. ---(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] Help specifying new machine
William Yu wrote: Rory Campbell-Lange wrote: The present server is a 2GHz Pentium 4/512 KB cache with 2 software-raided ide disks (Maxtors) and 1GB of RAM. I have been offered the following 1U server which I can just about afford: 1U server Intel Xeon 2.8GHz 512K cache 1 512MB PC2100 DDR ECC Registered 2 80Gb SATA HDD 4 4 port SATA card, 3 ware 8506-4 1 3 year next-day hardware warranty 1 You're not getting much of a bump with this server. The CPU is incrementally faster -- in the absolutely best case scenario where your queries are 100% cpu-bound, that's about ~25%-30% faster. What about using Dual Athlon MP instead of a Xeon? Would be much less expensive, but have higher performance (I think). If you could use that money instead to upgrade your current server, you'd get a much bigger impact. Go for more memory and scsi (raid controllers w/ battery-backed cache). ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PERFORM] Help specifying new machine
I'm thinking of upgrading an existing dedicated server and colocating my own server. The server is used for prototype systems running Postgresql, php and apache. The largest database is presently under 10GB and I haven't had any major performance problems. We expect to have to host larger data sets in the next year and anticipate one or two databases reaching the 30GB mark in size. We write a lot of our webapps functionality using pl/pgsql. The present server is a 2GHz Pentium 4/512 KB cache with 2 software-raided ide disks (Maxtors) and 1GB of RAM. I have been offered the following 1U server which I can just about afford: 1U server Intel Xeon 2.8GHz 512K cache 1 512MB PC2100 DDR ECC Registered 2 80Gb SATA HDD 4 4 port SATA card, 3 ware 8506-4 1 3 year next-day hardware warranty 1 There is an option for dual CPUs. I intend to install the system (Debian testing) on the first disk and run the other 3 disks under RAID5 and ext3. I'm fairly ignorant about the issues relating to SATA vs SCSI and what the best sort of RAM is for ensuring good database performance. I don't require anything spectacular, just good speedy general performance. I imagine dedicating around 25% of RAM to Shared Memory and 2-4% for Sort memory. Comments and advice gratefully received. Rory -- Rory Campbell-Lange [EMAIL PROTECTED] www.campbell-lange.net ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PERFORM] Help specifying new machine
Rory, Rory Campbell-Lange wrote: I'm thinking of upgrading an existing dedicated server and colocating my own server. The server is used for prototype systems running Postgresql, php and apache. The largest database is presently under 10GB and I haven't had any major performance problems. We expect to have to host larger data sets in the next year and anticipate one or two databases reaching the 30GB mark in size. We write a lot of our webapps functionality using pl/pgsql. The present server is a 2GHz Pentium 4/512 KB cache with 2 software-raided ide disks (Maxtors) and 1GB of RAM. I have been offered the following 1U server which I can just about afford: 1U server Intel Xeon 2.8GHz 512K cache 1 512MB PC2100 DDR ECC Registered 2 80Gb SATA HDD 4 4 port SATA card, 3 ware 8506-4 1 3 year next-day hardware warranty 1 There is an option for dual CPUs. I intend to install the system (Debian testing) on the first disk and run the other 3 disks under RAID5 and ext3. If you are going to spend your money anywhere, spend it on your disk subsystem. More or less, depending on the application, the bottleneck in your database performance will be the number of random IO operations per second (IOPS) your disk subsystem can execute. If you've got the money, get the largest (i.e. most spindles) RAID 10 (striped and mirrored) you can buy. If your budget doesn't permit RAID 10, RAID 5 is probably your next best bet. I'm fairly ignorant about the issues relating to SATA vs SCSI and what the best sort of RAM is for ensuring good database performance. I don't require anything spectacular, just good speedy general performance. Be sure that if you go with SATA over SCSI, the disk firmware does not lie about fsync(). Most consumer grade IDE disks will report to the OS that data is written to disk while it is still in the drive's cache. I don't know much about SATA disks, but I suspect they behave the same way. The problem with this is that if there is data that PostgreSQL thinks is written safely to disk, but is really still in the drive cache, and you lose power at that instant, you can find yourself with an inconsistent set of data that cannot be recovered from. SCSI disks, AFAIK, will always be truthful about fsync(), and you will never end up with data that you *thought* was written to disk, but gets lost on power failure. I imagine dedicating around 25% of RAM to Shared Memory and 2-4% for Sort memory. That is probably too much RAM to allocate to shm. Start with 1 buffers, benchmark your app, and slowly work up from there. NOTE: This advice will likely change with the introduction of ARC (adaptive caching) in 8.0; for now what will happen is that a large read of an infrequently accessed index or table will blow away all your shared memory buffers, and you'll end up with 25% of your memory filled with useless data. Better to let the smarter filesystem cache handle the bulk of your caching needs. Comments and advice gratefully received. Rory Best Luck, Bill Montgomery ---(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
