Nod32 and Subversion - Poor performance

Discussion in 'ESET NOD32 Antivirus' started by pause, Apr 10, 2008.

Thread Status:
Not open for further replies.
  1. pause

    pause Registered Member

    Joined:
    Apr 10, 2008
    Posts:
    2
    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?
     
  2. pause

    pause Registered Member

    Joined:
    Apr 10, 2008
    Posts:
    2
    Solved it by unchecking "Network drives" from "Media to Scan".
     
  3. jewellgm

    jewellgm Registered Member

    Joined:
    Jun 28, 2008
    Posts:
    7
    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.
     
  4. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Please perform a clean installation of version 3.0.667 with default settings and confirm or deny that the problem persist.
     
  5. jewellgm

    jewellgm Registered Member

    Joined:
    Jun 28, 2008
    Posts:
    7
    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.
     
  6. RvdV

    RvdV Registered Member

    Joined:
    Jul 28, 2008
    Posts:
    1
    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:
     
  7. Zuik

    Zuik Registered Member

    Joined:
    Sep 16, 2004
    Posts:
    14
    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?
     
  8. funkydude

    funkydude Registered Member

    Joined:
    Apr 5, 2004
    Posts:
    6,852
    I have to say I've been using SVN alongside ESET products for years without any problems.
     
  9. Zuik

    Zuik Registered Member

    Joined:
    Sep 16, 2004
    Posts:
    14
    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.
     
  10. agoretsky

    agoretsky Eset Staff Account

    Joined:
    Apr 4, 2006
    Posts:
    4,032
    Location:
    California
    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:cool: than previous versions of the software, which may make a difference.

    Regards,

    Aryeh Goretsky
     
  11. Siliconbullet

    Siliconbullet Registered Member

    Joined:
    Oct 3, 2005
    Posts:
    3
    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.
     
  12. Zuik

    Zuik Registered Member

    Joined:
    Sep 16, 2004
    Posts:
    14
    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.
     
  13. funkydude

    funkydude Registered Member

    Joined:
    Apr 5, 2004
    Posts:
    6,852
  14. Zuik

    Zuik Registered Member

    Joined:
    Sep 16, 2004
    Posts:
    14
    I am not running Vista, but windows xp.

     
  15. Zuik

    Zuik Registered Member

    Joined:
    Sep 16, 2004
    Posts:
    14
    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.

     
Thread Status:
Not open for further replies.