High CPU on Hyper-V VM
-
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...
-
@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).
Panda AV does, and I know McAfee used to, don't know about today.
-
Got an update on this...the day my daughter was having a baby, the server just bottomed out again...here I was trying to juggle being there for her and helping work get back up again...because of the 100% CPU problem, they were unable to do a lot of work off of the file server...they had access to it but running an intensive job from a shared folder was impossible...this all came to a head when my daughter was being rushed into a C-Section and I had my boss on the phone trying to walk him through shutting down VM's and then rebooting the host...
I've yet found time to move the anti-virus off to another server but may fast-track this...These new set of problems still do not point to one thing for certain. I was able to get some Performance Monitor logs on both the host and the VM...the logs are here if anyone wants to take a gander...it is just a few minutes of logs but taken at the height of the high CPU problems on the file server VM...also included logs for the host (called virtual):
New observations:
Rebooting is not the cure all. He rebooted the host and the VM's came back up and the file server was still topping 100% CPU.
When I got back to the office after 5PM. it was better.
When I actually POWER DOWN the host for a few minutes and then power back on and then the VM's come up, we do not see this problem right away. Could be days or weeks when it comes back.Considering observation number 3, could this very well be a hardware problem?
-
I'd be curious what happens if you unplugged the switch ports for a few moments, then reconnected. Though I can't tell you why I'm curious about that.
