我目前在数据库服务器上遇到了麻烦,因为数据库服务器有很多小的写操作,而大的读取量则比较少。读性能是更重要的,因为人是参与的,写是由自动化客户端执行。这个数据库目前是30 so,并将成长到100左右。
目前表现不佳的糟糕的设置是
因此,由于它的许多丑陋点(表现不佳,没有RAID,用于备份的外部USB驱动器),我计划设置一个新的数据库服务器。
我想过:
因此,有三个问题:
发布于 2009-07-26 14:04:43
如果您有很多磁盘,例如以某种形式的SAN,那么RAID10是显而易见的选择,因为它结合了速度和容错。然而,在大多数情况下,可以安装在服务器上的磁盘数量是有限制的,在这种情况下,您需要考虑将RAID5作为一种替代。
您的4个磁盘RAID10数组与2个磁盘RAID0的速度大致相同,或者比未被攻击的磁盘的速度略低两倍,所以它们不会那么快。相反,使用4磁盘RAID5可以使数组具有更快的流读和写入速度,但是随机访问的写入速度要慢一点(我已经在戴尔Perc5/i控制器上测试了这一点,我认为其他控制器也是如此)。
我会考虑使用您的10个磁盘作为6个磁盘RAID10和4个磁盘RAID5。将RAID5分成一个用于操作系统的小C:分区,另一个作为日志文件的D:分区。日志往往是按顺序写入的,因此较慢的随机访问速度不是这样的问题。将数据放在RAID10上,它们将受益于高随机访问速度,特别是高随机访问写入速度。
注:我不建议您将磁盘组织为RAID10和RAID5,但是我建议您使用这种格式测试磁盘,并将其速度与RAID1 + RAID10 + RAID10的建议进行比较。
JR
发布于 2009-07-26 21:48:34
在开始购买硬件之前,我会使用Performance进行一些调查,以确保磁盘滞后。如果性能问题是由那些“自动客户端”阻塞造成的,您可能会发现新服务器上的性能与您现在的性能并没有太大的不同。
编辑1:我喜欢看Avg。磁盘秒/传输号。从本质上说,这些是驱动器延迟的度量。我过去经常使用队列号,但是您应该将它们除以RAID数组中的纺锤数。您并不总是知道这个数字,特别是在SAN存储中,Microsoft Ninjas告诉我放弃队列深度编号,大约在2002年左右。
(通常,我会观察sec/transfer数字、每秒读和写的数字(它们给人一种很好的感觉磁盘是如何运行的)以及逻辑和物理页面读取值(帮助发现其他一些非SQLServer的东西正在使用磁盘,以及当SQL只是在从RAM中扫描大量数据时)。最后一个值位于SQL计数器下,而不是磁盘计数器下。当然,对于每个可用的核心(而不是“总计”),都使用了简单的旧处理器。
和阿夫格一起。磁盘秒/传输值,我只是寻找平均值低于50毫秒的数据驱动器和20毫秒的日志驱动器。请注意,您当前设置的操作系统和日志位于相同的纺锤体上,这意味着它们将争夺驱动器头的控制权,这将提高您的延迟时间。
请注意,数据库的高读取率可能仅仅意味着错误的索引。很难通过索引问题在一个网络论坛上工作。由于新机箱中有这么多RAM,您可能最终会将几乎所有的数据都存储在RAM中。这将减少磁盘上的负载,但您可能会发现自己的处理器利用率很高,因为SQL仍然需要扫描所有这些数据;它只是在RAM中,而不是在磁盘上。在RAM中使用它将比在磁盘上的速度更快,但它仍将比索引良好的数据库慢。
此外,我还会尝试将数据和tempdb保留在不同的纺锤体上,因为当您对tempdb进行大量写入时,通常意味着要从数据中大量读取数据(比如从huge_table选择*到#report,或者可能对大型结果集使用distinct或group by )。如果您的应用程序没有过多地使用tempdb,那么它可能不会有多大关系。
对于经过良好调优的Server,不应该需要将整个数据库存储在RAM中。我有12 GB内存的服务器,还有100's级的数据。
此外,您可能可以节省一点钱,使用10 10KRPM驱动器的操作系统。一旦SQL启动并运行,它就不应该过多地接触引导驱动器了。
如果我在你的位置,我最担心的是在你当前设置的RAID冗余,其次是(可能)在USB驱动器上的长备份时间。
如果我被那个USB驱动器卡住了一段时间,我可能会考虑每周做一次完整的备份,然后每天备份一次。取决于您的数据在任何给定的一天中真正发生了多少变化,这应该减少您必须移动到USB驱动器的数据量。
发布于 2009-07-27 14:10:13
这么多问题..。
这是专用Server吗?(应该是!)32 is内存很好,CPU看起来也不错.
这个服务器是只承载这个单一的数据库,还是被许多不同数据库的应用程序所使用?
服务器的工作负载是什么?每秒有多少事务(读/写)?
数据有多重要?如果它非常重要(即不能丢失它),那么将构建偏向冗余。如果它必须100%可用(没有停机时间),那么就偏向于弹性(并获得更大的预算)。如果它只是一个性能数据库(即数据仓库),那么您可以优化性能。
您必须查看性能计数器,以找出当前瓶颈所在。高磁盘I/O和磁盘队列?高CPU?(通常由有限的RAM和上下文垃圾处理引起)
SQL代码写得对吗?我见过大型计算机(而且您的机器相当大)被糟糕的SQL代码和小型机器(1 CPU,1GB RAM)运行了编写良好和繁忙的数据库的负载。
通常,远离RAID 5(您的数据库大小足够小,不需要额外的容量),RAID10是最好的。
您应该使用双驱动器RAID 1作为日志,为TEMP提供双驱动器(在这两个驱动器中创建与CPU相同数量的临时数据文件),然后数据可以放在一个更大的4到6 RAID10数组上。
https://serverfault.com/questions/45607
复制相似问题