If you would like to read the other parts in this article series please go to:
- How Longhorn Server’s Server Manager will Change Server Management (Part 1)
- How Longhorn Server’s Server Manager will Change Server Management (Part 2)
In Part two of this article series, I showed you how the Event Log Viewer has been modernized in Longhorn Server and how the Event Viewer has been integrated into the Troubleshooting section of the Server Manager. In this article, I want to conclude this article series by talking about the two other features included in the Troubleshooting section; the Service Control Manager and the Performance Diagnostics utility.
The Service Control Manager
Just beneath the Event Viewer container in the Server Manager’s Troubleshooting section is the Services container. If you click on the Services container, then the details pane of the Service Control Manager will be displayed.
As you know, Service Control Manager is not new to Longhorn Server. It has existed in every version of Windows Server. I don’t want to waste too much time talking about the Service Control Manager because, from what I can tell, it is basically unchanged since Windows Server 2003. I did however want to at least mention that the Service Control Manager is now accessible through the Troubleshooting section of the Server Manager.
What’s a lot more interesting is the Performance Diagnostics container. If you have worked with Windows for a while, you are no doubt familiar with the Performance Monitor. The Performance Monitor is a part of the Performance Diagnostics portion of the Server Manager, but there’s a lot more to it than that.
If you select the Performance Diagnostics container, you will see a resource overview, similar to the one shown in Figure A. As you can see in the figure, the top portion of the resource overview displays a set of graphs that illustrate CPU, disk, network, and memory utilization.
Figure A: The resource overview graphically illustrates the utilization level of your system’s primary components
As you look at Figure A, you’ll notice that just below the graphs are individual listings for the CPU, disk, network, and memory. At first glance, these listings don’t really appear to give you any information that you can’t get by looking at the graphs above. However, if you look to the right side of the screen, you will notice a down arrow in each section. If you click these down arrows, the resource overview will give you much more detailed information about the utilization of each component. For example, if you click the down arrow in the CPU section, you’ll see a listing of all of the processes that are running on the server and how much CPU time each process is using. Similarly, clicking the down arrow in the disk section will cause the resource overview to display a list of processes that are accessing the disk and the levels of disk activity that those processes are generating.
If you go back to the console tree and expand the Performance Diagnostics container, you’ll see that it contains a Monitoring Tools container. The Monitoring Tools container doesn’t do anything by itself, but it does contain two different monitoring tools; the Performance Monitor and at the Reliability Monitor.
The Performance Monitor
I want to briefly talk about the Performance Monitor just in case you’re not familiar with it. For those of you who are familiar with the Performance Monitor, you can skip ahead to the next section. The Performance Monitor does not seem to have changed much since Windows Server 2003, aside from its integration into the Server Manager.
The Performance Monitor, shown in Figure B, is a diagnostic utility that is designed to help you to troubleshoot hardware bottlenecks. If you look at the bottom of the figure, you can see a check box next to a counter called % Processor Time. The % Processor Time counter takes a look at the server’s overall processor utilization at certain intervals and reports its findings on the graph.
Figure B: The Performance Monitor is a diagnostic tool used to locate hardware bottlenecks
The % Processor Time counter is only one of hundreds, or maybe even thousands, of available counters. Each counter is designed to measure a certain aspect of system performance. There is typically a threshold value associated with each counter that represents problematic performance. For example, if you look at the figure, you can see that there are a few spikes in processor activity in which the processor reaches 100% utilization. These spikes are considered normal, because the average processor utilization aside from the spikes is fairly low. If the average processor usage were consistently above 80%, it would represent a processor bottleneck.
Don’t want to get too deep into the science of performance monitoring, I wanted to at least introduce the Performance Monitor for the benefit of anyone who has never used it before.
The Reliability Monitor
The last thing that I want to show is the Reliability Monitor. The Reliability Monitor is an excellent tool for those people who sometimes have to work with unfamiliar systems. For example, if you happen to be a consultant and a client calls you to come and look at a server problem, then one of the first questions that you’ll probably ask the client would be about the history of the problem, or the history of the server. The problem is that the person that you are talking to may or may not give you all the information that you need. For example, the person may be cooperative but not really know the server’s history. Another possibility is that the person that called you actually did something to cause the problem and is too embarrassed to admit it. This is where the Reliability Monitor comes into play.
The Reliability Monitor, shown in Figure C, does a couple of different things for you. The first thing that you’ll probably notice when you look at the figure is the large graph. If you look at the top portion of the graph, you’ll see a bunch of dots connected by a line. These dots represent the system stability Index for each day. The basic idea behind this index is that the index number slowly increases for each day without a failure and without installing or uninstalling any applications.
Figure C: The Reliability Monitor keeps track of various failures and events that occur on your server
I don’t have any documentation on the Reliability Monitor so I can’t really say for sure, but from what I have been able to observe, the stability Index seems to go down after you install an application. The index slowly goes back up a little bit each day as the system proves itself to be stable while running the application. The same thing happens whenever any kind of failure occurs. When a failure occurs, the stability Index for that day drops sharply. As time goes on the stability Index will eventually increase assuming that no more failures occur.
You will notice in the lower portion of the graph that failures are marked on the day that they occurred. Just by looking at the graph, you can see what type of failures have been an issue in the past. You can even double click on a particular failure to get more detailed information about the event that generated the failure report.
One thing that I really liked about the Reliability Monitor is that it allows you to anticipate problems. For example, suppose that by looking at the graph you happen to notice that there is an application failure that occurs every four days. If this happens consistently, then there is a definite pattern to the event. Many times, knowing the pattern is very helpful in troubleshooting various failures. Displaying failures in graphical format makes it easy to spot patterns that you might otherwise miss.
In this article, I have discussed the various troubleshooting tools that are built into the Server Manager. Hopefully as you have read this article series, you have begun to understand just how important the Server Manager will be in Longhorn Server. Keep in mind that at the time that this article was written, Longhorn Server was still in beta testing. Any of the things that I have talked about could potentially change by the time that Longhorn Server is eventually released.
If you would like to read the other parts in this article series please go to: