Anyone who has tried x86-64 linux knows what a royal pain in the ass it is. They didn't do anything sensible, like just make the whole OS 64 bit, no, they had to split it up, and put 64-bit libs in a new directory /lib64. This means that a great many applications don't know to check in there for libs, and don't compile pleasantly, php is one among them. I forget what others, it's been awhile now. Of course if you actualy want to use more than 4gig RAM in a pleasant way, it's pretty much essential.
Alex.
On 6/12/06, Steve Atkins <steve@blighty.com> wrote:
On Jun 12, 2006, at 6:15 PM, Joshua D. Drake wrote:
>
>> Empirically... postgresql built for 64 bits is marginally slower
>> than that built
>> for a 32 bit api on sparc. None of my customers have found 64 bit x86
>> systems to be suitable for production use, yet, so I've not tested
>> on any
>> of those architectures.
>
> Really? All of our customers are migrating to Opteron and I have
> many that have been using Opteron for over 12 months happily.
An Opteron is 64 bit capable; that doesn't mean you have to run 64 bit
code on it.
Mine're mostly reasonably conservative users, with hundreds of machines
to support. Using 64 bit capable hardware, such as Opterons, is one
thing,
but using an entirely different linux installation and userspace
code, say, is
a much bigger change in support terms. In the extreme case it makes no
sense to double your OS support overheads to get a single digit
percentage
performance improvement on one database system.
That's not to say that linux/x86-64 isn't production ready for some
users, just
that it's not necessarily a good operational decision for my
customers. Given
my internal workloads aren't really stressing the hardware they're on
I don't
have much incentive to benchmark x86-64 yet - by the time the numbers
might be useful to me we'll be on a different postgresql, likely a
different
gcc/icc and so on.
Cheers,
Steve
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster