My client has a virtual Server 2008 R2 terminal server running under ESXi 5.1.

This server, which been in production for around 4 months, experiences intermittent slowness / non-responsiveness for logged-in users. When this issue occurs iexplore.exe processes (32- & 64-bit) are using very high CPU & RAM.

Screenshot: Windows Task Manager: "Processes" tab
iexplore.exe high resources

Screenshot (taken at different time than first screenshot): Windows Task Manager: "Performance" tab task manager

(These two screenshots were taken at separate times)

Any ideas on how to resolve this issue permanently?

We have a number of terminal servers used by clients, however this is the first TS that we've deployed under VMware. Our other terminal servers are either under XenServer or physical. Could this be an issue with VMware?

  • Neither screen shot shows high RAM usage. They both show RAM usage around 50% (the balance is cache) I suspect that you aren't diagnosing the problem correctly and it likely has nothing to do with RAM usage. – David Schwartz Mar 18 '13 at 2:43
  • Overall RAM usage is not high, however wouldn't 791MB being used by one iexplorer process be considered high? – Ash Mar 18 '13 at 4:52
  • Since overall RAM usage isn't high, it doesn't matter. It's like trying to breathe less air -- if you have plenty of air, why would you bother? – David Schwartz Mar 18 '13 at 6:03

So you're telling me that the guest OS uses a significantly different amount of memory based on what hypervisor it's running under, given an identical workload? I don't think I buy that...

One obvious problem I see is that Internet Explorer is obviously a very heavily used application on your terminal server, however, you're using a mix of 32-bit and 64-bit instances of Internet Explorer. The problem with this is that the copy-on-read/write memory and other shared memory techniques that usually benefit a terminal server when multiple sessions are launching the same application, is that they lose those optimization techniques; they cannot be shared among 32 and 64 bit versions. If you standardized all your users on either 32 or 64 bit Internet Explorer, your overall memory usage would be less.

Running an Application

After user logon, the desktop (or application if in single-application mode) is displayed for the user. When the user selects a 32-bit application to run, the mouse commands are passed to the Terminal Server, which launches the selected application into a new virtual memory space (2-GB application, 2-GB kernel). All processes on the Terminal Server will share code in kernel and user modes wherever possible. To achieve the sharing of code between processes, the Windows NT Virtual Memory (VM) manager uses copy-on-write page protection. When multiple processes want to read and write the same memory contents, the VM manager will assign copy-on-write page protection to the memory region. The processes (Sessions) will use the same memory contents until a write operation is performed, at which time the VM manager will copy the physical page frame to another location, update the process's virtual address to point to the new page location and now mark the page as read/write. Copy-on-write is extremely useful and efficient for applications running on a Terminal Server.

When a Win32-based application such as Microsoft Word is loaded into physical memory by one process (Session) it is marked as copy-on-write. When new processes (Sessions) also invoke Word, the image loader will just point the new processes (Sessions) to the existing copy because the application is already loaded in memory. When buffers and user-specific data is required (for example, saving to a file), the necessary pages will be copied into a new physical memory location and marked as read/write for the individual process (Session). The VM manager will protect this memory space from other processes. Most of an application, however, is shareable code and will only have a single instance of code in physical memory no matter how many times it is run.

> It is preferable (although not necessary) to run 32-bit applications in a Terminal Server environment. The 32-bit applications (Win32) will allow sharing of code and run more efficiently in multi-user sessions. Windows NT allows 16-bit applications (Win16) to run in a Win32 environment by creating a virtual MS-DOS-based computer (VDM) for each Win16 application to execute. All 16-bit output is translated into Win32 calls, which perform the necessary actions. Because Win16 apps are executing within their own VDM, code cannot be shared between applications in multiple sessions. Translation between Win16 and Win32 calls also consumes system resources. Running Win16 applications in a Terminal Server environment can potentially consume twice the resources than a comparable Win32-based application will.

  • Thanks for your response. Originally users were only using the standard 32-bit IE, however I asked them to try 64-bit IE after complaints about the slowness of the terminal server (high CPU usage from iexplorer *32). The virtual server has 2 x Xeon E5620 processors @ 2.40GHz, 24GB RAM. At most around 20 users are logged in at any one time. We have other terminal servers running under Xen (yes different workloads, but similar number of users and requirements) that don't have their CPU usage used up like this server. – Ash Mar 18 '13 at 5:00
  • I could see CPU usage being drastically different across hypervisors if on one of them, the integration tools/services were not installed on the guest VM... – Ryan Ries Mar 18 '13 at 13:13
  • VMware Tools is installed on the guest VM. – Ash Mar 18 '13 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.