优化 - Mysql导致服务器的OOM

概述

优化了一次程序处理不当导致的CPU的一次爆机行为，当然，这和服务器的配置低也有着密不可分的关系，简单的逻辑学告诉我们，要找到真正的问题，进行解决，CPU爆机的关键点在于前后端两个方面，下面针对具体的问题，进行分析和解决。

定位问题

看监控的图表，CPU已经达到了100%，但是内存的使用曲线很平缓(也说明内存可以有更大的利用空间)，出现这种情况，大概率是代码或者循环中产生的问题，服务器进程处理产生多条阻塞，大量的请求处理积压，导致的崩溃。

CPU曲线中从100%降到底，产生这种情况的原因是系统自身的保护机制，当系统产生爆机，触发系统中的主监测程序，kill掉当前进程，恢复服务器其他进程的正常使用。

服务端Join影响了性能

顺着代码分析，找到了影响性能的几个关键点，服务端导致性能慢的关键点在于18w的用户表分别和26w的评估记录表、88w的训练动作表、19w的用户签到表进行Join所产生的进程处理缓慢，下面我们用explan工具分别看一下所在的性能差别。

Mysql主要看到的是type和rows的指标，下面的语句告诉我们是全量(all)扫描了179223条数据，优化到了range级别的349条。

+----+-------------+-------+------+-------------------+---------+---------+----------+--------+----------------------------------------------+
| id | select_type | table | type | possible_keys     | key     | key_len | ref      | rows   | Extra                                        |
+----+-------------+-------+------+-------------------+---------+---------+----------+--------+----------------------------------------------+
|  1 | SIMPLE      | u     | ALL  | PRIMARY,origin_id | NULL    | NULL    | NULL     | 179223 | Using where; Using temporary; Using filesort |
|  1 | SIMPLE      | a     | ref  | user_id           | user_id | 4       | cc.u.uid |      1 | Using where                                  |
+----+-------------+-------+------+-------------------+---------+---------+----------+--------+----------------------------------------------+

+----+-------------+---------------+-------+---------------+---------+---------+------+------+-----------------------------+
| id | select_type | table         | type  | possible_keys | key     | key_len | ref  | rows | Extra                       |
+----+-------------+---------------+-------+---------------+---------+---------+------+------+-----------------------------+
|  1 | SIMPLE      | cc_assessment | range | user_id       | user_id | 4       | NULL |  349 | Using where; Using filesort |
+----+-------------+---------------+-------+---------------+---------+---------+------+------+-----------------------------+

和上面的问题差不多，都是全量检索了80w+数据,优化后range方式检索了1.2w+条数据。

+----+-------------+-------+--------+-------------------+---------+---------+--------------+--------+-------------+
| id | select_type | table | type   | possible_keys     | key     | key_len | ref          | rows   | Extra       |
+----+-------------+-------+--------+-------------------+---------+---------+--------------+--------+-------------+
|  1 | SIMPLE      | t     | ALL    | user_id           | NULL    | NULL    | NULL         | 881949 | Using where |
|  1 | SIMPLE      | u     | eq_ref | PRIMARY,origin_id | PRIMARY | 4       | cc.t.user_id |      1 | Using where |
+----+-------------+-------+--------+-------------------+---------+---------+--------------+--------+-------------+

+----+-------------+-----------------+-------+---------------+---------+---------+------+-------+-------------+
| id | select_type | table           | type  | possible_keys | key     | key_len | ref  | rows  | Extra       |
+----+-------------+-----------------+-------+---------------+---------+---------+------+-------+-------------+
|  1 | SIMPLE      | cc_train_action | range | user_id       | user_id | 4       | NULL | 12979 | Using where |
+----+-------------+-----------------+-------+---------------+---------+---------+------+-------+-------------+

Mysql以page为基础，采用Be+Tree的结构存储在硬盘中，对硬盘的I/O传输效率非常明显和敏感，一般的CPU爆机可能产生的情况就是代码中的循环和递归使用的不当，还有一种可能的情况就是Mysql的Sql使用的不当导致的。

代码字典式拼接

之前的查询写在了循环里，数据多的时候，Mysql需要进行反复的连接、查询、断开影响性能，这个地方也进行了优化。

    $areaList = $this->area_model->get_info(['id' => $areaAllIds], '', '', '', 'id,name');
    $areaNameDict = array_column($areaList, 'name', 'id');
    foreach ($user_infos as $key => $val) {
        //数组拼接
        $user_infos[$key]['province_name'] = isset($areaNameDict[$val['native_province_id']]) ? $areaNameDict[$val['native_province_id']] : '';
    }

大胆使用内存

因为内存的曲线较为平缓，说明内存不是导致问题的关键行为，PHP-FPM的特性在子进程执行结束也会进行释放，所以在进程执行时要保证内存的合理使用，可以一次性的加载数据。

ini_set('memory_limit', '1024M');

前段的定时器

Http的每一次请求，服务器都会对应开启一个进程，进行处理和响应，前段的小伙伴使用定时器每分钟进行一次请求，导致的直接结果就是服务器进入了多条等待导致的阻塞，直接到CPU打满。

和前端的小伙伴沟通和协商，30分钟请求一次服务，就变的平稳和丝滑了，至此这个问题告一段落了。

最后

技术人更高维度是要学会合作、沟通和理解，协商的解决问题，Tcp、Http、Udp都是协议，都是请求和响应的双方达成一致，进行的通信。

当然，要保持良好的学习习惯和修炼技能的纯度，也是必不可少的，毕竟，未来永远充满了不确定性。