• SQLSERVER 数据库性能的基本


    很久没有写文章了,在系统正式上线之前,DBA一般都要测试一下服务器的性能

    比如你有很多的服务器,有些做web服务器,有些做缓存服务器,有些做文件服务器,有些做数据库服务器

    做数据库服务器的那台服务器性能要相对较好,磁盘,内存,CPU等等,

    那么在选用其中某一台服务器作为数据库服务器之前需要测试每一台服务器的性能

    并且需要设置一些硬件的参数,例如设置磁盘控制器的参数,参考文章:Writeback和Writethrough区别

    那么具体怎麽测试呢?怎麽得出测试指标呢?

    大家可以参考这篇文章:SQL Server Database Engine Performance Tuning Basics


    正文

    随着市场份额的SQL Server的发展随着时间的推移,有越来越多的对SQL服务器性能调优的需求。

    有不同的团队和个人采用各种各样的方法提高SQLSERVER服务器的性能,

    而且我认为这些记录SQLSERVER troubleshooting 的基本步骤和提高各种程序性能的文档对SQLSERVER社区是有意义的

    磁盘

    为了SQLSERVER能有效运行,监控和优化SQLSERVER的磁盘子系统是一个重要的方面

    我们需要非常明确磁盘的性能需求

    Avg. Disk Sec/Read 这个计数器是指每秒从磁盘读取数据的平均值

    下面的列表显示这个计数器值的范围,并指出这个计数器所处范围的意思

    少于 10 ms - 非常好
    在 10 - 20 ms 之间- 还可以
    在 20 - 50 ms 之间- 慢,需要关注
    大于 50 ms –严重的 I/O 瓶颈

    磁盘性能测试工具

    (1)CrystalDiskMark

    (2)HDTUNE 硬盘检测修复工具 

    (3)ATTO Disk Benchmark 

    辨别I/O瓶颈

    PhysicalDisk Object:Avg. Disk Queue:所选物理磁盘在取样期间被排队的磁盘读写请求平均值

    如果你的磁盘队列长度经常超出SQLSERVER磁盘使用峰值的2倍,那意味着可能有I/O瓶颈了

    Avg. Disk Sec/Read:每秒从磁盘读取数据的平均值 

    Avg. Disk Sec/Write:写入数据到磁盘的平均时间,Avg. Disk Sec/Read参考指标

    Physical Disk:%Disk Time磁盘时间是所选磁盘驱动器繁忙处理读写请求时所花时间的百分比,一个指标就是如果这个值大于50%,那么就存在I/O瓶颈

    Avg. Disk Reads/Sec:在磁盘上的读操作的比率。确保这个数字小于磁盘吞吐量的85%。当这个值超过85%磁盘访问时间会以指数式增长

    Avg. Disk Writes/Sec c:在磁盘上的写操作的比率。确保这个数字小于磁盘吞吐量的85%。当这个值超过85%磁盘访问时间会以指数式增长

    对于更多的信息,可以参考“如何创建性能计数器集”:http://technet.microsoft.com/en-us/library/cc722148.aspx

    磁盘驱动器的位置

    为了不同的目的,你需要使用不同的驱动器来存放下面的东西
    独立的磁盘延时需求:
    数据库大于15ms

    事务日志大于2ms

    Tempdb数据库大于2ms

    磁盘速度的优先级

    意思是说,Tempdb放在单独的物理磁盘,事务日志文件放在单独的物理磁盘,数据文件放在单独的物理磁盘,操作系统放在单独的物理磁盘,

    数据库备份文件放在单独的物理磁盘

    一般我们的做法:不可能有那么多单独的物理磁盘,一般就是做了磁盘阵列的存储

    C盘放操作系统文件

    D盘放数据文件和事务日志文件 和Tempdb数据文件和Tempdb日志文件

    E盘放数据库备份文件

    当格式化磁盘的时候,对于要存放SQLSERVER数据文件和日志文件的磁盘,尽量不要使用默认的磁盘分配单元

    使用64k 簇大小 Allocation Unit 来格式化磁盘,至于为什麽大家可以看一下这篇文章:如何用Procmon.exe来监视SQLSERVER的logwrite大小


    杀毒软件

    杀毒软件会对SQLSERVER的一些功能产生问题,使用杀毒软件的排除功能将数据库的文件排除在扫描的范围外是很重要的(放入杀软的扫描例外里)

    下面的文件类型是需要排除在外的

    *.mdf, *.ndf, *.ldf, *.bak

    相关文章:杀毒软件导致YourSQLDba备份失败

    文章中说到因为杀毒软件扫描备份文件夹并锁住了备份文件夹,导致SQLSERVER备份数据库失败


    内存

    总是给分配最大的内存给SQLSERVER实例在服务器属性那里设置


    注意:最大内存设置只对SQLSERVER的buffer cache部分有效,不包括SQLSERVER的一些需要内存的功能,例如复制

    (SQLSERVER2012的最大内存设置已经可以限制buffer cache部分和非buffer cache部分的内存)

    为了指明Non-Buffer Pool 的内存占用,使用下面的说明

    SQL Server’s buffer pool外的内存需求(这个需求不是说你设置了SQLSERVER最大内存之后,所剩下的内存的需求,不管你有没有设置SQLSERVER的最大内存

    下面几项都是服务器固定需要消耗的内存,而无论你的服务器内存是4G,8G还是16G,下面几项都会固定占用服务器的内存)

    (1)操作系统需要占用2GB内存,如果是64位操作系统,操作系统占用内存不大于3GB

    (2)SQLSERVER工作线程的倍数,你可以在SQLSERVER服务器属性里设置最大工作线程,

    每个线程会使用0.5MB内存(X86服务器)

    每个线程会使用2MB内存(X64服务器)

    每个线程会使用4MB内存(Itanium服务器)

    注意:0.5MB内存存放的是线程自身的数据结构和相关信息,不包括数据

    为什么各种服务器所分配的线程内存不一样,这个是操作系统分配的,SQLSERVER并没有做特别的设置!

    如果你设置最大的工作线程数为10个,服务器是X86,刚好服务器用尽了10个线程,那么占用的内存是10*0.5MB=5MB内存

    (3)1GB的 multi-page 内存占用,链接服务器和其他SQLSERVER外围的程序占用

    (4)运行在服务器上的程序可能占用1~3GB内存,例如备份程序

    例子

     例如,一个8核服务器,16GB内存,运行着SQLSERVER2012 X64,上面运行着第三方的备份程序,你可以参照下面的清单

     (1)3GB 给 Windows (2GB for 32 Bit Windows)

     (2)1GB 给 SQLSERVER 工作线程 (576 × 2MB 大概)

    各种CPU和SQLSERVER版本组合自动配置的最大工作线程数
    CPU数       32位计算机      64位计算机
    <=4             256               512
    8                 288               576
    16               352                704
    32               480                960

    (3)1GB for MPAs, etc. (multi-page apply)

    (4)1~2 GB 给 备份程序.

    您能够找到更多信息关于“最大工作线程选项”http://technet.microsoft.com/en-us/library/ms187024(v=sql.105).aspx

    (For SQL Server 2008).

    开启Lock Pages in Memory 选项

    Windows组策略决定哪个Windows账户能使进程将他的数据逗留在物理内存里,防止操作系统把程序数据从物理内存换页换出磁盘上的虚拟内存

    这能够给您带来性能上的提升,特别遇到内存压力的时候


    TempDB 数据库的优化

    默认,Tempdb数据库只有一个数据文件和事务日志文件。然而,为了性能的优化,跟着下面给出的建议最佳实践

    TempDB数据库的存储计划

    (1)设置Tempdb数据库的恢复模式为简单(默认就是简单的),简单模式能够自动回收日志空间使日志空间的需求保持最小

    (2)不要让Tempdb的数据文件自动增长,这可以减少管理动态文件增长的CPU开销

     对于Tempdb数据库,可以分开多个数据文件(总的Tempdb数据库数据文件的数量=CPU逻辑处理器的数量,比如8核服务器可以分8个数据文件)

    每个数据文件的大小要一样

    (3)尝试将这些数据文件存放在不同的磁盘驱动器上以利用并行I/O

    (4)TempDB 数据文件和 日志文件应该存放在较快速度的磁盘上(如果可能推荐放在做了RAID 1的磁盘上)

    (5)使用RAID-10 或者 SSD 磁盘

    (6)预先定义好Tempdb数据库的文件大小

    (7)设置Tempdb总的大小为当前数据库实例中最大的那个数据库的25% 

    (8)设置Tempdb数据文件自动增长的固定大小小于200MB

    (9)你应该设置Tempdb数据库的数据文件数量跟逻辑CPU的数量一致,最多不超过8个数据文件



    CPU的优化

    设置最大并行度(Max Degree of Parallelism)

    定义多少个逻辑CPU能并行执行查询

    很多微软的产品,例如SharePoint 和 Dynamics CRM都把这个设置设置为1,这个是推荐的设置


    对于 SharePoint  的LOB 应用程序,当你看到有很多CXPACKETS 的等待类型在你的SQLSERVER服务器里,

    你应该考虑一下将这个设置(Max Degree of Parallelism)设置为1


    索引填充因子

    如果你的SQLSERVER服务器有非常高的事务量TPS (transaction per second)

    你的索引有比较高碎片级别,考虑一下将填充因子设置为“80%”

    并且使用下面的SQL语句检测一下索引碎片

    SELECT  DB_NAME(ps.database_id) AS 'Database Name' ,
            OBJECT_NAME(ps.OBJECT_ID) AS 'Database Object' ,
            ps.index_id ,
            b.name ,
            ps.avg_fragmentation_in_percent
    FROM    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS ps
            INNER JOIN sys.indexes AS b ON ps.OBJECT_ID = b.OBJECT_ID
                                           AND ps.index_id = b.index_id
    WHERE   ps.database_id = DB_ID('ReportServerTempDB')
    ORDER BY ps.avg_fragmentation_in_percent DESC
    GO
     


    使用Performance Monitor (Perfmon.exe)来监控系统性能

    为了捕获SQLSERVER特定的性能指标,你需要使用下面的计数器

    Processor: % Processor Time  :平均应该低于75% (最好低于50%)   

    System: Processor Queue Length:平均每个逻辑CPU应该低于2,例如在一个2逻辑CPU的机器上,他应该保持在4

    Memory—Pages/sec:平均应该低于20(最好低于15%)

    Memory—Available Bytes :可用内存应该保持在50MB以上

    Physical Disk—% Disk Time:
    Physical Disk—Avg. Disk Queue Length :每个磁盘平均应该低于2,例如:一个RAID5磁盘,这个指标应该平均低于10

    Physical Disk—Avg. Disk Reads/sec :取决于CPU和磁盘的大小,应该低于相对应磁盘的吞吐量的85%

    Network Interface—Bytes Total/sec :用于统计网络带宽方


    SQL Server: Buffer Manager—Page Life Expectancy:用于统计内存,应该保持在300秒
    SQL Server: 一般统计用户的连接数 来估计大概使用的内存
    SQL Server: Databases— Transactions/sec :每秒的事务数
    SQL Server: Databases—Data File(s) Size KB:用于统计数据库数据文件的大小,衡量磁盘子系统的性能
    SQL Server: Databases—Percent Log :衡量磁盘子系统的性能

    如有不对的地方,欢迎大家拍砖o(∩_∩)o

  • 相关阅读:
    【Lintcode】112.Remove Duplicates from Sorted List
    【Lintcode】087.Remove Node in Binary Search Tree
    【Lintcode】011.Search Range in Binary Search Tree
    【Lintcode】095.Validate Binary Search Tree
    【Lintcode】069.Binary Tree Level Order Traversal
    【Lintcode】088.Lowest Common Ancestor
    【Lintcode】094.Binary Tree Maximum Path Sum
    【算法总结】二叉树
    库(静态库和动态库)
    从尾到头打印链表
  • 原文地址:https://www.cnblogs.com/gjhjoy/p/3840607.html
Copyright © 2020-2023  润新知