记录：最近一次线上磁盘使用出现毛刺的分析过程

  最近收到一封邮件，对于线上磁盘使用出现毛刺的分析。中间的分析过程不错，记录下来自己的一些理解，便于后期翻看，也当成是献给即将离开这个行业的我......

   话说某天，磁盘使用的监控出现多个毛刺，每秒读的大小为20M/S,造成的影响就是响应时间慢，用户体验不好。于是开始了分析的过程，通过查看毛刺出现点的web server日志，发现这个时候多是在处理查询的请求，于是开始进一步探索这个时候的查询都分别是对哪些表，什么动作行为的查询？查看得知，此时最多的查询请求是对我们item表--记录当前资源信息的表的查询，于是，想到，对表的查询，速度慢，原因是啥呢？索引？数据量大？分区，分表不合理？于是，对该表的信息进行查询，发现该表当前存在13W条左右的数据，占据的磁盘大小为4G+，相当于每一条数据占据的大小为32K，那么做一次全表扫描，，，，，，，这个动作造成的磁盘的IO的确很惊人。通过对DB此时查询执行的sql语句进行分析，进行查询的条件多没建索引，于是尝试建立索引（考虑了该类索引对应的字段内容是不是会经常进行修改，字段类型是不是适合建立索引等）。这些动作做完之后，回归该问题，发现比之前有所改进，但是毛刺还是不理想，于是开始分析，发现我们的环境里面还存在一个情况，就是虽然我们做了上面的操作：合理的建立了索引、将查询的数据分批次执行（不将13w的数据一次性全表扫描），但是环境里面出现多次对item表操作的动作，为什么呢？还是查看日志，发现我们环境里有一台机器不知道为什么，每半分钟就从item表里面拉5次数据，之前这个机器是用来做缓存的，可能当时没有考虑到这样频繁拉到带来的影响，现在已经有了新的替代方案，做了nginx的代理缓存和web缓存，这一层对于db数据的缓存也用了相应的技术解决，于是申请停掉该机器的服务，再次回归，问题回归合理值。读从20M/s回归到0.2M/S。

  恩，其实有时候感觉，看起来很复杂，很棘手的事情，如果能够理清楚了思路，弄清楚了该怎么做，然后下手，这样的话就会层层递进，享受过程，否则就是煎熬