This content has been marked as final. Show 14 replies
Yes, we do experience the same problem. Therefor I've rescheduled deployment task to lunch time (1200 with some randomization) . Also must say that 8.7 version got it worse so I decided not to deploy it to any workstations/servers.
My PC is usually at least 5 mins unusable and I rather go get cup of tea :)
ePO 4P4, VSE 8.5P8 & 8.7
Folks - can I ask what the specification of the PC's is ? - especially in terms of memory ?
Can I also ask if you see the same issues if you perform a manual "update now" from the client PC ?
all the machines are running XP SP3 with 1GB of mem. PC's are usually hp compaq nc6xxx (laptops) or hp dc7xxx (desktops).
Regarding the manual update I'll have to try it tomorrow since I'm already up-to-date.
Thnaks for that.
Do you force PC shutdowns/reboots overnight as part ov an Environmental policy perhaps ? ( I'm not an eco-warrior - LOL - just a good way to get overnight reboots regularly:) )
Reason I'm asking is that when we've seen these "long slowdowns/lockups" during DAT updates it usually looks like a virtyual memory contention issue that's trigerred by the update process.
Upgrading memory on the PC's usually resolves it but regular reboots and user useage education (not lots of concurrentbrowser sesions or apps etc.) also helps.
Obvioulsy I've a suspicion that for some bizarre reason "update now" is handled differently...
No, we don't have such policy in place. Many of the workstations are assigned to agents in call center, hence I guess that they just log off and reboot PC occasionally (windows update etc.).
Many people also have laptops which is quite problem if you put PC into standby mode. I've encountered that PC's terrible slow after you do it couple of times. Even though you close all the running applications.
I'm pretty much in the same situation. My workstations mostly have Win XP SP3/1GB RAM. I made a little timeline of a server being killed by an autoupdate initiated manually in an effort to troubleshoot the problem.
VMWare Windows 2003 SP2 / 1GB RAM.
3:08:25 - Server is responding normally. Autoupdate is manually initiated.
3:09:00 - Server is unresponsive.
3:11:15 - UpdateLog.txt shows : Update succeeded to version 5562.0000. ... Update Finished.
3:11:30 - Server is still unresponsive. McShield shows 95% cpu utilization when the screen cares to refresh itselfs. McUpdate.exe 0% CPU but 138MB of RAM.
3:31:00 - Server is still unresponsive.
3:35:00 - Server is responsive again. vstskmrg.exe is using all idle cpu cycles but seems to be running with low priority.
Total Down time : 27 minutes.
If I initated update manually when there's no new DAT file, everything goes well. Judging by the ammount of help desk calls regarding McAfee log around the time of the update, about 5-10% of my workstations seems to be impacted. I'll do further research today regarding virutal memory.
Maybe rebooting nightly could improve stability on those workstations. I'll keep that in mind.
Thanks for the feedback - interesting that you see the same symptoms whether the update is manually trigerred or via a scheduled task.....
i'm facing the same problems, some information on that:
- mcafee is decreasing the size of DAT files, they add generic detections instead of definition for every threat. (so far, the size is ~ 5 MB less now)
- during and after an update mcshield don't release the memory (8.5i), there are 2 sets of DATs in memory. there's an hotfix available form tier III for that.
- did you try the lowpriority.reg fix for agent version 4.0 p1? i'll search it for you if you want to give that a try. for me it didn't work as i hoped it would ;)
- the main cause of the high cpu utilization are the growing DAT files...
- agent 4.5 will have a better performance during updates.
hope this helps :)
i was pointed to the following from mcafee support. i haven't tried it on my machine yet, but here's what they said:
I understand that you are facing issue CPU usage spikes during policy enforcement and a DAT update I kindly request you to refer article and perform the steps.
You can view the article KB53690 in the below mentioned link.