QuestionWhat can be done to improve the speed of the Notification Server and Altiris Console? What items can increase efficiencies?
Answer Disabling Alert Manager Synchronization
How to Disable Alert Manager and Notification Server synchronization: below are the registry changes needed to disable the synchronization functionality of AlertManager/Helpdesk. This has proved to produce performance improvements on busy notification servers where AlertManager/Helpdesk asset and contact synchronization from the Notification Server is not required.
Using regedit, add the following two REG_SZ entries :
HKLM\Software\Altiris\eXpress\Helpdesk Package\DisableAutoUpdateProcessing = true
HKLM\Software\Altiris\eXpress\Helpdesk Package\DisableSyncIncidentProcessing = true
Stop the Altiris Service (AeXSvc.exe) and the Altiris Client Message Dispatcher service.
Go to Start > Run, and type "iisreset" and click OK. This will recycle IIS, including the worker process.
Start the Altiris Service (AeXSvc.exe) and the Altiris Client Message Dispatcher service.
Increasing SQL Performance by defragging the SQL indices
Several defrags can increase SQL performance.
1. SQL script to defrag all database indices for the Altiris database:
declare @index_name nvarchar(255)
declare @table_name nvarchar(255)
declare index_cursor cursor for
select
si.name as index_name,
object_name(si.id) as table_name
from sysindexes si
left outer join sysobjects so on so.name=si.name
where objectproperty(si.id, N'IsUserTable') = 1
and objectproperty(si.id, N'IsUserTable') = 1
and si.name <> object_name(si.id)
and si.impid <> -1
open index_cursor
fetch next from index_cursor into @index_name, @table_name
while @@FETCH_STATUS = 0
begin
print 'Attempting defrag of index [' + @index_name + '] on table [' + @table_name + ']'
dbcc INDEXDEFRAG( 0, @table_name, @index_name )
fetch next from index_cursor into @index_name, @table_name
end
close index_cursor
deallocate index_cursor
2. The above script defrags all the indices used in the Altiris database. Run this against the Altiris database using SQL Query Analyser or other SQL scripting tool.
3. Defrag SQL data and log volumes. Post upgrade the log files of the Altiris database can be heavily fragmented. Use Enterprise Manager or similar SQL management tool to defrag these volumes to greatly improve SQL performance Post-upgrade.
SQL Configuration OptimizationThe 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 > 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 development is to place the .LDF file(s) on a separate physical disk from the data file(s). 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 > 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 ellipsis 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 checkmark.
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, hit 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 heavy 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)
ALTER DATABASE tempdb modify file (name=tempdev, FILENAME= ‘e:\SQLDATA\tempdb.mdf’)
ALTER DATABASE tempdb modify file (name=templog, FILENAME= ‘e:\SQLDATA\tempdb.ldf’)
Stop and restart SQL Server service
Verify that the new tempdb.mdf and tempdb.ldf files have been created. Then go ahead and delete the older original copy.
If there are more than three physical disks available it is possible to split a little further. Spanning the tempdb data files across multiple physical disks increases performance further.
Microsoft Recommended SQL OptimizationsThe following are optimizations recommended by Microsoft for increased performance of SQL in general.
Optimizing Transaction Log Performance. General recommendations for creating transaction log files include:
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 2000 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
