Intel,Altiris Group

We have been using NS 6.0  and NS 7.0 on a VMware platforms. After migrating from 6.0 to 7.0 we have moved the CMDB to a separate physical server, The Altiris Console performance actually worsen, even though more CPU and RAM was available.

I am reading here and there that the physical server will outperform the virtual by 10-50 %.

In real life I see poor performance by the NS on VMware. Our environment is as follows:

- highly distributed WAN environment with many WAN sites;

- 3000 workstations;

- CMS suite with SW inventory daily, HW inventory weekly, AD import of special user groups hourly; default settings for the agents settings; weekly new SW deployments; bi-weekly patch management deployments; hourly policy updates; daily basic inventory

- separate SQL server - physical;

- separate package and task servers at major sites with 50+ computers;

- the Symantec Management Console is used by 5-10 service desk analyst plus 5-10 reporting users.

What is needed at this point is a documented performance metric comparison between the identical physical vs. virtual environemnt.

Has anybody seen such a thing? How soon can this be created?

Your title says 7.1, but your description says 6.0 to 7.0.  Are you running 7.0 or 7.1?

How many vCPU's are in use by your NS?  I assume you only have one NS.  How much RAM?

Some parts of the console are slow, no matter what, in Altiris 7.0.  Performance is vastly improved in 7.1.

My greatest recommendation without knowing any additional information is that you move the software inventory to monthly, replacing the "need to know" data with custom inventories that can run more frequently (e.g. daily).  This is Symantec best practice to avoid performance degradations such as what you're seeing.  That's a tremendous amount of inventory burden.  Replace it with custom inventories.  Likewise for the hardware inventory, move to monthly.  Set both to gather during non-production hours, but if some systems are offline, understandably you'll want them to run it when they turn on.

Does your NS serve more than 500 clients?  If so, provision a site server with package and task services to cover the nodes unassigned to other site servers at your WAN sites.

When you say it's used by 5-10 service desk analysts and 5-10 reporters, do you mean that you run ServiceDesk?  If so, where is it installed -- separate box or on the NS?  Do you mean concurrent users?  Or total that's who has access?

Be sure the agent update configuration is every 1 hour, task every 5 minutes should be fine with sufficient task servers, your delta and policy update schedules should be every 30 minutes, your full resource membership update schedule should be every day, delta inventory collection can happen every week.  As I mentioned, full inventories should only be happening every month.  Change your settings to these values (unless they are already less frequent than this), and report back what they used to be.

Please post back with answers to questions above, what settings you have vs. what you changed them to based on best practice above, and whether this has improved performance.  If performance is still slow, please run taskmgr on your NS when the console is being accessed and is slow.

Having more CPU and RAM for SQL is great, but the #1 requirement for is high IO.  This is why virtualized SQL is generally not recommended - virtualization usually hinders IO.  On your SQL server, monitor the Avg. disk queue length (should always be less than 1.00) and transfers per sec. (aka IOPS - should be able to surpass 600 IOPS).  Here is a very helpful doc on SQL performance and optimization...

http://www.symantec.com/business/support/index?page=content&id=HOWTO10723

first yes we need to know more about yoru environment but second I do have some experience with this.

1. we run NS using VMware it is highly cpu intensive and does at time chug in VMware.  We have assigned two CPU's to this system and 4GB of RAM.  We use a dell 2850 ESX 3.5 right now. Local Storage

2. the sql server is a dell 2850 with 4GB of RAM and has not been a problem runs multiple databases.  Local Storage RAID 5 SCSI storage.

The NS Server (7.0 SP4) at the beginning did give us major issues as we started only one cpu but the second CPU has helped.  It is by far the most CPU intensive server we have on that ESX host with 7 other servers.

At times it does chug down but pops back up.  We did have a time where the NS would just go out to lunch for like 50 minutes at a time I had a ticket open with Symantec regarding this and they recommended - NOT MUCH.

A few things I did is looked at the scheduled task and disabled the items we did not need running like Linux and Redhat task then also really looked at a bunch of the task that run like ALL the time.  I backed these off.  The adobe and Microsoft updates were big ones they were running like every 30 minutes or something and now I only run them every 12 hours and also on a off time frame like 6:32 so they won't conflict with something that runs on a normal timeframe of say 6:30.  The other item to really look at is your NS Server settings - Resource Membership Updates these are set to unrealistic schedules by default and are a known cause for CPU issues.  I have set these to run every hour and should probably back that off a bit more.

The last thing in our cpu puzzle issue was Mcafee DAT updates.  Every day at 4PM our servers updated DAT's and this would just cause NS to die for like 30 minutes.  We fixed this by going to SEP now hands down from a management standpoint I would not recommend SEP as it has been HELL for the last 6 months but from a cpu standpoint it for sure appears to be better on the clients and dat updates are no longer a issue even though the dats are like twice the size fo Mcafee dats.  I'm only providing you the information from my experience.

As far as this comment:

How soon can this be created?

I would ask when can you begin and how long do you think it will take you?  Sorry but I don't see anyone building this type of documentation for you.  I would be more than willing to provide you with all my experience though.

FYI our environment is very similar but we only do about 200 total CMS machines 35 Inventory on Servers.

We have a multi wan environment that is connected via VPN site to site connections. We also have task and package servers in our 4 locations because of the latency between the sites.

Hands down the console just sucks.  I'm very eager to jump to 7.1 as soon as I have time.

Symantec says to expect a 10% performance degradation in VMWare.  I think it's more CYA than anything, I have access to infinitely more resources in VMWare than I would if I were limited to a physical box.  We can't buy fast disk, fast CPU, or fast RAM if it will be idle -- but when multiple servers share this fast pool, we can afford it.  VMWare is the way to go in my opinion.

mclemson,

Would you still recommend VMWare for ~6,000 endpoints? Our SQL server is off-box physical server, but I would like to install 7.1 in VM. Can you comment to on Service Desk servers?

I'm intently watching this thread because I would love to move to VM. :)

Thanks guys,

George

Yes to SMP and solutions, provided you meet the hardware requirements mentioned in the guides.  And of course your site servers can be virtualized as well.  I can't really comment on Service Desk.  That might be a question for the Service Desk forum.

Service Desk has CRAZY requirements and why we decided to not buy the solution.  That is all I know regarding Service Desk.

Hi,

Have you tried to change the frecuency of, for example, SW inventory, AD import and policy updates?

3000 machines asking for new policies hourly means that there is one petition per second received by the server. Is that frecuency needed? If you deploy SW weekly, and you patch bi-weekly, I guess you can safely turn the policy updates to a daily basis, or maybe to four-five hours (so every computer asks for new policies twice in working hours, for workstations and laptops). If they are servers, I guess that you can change it to 12 hours.

If you distribute SW weekly, is it neccesary to have the SW inventory running daily? Try to change it to run after the SW and Patch deployments.

Do you need the basic inventory to run daily? Try to schedule to run twice or three times per week.

And also, review your configuration about Resource Membership Update. If you don't have a significant amount of machines added to your NS, may be you can update the membreship may be once a day...

Just my two cents.

Let us know if you found the magical configuration :)

Good luck:

         Falquian