32-bit or 64-bit Linux for my LAMP stack?

[sneakyimp]

I asked my hosting provider for an upgrade to my dedicated server. I now have centOS 5 installed and it apparently has the 32-bit version of linux installed:

[root@server2 ~]# uname -a
Linux server2.mydomain.com 2.6.20.1 #12 SMP Fri May 18 19:03:50 EDT 2007 i686 athlon i386 GNU/Linux

Should I leave it or should I demand a 64-bit kernel? I'm going to be running Apache 2, PHP 5, and MySQL 5.

cpuinfo indicates my CPU is 64-bit:

[root@server2 ~]# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 75
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping        : 2
cpu MHz         : 2204.705
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc
bogomips        : 4412.82
clflush size    : 64

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 75
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping        : 2
cpu MHz         : 2204.705
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc
bogomips        : 4409.26
clflush size    : 64

[Horizon88]

Why not use 64-bit? Ask them if they've got any reasoning behind installing 32-bit - they might have hardware issues with the 64-bit version of CentOS 5 or something that prevents them from doing so. If they don't have any real reason, you might as well ask for a 64-bit install.

[sneakyimp]

Yes but will it help? It's just a LAMP stack and not Folding@home or anything. Plus I understand that things like pointers will consume 8 bytes instead of just 4 meaning my RAM might not be used as thriftily.

More importantly, will it have any impact on Apache, PHP, or Mysql?

[MarkR]

Test your application with 64-bit in your test environment. If you're sure it works, 64-bit is definitely better than 32, especially for a large MySQL server (say with 8G of ram).

If you have > 1G of ram, it's almost a certainty.

But still test it.

Mark

[sneakyimp]

Thanks, MarkR!

When you say 'test your application', what sort of problems might I expect? My application is a giant site with hundreds of pages. Linux/Apache/PHP/MySQL with some session functions and a bit of image processing for graphs and user avatars.

MarkR wrote:

If you have > 1G of ram, it's almost a certainty.

Why is that exactly? I'm familiar with 32-bit systems having limited address space which comes into play around 4GB of RAM but I've never heard of 1G being some break point. Could you elaborate?

[MarkR]

32-bit Linux uses a system where some ram is "high" an others is "normal". I believe the limit for "normal" RAM is about 1G.

Effectively, "normal" ram is kept permanently mapped in by the kernel, which makes it easier for it to get to it (less changing of page tables etc) - whereas "high" memory isn't (because there isn't enough address space).

The limit may not be 1G, but it's certainly lower than 2G.

In user-space, processes can only allocate about 2G of address space on most 32-bit linux boxes (perhaps 3G on a few?) - this is a major issue for tuning MySQL for large workloads.

I believe some benchmarks have shown running 32-bit userspace on 64-bit kernels to be advantageous, but I've never done any work on it myself.

Mark

[MarkR]

sneakyimp wrote:

Thanks, MarkR!

When you say 'test your application', what sort of problems might I expect?

If you knew that, why bother testing it?

My application is a giant site with hundreds of pages.

All the more reason to thoroughly test it.

What sort of test environment do you currently have? Can you create an automated system which exercises (at least) a significant subset of these 100s of pages?

Without any kind of testing, no software should really be deployed to production. It needs to be tested in the context of YOUR applciation, to ensure that it doesn't create any unforeseen problems.

Because these problems are unforeseen, of course I can't tell you what they might be.

Mark

[sneakyimp]

I was just wondering if there might be some standard set of problems that occur using a 64-bit OS. My nightmare is that there might be those unreproducable, weird errors that sometimes happen (and usually don't) in badly designed multithreaded applications. I was rather hoping that any errors would be a big fat fatal error or something.

But I guess we don't really know. It's encouraging to me that there's no obvious set of difficulties. I'm assuming at this point that there's no inherent problem running Apache or PHP or MySQL on a 64-bit OS. I suppose I'll try to upgrade that kernel and start testing things.