[mdlug] Moving to Debian 64bit - Lessons Learned?

[Michael S. Mikowski]

Point taken.  

There may be usage scenarios where the large memory patch does not work well, 
and as I indicated in my prior post, I didn't dig any further into the issue 
because for our usage pattern, the large memory kernel appeared to work just 
fine. 

> > Exactly how that memory was accessed (e.g. if it were "paged" or not) I
> > never investigated since MySQL ran like a top.

I figured there was some paging or bank-switching going on like with the old  
128KB 8-bit systems of yore (Atari 128XL or similar comes to mind). 

Still, I would tend towards the 32-bit with the large memory patch first to see 
if it worked well for my usage.  If it did not, I would then move to 64 bit.

Cheers, Mike

On Saturday 01 August 2009 02:35:01 pm Brian wrote:
> Since it can't access all of the memory directly through the cpu the
> kernel has to create a structure to map requests to the higher memory
> addresses.  This structure has to be stored in regions that are
> directly addressible by the cpu.  If you take a look at /proc/meminfo
> this is displayed as low mem and high mem(addressed virtually).  For
> it's work the kernel can only operate in low mem.  Because of this
> it's actually quite possible to crush an OS's performance on 32 bit
> hardware by having too much memory.
>
> --
> Brian
>
> On 8/1/09, Michael S. Mikowski <z_mikowski at yahoo.com> wrote:
> > On Friday 31 July 2009 04:02:42 am Stan Green wrote:
> >> I am going to attempt to move my main desktop PC to Debian 5.0.2 64bit.
> >> (I'm doing it on a different PC, so I can keep my current one running
> >> until
> >> I have the new one running correctly.)  This is my first attempt at a
> >> 64bit
> >> Linux install. Are there any lessons others have learned from making
> >> this switch or with Debian 64bit? Has anyone had success/failure with
> >> VMWare Workstation 5.5 in this configuration?
> >>
> >> FYI: My main reason to go to 64bit is to be able to access more than 3gb
> >> of
> >> memory. Running VMWare can quickly chew up memory.
> >
> > My advice is don't do it.  Really, all the headaches you get from 64 bit
> > are not made up with speed or memory except in instances that usually
> > occur only in very high-volume database or number crunching situations.
> >
> > First, speed:  http://www.phoronix.com/ has shown repeatedly that 64 bit
> > desktops rarely run faster for most desktop tasks.  In fact, for most
> > apps, 64
> > bit often runs slower.
> >
> > Second, memory: You can install a 32 bit kernel with large memory
> > support. Last year we installed 2 Dell 1950's with 8 64 bit cores and 16G
> > ram each to handle ~ 3 billion MySQL inserts and ~750 million reads per
> > day.  We intended
> > to move it to a 64 bit OS to access all that memory.
> >
> > However, we discovered using the 32 bit PAE kernel provided by RedHat
> > (RHEL 5)
> > handled the memory just fine.  A check of free or top showed all 16G
> > available.
> > Exactly how that memory was accessed (e.g. if it were "paged" or not) I
> > never
> > investigated since MySQL ran like a top.
> >
> > <http://www.cyberciti.biz/tips/redhat-enterprise-linux-4gb-plus-ram-
> > support.html#comments>
> >
> > So unless you are doing some serious crunching, 64 bit is probably simply
> > not
> > compelling.  Avoiding all the hassle of 32 bit library and driver
> > incompatibilities probably is :)
> >
> >
> > Cheers, Mike
> >
> > ps Last I checked (8 months ago) VMWare only supported 32 bit kernels for
> > the
> > host OS.  So unless that has changed, there is little benefit there
> > either. _______________________________________________
> > mdlug mailing list
> > mdlug at mdlug.org
> > http://mdlug.org/mailman/listinfo/mdlug
>
> _______________________________________________
> mdlug mailing list
> mdlug at mdlug.org
> http://mdlug.org/mailman/listinfo/mdlug