刚刚开始在我们的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实例.重启后,一切恢复正常.错误突然停止发生.那么大的主内存使用量最终会导致错误吗?
另外,我做了一个快速谷歌的高内存使用mssql.我发现如果保留默认设置; SQL Server可以增长到那么大.此外,通过使用SQL Server中的配置选项找到了有关如何调整内存使用情况的 MS链接.
现在的问题是...... SQL Server应该限制多少主内存?
如果它是数据库本身,我肯定会感到非常惊讶,SQLServer是一个非常可靠的产品 - 远远优于Office或Windows本身,并且通常可以绝对和完全依赖.
对于rdbms来说1.5Gb并不算什么 - 而且所有这些都只是用缓存数据来填充它们的可用缓冲区.读取核心通常比磁盘访问快1000倍或更快,因此使用可用的每一块内存都是最佳设计.事实上,如果你看一下任何RDBMS设计理论,你会发现用于决定从核心扔掉什么的算法会因为它对性能产生重大影响而给予相当大的重视.
大多数专用数据库服务器将运行4Gb内存(假设为32位),其中90%专用于SQL Server,因此您肯定不会在此处查看任何类型的边缘情况.
到目前为止,您最可能的问题是编码错误或结构问题(例如锁定)
我确实有一点需要注意.非常(非常,非常 - 像10年两次)我偶尔会看到由于数据库文件损坏导致的SQL Server返回页面撕裂错误,这两次都是由基础的间歇性硬件故障引起的.幸运的是,在这两种情况下,这些都是在包含索引的页面中,通过删除索引,修复数据库,备份和还原到新磁盘,我能够恢复而不会回退到备份.我不确定页面撕裂错误将如何反映到C#API,但可以想象,如果你有一个磁盘错误,只有在核心已满(即它在某个交换空间的某个地方)之后才会出现,那么索引超出范围错误看起来像是一种表现形式,因为一个电话可能会返回垃圾 - 因此超出了数组范围.