Author Topic: constrain to kill/turn off avast antivirus because it's kill my SSD(Macbook Air)  (Read 6843 times)

0 Members and 1 Guest are viewing this topic.

Offline canope

  • Newbie
  • *
  • Posts: 9
HI,

I 've been constrain to disable completly avast antivirus for mac because of his really bad behaviour regarding my SSD...

The network protection engine ( webshield etc....) use the SSD as temporary storage point for fetching the data before sending them back to the browser.

I'm a huge user of netflix ....

each file/video segment are fetched and stored in the /private/tmp/proxy-XXXXX folder and deleted quickly after.

MacBook-Air:tmp root# pwd
/private/tmp
MacBook-Air:tmp root# ls -alrt proxy-buSda9/


This imply to write and delete GIgs ( 3 Gbyte per hours!!!!!) of data for nothing but finally only kill the SSD.



Can you have a better/cleaver engine where we dont geopardize our precious Macs ?

Thanks in advance





Offline canope

  • Newbie
  • *
  • Posts: 9
i've done the analysis with the classical tools.

iosnoop, truss and dtrace.

it's clearly a weard working mode.

why saving the files and not doing an imemory scanning.

the pieces are not really big.


Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
By default, only the first 64MB of any checked file are stored to the tempfile (bigger files are
considered downloads that will be handled by the file shield). The size can be adjusted in
the configuration file (/Library/Application Support/Avast/config/com.avast.proxy.conf) to
any lower value:

Code: [Select]
[http]
LIMIT = 33554432 ; 32MB
[https]
LIMIT = 33554432 ; 32MB

Additionally You can create a  RAM disk on your system and and set the proxy to use it instead
of the /tmp directory by setting the global  TEMP_DIR option:

Code: [Select]
TEMP_DIR=/Volumes/ram

