云服务器内容精选
-
原因分析 查看CPU使用率监控指标,发现在16:08分左右实例的CPU使用率开始飙升到100%,且一直持续在高位线。 图1 CPU使用率 查看QPS、慢SQL数以及活跃连接数监控指标,发现在16:08分左右QPS突增,活跃连接数上涨,最终业务侧有较多的慢SQL产生。 图2 QPS 图3 活跃连接数 图4 慢SQL数 分析业务类型,查看16:08分前左右InnoDB的逻辑读速率有突增,且与慢SQL的速率趋势相似。 图5 InnoDB逻辑读速率 登录实例,查看实话会话,发现大量会话在执行SELECT COUNT(*)。 EXPLAIN确认该SQL的执行计划,发现走全表扫描且单条扫描行数在35万+,其并未走索引。 进一步查看该表的表结构,发现该表仅对字段“is_deleted”添加了一个索引“IDX_XX_USERID”,因此上述查询无索引可选。建议业务侧给字段“idx_user_id”新增索引后,实例在16:37分左右CPU下降到正常水平,业务恢复。
-
解决方案 建议新上业务时,提前对关键SQL通过EXPLAIN、SQL诊断等工具进行执行计划分析,根据优化建议添加索引,避免全表扫描。 业务量突增的高并发造成CPU占用率高,可以考虑升级实例规格或使用独享型资源避免出现CPU资源争抢,或者创建只读实例进行读写分离减轻主实例负载。 通过show processlist查看当前会话信息来辅助定位:运行状态为Sending data、Copying to tmp table、Copying to tmp table on disk、Sorting result、Using filesort的查询会话可能均包含性能问题。 应急场景可以借助SQL限流以及KILL会话功能来临时kill规避“烂SQL”。
-
原因一:内存相关参数设置不合理 GaussDB (for MySQL)中存在许多与内存相关的参数,表1-2列举了部分参数。当这些参数设置不合理时,可能会导致内存利用率过高。 表1 内存相关的参数 序号 参数名称 参数描述 1 innodb_buffer_pool_size InnoDB buffer pool大小。Global级别,容量不会缩减。 2 table_open_cache 表缓存的最大打开表数量。Global级别,当open_tables等于table_open_cache且opened_tables在不断增大时,可以适当调大table_open_cache。 3 sort_buffer_size 排序buffer大小。Session级别,调大值可以提高排序操作的性能,过大可能会导致内存不足。 针对上述原因,您可以采取以下处理措施: 内存相关参数值尽量使用默认值。 根据实际情况,合理配置相关参数。
-
原因二:存在大量消耗内存的查询语句 一些涉及到排序或者分组的语句会使用到临时表,当并发量过大、查询中间结果过多时,会导致临时表占用过多内存,出现实例OOM风险。 针对上述原因,您可采取以下处理措施: 可以使用EXPLAIN命令检查Extra列是否显示Using Temporary,确定语句是否会用到临时表,对于使用临时表的SQL语句进一步分析查询计划和重写查询语句,尽量减少临时表的使用。表2列举了部分需要使用临时表的SQL语句。 表2 需要使用临时表的场景 序号 场景 1 UNION查询。 2 用到TEMPTABLE算法或者是UNION查询中的视图。 3 ORDER BY和GROUP BY的子句不一样时。 4 表连接中,ORDER BY的列不是驱动表中的。 5 DISTINCT查询并且加上ORDER BY时。 6 SQL中用到SQL_SMALL_RESULT修饰符的查询。 7 FROM中的子查询(派生表)。 8 子查询或者SEMI-JOIN时创建的表。 9 评估多表UPDATE语句。 10 评估GROUP_CONCAT()或COUNT(DISTINCT)表达式计算。 创建合适的索引,减小查询结果的数量,来控制临时表使用的内存。 使用LIMIT子句限制查询结果的数量,避免一次性返回大量数据。 对于需要大量使用内存的SQL语句,减小并发度,避免内存突增导致实例OOM。 结合业务情况扩大实例规格。
-
内存使用率高的排查思路 以下排查思路根据原因的出现概率进行排序,建议您从高频率原因往低频率原因排查,从而帮助您快速找到问题的原因。 如果解决完某个可能原因仍未解决问题,请继续排查其他可能原因。 图1 内存使用率高的排查思路 序号 可能原因 解决方案 1 内存相关参数设置不合理。 请参见原因一:内存相关参数设置不合理。 2 存在大量消耗内存的查询语句。 请参见原因二:存在大量消耗内存的查询语句。 3 开启了消耗内存的特性。 请参见原因三:开启了消耗内存的特性。
-
原因三:开启了消耗内存的特性 部分特性开启会占用一定的内存空间。例如对小规格实例(如:2U4GB),开启performance_schema会带来一定的内存开销,可能会导致内存占用比例明显增大。 针对上述原因,您可以采取以下处理措施: 排查是否开启了消耗内存的特性,如performance_schema、plan cache、ptrc等。根据实际情况,考虑是否需要关闭相应特性。 结合业务情况扩大实例规格。
-
原因分析 ibdata1是InnoDB的系统表空间,主要包括: 多版本并行事务控制(MVCC)相关的数据:undolog Innodb表的元数据,如数据字典 change buffer/double write buffer等 其中,undolog是ibdata1增大的最主要原因,而undolog过大的主要原因如下: 长事务久未提交,导致undolog purge被阻塞。 写入并发太大生成大量的undolog,purge速度跟不上。 通过show engine innodb status中的“History list length”可以查看未被purge的undolog数量。
-
怎么解决查询运行缓慢的问题 通过查看慢SQL日志来确定是否存在运行缓慢的SQL查询以及各个查询的性能特征(如果有),从而定位查询运行缓慢的原因。 查询RDS for MySQL日志,请参见查询慢日志。 查询RDS for PostgreSQL日志,请参见查看错误日志。 云数据库 RDS for SQL Server可以通过查询DMV视图,从而定位查询运行缓慢的原因,有关使用DMV的信息,请参见官网信息。 查看实例的CPU使用率指标,协助定位问题。 请参见查看性能指标。 创建只读实例专门负责查询。减轻主实例负载,分担数据库压力。 多表关联查询时,关联字段要加上索引。 尽量避免用select*语句进行全表扫描,可以指定字段或者添加where条件。 父主题: 性能资源类
-
原因分析 执行以下语句,查看当前事务的运行时间,根据运行时间定位长事务。 Select t.*,to_seconds(now())-to_seconds(t.trx_started) idle_time from INFORMATION_SCHEMA.INNODB_TRX t; 执行语句后返回的参数“trx_query”是当前事务执行的SQL语句,如果参数值为NULL,则表示当前事务在等待状态下不执行SQL。 具体操作请参考MySQL官方文档。
-
原因分析 由于MVCC机制,MySQL更新表中数据时会生成undo日志,会占用磁盘空间;所有会话的相关事务提交或回滚后,undo日志会被清理,导致磁盘空间下降。 当存在长事务时,长事务只要不提交,其他会话对相关表更新生成的undo就无法清理,导致磁盘空间一直上涨。 排查思路: 通过如下语句,检查是否有长时间不提交事务。 select t.*,to_seconds(now())-to_seconds(t.trx_started) idle_time from INFORMATION_SCHEMA.INNODB_TRX t \G; 通过审计日志或慢日志,检查是否存在大事务一次性插入大量数据。
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格