Before troubleshooting Configuration Manager site performance, the first step should be to capture the actual site performance.
Collected performance counter information will give you a good overall view of how the site server is processing site information, any backlog of files for each Configuration Manager subsystem, and any other site system operations. For more information about using the Configuration Manager performance counters, see Monitoring Site Performance.
To assist in diagnosing a possible performance problem with a particular type of data, it is possible to stop Configuration Manager inbox file processing for different subsystems to have the server focus on one message type. This can assist you in determining whether the server is just very busy at this time or whether one type of data is processing slower than expected.
A number of system configuration issues can manifest themselves with slower server processing. Some of the most common causes and diagnosis are covered in this topic.
General Site System Slow Processing
If Configuration Manager site system performance appears to be running slowly, careful diagnosis of your disk system may be required.
Solution
Verify the following if you suspect a site server processing slow down:
- That disk-intensive operations are not
running.
- That antivirus software is not scanning the
site server inbox directories.
- That a system backup is not running during
periods of perceived site system performance slow downs.
If none of the preceding conditions exist, consider the following:
- Restarting the Configuration Manager
site server and running a disk benchmark program to verify the
performance of your disk subsystem.
- If you have a SAS Raid controller, look
carefully at the configuration of your write caching settings. If
write caching is not enabled, Configuration Manager site system
performance will be severely impacted.
General SQL Performance Troubleshooting Reference
The following information should be considered if the Configuration Manager site database or site database server system performance appears to be running slowly.
Solution
Ensure that the following items have been configured and scheduled to maintain site database performance goals:
- The SQL Server site database,
SQL Server tempdb, and SQL Server log files are installed
on different disk volumes.
- General SQL Server site database
maintenance is performed and that the Rebuild Indexes predefined
site maintenance task is scheduled to run regularly.
- Consider dividing the SQL Server tempdb
database into multiple database files. For best performance, the
SQL Server tempdb database should be divided into a number of
files corresponding to half the number of processors installed on
the SQL Server computer. When the tempdb SQL Server
database is installed using only one file, collisions with multiple
processors might occur. For more information, see "PRB: Concurrency
enhancements for the tempdb database" at http://go.microsoft.com/fwlink/?LinkId=103713.
- For general SQL performance investigations,
see the "Troubleshooting Performance Problems in SQL Server 2005"
whitepaper at http://go.microsoft.com/fwlink/?LinkId=103718.
Client Deployment Impact on Site Server Processing
During Configuration Manager client deployment, a lot of information is sent from the newly installed client to the site server, including the following:
- Fallback status point state messages during
the installation process.
- Configuration Manager client
registration.
- Full hardware and software inventory
reports.
- Full WSUS software update compliance scan and
state message reports.
Solution
When planning to deploy or upgrade a substantial number of Configuration Manager clients, ensure that their configured client agent schedules and the performance impact of other site processes are taken into consideration. Deploying or upgrading Configuration Manager clients during a large software updates deployment is not recommended.
When installing Configuration Manager clients, it might take a considerable amount of time for the site server to process all of the client installation generated information. During this time, site system performance might be degraded until all of the client deployment data has been processed.
Slow Hardware Inventory Processing
The following information should be considered if you suspect that hardware inventory report processing for the Configuration Manager site is slow.
Solution
If you suspect that hardware inventory report processing is slow for a Configuration Manager 2007 site, the following actions should be taken:
- Inspect the client inventoryagent.log log
file to determine whether the client is sending delta hardware
inventory reports or full reports. After initial client deployment,
a very high percentage of hardware inventory reports should be
deltas, which contain much less data than full inventory reports.
If you are seeing a significant number of full inventory reports,
this could be caused by inconsistent inventory report processing by
the site server. For example, a delta hardware inventory report
could be processed before a full inventory report for the same
system has been processed. In this situation, a hardware inventory
resynchronization request will be sent to the client and an
additional full inventory report will be generated. To determine
whether this is happening, review the dataldr.log log file on the
site server.
- Inspect the size of the hardware inventory
files in the site server's inbox directory to determine whether the
software inventory files have grown significantly from previous
inventory reports. If hardware inventory report file sizes have
grown beyond an initial hardware inventory report file size
baseline, you should determine the cause and whether the larger
inventory report files are expected to be larger. One possibility
is that the site’s SMS_def.mof file has been modified to collect
more inventory information from clients.
Note The performance counters monitor only the file processing rate, not the size of the files. - Determine whether there is a consistent
SMS_def.mof hardware inventory reporting file in use throughout the
hierarchy. If not, the hardware inventory processor might be
running very slowly because of changes in the database schema
caused by the different SMS_def.mof files throughout the hierarchy.
The dataloader.log log file will record instances of database
schema changes and should be reviewed when investigating this
issue. For more information about using a consistent SMS_def.mof
hardware inventory reporting file throughout the hierarchy, see
Performance
Configuration Recommendations.
Slow Software Inventory Processing
The following information should be considered if you suspect that software inventory report processing is slow.
Solution
If you suspect that software inventory report processing is slow for a Configuration Manager 2007 site, the following actions should be taken:
- Inspect the site sinvproc.log log file on the
site server to determine whether you are processing delta software
inventory reports or full reports. After initial client deployment,
a very high percentage of software inventory reports should be
deltas, which contain much less data than full inventory reports.
If you are seeing a significant number of full inventory reports,
this could be caused by inconsistent inventory report processing by
the site server. For example, a delta hardware inventory report
could be processed before a full inventory report for the same
system has been processed. In this situation, a software inventory
resynchronization request will be sent to the client and an
additional full inventory report will be generated.
- Inspect the size of the software inventory
files in the site server's inbox directory to determine whether the
software inventory files have grown significantly from previous
inventory reports. If software inventory report file sizes have
grown beyond an initial software inventory report file size
baseline, you should determine the cause and whether the software
inventory report files are expected to be larger. One possibility
is that the software inventory information to be collected from
clients has been modified by an administrator.
Note The performance counters monitor only the file processing rate, not the size of the files.
Slow DDR Processing
The following information should be considered if the Configuration Manager site discovered data resource (DDR) file performance processing appears to be running slowly.
Solution
If you suspect that DDR message processing is slow for a Configuration Manager 2007 site, the following actions should be taken:
- Inspect the DDR related logs to see whether
you are processing heartbeat DDRs or Active Directory system or
user discovery DDRs.
- If there is a large percentage of Active
Directory discovery DDRs over time, you might need to carefully
review the Active Directory discovery settings throughout the site
hierarchy to ensure that multiple sites are not discovering the
same resources. If multiple sites are discovering the same
resources, certain site database tables can become very large,
which will slow down DDR processing.
Slow State Message Processing
The following information should be considered if the Configuration Manager site state message processing performance appears to be running slowly.
There are several classes of data that are processed by the Configuration Manager 2007 state system. In general, the largest generators of state messages are as follows:
- Software updates information.
- Desired configuration management report
information.
- Asset intelligence Client Access License
(CAL) reporting information.
- Fallback status point messages.
If the state message processing for a site appears to be slower than expected, the following solution might help resolve the slow message processing condition.
Solution
There is no way to identify the type of data being processed by the state system at any given time by inspecting the state system performance counters. If you suspect that state message processing is slow for a Configuration Manager 2007 site, the following actions should be taken:
- Check the state system logs for errors.
- Check the state system logs for re-sync
reports from clients. If the site server thinks data is missing
from a client, it will generate a re-sync request to the client.
The client will respond with a large amount of historical data,
which can cause extra processing on the server.
- Rebuild indexes on your Configuration Manager
2007 site database. The state system interacts heavily with
SQL Server site database, and fragmented indexes can affect
performance.
- Check the schedules of site operations that
generate state messages. In particular, you should check the
following:
- Software update schedules.
- Configuration baseline assignment schedule
for desired configuration management.
- Asset intelligence Client Access License
(CAL) reporting schedules.
- The impact of any current client deployment
operations.
- Software update schedules.