2010-10-20 153 views
2

我有一个只读数据库(产品),它在自己的Sql Server 2008上进行记录。优化查询以减少I/O压力是否有意义?

我已经通过查看活动监视器中最昂贵的查询来优化查询 - 报告。我按CPU的成本订购了这份报告。我现在有50个查询/秒,没有查询超过300毫秒。

CPU时间正常(30%)和内存仅被使用20%(64GB中)。

有一个问题:磁盘时间稳定在100%(我查看了空闲时间性能计数器并使用ideras SQL诊断管理器)。我可以看到产品数据库的行为与我在另一台机器上的订单数据库不同,并且具有较小的表:如果我查看一个事件探查器跟踪,我在product-db中查询显示列“read”中的值高于50.000 。在我的订单DB中,这些值永远不会高于1000.在product-db中的查询使用大量的公用表表达式,在大型表上工作(有些大约有500万条)。

如果我应该投入时间优化I/O性能查询或者我应该只添加一台服务器,我并不确定。通过otimizing查询持续时间,我已经添加了缺少的索引。是为I/O优化通常做的事情?

+0

这可能是服务器故障的一个更好的问题。你只有一张光盘有事务日志,用户数据库文件和tempdb?如果不是哪一个(S)有长的磁盘队列长度? – 2010-10-20 20:13:07

+0

@Martin Smith他的数据库是只读的,所以我不希望事务日志中的重要负载。 – 2010-10-20 20:17:44

+0

@Peter - 的确如此。我有点不确定'order db'进入它的位置。 @Malcolm - 这是完全独立的硬件吗? – 2010-10-20 20:21:58

回答

5

总之,是的。优化均为 CPU和IO。

具有高CPU的查询往往会做不必要的内存中排序,(有时效率低下)散列连接或复杂的逻辑。

具有高IO(页面读取)的查询往往会进行全表扫描或以其他低效方式工作。

9次出10,相同的查询将靠近列表的顶部,但如果你曾经在高CPU上工作,你仍然对性能不满意,那么通过一切手段,工作在高IO接下来是procs。

4

总会有下一个瓶颈。

他们说。

既然已经调整了CPU使用率,那么I/O负载显然占主导地位是很自然的。你的表现已经可以接受吗?如果是停止,如果没有,你必须估计有多少小时你将不得不投资进一步调整,如果购买另一台服务器或更多的硬盘可能会更便宜。

关于I/O调整,请尝试通过简单的措施查看您可以实现的目标。有时你可以用CPU交换I/O,反之亦然。压缩就是一个例子。然后你会调整那个是你当前瓶颈的组件。

在尝试使I/O更快尝试减少生成的I/O之前,

1

为查询寻找明显的IO性能改进,但更重要的是,请查看如何在服务器级别提高IO性能。

如果您的其他资源(CPU和内存)未超载,则可能不需要新的服务器。考虑为日志和临时文件添加固态硬盘,和/或考虑是否可以将整个数据库合理安装到SSD阵列上。

当然,清除磁盘IO瓶颈可能会提高CPU使用率,但是如果性能接近可接受的水平,这可能会改善您现在可以停止优化的情况。

0

除非您使用固态硬盘或数据库优化的SAN,否则IO几乎总是数据库应用程序的限制。

所以,是的,优化,尽可能地摆脱它。

表索引是第一件要做的事情。

然后,添加尽可能多的RAM,直到您的数据库文件的完整大小。

然后对您的数据表进行分区(如果这是合理的做法),以便只对一个或两个表分区执行任何必要的表或索引扫描。

那么我想你要么购买更大的机器,更多的内存和/或购买固态硬盘,或者购买固态硬盘的SAN或SAN。

或者,您可以重建整个数据库应用程序以使用NoSQL或数据库分片之类的东西,并在中间接口层实现所有关系,连接,约束等。