Jump to content

100% CPU usage by esets_daemon, ECSP for Mac version 6.3.70.1


Recommended Posts

Hi,

     I've noticed several times, actually every day, for period of time, several minutes, esets_daemon taking my CPU for 100%. Happened I rather chose to kill the process. Here isa top -o cpu when it happened. Thank you for suggestion or fixing the issue.

 

Processes: 336 total, 3 running, 333 sleeping, 2190 threads                                                                                           11:15:58

Load Avg: 2.84, 3.11, 4.97  CPU usage: 2.66% user, 27.93% sys, 69.40% idle   SharedLibs: 139M resident, 35M data, 16M linkedit.

MemRegions: 108746 total, 2404M resident, 60M private, 633M shared. PhysMem: 8146M used (3265M wired), 45M unused.

VM: 926G vsize, 623M framework vsize, 342048717(509) swapins, 345144304(0) swapouts. Networks: packets: 35460354/27G in, 37391605/7886M out.

Disks: 38838439/1517G read, 36749732/1549G written.

 

PID    COMMAND      %CPU TIME     #TH   #WQ  #PORTS MEM    PURG   CMPRS  PGRP  PPID  STATE    BOOSTS           %CPU_ME %CPU_OTHRS UID  FAULTS      COW

21493- esets_daemon 99.8 14:16.64 16/1  1    76     14M    0B     109M   313   313   running  *0[1]            0.00000 0.00000    0    129203      968

22072  top          11.6 00:01.13 1/1   0    20     4268K  0B     0B     22072 7641  running  *0[1]            0.00000 0.00000    0    6239+       126

85871  Terminal     1.5  15:20.09 9     4    244    39M    60K    14M    85871 1     sleeping *0[4724]         0.00000 0.06971    501  5415862     6452

0      kernel_task  1.5  08:58:41 221/4 0    2      1169M- 0B     0B     0     0     running   0[0]            0.00000 0.00000    0    179412      3

1058   Screenhero   0.5  19:25.91 21    2    316    17M+   0B     104M-  1058  1     sleeping *0[13994]        0.00000 0.00000    501  6465157+    955

22061  Google Chrom 0.5  00:03.71 15    1    135    75M+   0B     0B     435   435   sleeping *0[2]            0.00000 0.00000    501  52560+      1690

435    Google Chrom 0.5  08:48:59 53    2    1651-  299M+  176K   635M-  435   1     sleeping *0[32220]        0.00000 0.00000    501  214550678+  22891667

1059   Remote Mouse 0.3  41:00.62 59    1    248    3552K  0B     8176K  1059  1     sleeping *0[6113]         0.04642 0.00000    501  4416459+    492

248    symptomsd    0.3  35:03.96 4     3    134    2428K  0B     5768K  248   1     sleeping  0[15770]        0.06167 0.00000    24   513074      230

 

 

Link to comment
Share on other sites

  • Administrators

ESET CyberSecurity Pro 6.4.128 is now available for download. The new version addresses various issues. Let us know if installing it resolves your issue as well.

Link to comment
Share on other sites

  • 2 weeks later...

Hi,

     The same 100% CPU is still happening. I did not notice that for a while, but now it's back.

 

Processes: 375 total, 4 running, 371 sleeping, 2471 threads                                                                                           11:02:28

Load Avg: 3.35, 3.56, 3.02  CPU usage: 14.69% user, 26.54% sys, 58.76% idle  SharedLibs: 137M resident, 33M data, 43M linkedit.

MemRegions: 111786 total, 2891M resident, 66M private, 958M shared. PhysMem: 8171M used (2221M wired), 18M unused.

VM: 1034G vsize, 623M framework vsize, 11294138(128) swapins, 12474102(0) swapouts.  Networks: packets: 1960487/1619M in, 1718896/612M out.

Disks: 3872687/84G read, 2523275/72G written.

 

PID    COMMAND      %CPU  TIME     #TH   #WQ  #PORT MEM    PURG   CMPRS  PGRP  PPID  STATE    BOOSTS            %CPU_ME %CPU_OTHRS UID  FAULTS   COW

320-   esets_daemon 98.8  32:06.70 17/1  1    84    20M    0B     109M   316   316   running  *0[1]             0.00000 0.00000    0    2248286  5776

18914  AddressBookS 41.4  00:00.63 8/1   6/1  103+  26M+   1400K+ 0B     18914 1     running  *1[1]             0.16169 0.00000    501  9874+    330+

224    WindowServer 7.3   23:25.93 5     2    563   75M    4136K  81M    224   1     sleeping *0[1]             0.33249 0.00000    88   3996967+ 3414

Link to comment
Share on other sites

  • 2 months later...

I have been having the same problem daily for the last weeks. I noticed this both with the 6.4.128 and 6.4.200.1 version.

The only way to stop my MacBook Pro (Retina, 15-inch, Early 2013) from making noise with the cpu fans, is by force-killing the esets_daemon process. But a while later, it starts again, and goes back to 100%. Very annoying!

Top -o cpu gives me:

Processes: 351 total, 3 running, 348 sleeping, 2902 threads                                                                                                                              23:23:49
Load Avg: 2.08, 2.58, 2.77  CPU usage: 3.33% user, 14.30% sys, 82.35% idle  SharedLibs: 161M resident, 40M data, 38M linkedit.
MemRegions: 231992 total, 5360M resident, 118M private, 1359M shared. PhysMem: 14G used (3092M wired), 1841M unused.
VM: 4120G vsize, 623M framework vsize, 1271252147(0) swapins, 1284880503(0) swapouts.   Networks: packets: 301063499/216G in, 347872491/299G out.
Disks: 154072914/7164G read, 80900782/6257G written.

