- Introduction
- Monitoring Server Hardware for Performance
- Monitoring Server Services for Uptime
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Monitoring Server Hardware for Performance
Available random access memory (RAM) becomes important when you're running web-based applications that are database-intensive. The more available RAM your application can access, the faster it responds to processing a user request. If the request requires more RAM than is available, the application is forced to use the system's virtual memory. Using virtual memory is much slower than using RAM because Windows is replacing RAM with hard disk space for writing memory-paging files. You may think that having 1GB of RAM or more may solve this problem and you'll never have to worry, but web-based applications using SQL Server often don't give the memory back to the system. (The source of the problem may actually be coding practices, which is beyond the scope of this article. Not closing connections, or using performance-expensive loops and queries, will use memory in a hurry and not give it back to the system.) It's important to an administrator to know when available RAM drops below a certain point, so you can take the necessary steps to release or give back memory to increase performance.
Many scripting examples and prewritten scripts are available free on the Internet to help you in devising your own scripts for administrative tasks. The script in Listing 1, which came from Microsoft's scripting repository, uses the WMI component to monitor the server's available memory. You can simply paste this script into any text editor (without the line numbers) and save it with a .vbs extension. The line numbers are for illustration purposes only.
Listing 1 WMI Script for Monitoring System Memory
1 strComputer = "."
2 Set objWMIService = GetObject("winmgmts:" _
3 & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
4 set objRefresher = CreateObject("WbemScripting.SWbemRefresher")
5 Set objMemory = objRefresher.AddEnum _
6 (objWMIService, "Win32_PerfFormattedData_PerfOS_Memory").objectSet
7 objRefresher.Refresh
8 Do
9 For Each intAvailableBytes in objMemory
10 If intAvailableBytes.AvailableMBytes < 4 Then
11 Wscript.Echo "Available memory has fallen below 4 megabytes."
12 End If
13 Next
14 objRefresher.Refresh
15 Loop
I'm not going to go into much detail about what the WMI scripting objects and classes do; I'll just point out some things that will be useful for customizing the script to your situation.
Line 1 tells the script which machine to look at on the domain. Leaving the strComputer variable with a period (".") checks the local server when the script is executed; replace the period with the server name or IP address of the machine you want the script to check.
Next, specify on lines 10–11 the least amount of available memory before the script will alert you with the message on line 11. In this example, the script will send a pop-up message if the system memory falls below 4MB. To test the script, double-click the script filename. Nothing will be reported if the machine is above the 4MB memory limit. If it's lower, you'll see the message. Experiment a little by changing the limit value on line 10 to make sure that the script is working. If you wanted to get really slick, you could have the script email you the message using the Microsoft CDO component for emailing messages from scripts, and have the script run at specified intervals using Windows Task Manager. I'll leave this to you to explore and figure out; I recommend it for any of scripts discussed in this article.
Another useful piece of hardware to monitor for performance reasons is the server's CPU(s). It's almost amazing how one piece of hardware can affect another in terms of performance. For example, insufficient available memory forces the operating system to use virtual memory, which causes increased disk read/write times. With increased disk time comes an increase in processor usage. If your disk is fragmented, the amount of disk time is even greater, causing more processor usage. The script in Listing 2 is handy for detecting when the processor exceeds a certain threshold. This script utilizes a time interval to make several attempts before alerting you that the threshold has been exceeded.
Listing 2 WMI Script for Monitoring CPU Threshold
1 strComputer = "."
2 Set objWMIService = GetObject("winmgmts:" _
3 & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
4 set objRefresher = CreateObject("WbemScripting.Swbemrefresher")
5 Set objProcessor = objRefresher.AddEnum _
6 (objWMIService, "Win32_PerfFormattedData_PerfOS_Processor").objectSet
7 intThresholdViolations = 0
8 objRefresher.Refresh
9 Do
10 For Each intProcessorUse in objProcessor
11 If intProcessorUse.PercentProcessorTime > 90 Then
12 intThresholdViolations = intThresholdViolations + 1
13 If intThresholdViolations = 10 Then
14 intThresholdViolations = 0
15 Wscript.Echo "Processor usage threshold exceeded."
16 End If
17 Else
18 intThresholdViolations = 0
19 End If
20 Next
21 Wscript.Sleep 6000
22 objRefresher.Refresh
23 Loop
If you know anything about programming, you'll be able to tell right away how this script works. The first thing it does starting on line 10 is cycle thru one or more processors on the system. Inside this loop it first checks whether the current processor exceeds 90% usage. One line 13, the script checks whether it exceeded the threshold limit 10 times. Line 21 tells the script to be dormant for six seconds, and then check the processor(s) again. If the processor exceeds the threshold limit 10 successive times (at six-second intervals), the alert message on line 15 is displayed.
Once this script is executed, it keeps running. The only way to terminate it is to end the wscript.exe process, unless you modify the script to stop after a certain time or fall out of the do loop that starts on line 9 and ends on line 23. Each time you execute a script, a separate wscript.exe process is started. Keep this in mind as you're experimenting. You could even write a script that shuts down other scripts at certain times. The sky's the limit!
While we could monitor many other hardware devices, working with the two I've described should get your feet wet.