X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 9E4263A5EC1 for ; Thu, 27 Jan 2005 14:36:59 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 66743-06 for ; Thu, 27 Jan 2005 14:36:52 +0000 (GMT) Received: from out011.verizon.net (out011pub.verizon.net [206.46.170.135]) by svr1.postgresql.org (Postfix) with ESMTP id 77C483A5E94 for ; Thu, 27 Jan 2005 14:36:54 +0000 (GMT) Received: from jfradkin ([66.15.127.235]) by out011.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050127143655.WNFS4717.out011.verizon.net@jfradkin> for ; Thu, 27 Jan 2005 08:36:55 -0600 From: "Joel Fradkin" To: Subject: Hardware for best performance was same question little different test MSSQL vrs Postgres Date: Thu, 27 Jan 2005 09:40:05 -0500 Message-ID: <000001c5047e$188cfad0$797ba8c0@jfradkin> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Authentication-Info: Submitted using SMTP AUTH at out011.verizon.net from [66.15.127.235] at Thu, 27 Jan 2005 08:36:54 -0600 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=3.328 tagged_above=0 required=5 tests=AWL, INFO_TLD, MSGID_DOLLARS X-Spam-Level: *** X-Archive-Number: 200501/291 X-Sequence-Number: 20079 Subject: RE: [SQL] same question little different test MSSQL vrs = Postgres Now you tell me. We had a fellow working here kept screaming AMD, but I am a very = paranoid person and was not aware Linux and Postgres have been running on the new chips. I don't like to be a first. We have bought the Dell and I cant = tell you if the controller uses 64bits, I just got what they had on their = page for their 4 proc rack mount. Part of my reason for going Dell was we = already have Dell equipment and the Linux support is offered from Dell as well, = so I have one vendor to worry about. Being a developer and Director of IT I = want the fastest best, but sometimes I flavor my opinions with safest and easiest. The RPM delivery is something I understand (it's easy). What is = SU like? Is there any difference in the performance between the two = Vendors? I am sure we will be buying more Postgres servers in the near future = (One of the big reasons we are taking the time to convert from MSSQL was so we = could afford to invest in more servers MSSQL was cost prohibitive even for one server). As easy as Fedura was I still had several issues getting to = where I am now, so I am paranoid of something that requires even more knowledge = to pull it off; that being said I never minded getting into the details to = get a better end result. As you said we have made the investment in the Dell (25K). I feel pretty stupid if it is as you say a waste of money to get = 8 gigs on this platform as I just made that same mistake a year ago when I bought the 2 processor boxes with standard addition MSSQL and 4 gigs (It only uses 2 gig). I was under the impression this machine would utilize = all 8 gigs. Are you saying only 4 will be available for caching etc, or just = the chipset cant deal with numbers 8 gig and will be slower to access them? = If it is the later then I would imagine it would still outperform a similar = box with 4 gig assuming my demand on cache is larger then 4 gig. Just to confirm you have these quad Opteron (I am assuming a 4 processor config?) in a production environment running su and postgres with = hardware support from HP and software from su? You indicate three separate = physical drives will give best performance (one for data 10K speeds, one for = admin, one for wall 15 speed)? I am not too sophisticated at knowing how to = irder this arrangement and set it up in Linux, any chance you could detail (1 = card with 2 channels 4 10k drives on one channel, 2 15k drives on the second, = do I need another channel and drive(s) for admin files?), drive layout when installing config in postgres to utilize?=20 If need be maybe we can get you to do this as a consultant as I do understand how important the hardware and the proper config is. I found = out too late with MSSQL that I should have used two seprate drive arrays, = one for data, one for log (this would have required the split back plane). So not to plug a specific vendor but if you have production environment example with real equipment suggestions I would be very appreciative. I know that's a lot to ask so if you don't have time that's cool, thanks = so much for bringing this up so that my next purchase I will seriously look = at quad Opteron technology if it is a tried and true solution for this OS = and Postgres. Joel Fradkin =20 -----Original Message----- From: Andrew Hammond [mailto:ahammond@ca.afilias.info]=20 Sent: Wednesday, January 26, 2005 5:16 PM To: Joel Fradkin Cc: pgsql-sql@postgresql.org Subject: Re: [SQL] same question little different test MSSQL vrs = Postgres -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We've done some pretty extensive benchmarking and load testing on a couple of platforms including the Xeon and Opteron. You may have already bought that Dell box, but I'll say it anyway. Xeon quad processors are a terrible platform for postgres. Trying to use more than 4GB of memory on a 32 bit machine is a waste of money. If you want performance, get a quad Opteron with the same amount of memory. I guarantee you'll see at least an order of magnitude performance improvement and substantially more under highly concurrent loads. If you decide to go this way, HP sells a very nice box. I also strongly recommend you investigate SuSE instead of RedHat. Fedora core is good technology, but SuSE offers equally good technology with better support. Also make sure that your SCSI HBA is actually using the 64 bit PCI bus. There are cards out there which plug into 64 bit PCI but only actually address 32 bits (Qlogic's QLA2340 / 2342 for example). You make no mention of the disk subsystem you plan to use. This is most critical part of your system. Database performance is almost always bound by IO. Usually disk IO. Briefly, put PGDATA on the widest RAID 10 array of disks you can manage. It's not worth spending the extra money to get 15kRPM disks for this. The size of the disks involved is pretty much irrelevant, only the number of them matters. Put the WAL files on a dedicated RAID 1 pair of 15kRPM disks. Put the postgres log files (or syslog) on a seperate filesystem. - -- Andrew Hammond 416-673-4138 ahammond@ca.afilias.info Database Administrator, Afilias Canada Corp. CB83 2838 4B67 D40F D086 3568 81FC E7E5 27AF 4A9A Joel Fradkin wrote: | The postgres is running on Linux Fedora core 3 (production will be redhat on | Dell 4 proc 8 gig box). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB+BaPgfzn5SevSpoRAgirAKDBbedScL3leQVidZjmsGmxoph8wQCgvhoW 2ZznEkxOMA3btZEBdzHd8TU=3D =3Deg7h -----END PGP SIGNATURE-----