本文共 4979 字,大约阅读时间需要 16 分钟。
监控数据库的目标就是了解SQL数据库内部发生的情况,SQL数据库的并发,用户连接数,服务器资源(CPU,内存,IO)效率,应用等待情况。捕捉这些情况让DBA门了解系统正常运行的情况。
系统上线后,并发,用户连接数,服务器资源(CPU,内存,IO)效率,应用等待情况建立基准,系统更新或者长时间运行后可以根据基准做出对比,出现问题及时解决。
可能的瓶颈方面 | 对数据库的影响 |
内存使用量 | 分配的内存不足或可由 Microsoft SQL Server 使用的内存不足导致性能下降。 数据必须从磁盘读取而非直接从数据缓存读取。 当需要页时,Microsoft Windows 操作系统将通过与磁盘交换数据来执行大量分页操作。 |
CPU 使用率 | 长期的高 CPU 使用率可能表明 Transact-SQL 查询需要优化或 CPU 需要升级。 |
磁盘输入/输出 (I/O) | Transact-SQL 可以优化查询以减少不必要的 I/O(例如,使用索引)。 |
用户连接与并发 | 可能有太多用户同时访问服务器,从而导致性能下降。并发操作批处理导致性能下降。 |
阻塞锁 | 应用程序设计不合理可能导致锁定或妨碍并发,因而导致更长的响应时间和更低的事务吞吐速度。 |
SQL数据库设置最大连接数select @@max_connections 默认32767
设置SQL数据库最大连接数(一般不用设置)exec sp_configure 'user connections', 100
SELECT @@CONNECTIONS查看数据库自上次启动以来的连接次数。
并发数是SQL数据库每秒进行的批处理数目。
可以利用windows自带的性能计数器查看用户连接处与并发数
批请求/秒是指SQL Server是每秒接收批处理的数量。这个计数器是可以查看我们的服务器处理速度。数字越大,表明我们的数据库处理查询的吞吐量越大。像许多计数器一样,没有一个单一的数字,可以说明服务器是太忙了。如今的服务器越来越强大,因此可以一刻不停的处理更多批次的请求。随着时间的推移,应该收集这个计数器,以确定我们的服务器环境基准数值是什么。
用户连接计数器是指同一时刻连接到服务器的用户的数量。我们需要观察这个基线用户连接数,不同时间的用户数量是不同的,且有个高低区间。如果此计数器的值下降,并在系统上的负荷是相同的,那么可能有一个瓶颈,导致我们的服务器不能来处理的正常负荷,这个需要检查了。当然也要注意计数器的值下降也可能是因为连接的确少了的原因。
CPU是服务器中最重要的资源。在数据库服务器中,CPU的使用情况应该时刻监控以便SQLServer一直处于最佳状态。
一个确定 CPU 使用率的有效方法是使用系统监视器中的 Processor:% Processor Time 计数器。 该计数器监视 CPU 执行非闲置线程所用的时间。 持续 80% 到 90% 的状态可能表明需要升级 CPU 或需要增加更多的处理器。
对应于等待处理器时间的线程数。 当一个进程的线程需要的处理器循环数超过可获得的循环数时,就产生了处理器瓶颈。 如果有很多进程在争用处理器时间,可能需要安装一个速度更快的处理器。 如果使用的是多处理器系统,则可以增加一个处理器。
如果处理器队列的长度一直超过服务器上可用处理器的总数量+1,则可能表示处理器堵塞。
监控内存使用。监控服务器的内存是非常重要的事情,有很多情况会引起内存消耗。所以要经常性地做检查。
1 Memory: Available Mbytes:剩余可用内存
2 Memory: Pages/sec:理解为从硬盘读到内存的数据。服务器上只跑的sqlserver,那这个指标的理想范围应该是0-20之间,偶尔超过20的话影响不大,如果这个值频繁的超过20,那说明你的这台服务器可能需要加内存了。
3 SQL Server: Buffer Manager: Buffer Cache Hit Ratio: 缓存命中率,在缓冲区高速缓存中找到而不需要从磁盘中读取(物理I/O)的页的百分比。可判断内存是否充足,最好保证95%以上。95% 或更高的命中率是令人满意的。 添加更多内存,直到该值始终大于 95%。 大于 95% 的值表示数据缓存满足所有数据请求中 95% 以上的请求。
4SQL Server: Buffer Manager: Page life expectancy,表示数据页驻留在内存的秒数。微软建议最少300秒。如果在一个实例中经常低于300秒,意味着数据保留的时间少于5分钟就被移出内存。
Microsoft SQL Server性能在很大程度上取决于I / O子系统(IOS)。IOS的延迟可能导致许多性能问题。
PhysicalDisk: Avg. Disk sec/Write 平均 磁盘秒/写
PhysicalDisk: Avg. Disk sec/Read 平均 磁盘秒/读
数据库日志不超过5ms
OLTP数据库不超过10MS
OLAP不超过25MS
Less than 10 ms - very good 棒
Between 10 - 20 ms – good 好
Between 20 - 50 ms - slow, needs attention 慢需要注意
Greater than 50 ms – Serious I/O bottleneck 严重的IO瓶颈
PhysicalDisk: Avg. Disk Queue Length Disk Queue也就是服务器端发出的存储操作正在等待被存储处理的请求数目。例如有一个应用发出一条读请求,但是目标磁盘当时正在处理其他任务。那么这个新的读请求就会被放在磁盘队列里。这时候磁盘队列的值就是1。如果这个值大于2,说明由磁盘阵列性能问题。
PhysicalDisk: Avg. Disk Queue Length 如果这个值特别大,可以在监控这三个参数,Avg. disk read queue length、Avg. disk write queue length、Current Disk Queue Length。
举例 由4块硬盘组合成的RAID5
Avg. Disk Queue Length=12 平均每块硬盘就是12/4=3 很显然由性能问题。
PhysicalDisk: Disk Bytes/sec 用来确定存储的带宽是否够用。
PhysicalDisk: Disk Transfers/sec 用来确定IOPS是否够用。
首先要监控主要计数器,如果主要计数器没有问题,就不用监控次要计数器了。
磁盘传输/秒由磁盘读取/秒和 磁盘写入/秒组成。您可以使用这些计数器来确定驱动器是否没有足够的支持磁盘。使用这些计数器时,可能需要调整已实现的RAID类型的值。要确定要使用的值,请使用以下公式:
Raid 0 - 每个磁盘的I / O =(读取+写入)/磁盘数量
Raid 1 - 每个磁盘的I / O = [读取+(2 *写入)] / 2
Raid 5 - 每个磁盘的I / O = [读取+(4 *写入)] /磁盘数量
Raid 10 - 每个磁盘的I / O = [读取+(2 *写入)] /磁盘数量
例如,如果磁盘传输/秒的最大值为1800,则可以确定该驱动器的RAID组中至少需要10个15k RPM磁盘。通常,15k RPM磁盘每秒能够执行大约180个I / O请求(IOPS)。180 * 10 = 1800.对于更高的值,您可能需要10个以上的磁盘。因为达到单个硬盘的IOPS80%就会出现性能问题,所以最少需要12个以上的硬盘。
如果出现严重的性能问题,可以考虑以下解决。
Disk Bytes/sec很高, Avg. Disk sec/Write ,Disk sec/Read 都很高说明是硬盘的问题,每秒读出数据很多,平均读写很高说明,也许硬盘性能就是很好。 Disk sec/Write ,Disk sec/Read高,Disk Bytes/sec很低说明是硬盘的问题。所有参数要综合起来看。
为了使SQL Server来管理系统上的并发用户时,SQL Server需要经常锁定资源,有时长有时短暂。锁等待/秒是指每秒针系统等待恰好所申请的资源被锁定的次数。理想情况下我们不希望任何要求等待锁,因此,要保持这个计数器为零或接近零。
指每秒导致死锁的锁请求数。死锁对于应用程序的可伸缩性非常有害,并且会导致恶劣的用户体验。该计数器必须为0,最好也为0.
进程阻塞计数器是指某一时刻进程阻塞的的个数。当一个进程因为申请的资源得不到释放时,这个进程被阻塞了,而其它依赖于同一个资源的进程都不能向前推进,最后导致阻塞的进程越来越多,要解决这个问题唯一的办法是直到其资源释放。理想情况下我们不希望看到任何阻塞的进程,当进程被阻止时应该深入调查。
SQL Server :Databases 计数器
SQL Server每秒在这个数据库上做的日志写的次数。每秒日志刷新数目
SQL Server每秒在这个数据库上做的日志写的量Bytes。
写入日志的操作曾经因为磁盘来不及响应而遇到的等待时间。这种等待会导致前端的事务不能提交,所以会严重影响SQL Server的性能。正常的SQL Server,刷新日志的总等待时间(毫秒)这个值应该在绝大多数时间里都是0.
在每秒提交的事务里,有多少个事务曾经等待过日志写入完成。理想情况下,日志写入应该立刻完成,不需要等待。如果有等地啊,需要检查存放日志文件的磁盘性能。每秒等待日志刷新的提交数目
转载地址:http://aobai.baihongyu.com/