There’s an interesting discussion on SliceHost forum that I spotted a while ago — “Might I have to say goodbye to Slicehost? (64-bit vs. 32-bit)”. Someone is thinking of leaving SliceHost because all its OS templates are running 64 bit Linux. That means your
sizeof(void*) are now 8 bytes instead of 4, which actually can significantly increase the memory usage depending on the applications you run.
The same has also been said in this SliceHost vs. Linode comparison — x86_64 simply uses more memory than the plain old x86. So now you not only paying the same for less memory ($20/month gets you 256MB on SliceHost vs. 384MB on Linode), your applications are also using more memory due to its 64 bit architecture — enough to force you to step up the plan. One of my friends has his WordPress website running at SliceHost. It’s a typical LAMB setup with no control panel, but originally I thought a 256MB Slice would suffice. Apparently not, and the amount of swapping due to possibly bad-optimisation and fat 30+MB Apache processes force him to upgrade to a 512MB slice. But 512MB just to run a low-medium WordPress site? That’s pathetic.
I too have similar experience. Two Ubuntu boxes. One 32 bit at VPSLink and one 64 bit at SliceHost. Both running pretty much my standard LAMP stack serving WordPress and Drupal sites (except Nginx instead of Apache). No opcode cache loaded. Minimum number of extensions. A
php-cgi process is around 35MB VSZ and 14MB RSS on 32 bit, but 120MB VSZ and 25MB RSS on 64 bit. That means I can run almost twice the number of FastCGI processes, which can be beneficial on a busy site.
I guess for a standard web app stack, unless I really have a specific need for 64 bit, I’ll probably stick to that plain old 32 bit.