Hey guys, I’m running a new retina MBP with 2.7Ghz i7 and 16gb.
I have noticed that when I put the unit to sleep, and then wake it up the com.avast.proxy process spikes in usage. I have attached a screenshot showing it at 100% but before I took the screenshot it was powering away at 300% (utilising 3 cores)
It definitely makes the MacBook Pro quite hot if left for a couple of minutes (plus eating battery) and almost unbearable to keep on your lap.
It doesn’t happen all the time on average it’s about 4/5 times.
I hope there is a way to fix this other than by quiting the process from the activity monitor, as I would hate to have to shift away from avast having used it on all my windows machines as well!
Thanks,
Asela
Edit: added a screenshot showing the process at 300%
Hello,
Is it always reproducible, i.e. it happens after every resume from sleep?
Are there any “Diagnostic Reports” in the Console (Applications->Utilities->Console)?
Yep every time from sleep, I have attached a screenshot from the console, seems like it cant connect to a server for some reason. There are lots of diagnostic reports for the com.avast.proxy daemon, I attached a screenshot of that too. It appears to be complaining about it’s cpu usage. I don’t think it’s related to the mail shield as mail is working fine (gmail imap through apple mail client)
Is there a way to check the sleep mode? I would just be using the default sleep mode, that happens when you close the lid. I haven’t changed any of the energy saving settings at all. Interestingly the process didn’t run away to 300% when I resumed today.
I’ve managed to put it into the same state but it’s very difficult to simulate it. I hit the state by accident today. Hopefully I’ll manage to collect enough data for tumic.
You can get your sleep mode configuration by running this on the terminal: pmset -q
On my mac the output is:
xxxxxxxxx$ pmset -g Active Profiles: Battery Power -1* AC Power -1 Currently in use: standbydelay 4200 standby 1 halfdim 1 hibernatefile /var/vm/sleepimage darkwakes 0 disksleep 10 sleep 10 hibernatemode 3 ttyskeepawake 1 displaysleep 10 acwake 0 lidwake 1
The hibernatemode says the sleep mode config. Post here a full output of pmset -g, please.
Active Profiles:
Battery Power -1
AC Power -1*
Currently in use:
standbydelay 4200
standby 1
womp 1
halfdim 1
hibernatefile /var/vm/sleepimage
darkwakes 1
gpuswitch 2
networkoversleep 0
disksleep 10
sleep 180 (sleep prevented by )
hibernatemode 3
ttyskeepawake 1
displaysleep 10
acwake 0
lidwake 1
I should note that it seems like the problem has disappeared. It has gone from being every time I resumed from sleep to now not occurring. I have successfully resumed from sleep and com.avast.proxy has behaved. So I guess there is a specific set of circumstances other than just resuming from sleep that causes com.avast.proxy to eat CPU.
Correct, the issue has (most probably) nothing to do with sleep/resume. I was hoping that resuming
the machine from sleep would be a “safe” way to trigger this issue what is nearby impossible for us
to reproduce, but it does not “work” for me… Anyway, thanks for your report and help.
I also got this hgh CPU usage from the proxy component a couple of times, what was common in those situations was have a bad wifi connection and pages in Firefox taking a considerable time to load, or maybe they where taking so much time because the proxy was unable to process the requests?
I got the problem a couple times more and actually decided to try the build posted, I’m never, ever going to do this again, I followed the instructions to uninstall Avast, so I had to reconfigure everything again when I installed this version, you should have warned about that.
When you uninstall avast! (properly from the program menu), it always cleans everything that was installed, including the avast! configuration. If you uninstall avast! to test a development version it is still a regular uninstall, so there is no special warning here as this is not a special case.
The problem can occur on unexpected connection closes, so a bad wifi connection can trigger this pretty well. There will be a fix in the next program update, that will fix all the remaining problem cases.