6
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(long) and 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.
Most slices on SliceHost are configured using the tutorials published on articles.slicehost.com, which are fantastic but don’t warn people about setting Apache2 MaxClients with too high a value. When people reduce their MaxClients from 150 to 35 or so (for lightly trafficked sites), the responsiveness of their slice improves dramatically.
Also, running services such as Apache2 and PHP, etc. from within 32-bit chroot’d environments can recapture most of the memory lost to native 64-bit far pointers.
An alternative is also not to use Apache, there’s plenty of tutorials on using LigHTTP or nginx. I personally use nginx on my 256mb slice, and I’ve had some heavy traffic days, and haven’t had any problem keeping up. I actually thought it was all “64 bit optimized” (PHP, MySQL), so it wouldn’t be any difference. Oh well
I too am using Nginx to host this site, which is on SliceHost. However, my friend basically contracted a local design shop to get his site up and running, and they simply do not have any clue on setting up a Nginx — most them would not want to support anything that’s not LAMP.
Also — although running Nginx/Lighttpd with PHP/FastCGI makes a site run on 256MB RAM, I could have run 5 FastCGI backends instead of 3 due to memory restriction. Or I could run the same number of backends but with more space for disk cache or memcached. 64 bit is wasteful of memory on a small VM — no matter what software you use.
Even MaxClients at 35 is “extreme” for a 256MB VM. I can’t imagine having 35 pre-forked Apache instance that’s 30MB RSS each because all of them are fully loaded with mod_php…
As of chroot’ed 32bit environment. Yes it’s do-able, but why bother? At some point people will just say “too much pain!” and switch to a competitor’s offering that comes pre-configured for 32bit.
Has anyone done any benchmarking to see if nginx is faster in 32 or 64bit mode?
[...] 最近我在 VPSLink 上注册了一个64M VPS，分别装了一次32位的 Ubuntu 和64位的 Ubuntu，安装完 php+mysql+nginx 后发现32位系统确实比64位节省更多的内存。32 or 64 Bit for Your VPS? 的作者也有同样的感受，除非你对64位有特别的需求，否则还是推荐低廉、快速而且有效的32位系统。 [...]