Practically this is limited only by hardware restraints. The theoretical limit for a 64-bit-system is far higher than anything you can afford. (4GB is the limit for 32-bit addressing. Multiply this with 2^^32 again to get the limit of 64-bit addresses.)

The hardwares limit depends on which type of RAM you are using (this limits the size of the available RAM sticks) and the number of sockets on your board. Refer to your hardwares documentation for this info.


This (reinstallation with 64-bit) is probably the best solution anyway. A system with no possibility of a downtime is very poorly planned anyway and it will not hurt to redesign this setup now under controlled circumstances instead of in the case of hardware failure where the situation is unplanned.

If your managers or customers complain: let them. Don't care. What would they do if the hardware would break? If this would mean the end of the world, then how comes they haven't taken precautions against this when the system was planned?

Make it clear, that it is their own fault that the system was set up without any contingency. E-V-E-R-Y hardware has to be taken down / taken offline from time to time. For maintenance, for hardware upgrade, for whatever. That means that systems which must not go down, have to be designed as high-availability-clusters either with hot-standby-systems or something such or load-balancers and several identic machines behind that. If this is the case it is easy to take one system down, upgrade it, take over from the other system and take that down to upgrade it too.

Obviously this is not the case. There is no fallback system. Then your managers/customers have no business lamenting that such an upgrade takes time. Its their own fault. Don't have any compassion with them, they have been greedy bastards to save the extra costs and are now paying the price with the downtime.

You may want to do the reinstallation at a separate system and then only move the LUNs with the installed image to your server. This way you could do the upgrade faster and with less downtime. Anyway: the most important thing is to not let you hasten just because others need the system back urgently. If it would really be that urgent - see above. But by trying to do it faster than you comfortably can you run a high risk of doing something idiotic. This would be your fault - not succumbing to some managerial pressure is not.

So do what you have to do and take the times it takes to do it. If somebody has a problem with that - its his problem, not yours.

I hope this helps.

bakunin