数据库运行时如何查看哪个进程占用IO多少

据我所知, 在OS一级, 没有统计那个process占用的IO的命令

一般的统计, 都是根据device来统计的, 也就是你/dev下的文件, 比如某个磁盘分区,等等

在solaris10下倒是有个Dtrace命令可以统计下process占用的IO, 但是根据这个命令的名字

可以看出来, 它是对process进行dynamic trace, 来查看process的IO情况的, 使用起来比较复杂.

我们可能经常会遇到SQLServer数据库频繁关闭的情况。在分析了内存和CPU使用情况后，我们需要继续调查根源是否在I/O。我们应该如何识别SQLServer是否有I/O相关的瓶颈？

解决：

当数据页经常从缓冲池中移进移出的时候，I/O子系统就会成为SQLServer性能问题的关键因素之一。事务日志和tempdb同样也会产生重大的I/O压力。因此，你必须确保你的I/O子系统能按照预期运行。否则你将会成为响应时间增长和频繁超时的受害者。在这篇文章中，将描述如何使用内置工具识别I/O相关瓶颈，并提供一些磁盘配置的方法：

性能计数器（Performance Monitor）：

可以使用性能计数器来检查I/O子系统的负荷。下面的计数器可用于检查磁盘性能：

PhysicalDisk Object:Avg.DiskQueue

Length：计算从物理磁盘中的平均读和写的请求队列。过高的值代表磁盘 *** 作处于等待状态。当这个值在SQLServer峰值时长期超过2，证明需要注意了。如果有多个硬盘，就需要把这些数值除以2。比如，有4个硬盘，且队列为10，那么平均值就是10/4=2.5，虽然也证明需要关注，但不能使用10这个值。

Avg.Disk Sec/Read和Avg.Disk

Sec/Write：显示从磁盘读或者写入磁盘的平均时间。10ms内是很好的表现，20以下还算能接受。高于此值证明存在问题。

Physical Disk:%Disk

Time：在磁盘忙于读或者写请求的时候持续时间的比率。根据拇指定律，此值应该小于50%。

Disk Reads/Sec和Disk

Writes/Sec计数器显示出在磁盘中读写 *** 作的速率。这两个值应该小于磁盘能力的85%。当超过此值，磁盘的访问时间将以指数方式增长。

可以通过以下方式来计算逐渐增长的负载的能力。一种方法是使用SQLIO。你应该找到吞吐量比较稳定，但缓慢增长。

可以使用以下公式来计算RAID配置：

Raid 0: I/O per disk = (reads + writes) / number

ofdisks

Raid 1: I/O per disk = [reads + (writes*2)] /

2

Raid 5: I/O per disk = [reads + (writes*4)] / number of

disks

Raid

10: I/O per disk = [reads +

(writes*2)] / number of disks

比如：对于RAID 1，如果得到下面的计数器：

Disk Reads/sec = 90

Disk

Writes/sec =75

根据公式：[reads + (writes*2)] / 2 or [90 + (75*2)] /

2 = 120I/Os每个磁盘。

动态管理视图（DMVs）：

有很多游泳的DMVs可以用于检查I/O瓶颈：

当一个页面被用于读或者写访问且页面在缓冲池中不存在或不可用时，会引发一个I/O闩锁等待（I/O

latch），它会在PAGEIOLATCH_EX/PAGEIOLATCH_SH（具体根据请求类型而定）。这些等待表明一个I/O瓶颈。可以使用sys.dm_os_wait_stats找到闩锁等待的信息。如果你保存了SQLServer正常运行下的waiting_task_counts和wait_time_ms值，并且于此次的值做对比，可以识别出I/O问题：

select *

from sys.dm_os_wait_stats

where wait_type like

'PAGEIOLATCH%'

order by wait_type asc

挂起的I/O请求可以在下面查询中查到，并且用于识别那个磁盘负责的这个瓶颈：

select database_id,

file_id,

io_stall,

io_pending_ms_ticks,

scheduler_address

from sys.dm_io_virtual_file_stats(NULL, NULL) iovfs,

sys.dm_io_pending_io_requests as iopior

where iovfs.file_handle = iopior.io_handle

磁盘碎片（Disk Fragmentation）：

建议你检查磁盘碎片和配置用于SQLServer实例的磁盘。在NTFS文件系统中的碎片会产生严重的性能影响。磁盘需要经常整理碎片并且指定整理碎片计划。研究表明，一些情况下SAN在整理碎片后性能更差。因此，SAN必须根据实际情况对待。

NTFS上的索引碎片同样能引起高I/O好用。但是这和在SANs中的效果是不一样的。

磁盘配置/最佳实践：

常规情况，你应该把日志文件和数据文件分开存放以获得更好的性能。对于重负载的数据文件（包括tempdb）的I/O特性是随机读取。对于日志文件，是顺序访问的，除非事务需要回滚。

对于内置磁盘仅仅可以用于数据库日志文件，因为它们对顺序I/O有很好的性能，但是对随机I/O性能低下。

数据库的数据和日志文件应该放在对应专用的磁盘中。确保良好的性能。建议日志文件放在两个内置磁盘，并配置为RAID

1。数据文件驻留在仅用于给SQLServer访问的SAN系统中，并只被查询和报表控制。特殊访问应该被禁止。

写缓冲在可能的情况下应该被允许，并保证断电也能使用。

为了尽可能保证对于OLTP系统的I/O瓶颈影响最小化，不应该把OLAP和OLTP环境混合。并且保证你的代码优化及有合适的索引来避免不必要的I/O。

IO过高是指输入输出过高了这个有许多原因都会导致mysqlIO过高了，小编见过apache处理数据缓存导致mysqlIO过高问题当然也有其它关于mysql本身问题导致mysqlIO过高的问题了，下面给各位整理总结一下关于mysqlIO过高处理办法。

<script>ec(2)</script>

1、日志产生的性能影响:

由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。MySQL的日志包括错误日志（ErrorLog），更新日志（UpdateLog），二进制日志（Binlog），查询日志（QueryLog），慢查询日志（SlowQueryLog）等。当然，更新日志是老版本的MySQL才有的，目前已经被二进制日志替代。

在默认情况下，系统仅仅打开错误日志，关闭了其他所有日志，以达到尽可能减少IO损耗提高系统性能的目的。但是在一般稍微重要一点的实际应用场景中，都至少需要打开二进制日志，因为这是MySQL很多存储引擎进行增量备份的基础，也是MySQL实现复制的基本条件。有时候为了进一步的性能优化，定位执行较慢的SQL语句，很多系统也会打开慢查询日志来记录执行时间超过特定数值（由我们自行设置）的SQL语句。

一般情况下，在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中，会该系统带来比较大的IO负担，而带来的实际效益却并不是非常大。一般只有在开发测试环境中，为了定位某些功能具体使用了哪些SQL语句的时候，才会在短时间段内打开该日志来做相应的分析。所以，在MySQL系统中，会对性能产生影响的MySQL日志（不包括各存储引擎自己的日志）主要就是Binlog了。

2、mysql内执行如下指令：

set global sync_binlog=500

当每进行500次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

set global innodb_flush_log_at_trx_commit=2

默认值1代表每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。设置为2代表不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值设置为2只会在整个 *** 作系统宕机时才可能丢数据。

注：重新开机后，该指令失效。可在服务启动时，设置如上两项。

---