Anyone else having performance issues with cmdagent in 5.3.176757.1236? I see it taking up 100% CPU for bursts of 30sec-1min. and the overall performance of my system is sluggish. This did not use to be the case with 5.0, it started since I upgraded to 5.3
This is on Win XP Pro 32-bit user is admin.
A bunch of apps take a long time to start, as if it’s trying to scan them online even though I turned off all cloud scanning. But once an app starts, I can restart it again fairly quickly but then after a while it’s slow to start again. I think it may have something to do with the stateful a/v scanning.
The most concerning behavior is that I see cmdagent using up all the CPU it can very often. There’s something going on in this version IMHO.
Having said stateful inspection. What happens when you set the AV to On Access? Does that change things?
Please try disabling the AV component and see if the problem continues.
The best approach is to try to identify the component that’s causing the problem.
I’m running with D+ completely disabled (and yes before you ask, I did reboot). The problem is still there. I’ll set A/V to On Access and then disable it completely if the problem persists. But Stateful should be faster than On Access, right?
you’re not alone. I too have noticed this cpu hog
I thought maybe it was my system not up to the job…but maybe not the case??
Thanks for posting. No, I don’t think it’s the system, 5.0 was fine for me, the troubles started with the upgrade to 5.3
Could it be XP? I don’t think software in general gets very much testing these days on the ‘dinosaur’ OS, I suspect the main development and testing platform is Win7.
I have the latest Comodo on my Windows 7 64 bit it’s CPU usage on my system is less than 1 percent and I have everything installed D+ Sandbox and the AV and under normal usage less than 1 percent. During AV scan it jumps to 40 to 50 percent. By the way I have a quad core intel computer. I also have a XP 64 bit machine and the CPU usage is only 3 percent don’t blame XP This person may have either a virus or spyware running in the background without him knowing it.
I think it’s definitely the A/V part and it happens when new A/V defs are updated. I just experienced this: I had one app that was started fine, pretty fast with A/V defs 7630 I just checked for a/v updates and I got 7633 installed. I started the same app right away and it was dog slow, I think it needs to be validated against the new virus defs. Now if I restart the same app again, it’s fast, I suspect until the next a/v defs. What doesn’t make sense is that having the A/V set to On Access or Stateful does not make a difference. On Access I’d suspect it should always be slow as the app is scanned every time.
It’s disappointing to see that the A/V has issues again, historically the A/V caused troubles in CIS and many times I had to disable it and use some other A/V software.
I’ll disable the A/V completely and see what happens.
Then explain to me why my XP 64 Bit and Windows 7 64 Bit doesn’t have any of these so called Comodo’s AV problems. And my wife has Vista 64 bit and it is no slower than Vista normally is.
You explained it yourself: Win7 or Vista 64-bit. I’m on Win XP Pro 32-bit.
Maybe you have a virus Comodo can’t scan or spyware running in the background or maybe it is your 32 bit XP. Because 64 bit has no problems.
CAV has always been a resource monster when updating the virus database.
I’m running Win XP Pro SP3, and I don’t see anything different with 5.3 than it has always been.
I have the same problem see attached. I have all comodo access blocked and do not use comodo antivirus. I have cloud check off ipdaye check off and cmdagent is trying something ever few secs.
It has been in several versions now and nothing gets done. with everything blocked and unchecked it shoild not be trying to get out.
[attachment deleted by admin]
You’re also using a quad CPU so one core can be busy with cmdagent while you still have 3 other cores available for other tasks. You won’t notice the performance hit.
Try running it on a laptop with 1 core and see what happens, if the computer is usable.
There’s definitely a performance issue here.
OK. Now I’m 100% positive is the real-time A/V scanning that’s causing this after a new a/v defs database is installed. Here’s my test:
I disabled A/V real time scanning while D+ was set to Clean PC Mode.
I updated the defs db and it went from 7633 to 7636.
I could start cygwin/zsh and other apps pretty fast.
I set A/V real-time scanning to Stateful.
Tried starting the same apps, they were VERY SLOW to start and the CPU went crazy at 100% with cmdagent being the culprit. Subsequent restarts of the same apps were fast, presumably because of the statefulness.
So real-time A/V scanning has performance issues.
How old is your laptop? Almost every new laptop is duel core all of the ones I’ve seen from 600 dollars and up at least.
You’re missing the point. It is not OK for cmdagent to take up a core for about 45 sec. when an application starts even if you have 16 cores available. You may not notice it but that doesn’t mean cmdagent doesn’t have a problem. If we’re buying more cores to run security software, we’re having a problem. Security software should be highly optimized and performant. My experience with CIS 5.0 is that it was decent for my hardware, the problems started with the upgrade to 5.3 Now, a clean install of 5.3 may not have this issue, maybe it happens only as the result of an upgrade from 5.0 to 5.3 but that still points to a bug in CIS.
Does this only happen when you are trying to run programs through cygwin?
No, I can see it with a few apps. It seems that it’s apps that load a bunch of DLLs or launch helper apps as each one has to be scanned. It’s also the windows command prompt (cmd.exe) followed by the windows ping.exe, it just hangs there for a good amount of time before ping actually starts doing something. All this time cmdagent is the top CPU hog, as soon as it calms down the apps respond.
I’ve turned off real-time a/v scanning and I’m not seeing any of these problems. D+ is still in Clean PC Mode so that part doesn’t seem to be the culprit. I think I’m pretty sure at this point it’s the real-time a/v that’s causing this. I tried both Stateful and On Access, same behavior.
Yet another post about CIS using a complete processor core. I suggest the “system requirements” is altered to “minimum 4 core” 88)