In my experience, a G4/1.25GHz computer with standard apple drive was much
faster than the PC (Pentium 2+GHz, don't remember details) we tested running
Linux. Both machines had plenty of RAM, same PostgreSQL settings, etc. The PC
was much slower than the mac running backup/restore (more than 2x slower). The
queries we tested were slower as well. Both machines had IDE drives. I'd think
the Linux box could probably be made to be faster, but it had a long way to go
to even match the G4.
One possible explanation for your results would be that the Mac IDE drive lies about write completion while the PC IDE drive does not. You mention a backup/restore test, which is very write-intensive. Any system with an IDE drive that lies about write completion is going to blow away (write performance-wise) a system with an IDE drive that does not lie about it. Our tests last year were all with SELECT queries to prevent this factor from skewing our results. (Our app is read-heavy and we knew we would be getting a good hardware RAID setup that could handle the writes.)
I do not have the same Apple hardware from a year ago to reproduce my tests. If I get time in the next week, I can try something on the same PC (RedHat 9, P3/800) vs. a G4/933, OS X Server 10.2.
We have had excellent stability on both G4 and G5, MacOS 10.2.x and 10.3.x, PostgreSQL 7.3.x and 7.4.x. The only time we experienced instability was just after the G5 was released, the combination of G5, MacOS 10.2.7 and PostgreSQL 7.3.x just didn't work very well. Upgrading the G5 to MacOS 10.3.x and PostgreSQL 7.4.x brought back the stability we expected and we haven't really had any problems since.
Our primary OS X 10.2 server crashed very frequently. Sometimes more than once per day. We changed machines and the crashes continued. Apple HW test on both boxes showed no problems. The vast majority of these crashes were under moderate load (~120 queries/min). A few times, reindexing would cause a crash without any other DB activity. With almost all of these crashes, there were no CrashReporter log entries. At that point, we felt like we had no recourse but to try something different (Linux/x86) and haven't looked back.
- Jeff
--
Jeff Bohmer VisionLink, Inc. _________________________________ 303.402.0170 x121 http://www.visionlink.org/ _________________________________ People. Tools. Change. Community.
---------------------------(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
