ITOO线上问题（一）

    ITOO在线上运行的过程中出现了一些问题，个人觉得很有价值，作此整理，和大家一起分享！

   2018年1月18日全校性思修考试上午分为三场，和其他考试不同的是思修和近代史考试的突出特点有两个：1、思修和近代史是全校性考试，考试的人数多；2、应学校的要求，思修和近代史在考试之前必须首先填写问卷，学生答完问卷后才可进行考试。

   首先，交代一下本次考试出现的现象，第一场考试一切正常，各项监控均显示正常无压力；第二场考试，个别学生出现，“没有在开始周”、“该考生 没有试卷”、“提交答题记录失败”等问题，仅是个别学生出现，刷新一下均恢复正常；第三场考试，大面积出现“没有在考试周”、“该考生没有试卷”、“提交答题记录失败等情况”，且多次刷新无效。

   关于服务器检测，其他服务器均正常，仅是mysql服务器出现问题，本场考试，主备两台服务器均为四核：第一场考试，mysql服务器cpu占用为15%作用；第二场考试，cpu占用率增长为40%~50%；第三场考试cpu占用率持续增长，60%，70%，80%，90%（本次所说的数据均为mysql主服务器监控数据，从机仅有一个进程在同步主的数据，cpu占用率变化较小）

    本次ITOO部署分布情况如下图：

    通过对mysql服务器的监控（top命令），我们发现了mysql服务器cpu占用过高的异常，对此我们马上集中精力，把焦点集中在druid的监控页面上，在这个监控页面上我们可以发现当前正在执行的每一条sql语句，按照时间排序，我们找出了按照时间排序执行较慢几条sql，将执行较慢的sql粘贴到Navicat中，利用mysql的explain命令查看查看是否命中索引（要求数据必须为真实数据，如果数据随便填写表中并没有，则没有办法命中索引），因为找真实数据比较麻烦，而我们的时间又比较紧张，所以我们采取了1、找到慢sql操作的表，找到该表的索引 2、根据sql语句的更新条件来判断是否能命中索引的策略，检查过后发现索引健全。不过意外收获的是，我们发现我们现在用的逆向工程中的某些方法可能存在问题，如根据条件更新实体的方法等。

之后我们采取的措施为：

    1、暂停考试10分钟，并延长考试时间

    2、在暂停考试的时间内，重启mysql服务器

    3、重启mysql后，情况并没改善，前端开启全局备份

    第三场考试结束后，开始排查问题，出现的不正常的现象如下：mysql服务器cpu占用仍非常高，出现这种现象的原因有两个：1、客户端仍然在发请求；2、sql语句的执行发生了堆积，我们已经确认考试结束没有学生在答题，所以只剩下一个原因，也就是第二个。

    首先我们分析了可能发生问题，影响性能的点：1、定时器的执行（定时器要定时统计成绩）2、某些地方索引不健全，随着数据的增多，导致sql执行越来越慢，最终发生了堆积。

    因为一时无法正确定位问题，下午的考试也即将开始，对此我们采取的措施为：

   1、因为学生答题过程主要操作的表为答题记录表，我们对答题记录表中原有的数据进行了迁移，当时大概有34万条数据，这样就保证了下午考试时，学生的答题记录表为空表，以此来提高性能。

   2、停止定时器，避免汇总成绩对考试的影响

   3、重启各个服务（考评、教学等），减少不必要的影响。

   以上各个措施执行完毕后，我们重新抽题，来验证我们采取的措施是否有效果，正是在这个过程中，我们发现了问题：在填写问卷的过程中，通过druid的监控页面我们发现，更新问卷的答题记录的sql执行比较慢，通过对索引的检查，我们发现问卷的答题记录表并没有索引，我们马上按照sql语句中的更新条件对该表添加了索引。

    至此，下午的考试也要开始了，下午考试一切正常，没有发生任何问题。还有一个小插曲就是在考试的过程中，我们不小心点击了一下设计表，刚刚打开，负责mysql监控的人员立刻反应mysql服务器cpu占用突增，我们马上关闭了设计表的窗口，设计表是会进行锁表操作的。