SQL Server 2005 和 SQL Server 2005 防毒软件
我们的网络人员坚持在所有服务器上安装防病毒 (eTrust) 软件，包括我们所有的 SQL Server 2005 计算机。 我怎样才能最好地证明这会损害性能？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您在计算机上未安装 eTrust 的论点失败了，我不会感到惊讶。
我建议而不是反对安装它，建议他们制定正确的排除规则，这样极不可能感染病毒的数据库和进程就不会被扫描。
这使得 eTrust 对性能的影响可以忽略不计。 （如果它是一个好产品，我从来没有使用过它。）
看看这个文档，第 98 页：eTrust antiVirus
这应该会让您了解如何正确配置它。
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.
首先，您必须确定它是否会损害性能。 当然，最清晰的方法是创建一个测试套件，您可以在其中评估 TPS 性能。 如果没有多个应用程序运行一套要求相当高的事务或多线程应用程序，您将很难做到这一点。 您可能需要 Google SQL Server、“测试”和“TPS”，看看是否有任何商业产品可以帮助您（我不知道有任何）。 如果您正在滚动自己的测试套件，我建议您从 redgate 软件获取“SQL 响应”的副本来进行性能监控。
防病毒软件本身主要通过内存消耗和网络连接监控来影响性能。 WRT 网络问题，许多防病毒软件包会在端口 1433 上查找 Helkorn 攻击（Helkorn 是一种流行的蠕虫 - Google 搜索 - 而端口 1433 是 SQL Server 的侦听端口），因此您可能会遇到一些在其他地方看不到的防病毒网络问题。 更重要的是，如果您想记录防病毒软件的缺点，我会寻找初始连接时间延迟。 但是，您还应该记住，在没有防病毒软件的情况下飞行会让您更容易受到 Helkorn 的影响，因此您需要采取措施来降低风险。
关于内存，SQL Server 在满载时非常消耗内存。 在这里，您需要查看防病毒软件的内存占用是否有任何影响。 老实说，我有疑问。 WRT CPU，我怀疑你会看到很大的区别； 特别是如果您在下班时间安排全面扫描。
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.
测试这一点的一种快速方法是使用 2 个虚拟盒子。 事实上，您实际上可以将它们设置在同一个物理盒子上。 让他们都开始某种冗长的 SQL 插入/查询/删除/等等。 看看哪个先完成。 如果存在显着差异，那么您的假设就可以得到证明。
我的岳父是一位科学老师，我所听到的都是科学方法。 提出假设，检验你的假设。
让我们知道发生了什么。
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.
在运行 eTrust 之前和之后对服务器进行基准测试。 您可以通过分析访问服务器的应用程序以及在服务器本身上运行的进程来实现此目的。 创建可以在这两种情况下进行测试的查询。 获得绩效矩阵后，您可以将其提交给管理/网络人员。
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.