windows磁盘I/O的性能评估方法详解
通常，我们很容易观察到数据库服务器的内存和CPU压力。但是对I/O压力没有直观的判断方法。
磁盘有两个重要的参数： Seek time、 Rotational latency。正常的I/O计数为：①1000/(Seek time+Rotational latency)*0.75，在此范围内属正常。当达到85％的I/O计数以上时则基本认为已经存在I/O瓶劲。
理论情况下，磁盘的随机读计数为125、顺序读计数为225。对于数据文件而言是随机读写，日志文件是顺序读写。因此，数据文件建议存放于RAID5上，而日志文件存放于RAID10或RAID1中。
下面假设在有4块硬盘的RAID5中观察到的Physical Disk性能对象的部分值：
- Avg. Disk Queue Length 12
- Avg. Disk Sec/Read .035
- Avg. Disk Sec/Write .045
- Disk Reads/sec 320
- Disk Writes/sec 100
- Avg. Disk Queue Length，12/4=3，每块磁盘的平均队列建议不超过2。
- Avg. Disk Sec/Read一般不要超过11～15ms。
- Avg. Disk Sec/Write一般建议小于12ms。
从上面的结果，我们看到磁盘本身的I/O能力是满足我们的要求的，原因是因为有大量的请求才导致队列等待，这很可能是因为你的SQL语句导致大量的表扫描所致。在进行优化后，如果还是不能达到要求，下面的公式可以帮助你计算使用几块硬盘可以满足这样的并发要求：
- Raid 0 -- I/Os per disk = (reads + writes) / number of disks
- Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2
- Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks
- Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks
我们得到的结果是：(320+400)/4=180，这时你可以根据公式①来得到磁盘的正常I/O值。假设现在正常I/O计数为125，为了达到这个结果：720/125=5.76。就是说要用6块磁盘才能达到这样的要求。
但是上面的Disk Reads/sec和Disk Writes/sec是个很难正确估算的值。因此只能在系统比较忙时，大概估算一个平均值，作为计算公式的依据。另一个是你很难从客户那里得到Seek time、Rotational latency参数的值，这也只能用理论值125进行计算。
如何通过Performance Log确定SQL的磁盘有性能问题?
1. 查看Disk Bytes/sec. 举个例子, 这个counter的最大值如果是11M, 那么说明work load并不高.
2. 查看Avg. Disk sec/Transfer. 举例, 这个counter的推荐值是<0.015.
3. 查看Avg. Disk Queue Length, 这个推荐值是<2.
一些比较重要的performance counter:
|
Counter |
Description |
|
LogicalDisk\ % Free Space |
报告磁盘空间中未被分配的空间占逻辑卷中总可用空间的百分比. 当选择_Total实例的时候, 该计数器会重新计算每个盘总和. PhysicalDisk对象没有这个计数器. |
|
LogicalDisk|PhysicalDisk\ Avg. Disk Bytes/Transfer |
衡量输入/输出(I/O)操作的数据量的大小. 如果磁盘相对快速地传输大量数据, 那么磁盘是高效的. 当衡量最大吞吐量的时候, 应该观察这个计数器. 要进一步地分析数据传输, 应当查看Avg. Disk Bytes/Read 和Avg. Disk Bytes/Write两个计数器. |
|
LogicalDisk|PhysicalDisk\ Avg. Disk sec/Transfer |
标示着数据被移动的速度(以秒衡量). 衡量每次数据传输的平均时间, 而不论读或写的数据的大小. 它展示了从数据离开Diskperf.sys, 到操作完成的读或写的总时间. 这个计数器的高数值可能意味着系统因为队列太长而在重试请求, 或者由于不常见地磁盘错误而重试请求. 要进一步地分析数据传输, 应当查看Avg. Disk sec/Read 和Avg. Disk sec/Write两个计数器. |
|
LogicalDisk|PhysicalDisk\ Avg. Disk Queue Length |
记录了在计数器数据采样点之间的时间内被放入队列中等待磁盘的请求的数量, 也包括正在被处理的请求在内. 所以, 这有可能是有点夸大的数据. 如果有多于两个的请求持续地在一个单磁盘的系统中等待, 那么磁盘可能就是瓶颈. 要进一步地分析队列长度的数据, 应当查看Avg. Disk Read Queue Length 和Avg. Disk Write Queue Length两个计数器. |
|
LogicalDisk|PhysicalDisk\ Current Disk Queue Length |
标示着当前正在等待的磁盘请求的数量, 也包括正在被处理的请求. 受许多因素的影响, 除非工作量的状态比较稳定, 并且你收集了充足的采样, 才能建立一个模式. 这是一个即刻的数值或是当前队列的长度, 跟Avg. Disk Queue Length, Avg. Disk Read Queue Length, 和Avg. Disk Write Queue Length不一样, 那三个反应的是平均值. |
|
LogicalDisk|PhysicalDisk\ Disk Bytes/sec |
标示着字节被传输的速率, 该计数器是磁盘吞吐量的主要衡量指标. 要进一步地分析读或写的传输的数据, 应当分别查看Disk Read Bytes/sec 或Disk Write Bytes/sec两计数器. |
|
LogicalDisk|PhysicalDisk\ Disk Transfers/sec |
标示着每秒钟完成的读和写操作数, 而不论这些读写操作涉及到多少数据. 该计数器衡量磁盘的利用率. 如果该值超过50(如果是striped的分卷, 那就是看平均到每块物理磁盘上), 那么这可能就是一个瓶颈了. 要进一步地分析读或写的数据传输, 应当分别查看Disk Read/sec 和Disk Writes/sec |
|
LogicalDisk\ Free Megabytes |
汇报磁盘上没被分配的字节的量. PhysicalDisk对象上, 没有这个计数器. |
|
LogicalDisk|PhysicalDisk\ Split IO/sec |
汇报操作系统将I/O请求分为多个磁盘请求的比率. 如果一个程序请求的数据大小太大, 以至于不能放在一个单个请求中, 或是磁盘有碎片, 那么一个split I/O请求可能会发生. 影响IO请求大小的因素可以包括应用程序设计, 文件系统, 驱动程序. 高比率的split I/O可能本身不会作为一个问题出现. 然而, 在单磁盘系统中, 这个计数器的高数值趋向于标志着磁盘碎片. |
|
LogicalDisk|PhysicalDisk\ % Disk Time |
报告选择的磁盘驱动器忙于服务读写请求的时间比率. 因为这个计数器的数据会跨越多个采样, 持续地夸大磁盘利用率, 那这个值跟%Idle Time比较, 这样能获得更清晰的认识. 默认这个计数器的值不会超过100%的. |
|
LogicalDisk|PhysicalDisk\ % Disk Write Time |
汇报被选择的磁盘忙于处理写请求所占的时间的百分比. |
|
LogicalDisk|PhysicalDisk\ % Disk Read Time |
汇报被选择的磁盘忙于处理读请求所占的时间的百分比. |
|
LogicalDisk|PhysicalDisk\ % Idle Time |
汇报磁盘系统没在处理任何请求, 而且没有任何工作在队列中的时间的百分比. 注意这个计数器和%Disk Time相加的时候可能结果不是100%, 因为%Disk Time可能会夸打磁盘的利用率. |
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。
相关推荐
-
Python实现测试磁盘性能的方法
本文实例讲述了Python实现测试磁盘性能的方法.分享给大家供大家参考.具体如下: 该代码做了如下工作: create 300000 files (512B to 1536B) with data from /dev/urandom rewrite 30000 random files and change the size read 30000 sequential files read 30000 random files delete all files sync and drop cac
-
由注册表引起的 I/O 操作发生了不可恢复的错误修复方法
服务器出现此问题: 很多使用Windows Server 2003系统的用户都会收到如下错误: 事件类型: 错误 事件来源: Application Popup 事件种类: 无 事件 ID: 333 日期: 2007-8-11 事件: 8:48:03 用户: N/A 计算机: LZ_YQ 描述: 由注册表引起的 I/O 操作发生了不可恢复的错误. 注册表将不能读取.写出或刷新包含注册表系统图像的其中一个文件. 然后系统失去响应,需要重新启动. 事件ID是333,英文日志为 Event Type:
-
服务器常用磁盘阵列RAID原理、种类及性能优缺点对比
磁盘阵列(Redundant Arrays of Independent Disks,RAID) 1. 存储的数据一定分片: 2. 分基于软件的软RAID(如mdadm)和基于硬件的硬RAID(如RAID卡): 3. RAID卡如同网卡一样有集成板载的也有独立的(PCI-e),一般独立RAID卡性能相对较好,淘宝一搜便可看到他们的原形: 4. 现在基本上服务器都原生硬件支持几种常用的RAID; 5. 当然还有更加高大上的专用于存储的磁盘阵列柜产品,有专用存储技术,规格有如12/24/48盘一柜等
-
Java I/O深入学习之File和RandomAccessFile
前言 I/O系统即输入/输出系统,对于一门程序语言来说,创建一个好的输入/输出系统并非易事.因为不仅存在各种I/O源端和想要与之通信的接收端(文件.控制台.网络链接等),而且还需要支持多种不同方式的通信(顺序.随机存取.缓冲.二进制.按字符.按行.按字等). Java类库的设计者通过创建大量的类来解决这个难题,比如面向字节的类(字节流,InputStream.OutputStream).面向字符和基于Unicode的类(字节流,Reader.Writer).nio类(新I/O,为了改进性能及功能
-
解析NodeJS异步I/O的实现
在现在的项目开发中,任何一个大型项目绝对不是简简单单的采用一个种语言和一种框架,因为每种语言和框架各有优势,与其死守一个,不与取各家之所长,依次得到一个高性能.搞扩展的产品. 对于一个.NET开发者,尤其是主要从事Web开发的.NET程序员,个人觉得有必要学习一门性能优越的Web平台开发语言.一个开发者不能简简单单的只学习一门语言,思维应该开阔,从各个方面去看待同样的一个问题,这样或许会得到另一番效果和见解,个人认为应该学习一下其他的语言,这样有利于我们对比语言的优势和缺点,例如java.nod
-
浅谈带缓冲I/O 和不带缓冲I/O的区别与联系
这里搜集从网上看到的一些言论,自认为还是比较靠谱的,有些不靠谱的根据自己的理解进行了修正. 首先要明白不带缓冲的概念:所谓不带缓冲,并不是指内核不提供缓冲,而是只单纯的系统调用,不是函数库的调用.系统内核对磁盘的读写都会提供一个块缓冲(在有些地方也被称为内核高速缓存),当用write函数对其写数据时,直接调用系统调用,将数据写入到块缓冲进行排队,当块缓冲达到一定的量时,才会把数据写入磁盘.因此所谓的不带缓冲的I/O是指进程不提供缓冲功能(但内核还是提供缓冲的).每调用一次write或read函数
-
windows磁盘I/O的性能评估方法详解
通常,我们很容易观察到数据库服务器的内存和CPU压力.但是对I/O压力没有直观的判断方法. 磁盘有两个重要的参数: Seek time. Rotational latency.正常的I/O计数为:①1000/(Seek time+Rotational latency)*0.75,在此范围内属正常.当达到85%的I/O计数以上时则基本认为已经存在I/O瓶劲. 理论情况下,磁盘的随机读计数为125.顺序读计数为225.对于数据文件而言是随机读写,日志文件是顺序读写.因此,数据文件建议存放于RAID5
-
基于Tomcat安全配置与性能优化详解
Tomcat 是 Apache软件基金会下的一个免费.开源的WEB应用服务器,它可以运行在 Linux 和 Windows 等多个平台上,由于其性能稳定.扩展性好.免费等特点深受广大用户喜爱.目前,很多互联网应用和企业应用都部署在 Tomcat 服务器上,比如我们公司,哈. 之前我们 tomcat 都采用的是默认的配置,因此在安全方面还是有所隐患的.上周对测试环境的所有服务器的tomcat都做了安全优化,其间也粗略做了一些性能优化,这里就简单记录分享下! 一.版本安全 升级当前的tomcat版本
-
iOS 下的图片处理与性能优化详解
图片在计算机世界中怎样被存储和表示? 图片和其他所有资源一样,在内存中本质上都是0和1的二进制数据,计算机需要将这些原始内容渲染成人眼能观察的图片,反过来,也需要将图片以合适的形式保存在存储器或者在网络上传送. 这种将图片以某种规则进行二进制编码的方式,就是图片的格式. 常见的图片格式 图片的格式有很多种,除了我们熟知的 JPG.PNG.GIF,还有Webp,BMP,TIFF,CDR 等等几十种,用于不同的场景或平台. 这些格式可以分为两大类:有损压缩和无损压缩. 有损压缩:相较于颜色,人眼对光
-
MySQL COUNT(*)性能原理详解
目录 前言 1.COUNT(1).COUNT(*)与COUNT(字段)哪个更快? 实验分析 实验结果 实验结论 2.COUNT(*)与TABLES_ROWS 3.COUNT(*)是怎么样执行的? 4.总结 前言 在实际开发过程中,统计一个表的数据量是经常遇到的需求,用来统计数据库表的行数都会使用COUNT(*),COUNT(1)或者COUNT(字段),但是表中的记录越来越多,使用COUNT(*)也会变得越来越慢,今天我们就来分析一下COUNT(*)的性能到底如何. 1.COUNT(1).COUN
-
MySQL 5.6.36 Windows x64位版本的安装教程详解
1,目标环境 Windows 7 64位 2,材料 (1)VC++2010 发布包(64位) (2)MySQL 5.6.36 Windows x64位版本(非MSI,可从官网获取免费版本) (3)EditPlus(可选) 3,基础操作 本文中部分操作需以管理员身份+命令行进行执行. 4,步骤 (1)(解压到当前文件夹方式)解压安装包,编辑其中的my-default.ini文件,主要是2项: ①basedir即为mysql基础文件夹,形如:C:\mysql-5.6.36-winx64 ②datad
-
如何在windows下安装Pycham2020软件(方法步骤详解)
1.在pycham官网下载安装软件https://www.jetbrains.com/pycharm/download/ 2.我下载的是64位的安装包,现在开始安装 3.下一步,选择安装位置,我不太想用它的默认路径,我建了个Python的文件夹,准备把Python相关的装到这里. 4.根据你电脑的情况进行勾选,我选的是64位.添加路径.和.py文件默认以pycham打开. 5.下一步,安装 6.安装完成! 补充:还需要安装Python的库Pycham才能运行哦!有两种方式可以实现,一种是安装Py
-
Windows 版本Git命令行的使用详解
Git的使用基本教程 git安装 官网 msysgit.github.io(百度搜索git下载地址也行)下载 git安装(路径选择你的路径或者默认也行) 步骤中:出现选项注意选择Use git from git bash only(其他默认一路下一步就行了) 最后配置环境变量(目的就是在CDM窗口任意目录都可以执行git命令行) path:D:\Asoftware\java\Git\bin 详情请参考:https://www.jb51.net/article/191327.htm git配置账户
-
Windows bat脚本之for循环用法详解
Windows bat脚本的for语句基本形态如下: 在cmd窗口中:for %I in (command1) do command2 在批处理文件中:for %%I in (command1) do command2 之所以要区分cmd窗口和批处理文件两种环境,是因为在这两种环境下,命令语句表现出来的行为虽然基本一样,但是在细节上还是稍有不同,最明显的一个差异就是:在cmd窗口中,for之后的形式变量I必须使用单百分号引用,即%I:而在批处理文件中,引用形式变量I必须使用双百分号,即%%I.为
-
java 较大数据量取差集,list.removeAll性能优化详解
今天在优化项目中的考勤同步功能时遇到将考勤机中的数据同步到数据库, 两边都是几万条数据的样子,老代码的做法差不多半个小时,优化后我本机差不多40秒,服务器速度会更加理想. 两个数据集取差集首先想到的方法便是List.removeAll方法,但是实验发现jdk自带的List.removeAll效率很低 List.removeAll效率低原因: List.removeAll效率低和list集合本身的特点有关 : List底层数据结构是数组,查询快,增删慢 1.List.contains()效率没有h
-
Windows下Goland的环境搭建过程详解
1.安装包下载 进入Go官方下载界面 下载并安装,安装时注意最好不要将其安装在C盘,我这里将它安装在D盘: 2.环境变量配置 安装包会自动添加环境变量,但是默认的Go工作空间C盘,而我们一般不在C盘放自己的文件,这里以我的工作空间为例我的Go项目文件放在D盘的GoFiles文件夹中,所以这里演示重新配置: 主要是配置两个环境变量:GOROOT和GOPATH: GOROOT指GO的安装目录 GOPATH是作为编译后二进制的存放目的地和import包时的搜索路径,不要设置为GO的安装目录,我们一般用