Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by Torre

  1. Thanks brcd.  If you don't have a lot of music, movies, photos and don't do a lot with large files stored locally on your disk (such as Virtual Machines, don't worry if you don't know what these are), you probably don't have a large home directory.  Easiest way is to click on a Finder window, then type Shift-Cmd-H, then Cmd-I (shortcut for Get Info).  Make sure you don't click on anything in between the two key sequences.  You should see the info window pop up with a house icon and your login name on the top left, and the size of your home folder is on the top right.

    For me, after trying everything MBAM asked plus doing my own testing, home directory size was the only difference I can think of between the accounts that behaved and the one that doesn't.

  2. Thanks, brcd.  In my case I tested with 5 different accounts on 4 different machines.  Most of them showed ~1% CPU with infrequent jumps to 20%/40%.  On the "problem" account it shows mostly ~15% with more frequent jumps to 60-80% (this is a long term estimated average; I've also seen it drop to sub-1%).  This is also the account which has the largest home directory so I wonder if that has anything to do with the CPU usage.  Would you be ok posting how much disk space your home directory uses?  Mine as mentioned is >280GB.

  3. MBAM support was very responsive in the end for me.  However I am quite disappointed that the only suggested remedies were "remove browser extensions" (aside from one or two the rest are needed) and "remove your Library/Caches directory because it's larger than normal" (most of these were  iTunes / Apple Music files, so not surprising they are large as I have a LOT of music).  Neither helped.

    In my case MBAM CPU hogging (as opposed to occasional spikes) seem to be related to something else such as stuck installs.  MBAM just seems very sensitive and happy to eat a lot of CPU at the slightest provocation compared to other real-time protection tools I've used.  No surprise then that if something goes haywire, MBAM goes along with it.

    I do hope this gets better as I'm not keen to re-up my sub next year if this persists.

  4. So I promised to post the findings of the support ticket.  Here we go.

    • After testing MBAM across 4 machines and at least 5 accounts, There was no root cause found and I am still having high but not obscene CPU usage on one account (call this machine "Mac 1")
    • One of the test machines (Mac 2) was more or less of the same vintage and used in a similar manner to the "problem" account on Mac 1, it did not exhibit high CPU
    • Other accounts on Mac 1 also did not exhibit high CPU, however I was not able to replicate usage as closely I as I did on Mac 2
    • The only possibility remaining is that the "problem" account on Mac 1 is very large (>280GB of space) compared to all other accounts

    In the end I simply gave up as all this testing took too much time out of my work day.

    With MBAM support help, we tried the following.  All had little to no effect on lowering CPU.

    • Removing / reducing the size of the Library/Caches (most files were due to iTunes & Music, so understandable that this directory is so large)
    • Removing / reducing the size of Library/Favorites
    • Removing / reducing browser plugins 
    • Removing / reducing login items 

    My observations on MBAM RTProtectionDaemon usage over these months (using Activity Monitor) are:

    • RTPD seems extremely sensitive and frequently jumps the CPU, things that can cause higher CPU usage include
      • Switching application windows, especially to browsers
      • Using the scroll wheel in Safari
      • Web sites with a lot of embedded video content, even if the videos don't play (e.g. YouTube, ESPN)
    • RTPD also spikes the CPU when some other application is "not behaving well".  I had a Office update that got stuck and RTPD went crazy along with installd.  I also had OneDrive for Business behave badly and that spiked RTPD as well (maybe it's just Microsoft).  While I understand abnormal app behaviour can spike anti-malware programs, RTPD seems much more susceptible than other AV programs I have used
    • As mentioned, I wonder if RTPD performance is related to the home directory size, as that is the only difference between the machines and accounts

    My conclusions?  I'll keep MBAM for now as IME it's one of the best anti-malware programs but will evaluate at the end of my subscription period.

  5. That's a GREAT question.  I wish I knew what "normal" was but I don't, so I define "acceptable" as "It doesn't get in the way" and "isn't running at 60+% most every time I look", which was how it was before.

    Just as a recap 2-3 weeks ago I reported that RealTimeProtectionDaemon was going mostly 50% CPU, occasionally dropping to 20%, and frequently spiking to 90+%.  Now it is (1) mostly hovering under 10 (2) occasionally hovering around 20% (3) sometimes spiking above 80.

    I was able to profile RTPD behaviour on a similar machine and also tried out a different user account on the same machine and get much lower CPU usage, and thus far we have not been able to isolate why one user account on one machine runs so hot.

  6. 4 minutes ago, brec said:

    Seems like that has to be it -- thanks!

    Not sure... in my case RTProtectionDaemon definitely went nuts two evenings ago (I have Activity Monitor running as MWB support & I are still debugging this issue).  This was after an OSX update and Office 365 also updated.  The next morning RTPD seemed better behaved and I also found a stuck Office 365 update.  Not sure if they are related.  RTPD is now back to "acceptable" but still high CPU levels and I am still working with MWB support.

  7. Thanks treed & MAXBAR1, this is useful information (for me at least!)

    Frankly I was a bit surprised about Chrome as few in our household use it, preferring Safari.  Only a few were unused.  I went ahead & cleaned out Firefox & Safari while I was at it but it did not help.  There are no more than 4-5 extensions on Chrome and Safari remaining.  Given that there are a few machines and users in my house and we are all having the same issue, I will try to find what I can about the other users and see if there is any commonality on symptoms and causes & let adas know, in case there is something there.

    In any case I'll keep working with adas and if we find anything interesting I will post back to this forum.

  8. Thanks everyone for chiming in.  I am sure it is as alvarnell said, in fact I was about to make the same point. I don't fault the MWB support personnel for stating fact (in my experience that's what engineers do, and we don't want it any other way!)  MWB is also not the only company I know who are struggling with the new normal.

    To bring things back to the topic at hand, I am quite disappointed with attempted solution so far.  As mentioned this affects all Macs of varying age and models in the household and I see many reports of high CPU in searches as well.  Any Mac users NOT having CPU issues with RTProtectionDaemon when real-time Malware Protection is enabled?

  9. Hi Adas

    I am in contact with the support agent, so far it is not helpful.  It seems the diagnostic tool sniffs around for things in my system (helpers, plugins, etc.) and the only suggestion I have had so far is "remove Chrome plugins" (I've removed about four or five that I don't use) which doesn't help, and already the support agent seems ready to throw in the towel.  In this respect, the support tool and support suggestion is no better than an EtreCheck report.

    The CPU issue is affecting EVERY Mac in the household and I have had to turn OFF "Malware Protection" on all of them.  I ran some cursory experiments and found:

    1. If I quit all applications and leave only Finder running, RTProtectionDaemon CPU is very low (5% with intermittent spikes to 20%)
    2. Running Powerpoint causes intermittent CPU spikes to 100%, but generally stays around 20% (borderline acceptable)
    3. Adding Word causes more CPU spikes to 100%, but generally stays around 20% (less acceptable)
    4. Adding Safari now makes the CPU hover around 60-80% with spikes to 100% (completely unacceptable)

    So it definitely seems activity related and appears to be a significant performance issue in RTProtectionDaemon.

  10. Thanks for all the replies.

    Here's a bit more information for the MWB support guys:  it seems that only Malware Protection causes the CPU issues.  I tried disabling both App Block and Malware Protection, then re-enabled each.  Ad Block is fine but the second that Malware Protection is enabled the CPU goes crazy again.

    Secondly I respect what the MWB team has done.  It is a great product, I like the company philosophy, and it catches stuff that the other guys don't.  After the second time I used MWB to remove crap that <insert other product name> couldn't, I decided to pay for it.  But you must scale up support because a 5-7 business day turnaround is NOT acceptable for paying customers.

    Third: 4.6.10 beta does not solve the issue.  After installation I turned on Malware Protection and BANG the CPU goes right up  It's hovering around 50% right now like before.

  11. Adding my voice to the many who find v4.5.15 a CPU hog.

    I'm a big fan of Malwarebytes but only recently paid for premium as competitors (Avira, Avast, BitDefender, etc.) give it away free.  Imagine to my surprise when I see RTProtectionDaemon hogging CPU constantly.  It is never below 20% CPU, it is mostly above 60% CPU, it is often above 85% CPU on my 2015 MBP on Catalina 10.15.7.  This issue appears to have been present since at least July without a fix.

    WORST of all, support does not respond.  Opened a ticket yesterday and no human has said "boo" after 24 hours.  I can't track my own support ticket online either.

    This is absolutely not what I paid for.  How do I get a refund?

Back to top
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.