Nod32 and Subversion - Poor performance

We're evaluating antivirus software at the moment, and are currently looking at Nod32. This morning we identified a performance problem that needs to be resolved. Here's the situation:

When performing a Subversion checkout a repository the performance is very poor. Ekrn.exe is taking up lots of CPU (20-40%) and getting the files takes forever.

- When disabling Real-time system protection the speed is ok.
- Getting the files via svn:// protocol is ok. The problem seems to be related to the file:// protocol.
- Copying a file from the server to client with Real-time system protection enabled is OK.
- An OK solution for us would be to exclude the local directory from scanning. I've tried this by adding it to Setup -> Antivirus and antispyware -> Exclusions (added c:\projects\*.*) but with no difference in performance.

Some questions:
- What are the recommended settings for Subversion usage?
- How come my exclusion does not work? What am I doing wrong?

The problem is reproducable on many clients, both XP and Vista machines.
Nod32 version is 3.0.642.0.

Any ideas?

 

Solved it by unchecking "Network drives" from "Media to Scan".

 

Sorry to resurrect this old thread, but I am having the same issue. However, our repositories are accessed over http(s), and disabling scans over network drives doesn't apply.

Like the original poster, entering exclusions to the URLs of the repositories has absolutely no effect whatsoever. When the antivirus software is disabled, however, everything works great. This problem is definitely a result of some interaction between Nod32 and subversion/apache httpd.

 

Please perform a clean installation of version 3.0.667 with default settings and confirm or deny that the problem persist.

 

I exported my current settings of Nod32, performed an uninstall of my existing software, rebooted, and then deleted the remaining directory.

After deleting the directory, I installed version 3.0.667. During the installation, I chose a typical install, disabled ThreatSense.net, and enabled the detection of potentially unwanted applications. Once the installation was complete, I performed an update to get the latest revisions of whatever was available.

Immediately after performing the update, I attempted to connect to my Subversion repository. The results were the same as before -- my system slowed down and the page was incredibly slow to load. (You can access the repository with a browser, but not check anything out or in without a "real" client.)

I rebooted my system again, disabled the antivirus software, and went the the repository again. This time, the response was immediate.

I want to reiterate that although I exported my original configuration, I never re-imported it after the clean install.

 

We're experiencing the same problem as Jewellgm at our company. I have also attempted to file a support request with ESET, but they suggested I post in this thread instead.
I will paste the entire support request I sent to ESET below and I hope you'll be able to come up with some kind of solution / workaround:

 

It appears this problem continues to be an issue. I have subversion installed as well, using it as a local repository. Excluding svn.exe, svnadmin.exe, svndumfilter.exe, svnserve.exe, svnsync,exe, svnvesion.exe does not help either.

Further, when attempting to port a repository using svnadmin load /repo/trunk < dumpfile from a cmd prompt eset will fail the load by not being able to move a file. Plus it is very slow. As soon as eset is disabled, the svnadmin load goes 10x faster and succeeds. The same happens with a check out. All the files stored in the repository are text files and code files, except for the subversion database files.

Is there a better solution than just disabling eset?

 

I have to say I've been using SVN alongside ESET products for years without any problems.

 

Me also, but I was only using tortoisesvn to access a remote repository. But ever since I created a local repository and have started using svnadmin to sync with a remote repository, the problems showed themselves. So, Eset has become a road block for me and I have no alternative but to disable it.

 

Hello,

If you are running Microsoft Windows Vista, would you mind installing ESET Smart Security or ESET NOD32 Antivirus v4.0 public beta 1 to test and see if the problem still occurs?

v4 interfaces a little differently with Windows Vista (and Windows Server 200 than previous versions of the software, which may make a difference.

Regards,

Aryeh Goretsky

 

I have come across a similar situation tiday; using Sage Accounts, a particular function takes approx 25 seconds for the action to complete; this is with the mapped network data drive excluded; but by switching off checking of network drives - find that the same action now takes approx 1-2 seconds!

That seems to indicate that mapped drive letter exclusions are not working.

Client is using NOD32 32 business edition version 3.0.684.

I have to agree, with previous poster that only if one can be 100% sure of all writes to the network drive are safe, then can this network drive checking be switched off (and of course who can be 100% certain). I wanted to be able to exclude a particular network drive that has a dedicated function and therefore more safe, without having to blanket not check any network drives at all.

I think ESET need to check this carefully and quickly.

 

Eset is also deleting part of the repository database. It thinks
Real-time file system protection C:\dev\repos\db\revs\0\9 is a VB worm and deletes it, corrupting the repository.

C:\dev\repos\db\revs\0\9 VBS/Solow.A worm cleaned by deleting - quarantined NT AUTHORITY\SYSTEM

Which means I have to turn off Eset permanently to get my work done. Trying exclusions, but that did not work in the past.

 

I suggest you follow these steps http://kb.eset.com/esetkb/index?page=content&id=SOLN141 and make sure you put in all the info you can about the problem.

 

I am not running Vista, but windows xp.

 

So have I but now there is a performance problem. Running svnadmin load /repo < dumpfile is very slow compared to when Nod32 is disabled. I have tried excluding the repository directory and the svn binaries.