您现在的位置是:首页 > 技术教程 正文

优化 - Mysql导致服务器的OOM

admin 阅读: 2024-04-30
后台-插件-广告管理-内容页头部广告(手机)

概述

优化了一次程序处理不当导致的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都是协议,都是请求和响应的双方达成一致,进行的通信。

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

标签:
声明

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

在线投稿:投稿 站长QQ:1888636

后台-插件-广告管理-内容页尾部广告(手机)
关注我们

扫一扫关注我们,了解最新精彩内容

搜索
排行榜