Making Changes Based on Analysis

After you identify the problems in your site hierarchy design, you should analyze the cost in time and money that will be required to resolve each problem against the benefits of improved performance. You will probably need to perform this analysis several times to create a system with outstanding performance.

It is often true that a computer system could have better performance, regardless of the amount of performance tuning that has already been conducted. However, there is a point at which the time gained by increased performance is outweighed by the money and effort required to create a better system.

Identifying the cost, in both additional hardware expenditure and additional hours to troubleshoot and resolve a performance issue, can be difficult. After your pilot project has been running for some time, you will have a better idea of how to conduct your performance testing and troubleshooting. You can assume at the start, however, that disk I/O problems will be the hardest to diagnose and will require the most hours to resolve, while CPU problems will be the easiest to diagnose and resolve. At the same time, however, disk I/O improvements are likely to give a very large return on the time invested in diagnosing them, so they are likely going to be worth your time and effort.

Hardware and Software Tuning

You can solve some problems, such as disk I/O and memory issues, without hardware tuning. For example, if you receive “Out of Virtual Memory” error messages on your site server, you might need to adjust your virtual memory sizes. When this occurs, set the initial paging file size to 11 MB more than the size of the RAM (for example, 128 MB computers should be set to 139 MB), and the maximum paging file size to any setting higher than that.

Some hardware issues can be solved quickly and easily by adding a physical disk or more memory. These are easy, relatively inexpensive options that will tax neither your hardware budget nor your time or staffing resources. For this reason, it is a good idea to identify these problems first and resolve them as you proceed through each iteration of your system analysis.

SMS disk I/O

Testing and optimizing your disk input/output (I/O) is vital to a successful SMS deployment. Although you can take several different approaches after deployment to reduce disk I/O problems, it is best to address those issues when testing your site system hardware. Both hardware and software RAID solutions can be very effective in addressing disk I/O issues.

When trying to avoid problems caused by disk I/O bottlenecks, consider the following actions. These actions will provide progressively better performance (at increasing levels of expense):

1. Add more physical disks. Installing the data device, log device, and SMS directories on separate disks will result in moderate improvement.
2. Implement software RAID, which is an implementation of RAID storage methods in system software rather than in the firmware of a RAID controller. While commonly rejected for not being a true “enterprise level” solution, software RAID can provide very inexpensive performance improvements for smaller SMS installations. Using the software RAID built into Windows NT to stripe a couple of disks will result in good improvement.
3. Implement hardware RAID arrays. If you have a large number of disks in multiple volumes, implementing hardware RAID will result in excellent reliability and speed improvements.

Disk I/O issues can be difficult to diagnose. For information about individual disks and software RAID, see the Windows NT Workstation 4.0 Resource Kit and your hard drive specifications. Diagnosing the disk I/O activities of your hardware RAID is more difficult because the built-in Windows NT performance counters for disks do not recognize disks masked by a hardware RAID layer. You might consider using third-party software to identify disk I/O problems and consulting hardware RAID manufacturers to optimize systems that use hardware RAID.

SMS tuning

The intervals of all the operations that run in your site will greatly affect the load that your site will sustain while running every day. For example, hardware and software inventory are the most processor-intensive operations on clients and servers. Reducing the frequency of inventory collection by as much as your business needs allow will free up computing resources and enable you to maximize your hardware investment. Carefully select the low network traffic times to schedule hardware and software inventory to run on clients.

The number of SQL Server connections required by SMS is determined mainly by the number of remote SMS Administrator consoles that are running and connecting to it at any given time. If more than 40 simultaneous remote SMS Administrator consoles will access your site, you should monitor the connection status in SQL Server. By default, the SMS Provider uses a maximum of 60 connections to SQL Server. If the SMS Provider is constantly using all 60 connections to SQL Server, increase the value of MaxSQLConnections to the maximum number of connections that you want to allocate to the SMS Provider. For more information about setting SQL Server connections, see Chapter 4, “Setting Up Remote Administrator Consoles,” in this guide.

SQL Server tuning

Collecting the following information about the SMS site and software metering databases in your pilot project should provide you with an accurate idea of the hardware required for SQL Server:

• TempDB data size
• TempDB data space available
• TempDB log size
• TempDB log space available
• SMS data size
• SMS data space available
• SMS log size
• SMS log space available
• SMS_LicDB data size
• SMS_LicDB data space available
• SMS_LicDB log size
• SMS_LicDB log space available

You can use this information to manually tune SQL Server for the SMS site databases and software metering databases in your site hierarchy.

Moving Site System Roles

As your business needs change and expand, you might find that your original site hierarchy design will reduce performance to unacceptable levels. If this situation occurs, you might be able to increase the performance of your site by moving and assigning site system roles to additional computers. Keep in mind that some site system roles can be moved after installation; others cannot. Table 2.10 lists which roles can and cannot be moved after SMS installation.

Table 2.10 Site System Roles That Can and Cannot Be Moved After Installation

Removing the CAP role from the site server

If you want to remove the CAP role from the site server to another server to lighten the load on the site server, use the following procedure.

  To remove the CAP role from the site server

1. Assign the CAP role to another server, share, or volume.
2. Wait for the installation to complete and the second CAP to be online long enough for clients to detect it (perhaps a week).
3. Remove the CAP site system role from the site server computer.

This process will enable all clients to complete the 23-hour client service maintenance cycle, which updates the client registry with the information about the new CAP. If this process is not followed and the clients do not detect the new CAP, and the original CAP role (on the site server) is removed, the clients cannot connect to a CAP and update their registry. In effect, these clients are “orphaned.”

Recovering from the Failure of a Site’s Single CAP

If the single site system (other than the site server) that is performing the CAP role fails unexpectedly, the SMS clients installed through the Windows NT Remote Client Installation method are effectively “orphaned.” This occurs because there is no way for SMS client software to gain access to the site for updates and for sending inventory and other information to the site server except through the CAP. If this happens, do the following:

  To recover from the failure of a site’s single CAP

1. Install a new Windows NT Server computer and assign it the same NetBIOS name as the CAP that failed.
2. In the SMS Administrator console, navigate to Site Systems.

Systems Management Server   Site Database (site code - site name)      Site Hierarchy         site code - site name            Site Settings               Site Systems

3. Select the current CAP and then delete it.
4. Create a new site system with the same name as the deleted one and assign it the CAP role.

SMS will create the CAP role on the new server. After the process is successfully completed, SMS clients can once again connect to the CAP.

Service and thread components

Table 2.11 lists the site systems on which SMS service components are installed.

Table 2.11 Where SMS Service Components Are Installed

Table 2.12 lists the types of sites on which each of the SMS thread components run.

Table 2.12 Sites Where SMS Thread Components Run