Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog

Performance Tuning for SMP 7.1SP2

Created: 27 Dec 2012 • Updated: 26 Apr 2013 • 7 comments
HighTower's picture
+7 7 Votes
Login to vote

At the last couple of Symantec Endpoint Management User Group meetings I talked about a couple of things that can be done to improve the performance of your Symantec Management Platform.  I figured it would be best to summarize them in the group itself:

  1. The first one I mentioned had to do with changing the Kerberos authentication order in the IIS website from Negotiate > NTLM to NTLM > Negotiate
  2. The second we just ran across this week.  Our 16 core, 24gb RAM SQL server was running a constant 80-90% CPU utilization and we were experiencing frequent deadlocks.  On Sunday, a deadlock/blocking situation corrupted our PMImport and broke Patch.  Very bad things happened.

    In any event, we found that the SQL Tuning guide had been updated by Symantec earlier this month.  We implemented their recommendations about Maximum Degree of Parallelism (we changed from '0=unlimited' to '2').  We're theorizing that we actually have too much horsepower for the SQL server and unlimited MDOP was causing problems.  Basically, after making the recommended changes our SQL server idles by at about 10% CPU and the SMP console FLIES.  7000 computer objects, CMS, SMS, AMS, and Mobile all installed and this thing performs as well as the fake demo environments.

    Settings - SQL Server Instance

    • If your SQL server has more than 4 cores, lowering the Max Degree of Parallelism (rather than leaving at the default of 0 (unlimited)) will provide better performance. To set:
      • In Server Properties, on the Advanced page, set the Max Degree of Parallelism to half the number of physical processor cores on your system, up to a maximum value of 8.4
        • For a client-facing server that does not do much reporting, the suggested value is 2.
        • For a reporting server, or parent server in a hierarchy, the suggested value is 4.
        • For servers that are queried by IT Analytics, the suggested value is 4.
        • Monitor CXPACKET waits on the SQL instance. The goal is that they be less than 5% of relevant waits. 6 If CXPACKET waits remain higher than 5%, consider lowering the Max Degree of Parallelism by half again.

    • Set the Cost Threshold for Parallelism to 10
    • Enable Arithmetic Abort in the Server/Instance Properties on the Connections page.
  3. Finally, and this is one that we have not implemented yet but are likely to do so in January, is the approach at splitting up the IIS worker pools to no longer have all of the web apps contained in the DefaultAppPool and instead give them their own memory spaces to work in:


The first two changes made a WORLD of difference for the performance of the product and our ability to use it.  Imagine no longer taking 20-30 seconds to right-click a resource and get to the Resource Manager page!


Comments 7 CommentsJump to latest comment

BigDaddyPS's picture

Excellent information! I will give this a try. Thanks!

Login to vote
dlopes's picture

It´s important to notice that those performance tricks made a HUGE difference in our production enviroment, yest it works ;)

We already split the app pools in our production enviroment, but it´s important to notice that you also have to regroup them before updating or appling any hotfix from symantec.

Thanks again!

Daniel Lopes de Oliveira
Technical Team Leader - Endpoint Management & Mobility

Login to vote
BigDaddyPS's picture

Looking into it now, I am not sure that this is going to do much for me.  My NS and SQL are both on one box and I only have one processor.  Should i still give this a try?

Login to vote
HighTower's picture

Until your NS and SQL are split onto separate servers I don't think you're going to be able to resolve your performance problems.

Login to vote
HighTower's picture

It seems that Symantec has pulled down KB and Connect articles regarding separating the IIS App Pools.  The original article can be found in Google's cache and there is a comment that suggests that separating the app pools may lead to problems with some solutions.

In light of that I will be reverting my split pools back to the factory configuration when I apply rollup v4 and leave them that way until further guidance is provided by Symantec.

The undo script was lost when the Connect article was taken down.  If you're looking to UNDO your custom pools, use this script.  However, I will not provide the script to create the custom pools, so don't ask :)

@echo off

set appcmd=%comspec%\..\inetsrv\appcmd

%appcmd% set app "Default Web Site/Altiris/NS/Agent" -applicationPool:"Classic .NET AppPool"

%appcmd% set app "Default Web Site/Altiris/TaskManagement" -applicationPool"Classic .NET AppPool"

%appcmd% set app "Default Web Site/Altiris/ClientTaskServer" -applicationPool"Classic .NET AppPool"

%appcmd% set app "Default Web Site/Altiris/ActivityCenter" -applicationPool:"Classic .NET AppPool"

%appcmd% set app "Default Web Site/Altiris/PatchManagement" -applicationPool:"Classic .NET AppPool"

%appcmd% set app "Default Web Site/Altiris/PatchManagementCore" -applicationPool:"Classic .NET Apppool"

%appcmd% set app "Default Web Site/Altiris/PatchManagementMac" -applicationPool:"Classic .NET Apppool"

%appcmd% set app "Default Web Site/Altiris/SoftwarePortal" -applicationPool:"Classic .NET AppPool"

%appcmd% set app "Default Web Site/Altiris/ITAnalytics" -applicationPool:"Classic .NET AppPool"

%appcmd% set app "Default Web Site/Altiris/ITAnalyticsCSMP" -applicationPool:"Classic .NET AppPool"

%appcmd% set app "Default Web Site/Altiris/ITAnalyticsSEP" -applicationPool:"Classic .NET AppPool"

Login to vote
BigDaddyPS's picture

The performance wasnt bad when we first brought up the server a year and a half ago.  I have noticed since then that is has slowed a bit and i just wanted to get some tricks of the trade to maybe better the perfomance of the server, maybe closer to what it was when we first brought it up.

Login to vote