Home / server / Questions / 100531
Accepted
jonfhancock
Asked: 2010-01-08 09:18:30 +0800 CST

Terminal Services - MS Access Frequently "Not Responding"

  • 772

Exposition:

We use a program built in MS Access that I serve via Terminal Services. I just installed a new TS Server with a Quad Core 2.6GHz Xeon, 8GB RAM, and 4 SATA drives in a RAID 0. In installed Server 2008 R2 (64bit obviously). It's only role is TS.

The problem:

With just a few sessions (under 10), I start getting frequent Not Responding messages in each session. When it happens, the users aren't doing anything particularly taxing, just form navigation and simple insert queries.

I can live with some stalls, but it is visually jarring in WS08 because the screen goes gray, and it presents a dialog offering to wait or close with some other options.

Questions:

  1. Any suggestions for improving performance and reducing hangs?
  2. Is it possible to disable the dialog (always wait) and screen graying?
windows-server-2008 terminal-server microsoft-access windows-terminal-services not-responding

1 Answers

  1. Best Answer

    Sounds like you need some basic performance analysis, for starts, to see where you're bottlenecking. The numbers you get from this chart will give you a really gross idea of where to start looking for your performance problems.

    I'd fire up Performance Monitor (Start / perfmon), navgate to the "Performance Monitor" node, and using the "+" icon in the tool bar, add the following counters to the chart:

    • Memory - Pages / sec - This is going to show memory paging activity that contributes to poor perfomance (it can also show paging activity that has nothing to do with poor performance, as well). If you're seeing high paging then you may be bottlenecking on RAM capacity. This may also manifest itself as a disk bottleneck (because of reads / writes to the paging file), so be wary.

    • Physical Disk - Avg. Disk Queue Length - Choose the instance that corresponds to the drive where the Access database file is located (assuming they're on the local disk of the server computer) - This number should be no greater than 2 x the number of spindles in the RAID volume as a very, very general rule of thumb. You can dive deeper into disk counters if it looks like you're having a disk bottleneck.

    • Network Interface - Bytes Total / sec - Choose the instance that corresponds to the NIC that clients are accessing the server through. If the Access database file is hosted on a network share, add an instance for the NIC that the server uses to access that network share (assuming it isn't the same NIC that clients are accessing the share through). - This is going to give you a gross number of the bytes / sec moving on the network interface. You can use a very load testing tool, WSTTCP, to gauge the maximum bandwidth utilization between the server and a client computer. Compare that number to this number.

    Perfmon will add a "% Processor Time" counter for the "total" of all processors in the machine automatically. I'd remove it and add the a Processor - % Processor Time counter for each processor instance in the machine, individually. Microsoft Access is primarily single-threaded, and if you're begging a single processor instance the "_Total" % Processor Time counter may only show 25% (or 12.5% if you have hyper-threading on your processor).

    That covers the potential bottlenecks - disk, RAM, network, and CPU. You can use that chart to get a feel for gross performance of the box. Then you can start drilling into specific bottlenecks and getting a feel for the culprit.

    A Customer of mine deployed a "little Access app" that they'd been using around their office for a couple of years onto a Terminal Server running Windows Server 2008 and were shocked at how poorly it performed. It "ran fine" on desktop machines, and they expected it to be the same on the Terminal Server. It turned out that they were max'ing out all the RAM on the Terminal Server very quickly when users opened the application up simultaneously. It wasn't a big deal for the database to open on one of their desktop machines w/ 1 or 2GB of RAM, but 15 people trying to share it on the Terminal Server was too much. (The database had large PDF files stored as OLE objects inside it, if you can believe it... Unbelievable but true. The MDB file was over 300MB...)

    As an aside: RAID 0? On a server? You're multiplying your odds of failure by using RAID-0, since it has "zero" redundancy. If you're looking or high performance you'd be better off using RAID-10 and sacraficing some disk space in the name of reliability. I can't imagine you need the raw IO performance of RAID-0 on a Terminal Server machine running Microsoft Office-type applications.

    • 2