We are planning our big 10.2 upgrade from 10.1 this November. A piece of this upgrade is infrastructure/performance.
We are hosted by EMS in a single tenant environment. All of our users access the E10 client through 1 of 3 terminal servers running Server 2012 R2. Each server has 8 cores and 32GB memory.
My question is, is it wise to move our users to the 64-bit client during the upgrade? 2GB of usable memory by the client just does not seem like enough these days, and we sometimes run into issues with dashboards crashing due to being out of memory (I know the underlying queries could probably be designed better as well).
In an age with 56 core processors, workstations with 64 gigs of memory, and PC games requiring a 64-bit OS just to run, 32-bit seems to be old news.
So what are the pros and cons of the 64-bit client in the view of our community? Have any of you moved your user base fully to the 64-bit client?
Thanks!
aidacra
(Nathan your friendly neighborhood Support Engineer)
#2
The standard line is that the 32bit client should be used by everyone unless there is a reason to use the 64bit bit client–which is why our client installer only installs the 32bit client shortcut.
The reasons to use the 64bit client would be if specific users receive out of memory error messages doing something client side (dashboard, Crystal report generation, etc), or there is a custom 64bit only assembly that is used client side that requires the 64bit client(which was the actual reason why we created a 64bit client back in the E905 days if memory serves.)
We warn users against using the 64bit client unless it is absolutely needed.
My experience is that the 64bit client is slower than the 32bit, but, I can’t provide you an actual reason why that would be true or even if it is actually true. Someone more knowledgeable than me (@josecgomez, @Bart_Elia, @Rich or basically anyone else really) could confirm/deny my experience with it with a technical reason. It’s possible that it’s all in my head as I haven’t actually looked at the metrics via UI trace or process monitor.
This doesn’t help you at all, but, that is the official answer anyways
Is one reason for going to 64bit because we are upgrading to a virtual server environment with an operating system that handles only 64bit? This is for only E9.
The 32 Bit Client is a little faster and less resource intensive as compared to the 64 Bit Client primarily because it allocates and manages a smaller amount of memory. Out of interest, I just loaded up both a 32 and 64 Bit Client version of 10.2.200.13 and then viewed the memory allocation via the Windows Task Manager. There are several different counters available for Memory and all of them were 25% to 30% less for the 32 bit client.
The actual source code of Epicor.exe and Epicor64.exe is the same - we just compile Epicor.exe for a 32 bit environment while Epicor64.exe is the same code compiled for “any” environment.
As Nathan notes, the Epicor recommendation is to generally use the 32 Bit Client unless you have very large amounts of data or have a need to interface with 64 Bit DLLs.
The Server should always run as a 64 Bit environment as the Epicor Server memory footprint can become fairly large.
1 Like
aidacra
(Nathan your friendly neighborhood Support Engineer)
#6
For Epicor 9.05, everything else being equal, installing the 32bit version of OE and the 32bit version of Epicor ERP (Progress, SQL ISO, or SQL Unicode) will provide better performance than 64bit due to an issue with OE, the Windows Operating Systems that were supported with OE 10.2a and Intel processors that goes back quite a ways–if your hardware is AMD, the issue that I am referring to doesn’t apply. A proapsrv (the agent of the appserver process) should never get above ~500MB of private memory, so 32bit is just fine–if it is ever over 500MB, something is leaking memory and it stops processing anyways.
That being said, you can install the 32bit versions of OE and Epicor on a 64bit Windows OS without issues.