Also note that the files in the file system must not be (and usually aren't) in fact written to the HDD,
the kernel uses some caching mechanisms designed to handle exactly such tempfile scenarios.
« Last Edit: May 07, 2015, 01:40:12 PM by tumic »

Offline canope

  • Newbie
  • *
  • Posts: 9
Hi,

i've done the analysis with the standard system tools and also monitored the Io generated at SSD level.

data are written... and deleted just after :-(

do you plan to have some changes for dealing with this kind of case ?

Offline canope

  • Newbie
  • *
  • Posts: 9
To complete,

i think it's a global issue regarding how you treat I/O at application level.

The Activity.db is updated all the time and genette also a lot of continuous I/O

2015 May  7 14:44:05 ??        1   4     0   449 W 77321216   4096  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:05 ??        1   4     0   449 W 77321280   8192  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:06 ??        1   4     0   449 W 49730608  16384 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:06 ??        1   4     0   449 W 49730608   4096 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:06 ??        1   4     0   449 W 77321216   4096  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:06 ??        1   4     0   449 W 77321280   8192  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:08 ??        1   4     0   449 W 49730904  16384 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:08 ??        1   4     0   449 W 49730904   4096 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:08 ??        1   4     0   449 W 77321216   4096  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:08 ??        1   4     0   449 W 77321280   8192  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:12 ??        1   4     0   449 W 106440288  16384 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:12 ??        1   4     0   449 W 106440288   4096 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:12 ??        1   4     0   449 W 77321216   4096  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:12 ??        1   4     0   449 W 77321280   8192  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:14 ??        1   4     0   449 W 106440392  16384 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:14 ??        1   4     0   449 W 106440392   4096 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:14 ??        1   4     0   449 W 77321216   4096  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:14 ??        1   4     0   449 W 77321280   8192  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:15 ??        1   4     0   449 W 106450896  16384 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:15 ??        1   4     0   449 W 106450896   4096 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:15 ??        1   4     0   449 W 77321216   4096  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:15 ??        1   4     0   449 W 77321280   8192  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:17 ??        1   4     0   449 W 106451848  16384 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:17 ??        1   4     0   449 W 106451848   4096 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:17 ??        1   4     0   449 W 77321216   4096  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:17 ??        1   4     0   449 W 77321280   8192  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:18 ??        1   4     0   449 W 106451984  16384 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:18 ??        1   4     0   449 W 106451984   4096 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:18 ??        1   4     0   449 W 77321216   4096  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:18 ??        1   4     0   449 W 77321280   8192  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:20 ??        1   4     0   449 W 95823376  16384 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:20 ??        1   4     0   449 W 95823376   4096 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:20 ??        1   4     0   449 W 77321216   4096  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:20 ??        1   4     0   449 W 77321280   8192  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:22 ??        1   4     0   449 W 95852064  16384 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:22 ??        1   4     0   449 W 95852064   4096 ??/service-data/activity.db-journal com.avast.servic\0
2015 May  7 14:44:22 ??        1   4     0   449 W 77321216   4096  ??/service-data/activity.db com.avast.servic\0
2015 May  7 14:44:22 ??        1   4     0   449 W 77321280   8192  ??/service-data/activity.db com.avast.servic\0

Offline canope

  • Newbie
  • *
  • Posts: 9
Hi there,

can you help us and tell us if there is any plan regarding improvise the proxy engines for not killing/wearing our SSDs ?

thanks in advance,

I really like this feature but it's not usage as it.

I really dont understand why this could be difficult as other web proxies already have memory caching engines ( even the old but still good Squid Web Proxy).

Regards,

Offline canope

  • Newbie
  • *
  • Posts: 9
Hi,

same product same issue...

I've tried to do a full scan of an external USB enclosure.....

I've stopeed it after 1 hour ... i've found exactly the same problem....

The file scan engine also use the /tmp folder located in the SSD for doing the scan.

I've just completly disabled the antivirus since it's worst than a malware at I/O disk usage...

again some traces:

MacBook-Air:~ root# iosnoop -v -a  -m / | grep " W " --line-buffered
2015 May 11 18:02:34 ??        1   4     0   160 W 83921208 360448      ??/tmp/unp101084079.tmp com.avast.daemon\0
2015 May 11 18:02:34 ??        1   4     0   160 W 83922280   4096      ??/tmp/unp217890557.tmp com.avast.daemon\0
2015 May 11 18:02:34 ??        1   4     0   160 W 84353664 131072       ??/tmp/unp63639166.tmp com.avast.daemon\0
2015 May 11 18:02:34 ??        1   4     0   160 W 84353920 131072       ??/tmp/unp63639166.tmp com.avast.daemon\0
2015 May 11 18:02:34 ??        1   4     0   160 W 84354176 122880       ??/tmp/unp63639166.tmp com.avast.daemon\0
2015 May 11 18:02:34 ??        1   4     0   160 W 84354624   4096      ??/tmp/unp203530041.tmp com.avast.daemon\0
2015 May 11 18:02:34 ??        1   4     0   160 W 84355752   8192      ??/tmp/unp255206220.tmp com.avast.daemon\0
2015 May 11 18:02:34 ??        1   4     0   160 W 84356552   4096      ??/tmp/unp185955953.tmp com.avast.daemon\0
2015 May 11 18:02:34 ??        1   4     0   160 W 84356712   4096      ??/tmp/unp204358068.tmp com.avast.daemon\0
2015 May 11 18:02:34 ??        1   4     0   160 W 84356968   4096      ??/tmp/unp114379157.tmp com.avast.daemon\0

Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
i've found exactly the same problem...
The file scan engine also use the /tmp folder located in the SSD for doing the scan.
That's not a problem, this is the intended behavior. The engine uses the /tmp directory for
extracted files, when scanning archives.

Again, when you are so concerned about temporary files written to your hard disk, then
use a RAM disk for the /tmp directory. This will solve your "problem" with not only Avast
but almost all SW on your Mac. You must be however prepared for some corner cases,
when the temporary files won't fit into the RAM disk.

Offline canope

  • Newbie
  • *
  • Posts: 9
Hi ,

i cannot agree with you.

You have a fundamental "BUG". You'e not aware of the specificities of apple devices.
SSD disk have to be treated with the best possible strategy regarding I/O usage.

I've choosed to have 8Gbyte of RAM for being able to reduce impact on the SSD ( no swaping).

i'st a shame to find  that you use it even for scanning a tiny little files ( some of them only 4kbyte).

Have you ever try to have some analysis regarding this ?

the Memory usage have to be ( i hope you'e ok with this) at application and not thru Users ( even experimented like me) custom configuration involving RAMDisk etc.


I'm there if you need help.

I think this kind of issue can lead a lot of websites ( and i know some guys on a lot of them)  to change their review regarding your product.

OK , Avast for Mac is free, but the product have to treat the device with respect and dont kill the SSDs for nothing.



Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
i'st a shame to find  that you use it even for scanning a tiny little files ( some of them only 4kbyte).
Have you ever try to have some analysis regarding this ?

Yes, there are some plans to reduce I/O on exactly those small files, but there will still be
situations that will require temporary files, e.g the archive unpacking.

Offline canope

  • Newbie
  • *
  • Posts: 9
So ,

today the only solution for SSD users like me ( and all the one with MacBook Air / Macbook 2015 / Macbook Pro Retina) is to uninstall Avast for Mac since it's killing the SSD....

This is enormous !!!

Offline canope

  • Newbie
  • *
  • Posts: 9
HI,

do you have any updates regarding the corrections of the defects listed in this thread?


thanks in advance

Offline Gianfar

  • Newbie
  • *
  • Posts: 1
My own 2014 13" 2.8Ghz 512SSD has read over 12.3TB and written over 10TB and the wear levelling count is still 100%, so with this in mind I doubt Avast will be a significant issue.
« Last Edit: September 02, 2015, 04:26:17 PM by Gianfar »