Antivirus signature update causes high HDD and RAM usage and makes PC very slow

[Guest]

[Rolo]

I agree with most comments.

I have xp and ubuntu 9.04 on my notebook, and after using ubuntu for a week and start the pc from XP, antivirus comodo took 15 minutes to update the database, at which time the computer was unusable.
Solution: I uninstall the antivirus, left firewall with D + proactive and install avira free, until the Comodo dev. team resolves this problem with comodo updates the antivirus database.
Comodo antivirus works ok, is fast and lightweight but the updates is a nightmare.
Anyway at the moment I am learning to use ubuntu.

Regards

[OmeletGuy]

Your right it slows down the PC a ton, the DB is going to shrink, and v4 will have a new DB format, that will fix this design flaw and shrink the DB even more.

[Agent24]

Your right it slows down the PC a ton, the DB is going to shrink, and v4 will have a new DB format, that will fix this design flaw and shrink the DB even more.

I hope so, this is the only problem I have with CIS at the moment (apart from how I think BOClean integrated should have its own options in the program...)

But currently this update problem is ridiculous. I really hope that this problem will be solved because I really like CIS and want to use it but currently I can't!!

[andzs]

I can walk away from the computer and do something else for the 15 minutes it's rendered useless by the update... 

The same routine for me. During update comp is totally useless.
Its weird that during update bases.cav gets overvriten so many times !!!  Funny stuff starts when progress meter shows 51%. bases.cav grows from 0 to ~103MB and then starts it all over again - file size gets 0 again ang grows all way up to 103 megs. In each of these cycles PC gets unresponsive for a while. There is 0 network activity. So I am thinking that something goes wrong in DB update procedure...

[jmeri]

From observing the behaviour of the update, it seems to me that the virus signature database is not a database at all in any modern sense.  It's like it's just an array of bytes, and any modification requires a complete rewrite of the file...  Oh, I'm getting flashbacks of magnetic tapes... ;-)

[slg123]

From observing the behaviour of the update, it seems to me that the virus signature database is not a database at all in any modern sense.  It's like it's just an array of bytes, and any modification requires a complete rewrite of the file...  Oh, I'm getting flashbacks of magnetic tapes... ;-)

I think you are right. Till 30% I have seen network activity, after that Its just replacing the DB.

[jmeri]

And seems that nothing is getting done about this problem.  My other computer was unused for a week, and just finished an hour-and-a-half update session.  Of this, about five minutes were database download the rest being furious disk writing...  This is not good.

[Agent24]

Yeah it seems especially bad if you miss a few days of updates

If OmeletGuy is right and this really is a flaw in the design (It really does look like one from where I'm standing!) then hopefully v4 will fix this and there will be no more problem.

As for the other guy who is denying it, I would like to know what he thinks of this thread and the comment that there is a design flaw.

[Ronny]

This is a limitation of the current version, what happens is the following.

Update process downloads let's say 10 incremental updates 5-30% progress.
Now to update the database the following happens:

• Read current bases.cav from disk in to RAM (See RAM increase)
• Merge update 1 and write back bases.cav to disk
• Read new current bases.cav from disk in to RAM
• Merge update 2 and write back bases.cav

So you will have avg 100MB of bases.cav written 10x to disk is 1GB of DISK Writes!
On RAM load you'll see it increase to about 3 times 100MB after that the first "image" get's released by the OS.

This is causing so much pressure on the DISK that your system is (almost) unusable during such an update.

I assume they will improve this process in the upcoming version.

[Alan Borer]

My first P.C. ran DOS 3.??? with a 5.25" floppy disc and a 20 MB Hard Drive.
I had a 1 MByte RAM and Bill Gates decided he had no use for the top 360 KB,
so I used a "ramdisk" utility that used Mhz speed RAM as a drive.

A *.BAT script or Basic interpreter were agony when run from the Floppy.
Much better when run from the H.D.
When loaded on the RAMDISK and ran it really flew supersonic.

I now have 1.25 GB of GHz speed memory, over half of which is never used.
Is it possible to install the Comodo ...\scanners folder into RAM,
or perhaps to use a Hard Link in ...\scanners to replace bases.cav and redirect from the scanners folder to an ultimate destination in the RAM Disk ?

Regards
Alan

[Ronny]

... the good old day's of loadhigh, stacker and doublespace 

I'm afraid CIS won't buy that... leave it on all day will be the only workaround here so it can update incremental when they are released so it's not a time consuming job.... but that's not very "Green" 

[HeffeD]

I'm afraid CIS won't buy that... leave it on all day will be the only workaround here so it can update incremental when they are released so it's not a time consuming job.... but that's not very "Green" 

No, I think the workaround would be for Comodo to design a better way to update. Of the dozens of AV solutions I've used, none has locked up my system like this when updating...

It does not even need to be a large update to impact the system severely! I can restart my system immediately after a database update, and surprisingly enough, shortly after the OS loads, CIS will hold my system hostage again for 5-10 minutes while it thrashes my HD around.

This is quite frankly, very poor software design. If they can't figure out a way to alleviate this, at the very least they need to lower the priority of this process so this kludgey update system is at least invisible to the user. I honestly don't care how long it takes for the update to happen as long as I can use my system while it is doing so!

And I don't have a weak system either.
AMD Athlon X2 Dual Core 4200+, 2.2GHz
2GB RAM
222GB free space on my HD
Running Win XP Pro SP2

And oddly enough, I never had this problem until I "upgraded" to version 3.12. It's a big enough problem that I may need to stop using CIS.

[Agent24]

Update process downloads let's say 10 incremental updates 5-30% progress.
Now to update the database the following happens:

• Read current bases.cav from disk in to RAM (See RAM increase)
• Merge update 1 and write back bases.cav to disk
• Read new current bases.cav from disk in to RAM
• Merge update 2 and write back bases.cav

Thank you! Now I understand how it works and how the problem ocurrs.

Would it work better to read bases.cav into memory, merge update 1, merge update 2, merge update 3 etc and finally write the file back to HDD?

That way there would only be 1 read and 1 write and all modification would happen in RAM

Or what if you create a different method and merge all incremental updates first and then write them into bases.cav once?

Would be interesting to know how the other AVs do it... because I have never seen one do it the way Comodo does (and for good reason!)

[Ronny]

I think the dev's are capable enough to figure out a nice an smooth way to fix this issue, and i prefer in RAM like Agent24 proposed 

[Agent24]

I think the dev's are capable enough to figure out a nice an smooth way to fix this issue, and i prefer in RAM like Agent24 proposed 

Well they didn't seem to figure it out very well the first time

In RAM sounds good unless you didn't have enough in which case it would all end up going to the pagefile and probably recreate the same problem...

[Tags:]