I had a cheap solution when I was actually brave enough to run 64 bit on a CPanel based server. Move all of the content from the various /lib64 directories to their /lib counterparts (over-writing as you go, if need be), and then simply symlink the /lib64 directories to their /lib counterparts.
Originally posted by porcupine I had a cheap solution when I was actually brave enough to run 64 bit on a CPanel based server. Move all of the content from the various /lib64 directories to their /lib counterparts (over-writing as you go, if need be), and then simply symlink the /lib64 directories to their /lib counterparts.
I wish I would have thought of that. I went through and changed all the configuration files to point to lib64 instead and then just did chattr +i on them so they wouldn't get overwritten.
Originally posted by sprintserve I actually considered that. But wasn't brave enough : ) How did that go?
It worked fine (in the aspect that it could affect), as the /lib and /lib64 files were named differently for the most prat, but tended to get caught up on other issues (there were more down the road, X11 needed stuff included also).
Problem was this was a FC2_64 driven box running CPanel64, which just didn't work (as much as they claimed it did), I found the following items did not work (or did not work properly).
- Frontpage (dead)
- PHP - Flash (dead)
- PHP - Ming (dead)
- PHP - Various other modules I can no longer recall by name (dead)
- PHP - 4.3.10 (couldn't compile, even though 4.3.9 could, I cant recall the exact error, it was unique though)
- Memory leaks out the wazoo (was running 3GB of DDR400 ECC Reg., after downgrading to a Dual Xeon 2.8, the server now runs 1GB of DDR400 ECC Reg. and has no issues whatsoever)
- IO Operations (Heavy HDD reads/writes, eg. backups) - Overly slow and consistently hogging the CPU. Nighly backups would at random (seemingly) shoot the load over 50.00, without much of a cause, as soon as the threads were stopped, the loads would drop back under 1.00
Overall, this box quickly went from an "upgrade" to a downgrade. It simply was not maintainable, and after around two months with minimal progress on a variety of vital issues (IO load, memory leaks, and dead modules obviously), we had to drop the box as noted. Personally I'd say if your box isn't heavily into production yet, and you intend to run CPanel/WHM, do yourself the favor, and go grab CentOS 3.4 32 bit for it, though you probably wont thank yourself, as you wont know what horror you escaped.
Yup. I would agree with your observations. In fact, we are installing 32bit CentOS on our 64bit Machines. I only leave 1 64bit machine with CentOS 4_64 as a case study and to learn more about it. End of the day, it's all a fallancy.
1. Cpanel is basically 32bit software. There's little benefit from 64bit.
2. Unless the applications is written specifically for 64bit, there's no performance gain, in fact there's a performance drop in benchmarks partly due to the size and possibly less optimized nature of the binary.
3. If you are ending up going to need 32bit libraries more, there's little reason to go 64bit
4. You are unlikely to need the large amount of RAM needed allowed under 64bit, one of the major benefits of the x86_64 architecture. (If you are looking to find the first alien, perhaps)
5. Cpanel claims it supports 64bit. It's false. Don't believe it.
6. A lot of the performance gains are from overall architecture improvements that you will continue to reap even under 32bit. i.e the bus on opeterons, the use of DDR2, faster pipe, cache etc under Xeon 64bit etc.
All in all, we observe the same issues. But I still keep 1 box on 64bit OS just to continue our observations, and testing.
Last edited by sprintserve; 05-18-2005 at 02:43 PM.