Subject: | |
From: | |
Reply To: | |
Date: | Fri, 23 Mar 2007 11:15:43 -0500 |
Content-Type: | TEXT/PLAIN |
Parts/Attachments: |
|
|
On Fri, 23 Mar 2007, Stephan Wiesand wrote:
> On Fri, 23 Mar 2007, Brett Viren wrote:
>
> > Johan Mares <[log in to unmask]> writes:
> >
> >> If you have dual core 64 bits processors in your server. Is it
> >> recommended to install x86-64 version of a linux distro like SL ?
> >> What are the benefits ? Are there any disadvantages ? It would be for
> >> a LAMP, so would Apache or MySQL perform better or wouldn't they make
> >> no use of it ?
> >> Does anyone have any experience with this ?
> >
> > 32 bits: more software available, typically proprietary in nature.
>
> Which often runs just as fine under the 64bit OS.
>
> > Can access only <4GB RAM.
>
> That's a common misconception. There's a per-process limit of 3 GB with
> the standard kernel. But the system can have and use more memory. Even
> 32-bit SL3 can handle at least 16GB with the ordinary -smp kernel.
>
> > 64 bits: ~20% faster floating point (AMD only I believe), can access
>
> Typically 20% faster for many scientific applications, with few
> exceptions. A bit more than 20% with AMD CPUs. Not limited to floating
> point processing.
>
> IIRC, MySQL is one of those that do benefit but not that much. OpenSSL may
> be anything from slightly slower to much much (several times!) faster,
> depending on cipher and task. No clue how apache behaves.
>
> 3GB per-process address space limit for 32-bit apps on SL3, 4GB on SL4.
> No (serious) such limit for 64-bit apps.
>
> > more RAM than you can afford. Potential compilation problems of
> > legacy code.
>
> Usually, serious compilation and runtime problems of bad code, legacy or
> not.
>
> Larger memory footprint, depending on application and payload.
It is common for large databases that use lots of memory to use 64 bit .
It make the memory usage of the program faster and easier.
-Connie Sieh
>
>
> The last two probably don't apply to a LAMP. I'd personally go for x86-64.
>
>
> Regards,
> Stephan
>
>
|
|
|