One of the most frustrating aspects of administering a Terminal Server environment is the fact that it can take relatively few user sessions to max out a terminal server’s capabilities. Microsoft’s documentation states that there is an effective limit of 300 user sessions per terminal server. However, factors such as the number of applications being run, the quantity of resources consumed by the various applications, the end user’s level of activity, and the server’s hardware can all make the actual number of sessions that a terminal server can support much, much lower than the stated value. One technology that is promising to help to limit the impact of these factors though is the gradual shift to 64-bit computing.
The 32-Bit Memory Model
One of the primary factors that contributes to the limited number of sessions that a terminal server can support is the 32-bit memory model. A Windows Server that is running a 32-bit operating system on 32-bit hardware uses a 32-bit memory model. This memory model imposes a maximum address space size of 4 GB. This 4 GB address space isn’t all available for applications through. Windows splits the operating space down the middle and creates a 2 GB address space for kernel mode processes and a 2 GB address space for user mode applications.
In a Terminal Service environment, this means that a 2 GB address space is shared by all of the processes that are running on the server. Once this 2 GB address space has been exhausted, no new processes can be launched. In terms of the end user experience, this means that if a user attempts to login, their session will be rejected. Users who have logged in prior to the address space being consumed are allowed to remain connected, but the performance of their sessions will be extremely degraded until some memory is freed up.
The advantage of a 64-bit server running a 64-bit Windows operating system is that 64-bit versions of Windows Server are not limited by the 32-bit memory model. A 64-bit server can support a kernel mode address space of up to 8 TB. Therefore, if address space limitations are the limiting factor in the number of sessions that your terminal server can support, then there is a good chance that you can resolve the issue by upgrading to a 64-bit server with a 64-bit operating system.
Page Table Entries
The fact that a 64-bit operating system significantly increases the maximum size of the server’s address space is not the only reason why 64-bit servers can often support more users than 32-bit servers. Another factor that is indirectly related to the address space limitation is that 32-bit servers support a limited number of page table entries. A Page Table Entry’s job is to hold stack allocations for each thread. These stack allocations are used when a thread makes a kernel mode call.
Page Table Entries (PTEs) are an important Windows resource. In fact a PTE shortage can cause Windows to become so instable that the operating system crashes. There is even a Performance Monitor counter (Memory \ Free System Page Table Entries) that you can use to see how many PTEs Windows has available. The generally accepted rule is that if the number of available PTEs drop below 7,000 then the system’s stability becomes questionable.
The reason that PTEs are such a big deal is because Windows reserves a very limited amount of space for PTEs. A 32-bit version of Windows Server 2003 only allocates about 900 MB of space for PTEs by default. If you use the /3GB switch in the BOOT.INI file to allocate more address space to user mode processes, they you severely decrease the number of available PTEs. To put it simply, in the 32-bit version of Windows Server 2003, PTE space is a scarce and valuable commodity. The more processes that run on a server, the more PTE space is consumed. This is especially problematic in terminal server environments since the server must run its own processes and a full set of processes for each user session.
In the 64-bit version of Windows though, PTE space isn’t nearly as much of an issue. In fact, Windows can allocate up to 128 GB of space for PTEs.
If you have been experiencing system stability issues on your terminal server, it might behoove you to use the Performance Monitor to see how much PTE space you actually have available when the server is under an average load. If you are running low on PTE space, you may benefit from an upgrade to a 64-bit server.
Hardware is a Factor
One last thing that I want to mention is that the simple act of buying a 64-bit server with a 64-bit version of Windows Server does not guarantee that you will be able to host more user sessions than you are now. Granted, a 64-bit memory model does have the potential to support a lot more user sessions (up to 600 sessions in some tests). However, the actual number of sessions that your new server can support depends greatly on your hardware. For example, a 64-bit server with 4 GB of RAM installed could theoretically perform more slowly than a comparable 32-bitserver because of the increased virtual memory dependency caused by the larger address space.
Likewise, some administrators have found that if they upgrade to a 64-bit server with plenty of memory (memory is key), that other parts of the server may not be able to keep pace. For example, a common complaint is that the server’s disk subsystem suddenly becomes a performance bottleneck.
Conclusion
In this article, I have explained how 64-bit servers running 64-bit versions of Windows Server 2003 (or eventually Longhorn Server) can overcome many of the limitations that have been traditionally associated with Terminal Server environments. Of course just buying a server with a 64-bit processor and a 64-bit operating system does not guarantee that the server will be able to host large numbers of terminal sessions. The actual number of sessions that a server can support still ultimately depend on the server’s hardware configuration (not just its processor), the types of applications being run on the server, and the level of activity that the users are placing on the server.
