On 2010 Dec 15, at 10:41, Jason Qualkenbush wrote:

> I'm being asked to build a 32bit system.  There is no specific reason for 
> this to be 32bit except my boss likes that there are less libraries to 
> install.  This is a CentOS 5 install and they way things work, this will 
> remain a 32bit install for the next four years (until a hardware refresh).
> 
> It's hard for me to explain why, but that just feels dirty to me.  When in 
> performance tuning classes, it was understood that you want 64bit over 32bit. 
>  I can't use "people told me 64bit is better", but I keep reading "unless you 
> have a specific reason for 32bit, choose 64".  I need something that has 
> details.
> 
> Can someone provide a link to why you want to install 64bit?  The best I 
> could come up with is this article: http://kerneltrap.org/node/2450 which 
> explains how PAE works.  Does 64 bit matter for large files?  Network 
> performance?
> 
> I'm irritated that I'm being forced to build this thing as 32bit.  It's a 
> RSyslog, Cacti, Nagios system, and if I build it, I'm pretty much signing my 
> name to this.  It becomes a "JQ built server".  I just feel like going 64bit 
> is better for "future proofing" this thing than 32bit.  

ObCaveat: I am not a performance tuning expert

My history with such things says that if you are expecting to handle large 
numbers of records of data (be it entries in a database, performance statistics 
for a lot of systems for trending, or large number of log events), you want 64 
bit so you can better handle the sheer number of events.  Without that 64 bit, 
you would have a significant hit to some query's speed.

Where I work, we made the transition to 64 on Linux in two areas before we 
transitioned everywhere else: databases and logging systems.  Eventually, the 
decision was made that having a special build for 32 bit didn't make sense from 
a support perspective.  

That last point is the one I would ask.  Why have some systems built 32 bit and 
some 64 bit?  It complicates the support equation in my experience, even if you 
use some fancy patch system.  Something always goes wrong, and testing new 
versions of code you produce now means one more type of system to test on.  

----
"The speed of communications is wondrous to behold. It is also true that
speed can multiply the distribution of information that we know to be
untrue." Edward R Murrow (1964)

Mark McCullough
[email protected] 

_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to