大型SQL Server内存使用会导致错误吗？

Question

刚刚开始在我们的C＃.Net应用程序上出现一堆错误，似乎无缘无故地发生了。 SqlDataReader对象上的System.IndexOutOfRangeException之类的东西，应该返回一个索引并且现在已经返回了一段时间。

无论如何，我看了一下任务管理器，看到sqlservr.exe运行在大约1,500,000 K Mem Usage。我绝不是一名DBA，但是对于使用Intel Xeon 3.33Ghz和4GB内存的Win Server 2003 R2企业版而言，大量使用内存对我来说是错误的。所以我重新启动了SQL Server实例。重启后，一切恢复正常。错误突然停止发生。 这个大的主内存使用量最终会导致错误吗？

此外，我为high memory usage mssql做了快速Google。我发现如果保留默认设置; SQL Server可以增长到那么大。另外，找到了一个关于How to adjust memory usage by using configuration options in SQL Server的MS链接。

现在的问题是...... 应该限制SQL Server使用多少主内存？

Answer 1

如果它是数据库本身，我肯定会非常感到惊讶，SQLServer是一个非常可靠的产品 - 远远优于Office或Windows本身，并且通常可以完全依赖。

对于rdbms，

1.5Gb nothing - 并且所有这些都将继续用缓存数据填充其可用缓冲区。读取核心通常比磁盘访问快1000倍或更快，因此使用可用的每一块内存都是最佳设计。事实上，如果你看一下任何RDBMS设计理论，你会发现用于决定从核心扔掉什么的算法会因为它对性能产生重大影响而给予相当大的重视。

大多数专用数据库服务器将运行4Gb内存（假设为32位），其中90％专用于SQL Server，因此您肯定不会在此处查看任何类型的边缘情况。

到目前为止，您最可能遇到的问题是编码错误或结构问题（例如锁定）

我确实有一点需要注意。非常（非常，非常 - 像10年两次）我偶尔会看到由于数据库文件损坏导致的SQL Server返回页面撕裂错误，这两次都是由基础的间歇性硬件故障引起的。幸运的是，在这两种情况下，这些都是在包含索引的页面中，通过删除索引，修复数据库，备份和还原到新磁盘，我能够恢复而不会回退到备份。我不确定页面撕裂错误将如何反映到C＃API，但可以想象，如果你有一个磁盘错误，只有在核心已满（即它在某个交换空间的某个地方）之后才会出现，那么索引超出范围错误看起来像是一种表现形式，因为呼叫可能会返回垃圾 - 因此超出了数组范围。

Answer 2

有很多不同的因素可以发挥作用设定的限制。通常，您希望以某种方式限制它，以防止它占用系统中过多的RAM。

如果该框是一个专用的SQL框，那么将它设置为使用框中RAM的90％左右并不罕见....

但是，如果它是具有其他用途的共享框，则可能还有其他注意事项。

Answer 3

  应该MSSQL有多少主内存   应该限于？

尽可能多地给予它，同时确保其他系统服务能够正常运行。是的，这是一个模糊的答案，但在一个专用的数据库盒子上，MSSQL会对90％的RAM等都很满意。按照设计，它将占用尽可能多的RAM。

Answer 4

1.5GB的4.0GB几乎不值得......我们的一台服务器通常以1.6GB的2.5GB运行，没有任何问题。如果不是那么多，我想我会更加担心。

我并不是说听起来很苛刻，但我不会那么快地责怪SQL Server的应用程序错误。根据我的经验，每次我试图将责任转嫁到SQL Server上时，它都是我的屁股。通常是系统管理员或流氓查询使我们的服务器陷入困境。

有几次，慢速运行查询的解决方案是重新启动服务器而不是检查查询，这几乎总是有问题。我知道我亲自重写了十几个查询，其成本远高于100。

这听起来好像是“'选择'被破坏了”所以我很好奇你是否能在代码中找到任何改进。

Answer 5

SQL需要它正在使用的ram。如果它是使用1.5演出，它使用它来进行数据缓存，程序缓存等。通常更好的单独留下 - 如果你设置一个上限太低，你最终会伤害性能。如果它在一个4格的网箱上使用1.5演出，我根本不会称之为异常。

您的错误很可能是由锁定引起的 - 我很难说您在问题中定义的SQL内存使用情况导致了您获得的错误。