Rav*_*nor 7 performance sql-server clustered-index insert nonclustered-index
我有一个大(6db)的跟踪表。它有一个通过 GETDATE() 创建的聚集键 (DateTime)。
连接到这个数据库/表的连接池在 10 台计算机的集群中平均上升到 50,因此平均我们有大约 500 个并发连接尝试插入。
数据库适合内存,几乎看不到任何 IO。
我试图弄清楚在持续的 INSERT 负载下,聚集索引是否会达到重新平衡树的程度,以及这是否会导致系统可以维持的插入次数减慢。
关于重新平衡索引是否是 SQL Server 对聚集索引(甚至是非聚集索引)执行的操作,我有一些疑问。
问题-
其他信息
SQL Server 不会将“重新平衡树”作为周期性事件。我最后一次在 Oracle 上下文中听到这个术语。SQL Server 所做的一切都会在必要时增加树的高度。这是一个在整个 B 树存在中只发生几次的事件。
在 DML 繁重的工作负载中,可能会有许多小的树调整,称为页面拆分。这些确实不利于 CPU 和 IO 的使用,并且会导致碎片化。如果您按日期升序插入,则不会发生此问题,因为树“追加”是 SQL Server 优化的特殊情况。在任何情况下,页面拆分只会影响少数页面。
没有周期性发生的树操作。
聚集索引具有(几乎)与非聚集索引相同的结构。
所有常用的 SQL Server B 树索引建议都适用:明智地选择键(似乎您有一个基于升序日期时间值的好键),并制定碎片策略和在删除时回收空间的策略。
是否有任何原因导致插入性能的周期性/循环放缓?
是的。检查点事件。对于写入密集型工作负载,如您所描述的,大 RAM 服务器会在内存中积累大量“脏”页面。在预定的检查点间隔内,所有这些脏页都会写入磁盘,从而导致 IO 请求激增。这反过来会减慢日志提交写入的速度,这表现为您定期观察到的 INSERT 响应时间的增加。QED。当然,这只是一种猜测,缺乏适当的调查。对于更确定的响应,我建议您阅读如何分析 SQL Server 性能并应用那里描述的技术来识别问题。
如果问题确实是由检查点引起的,那么 SQL Server 2012 自带的间接检查点:
SQL Server 2012 中新增的间接检查点为自动检查点提供了可配置的数据库级替代方案。... 间接检查点通过在后台不断地将脏页写入磁盘来减少与检查点相关的 I/O 峰值。
有关检查点对性能影响的更详细讨论,请阅读 SQL Q&A: Fine Tuning for Optimal Performance:
寻找尖峰
问:我正在解决一个问题,即我们看到来自我们的一个 SQL Server 的周期性 I/O 尖峰。我已经使用 PerfMon 将其缩小到检查点,但我无法确定哪个数据库是主要的罪魁祸首。我怎样才能进一步钻研?
在 SQL Server 2012 之前,您可以选择减少恢复间隔值。这将增加检查点的频率,但会减少每个检查点必须写入的脏页数。分散数据 IO 有帮助(购买更多的主轴)。将日志 IO 分离到它自己的路径(自己的主轴)对检查点没有帮助,但将日志提交与效果隔离开来,从而保持 INSERT 响应。SSD 创造奇迹。
我建议反对任何结构性变化。在我看来,您已经拥有时间序列的最佳聚集索引。任何结构变化都必须得到根本原因性能分析的支持,将当前结构视为一个问题。
归档时间: |
|
查看次数: |
1635 次 |
最近记录: |