Você está me dizendo que o sistema operacional convidado usa uma quantidade significativamente diferente de memória com base no hipervisor em que está sendo executado, considerando uma carga de trabalho idêntica? Eu não acho que compro isso ...
Um problema óbvio que vejo é que o Internet Explorer é obviamente um aplicativo muito usado em seu servidor de terminal; no entanto, você está usando uma mistura de instâncias de 32 bits e 64 bits do Internet Explorer. O problema com isso é que a memória copy-on-read / write e outras técnicas de memória compartilhada que geralmente beneficiam um servidor de terminal quando várias sessões estão iniciando o mesmo aplicativo, é que elas perdem essas técnicas de otimização; eles não podem ser compartilhados entre as versões de 32 e 64 bits. Se você padronizou todos os seus usuários no Internet Explorer de 32 ou 64 bits, seu uso geral de memória seria menor.
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.