SQL Server 2005 & Antivirus Software

Question

Our Network people insist on having antivirus (eTrust) software on ALL servers, including all of our SQL Server 2005 machines. How can I best demonstrate that this is hurting performance?

Answer 1

Benchmark your server both before and after you are running eTrust. You can do this by profiling your applications that access your server as well as running processes on the server itself. Create queries that you can test with in both scenarios. Once you have your performance matrix you can submit that to management/network people.

Answer 2

First, you must determine that it is hurting performance. The clearest way, of course, is to create a test suite wherein you can evaluate TPS performance. You'll be hard pressed to do this without either multiple apps running a pretty demanding suite of transactions or a multi-threaded app. You might want to Google SQL Server, "Testing" and "TPS" to see if there are any commercial products to help you (I don't know of any). If you are rolling your own testing suite, I'd suggest getting a copy of "SQL Response" from redgate software to do the performance monitoring.

The antivirus itself will affect performance primarily via memory consumption and network connection monitoring. WRT network issues, many antivirus packages look for Helkorn attacks on port 1433 (Helkorn is a popular worm - Google it - and port 1433 is SQL Server's listening port) so you might see some network issues with antivirus that you wouldn't see elsewhere. More to the point, I'd look for initial connection time latency if you want to document the drawbacks of antivirus. However, you should also keep in mind that flying without antivirus will make you more vulnerable to Helkorn so you'll want to take steps to mitigate the risk.

With respect to Memory, SQL Server is very memory hungry when fully loaded. Here you'll want to be looking to see if the memory footprint of your antivirus has any impact. Honestly, I have my doubts. WRT CPU, I doubt you'll see much difference; especially if you schedule full scans during off hours.

Answer 3

I wouldn't be surprised if you lost your argument to not have eTrust installed on the machine.

I would suggest rather then arguing against it being installed, suggest that they put in place the correct exclusion rules so databases and processes which are extremelly unlikely to get viruses aren't scanned.

This should make the performance impact of eTrust neglible. (If it's a good product, i've never used it.)

Look at this document, page 98: eTrust antiVirus

That should give you an idea how to configure it properly.

Answer 4

One somewhat quick way to test this would be 2 virtual boxes. In fact you could actually set them up on the same physical box. Have them both start some sort of long winded SQL insert/query/delete/etc. See which one finishes first. If there is a significant discrepancy, then your hypothesis could be proven.

My father-in-law is a science teacher and ALL I ever hear about is the scientific method. Make a hypothesis, test your hypothesis.

Let us know what happens.