RHEL4 64-bit or RHEL4 32-bit??

[jdell]

I have a brand spankin' new server with Dual Xeon 5160's (64-bit core2) and 4GB ram that is waiting for ZCS 4 NE to be installed.

Should I install RHEL4 64-bit, or RHEL4 32-bit on the new server?

This page http://downloads.zimbra.com/index.html shows 64 bit ZCS. Are these true 64-bit binaries? I have been using the 32-bit ZCS on the previous server with no problems. Anybody using 64-bit binaries?

Also, the wiki page here http://wiki.zimbra.com/index.php?tit...ific#64_Bit_OS
indicates these aren't real 64-bit binaries. The page is a few months old, has this changed?

Comments? Experiences?

Also, anybody think I will have problems moving existing ZCS from 32-bit to 64-bit platform?

Thanks!

[jdell]

I'd still like to hear from anybody who is currently running zcs 4.0.x on RHEL4 64-bit....

Searching these forums, I've found some references to people who have upgraded to 64-bit and they don't seem to be complaining so that's good :-)

[aside, it would be nice if the forum search feature didn't throw out a search for '64' because it is too short! If you search on '64 bit', you end up searching only on 'bit'. Also, searching on '64-bit' misses alot of threads ]

Of the threads I found, one indicated that the JVM is limited to 2GB, so that may be a reason to go 64-bit since I have 4GB of ram. Another thread indicated slight performance gains with 64-bit.

Given, both those tidbits, and lack of current complaints, I'm going to go with RHEL4 64-bit.

[dijichi2]

that's interesting, and a really good reason to rethink your OS if you're planning a large server, if it's true. is the JVM limit a known one? sure you're not hitting a default linux kernel limit for non hugemem kernels? i have a lot of boxes that run on 64bit cpus but for safety and stability reasons we still run 32bit redhat with hugemem kernels, certainly up to 32gb ram.

[Chris_H]

FWIW all of the binaries that I checked in my ZCS 4.0.2NE install are native 64-bit executables, so I would say that they are not just repackaged 32-bit binaries ;-)

There are reasons other than performance (you won't gain much going 32-bit --> 64-bit, and may in fact lose some due to overhead) to move to a 64-bit platform. For one, the 64-bit kernel VM subsystem is much cleaner than the 32-bit VM since it has no need to play tricks with memory mapping to access all of the memory in your system. This isn't as critical in small-memory systems (4GB or less), but it's a huge win in large mem systems as it removes huge swaths of (IMHO) buggy, hacky VM codebase from the kernel. This is a big win for stability.

As for the JVM 2GB limit (actually, slightly less than 2GB), that has more to do with the memory mapping model of the 32-bit Linux VM. The standard Linux memory model has a 2GB/2GB split, which keeps process VSS to something less than 2GB. Using a 32-bit hugemem kernel gets you a 3/1 split, but even that doesn't gain you much. Running a 64-bit kernel gets you a nice flat memory address space to play in ;-)

As an aside, I'd question the wisdom of going to such a large JVM heapsize unless you know what you're doing and are willing to put in the time to tune the heap allocation and GC settings. With such a large heap your GC times can have a very detrimental impact on app performance without proper tuning (eden size, survivor space sizes, collector implementation chosen, etc.). The defaults won't generally perform well in that circumsance. If you do decide to use a large heap I'd recommend that you read up on hugepage support as well.

Cheers,

-chris

[jdell]

As an aside, I'd question the wisdom of going to such a large JVM heapsize unless you know what you're doing and are willing to put in the time to tune the heap allocation and GC settings. With such a large heap your GC times can have a very detrimental impact on app performance without proper tuning (eden size, survivor space sizes, collector implementation chosen, etc.). The defaults won't generally perform well in that circumsance. If you do decide to use a large heap I'd recommend that you read up on hugepage support as well.

Thanks for the info! I assume you are talking about dijichi2's comment about 32gb RAM? Any reason to be concerned about tuning with just 4GB of RAM?

Also, I thought I read somewhere that the Zimbra installer does some basic JVM tuning according to the amount of RAM (now I can't find where I read that). Does that ring a bell?

Regards,
John

[Chris_H]

Thanks for the info! I assume you are talking about dijichi2's comment about 32gb RAM? Any reason to be concerned about tuning with just 4GB of RAM?

Actually I was referring to JVM heap sizes of ~2GB or greater, not system memory. But yeah, if you have a 32GB box you should really run the 64-bit RHEL or you're seriously hamstrung. If you have a 4GB box you should be able to just run with the as-installed Zimbra defaults.

Also, I thought I read somewhere that the Zimbra installer does some basic JVM tuning according to the amount of RAM (now I can't find where I read that). Does that ring a bell?

Zimbra does seem to self-tune based on how much RAM is in the system. I haven't dived into it much, but it seems to make reasonably good assumptions for heap size and MySQL parameters. A good admin could tweak them some more, but it's probably in the realm of diminishing returns for most sites. I'd like to see support for hugepages included in either the base install or as an install-time flag, but that's a minor gripe.

Cheers,

-chris

[dijichi2]

wow, thanks for the great info! i didnt know about the 64bit vm, thats interesting and quite reassuring given the uncertainty and radical rewrites that the 32bit vm has undergone in the past.

i believe some of the zimbra devs are original java devs or something, certainly theyve done a superb job of making reliable java code so far, hopefully they can deliver even better 64bit tweaks.