Items to help improve Console and Server performance in Notification Server

Article Id:179590

Status:Published

Updated On:28-08-2009 02:44

Legacy Id:HOWTO1895

Products:

Management Platform (Formerly known as Notification Server)

Issue/Introduction:

Resolution:

QuestionWhat can be done to improve the speed of the Notification Server and Altiris Console? What items can increase efficiencies?

Answer

Disable Debug mode in Web.config files

Follow the instructions as described in article 33499, "Improving IIS and NS response times by disabling debug mode."

Disable Alert Manager Synchronization

Follow the instructions as described in article 32315, "How To disable Alert Manager synchronization and the AM Hidden ping policy."

Increasing SQL Performance by defragging the SQL indices

Follow the instructions as described in article 40488, "Creating a SQL maintenance plan to optimize database performance"

SQL Configuration Optimization

The following items can increase SQL performance, thus increasing the speed of the Notification Server and the Altiris Console.

An I/O is generally a separate hard drive. This is not true when using ATA/IDE drives and the two drives are mastered and slaved. Consequently, the hard drives would need to be on separate IDE/ATA ribbon cables. For SCSI, two separate drives can be on the same SCSI cable.

In SQL enterprise manager open the database properties.

In the Data Files and Transaction Log tabs, note the current location of the .mdf and .ndf (if used) data file(s) and the .ldf transaction log file(s).

Close the properties and right-click on the database and click on All Tasks > Detach Database.

Once the database is detached, manually move the .mdf, .ndf (if used), and .ldf files.

One of the suggestions from Altiris is to place the .ldf files on a separate physical disk from the data files. This should allow transactions and data reads and writes to operate independently and concurrently.

After moving the .mdf, .ndf (if used), and .ldf files on the various drive locations, reattach to the database.

Open SQL enterprise manager, right-click on the Databases folder and click on All Tasks > Attach Database.

Use the ellipsis button (…) to browse to the current location of the .mdf file. This will populate a list of all the data files and their physical locations. The .mdf will be set based on the current location based on browsing with the ellipses button. However, all the other data files will retain their paths as it knew them before the database was detached.

Each path location will need to be corrected for the new location of that file until the red X turns into a green check mark.

Once all the file path locations have been set correctly, make sure that the database is the correct database name.

Click Verify and then, if that does not bring any errors, click OK.

The database will not be using the new locations for each of the files. This should be verified by the properties of the database on the Data Files and Transaction Log tabs.

Another suggestion that comes from SQL is to move the tempdb to a FAST I/O physical disk drive. This makes a lot of sense given how heavily Altiris uses the tempdb (anytime a temporary table is created).If the server has three physical disks, the operating system should be on one, most of the database files on the other, and the third, with the fastest I/O, should have the transaction logs and tempdb data files.

Moving the tempdb data files is done a little differently than moving data files of other database because the tempdb cannot be detached.Microsoft provided a different way to do this for the tempdb database only.

In Query Analyzer run this command (substitute the correct drive and folders, placing these files on a fast I/O drive)

Create the transaction log on a physically separate disk or RAID (redundant array of independent disks) device. The transaction log file is written serially. Therefore, using a separate, dedicated disk allows the disk heads to stay in place for the next write operation.

Set the original size of the transaction log file to a reasonable size to prevent the file from automatically expanding as more transaction log space is needed. As the transaction log expands, a new virtual log file is created. Write operations to the transaction log wait while the transaction log is expanded. If the transaction log expands too frequently, performance can be affected.

Set the file growth increment percentage to a reasonable size to prevent the file from growing by too small a value. If the file growth is too small compared to the number of log records being written to the transaction log, then the transaction log may need to expand constantly, affecting performance.

Manually shrink the transaction log files rather than allowing Microsoft SQL Server to shrink the files automatically. Shrinking the transaction log can affect performance on a busy system due to the movement and locking of data pages.

Optimizing tempdb Performance—General recommendations for the physical placement and database options set for the tempdb database include:

Allow the tempdb database to automatically expand as needed. This ensures that queries that generate larger than expected intermediate result sets stored in the tempdb database are not terminated before execution is complete.

Set the original size of the tempdb database files to a reasonable size to avoid the files from automatically expanding as more space is needed. If the tempdb database expands too frequently, performance can be affected.

Set the file growth increment percentage to a reasonable size to avoid the tempdb database files from growing by too small a value. If the file growth is too small compared to the amount of data being written to the tempdb database, then tempdb may need to expand constantly, thereby affecting performance.

Place the tempdb database on a fast I/O subsystem to ensure good performance. Stripe the tempdb database across multiple disks for better performance. Use file groups to place the tempdb database on disks different from those used by user databases.