vwman
Contributor
Contributor

Poor Win 2003 64bit performance on ESX 3.5

Are that any tricks to making a Windows Server 2003 64bit SP2 perform better.

The server is configured w/ two processor, 4GB of memory and a 30Gb C:\ drive running on a EMC FC SAN. I know that VMware says 64bit performance is better and 32bit, but I am definately not seeing that. The host is an HP BL480c G1 dual quad core 2.66GHz with 28Gb of memory. The Hosts CPU and Memory utilization are both running less than 50. i have verified that VT Support is enabled in the bios. All of the other 32bit guests seem to be running just fine.

Also, how do I determine if the ESX server is running in 32bit or 64bit mode?

Thanks

vwman

0 Kudos
4 Replies

Assuming that you have set guest OS correctly and that the right vmware tools is installed. How do you determine that it's performing slowly? As far as I now there are no 32/64 bit mode in ESX it is controlled by your guest os settings. Since you are using two cpu's in the vm, it has to wait for two available cores before executing, that might be the cause of performing slowly. How does it perform with 1 vcpu?

0 Kudos
bannonm
Enthusiast
Enthusiast

We experienced performance issues with Windows x64 and SQL 2005 standard on physical servers, so the same would apply to VMs. Here's what we found...

On a 32 bit system, the file system cache working set is essentially limited to 1 GB. This is the maximum size that is blocked off in the kernel for the system cache working set. Since most systems have more than 1 GB of physical RAM today, having the system cache working set consume physical RAM with read I/O is less likely.

This scenario; however, is more prevalent on 64 bit systems. With the increase in pointer length, the kernel's address space is greatly expanded. The system cache's working set limit can and typically does exceed how much memory is installed in the system. It is much easier for applications and drivers to load up the system cache with read I/O. If the demand is sustained, the system cache's working set can grow to consume physical memory. This will push out other process and kernel resources out to the page file and can be very detrimental to system performance.

The work arounds for this problem are either limit your application to a set amount of physical memory (we found out after the fact that SQL 2005 Enterprise has this ability) or set the system file cache less than the amount of physical RAM. This requires programming skills utilizing some newer APIs.

You didn't say what applications your server is running, but thought I'd toss this relatively unknown "feature" of x64 out there.

0 Kudos
vwman
Contributor
Contributor

Finally figured out that the CPU resource setting had been changed to 512MB from unlimited.

vwman

0 Kudos

Been there too, but for me it's just not a place that fall naturally to look for trouble yet.

0 Kudos