High CPU on Hyper-V VM
-
Take a look at Webroot
-
@thecreativeone91 said:
@garak0410 said:
@Aaron-Studer said:
Have you tried disabling Symantec just for a little while to see if that is the issue?
It is happening right now...not at 100% but hovering between 25 and 75%, back and forth..., so I disabled (but not killed process) Symantec and CPU did drop..
Time for a new AV. Also you should make sure File system scans are disabled at least during the day and use the on access protection for most of the time. You can do scans at night but make sure it does not interfere with backups.
Thanks for the tips...I never looked into this deeper because it has run pretty well since this server went live last March. I did see the slow CPU from last Friday that a full scan kicked off right before the slowness. And 2-3 weeks ago, the scan started at 1AM but somehow went into a suspended state.
Since we renew in December, I may offload the Suite to another server until it is time to renew/update...And may look at loading the latest version of it as well.
And also, just disabling the CLIENT brought the CPU down...the suite/server is still running.
-
Just a thought, can you see if you can set SEP processor affinity to only 1 processor?
Open task manager, select the process- right click - set Affinity- from list of all processor, deselect all and just select one processor.
-
Disabling the A/V still has no effect...rebooted file server last night (and A/V remained disabled) and came in to the pesky SYSTEM PROCESS being over 50%...
-
@Ambarishrh said:
Just a thought, can you see if you can set SEP processor affinity to only 1 processor?
Open task manager, select the process- right click - set Affinity- from list of all processor, deselect all and just select one processor.
Will this work when the SYSTEM process is being the biggest culprit?
-
Oh and one more interesting note...the A/V was disabled...so I re-enabled it....waited a few seconds and then disabled it and BAM, SYSTEM high CPU stopped and back to "normal"
-
Might be a shim that disabling the AV doesn't solve. you might have to uninstall it.
-
@Dashrender said:
Might be a shim that disabling the AV doesn't solve. you might have to uninstall it.
I am considering moving the suite (management) to another serve...but wondering if I just do not do A/V at all on the file server...
-
@garak0410 said:
@Dashrender said:
Might be a shim that disabling the AV doesn't solve. you might have to uninstall it.
wondering if I just do not do A/V at all on the file server...
That to me sounds like a bad idea. Could you just not turn off active scanning and change the schedule to a different time? Or better yet get rid of Symantec and get something like Webroot? I have that on all of my servers and it runs super lean.
-
I only suggest removing the AV as a test to see if the utilization goes down.
After that, if it did, I would definitely look to another product... or getting with Symantec support to find the problem.
-
@coliver said:
@garak0410 said:
@Dashrender said:
Might be a shim that disabling the AV doesn't solve. you might have to uninstall it.
wondering if I just do not do A/V at all on the file server...
That to me sounds like a bad idea. Could you just not turn off active scanning and change the schedule to a different time? Or better yet get rid of Symantec and get something like Webroot? I have that on all of my servers and it runs super lean.
I am going to get Symantec heavily involved...disabling it doesn't seem to disable it and it doesn't seem to heed to its scan schedule and exceptions...there is an update but their website is not validating my serial number to download the update and waiting on them to respond back on that...
I do plan on looking at Webroot when we upgrade next December...unless they would "buy out" the remaining 9 months we have on Symantec...
-
I can say this...Symantec's website is miserable...first it tells me IE is out of date and I need to turn off Compatibility settings...then I try Chrome and get my ticket entered but the submit button would not work...guess I'll be old fashioned and call them...
-
@Dashrender said:
I only suggest removing the AV as a test to see if the utilization goes down.
After that, if it did, I would definitely look to another product... or getting with Symantec support to find the problem.
Symantec said I have the option for cloud hosted A/V under our license...may move to that as a temporary solution...
-
I jumped at that as soon as I was able here - one less thing server side to worry about.
-
@garak0410 said:
@Dashrender said:
I only suggest removing the AV as a test to see if the utilization goes down.
After that, if it did, I would definitely look to another product... or getting with Symantec support to find the problem.
Symantec said I have the option for cloud hosted A/V under our license...may move to that as a temporary solution...
We did this when we had Symantec, one minor hiccup is that the update process would eat up our bandwidth and everything would slow to a crawl. Modifying the update policies helped with that.
-
@coliver said:
@garak0410 said:
@Dashrender said:
I only suggest removing the AV as a test to see if the utilization goes down.
After that, if it did, I would definitely look to another product... or getting with Symantec support to find the problem.
Symantec said I have the option for cloud hosted A/V under our license...may move to that as a temporary solution...
We did this when we had Symantec, one minor hiccup is that the update process would eat up our bandwidth and everything would slow to a crawl. Modifying the update policies helped with that.
That's good to know because we only have 6 meg internet here (serious)...I will do my research in migrating and this will at least float me until we can choose another suite this November...
-
Confirm with Symantec that the clients will share the dat updates with each other on the local LAN. many client AVs do that today to save on bandwidth.
-
@Dashrender said:
Confirm with Symantec that the clients will share the dat updates with each other on the local LAN. many client AVs do that today to save on bandwidth.
Interesting. Which ones do. That's a lot of the reason I would keep a server in house (much the same as WSUS).
-
@thecreativeone91 said:
@Dashrender said:
Confirm with Symantec that the clients will share the dat updates with each other on the local LAN. many client AVs do that today to save on bandwidth.
Interesting. Which ones do. That's a lot of the reason I would keep a server in house (much the same as WSUS).
I know ControlNow had this feature. Not sure about Symantec or Webroot, @Nic could probably answer that.
-
@coliver said:
@thecreativeone91 said:
@Dashrender said:
Confirm with Symantec that the clients will share the dat updates with each other on the local LAN. many client AVs do that today to save on bandwidth.
Interesting. Which ones do. That's a lot of the reason I would keep a server in house (much the same as WSUS).
I know ControlNow had this feature. Not sure about Symantec or Webroot, @Nic could probably answer that.
Good info...thanks...I am going to look into the cloud solution for now and then another suite this late fall...but the problem may still remain...I don't think it is so much the SEPM but the client itself...
