win7出现io错误-(win7发生异常io错误)

所以用top或iostat、iotop命令去分析系统的指标，用iotop看io使用率最高的进程的时候，发现了几个比较异常的点，可以看体育到ffmpeg有两个进程io使用率都飙到很高了，还有一个java进程使用率也是飙到很高，所以看到这一步之后，已经能够完全的确定是由于磁盘io使用率过高导致了mysql的执行数据受到了影响，在正常服务器上面的io使用率在大多数时候都会在百分之几这样一个状态，不可能像持续的两三个进程跑在了百分之七八十或者接近100%这种状态，所以在发现了这种问题进程之后，经过确认发现这两个进程其实是一个视屏转码的一个功能，然后测试环境是可以暂时关闭这种转码功能的，所以对这个转码功能进行了关闭，关闭之后，mysql就再也没有报警了。

其实在之前看抓包的时候，看到mysql返回超时的时候，其实就应该立即去看系统io这种硬件指标了，这里由于是测试环境，我还特意看了一下go-mysql-driver的代码做进一步的确认是否是超时导致的invalid conn异常，在整个排查问题的过程之后，有了如下反思：

1、测试环境的监控体系还不够完善，没有监控界面不然能够一眼就看出磁盘io的异常

2、回归到应用层看代码的时机在整个排查问题过程当中是处于一个比较靠后的状态，最主要的原因是因为我被invalid conn这个错误码所迷惑了，如果这个时候报timeout超时的错误，可能我会立马去看mysql执行时长这么一个问题，而不会去定位到可能是由于mysql客户端的一个连接无效或者是网络情况这种导致无效连接的情况

3、然后最重要的一点是我在排查问题当中忽略了一个点，当时这个报警，它是一个频繁报警的状态，但不是每时每刻都在报，最开始在碰到这个问题的时候，其实也是先有用top还有iostat这种工具去分析磁盘的一个占用情况，但是由于那段时间内指标是没有异常的，加上这个报错又是一个无效连接的报错，所以想当然的认为，这个问题应该是在网络连接上出了问题或者是mysql客户端这个连接的确是一个无效的连接，后来进行了抓包分析，所以在看这种偶发性的异常，这种报警的时候，应该持续性的去观察这个系统指标，我当时只看了十几秒钟觉得没有问题就去分析其他因素了，其实应该是一直持续不断的去看这个系统的硬件指标，直到报警再次出现，然后看报警出现后这些硬件指标会不会有异常情况，这也是我在整个排查问题的过程当中犯的一个最严重错误。

测试环境开启慢日志

set global slow_query_log=1

查看开启状态

show variables like 'show_query%'

开启了测试环境的慢日志,便于之后再碰到这种超时的情况，能够直接通过慢日志去看mysql执行sql的时长，而不用再去抓包进行分析。

开启慢日志的命令set global可以给mysql的一些变量属性赋值，但是这个值是会在mysql重启之后失效的，要想不失效，要去改mysql的cnf的配置文件，改完之后，可以通过show variables like命令去看一下慢日志是否开启并且慢日志的记录文件也会输出出来。