PID    COMMAND      %CPU TIME     #TH   #WQ  #PORTS MEM    PURG   CMPRS  PGRP  PPID  STATE    BOOSTS           %CPU_ME %CPU_OTHRS UID  FAULTS     COW      MSGSENT     MSGRECV     SYSBSD
1157-  esets_daemon 99.5 04:59:57 17/1  1    65     23M    0B     101M   92104 92104 running  *0[1]            0.00000 0.00000    0    667407     1425     123900      61094       282825444+
12697  CrashPlanSer 11.0 08:51:07 90    3    238    583M   0B     213M   12697 1     sleeping  0[0]            0.28245 0.00000    0    114966261+ 464      24779913+   5775271+    3041415928+
6168   top          4.4  00:00.94 1/1   0    20     8128K  0B     0B     6168  68703 running  *0[1]            0.00000 0.00000    0    5949+      113      573707+     286818+     11563+
23794  firefox      4.2  12:21:16 82    3    1365   1829M  35M    951M   23794 1     sleeping *0[22519]        0.00000 0.00000    501  280058431  5464980  112888849+  54273231+   479234532+
47710  Terminal     4.1  05:44.10 13    8    313    72M+   0B     69M-   47710 1     sleeping *0[3292+]        0.00000 0.01239    501  3497171+   16239    1769361+    236505+     2144660+
5288   sysmond      2.5  00:05.83 3     3    32     4028K  0B     300K   5288  1     sleeping  0[8]            1.82564 0.00000    0    9323+      142      310521+     154147+     515268+
6084   Activity Mon 2.1  00:05.86 7     5    240    51M    25M    0B     6084  1     sleeping *0[25]           0.00000 1.80261    501  64122+     611      85454+      3668+       266729+
19037  com.docker.h 1.8  03:46:17 18    1    38     17M    0B     544M   19030 19030 sleeping *0[1]            0.00000 0.00000    501  9338322    248      713         70          502275565

 

Link to comment
Share on other sites

  • 1 month later...
  • Most Valued Members

Not good to hear that it’s continuing to happen on 6.4.200.1. Would be good for ESET to have some collected logs/diagnostics to investigate what is going on in your system to cause this.

Perhaps a mod from the forum can help you with this, however it might be best to contact ESET support directly so they can immediately investigate the issue. 

Link to comment
Share on other sites

On 15/5/2017 at 11:27 PM, PaulK79 said:

I have been having the same problem daily for the last weeks. I noticed this both with the 6.4.128 and 6.4.200.1 version.

The only way to stop my MacBook Pro (Retina, 15-inch, Early 2013) from making noise with the cpu fans, is by force-killing the esets_daemon process. But a while later, it starts again, and goes back to 100%. Very annoying!

Top -o cpu gives me:


Processes: 351 total, 3 running, 348 sleeping, 2902 threads                                                                                                                              23:23:49
Load Avg: 2.08, 2.58, 2.77  CPU usage: 3.33% user, 14.30% sys, 82.35% idle  SharedLibs: 161M resident, 40M data, 38M linkedit.
MemRegions: 231992 total, 5360M resident, 118M private, 1359M shared. PhysMem: 14G used (3092M wired), 1841M unused.
VM: 4120G vsize, 623M framework vsize, 1271252147(0) swapins, 1284880503(0) swapouts.   Networks: packets: 301063499/216G in, 347872491/299G out.
Disks: 154072914/7164G read, 80900782/6257G written.

PID    COMMAND      %CPU TIME     #TH   #WQ  #PORTS MEM    PURG   CMPRS  PGRP  PPID  STATE    BOOSTS           %CPU_ME %CPU_OTHRS UID  FAULTS     COW      MSGSENT     MSGRECV     SYSBSD
1157-  esets_daemon 99.5 04:59:57 17/1  1    65     23M    0B     101M   92104 92104 running  *0[1]            0.00000 0.00000    0    667407     1425     123900      61094       282825444+
12697  CrashPlanSer 11.0 08:51:07 90    3    238    583M   0B     213M   12697 1     sleeping  0[0]            0.28245 0.00000    0    114966261+ 464      24779913+   5775271+    3041415928+
6168   top          4.4  00:00.94 1/1   0    20     8128K  0B     0B     6168  68703 running  *0[1]            0.00000 0.00000    0    5949+      113      573707+     286818+     11563+
23794  firefox      4.2  12:21:16 82    3    1365   1829M  35M    951M   23794 1     sleeping *0[22519]        0.00000 0.00000    501  280058431  5464980  112888849+  54273231+   479234532+
47710  Terminal     4.1  05:44.10 13    8    313    72M+   0B     69M-   47710 1     sleeping *0[3292+]        0.00000 0.01239    501  3497171+   16239    1769361+    236505+     2144660+
5288   sysmond      2.5  00:05.83 3     3    32     4028K  0B     300K   5288  1     sleeping  0[8]            1.82564 0.00000    0    9323+      142      310521+     154147+     515268+
6084   Activity Mon 2.1  00:05.86 7     5    240    51M    25M    0B     6084  1     sleeping *0[25]           0.00000 1.80261    501  64122+     611      85454+      3668+       266729+
19037  com.docker.h 1.8  03:46:17 18    1    38     17M    0B     544M   19030 19030 sleeping *0[1]            0.00000 0.00000    501  9338322    248      713         70          502275565

 

this morning was happened the same thing to me it's necessary to update virus database of Eset manually pushing "Update now" and the CPU usage slow down

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...