云服务器内容精选
-
场景1 慢查询导致CPU升高 问题原因：大量慢SQL导致实例CPU升高，需要优化相应的慢SQL。 排查思路： 查看CPU使用率和慢日志个数统计监控指标。 如果慢日志个数很多，且与CPU曲线吻合，可以确定是慢SQL导致CPU升高。 如果慢日志个数不多，但与CPU使用率基本一致，进一步查看行读取速率指标是否与CPU曲线吻合。 如果吻合，说明是少量慢SQL访问大量行数据导致CPU升高：由于这些慢SQL查询执行效率低，为获得预期的结果需要访问大量的数据导致平均IO高，因此在QPS并不高的情况下（例如网站访问量不大），也会导致实例的CPU使用率偏高。 解决方案： 根据CPU使用率过高的时间点，查看对应时间段的慢日志信息。 重点关注扫描行数、返回结果行数超过百万级别的慢查询，以及锁等待时间长的慢查询。 慢查询用户可自行分析，或使用数据管理服务(DAS)的SQL诊断工具对慢查询语句进行诊断。 使用数据库代理+只读节点架构，实现读写分离。只读节点专门负责查询，减轻主库压力，提升数据库吞吐能力，详见读写分离简介。 通过分析数据库执行中的会话来定位执行效率低的SQL。 连接数据库。 执行show full processlist;。 分析执行时间长、运行状态为Sending data、Copying to tmp table、Copying to tmp table on disk、Sorting result、Using filesort的会话，均可能存在性能问题，通过会话来分析其正在执行的SQL。
-
场景2 连接和QPS升高导致CPU上升 问题原因：业务请求增高导致实例CPU升高，需要从业务侧分析请求变化的原因。 排查思路： 查看QPS、当前活跃连接数、数据库总连接数、CPU使用率监控指标是否吻合。 QPS的含义是每秒查询数，QPS和当前活跃连接数同时上升，且QPS和CPU使用率曲线变化吻合，可以确定是业务请求增高导致CPU上升，如下图： 该场景下，SQL语句一般比较简单，执行效率也高，数据库侧优化余地小，需要从业务源头优化。 解决方案： 单纯的QPS高导致CPU使用率过高，往往出现在实例规格较小的情况下，建议升级实例CPU规格。 优化慢查询，优化方法参照场景1 慢查询导致CPU升高的解决方案。若优化慢查询后效果不明显，建议升级实例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”。
-
原因分析 查看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下降到正常水平，业务恢复。
-
解决方案 随着业务数据的增加，原来申请的数据库磁盘容量可能会不足，建议用户扩容磁盘空间，确保磁盘空间足够。 如果原有规格的磁盘已是最大，请先升级规格。 云盘实例可以设置存储空间自动扩容，在实例存储空间达到阈值时，会触发自动扩容。 针对数据空间过大，可以删除无用的历史表数据。 如果实例变为只读状态，您需要先联系客服解除只读状态；如果实例非只读状态，则可以直接执行删除操作。 查看物理文件大小Top50库表，识别可以删除的历史表数据，具体操作请参见容量预估。 可在业务低峰期对碎片率高的表执行optimize优化，以便释放空间： 清理整张表使用DROP或TRUNCATE操作；删除部分数据，使用DELETE操作，如果是执行DELETE操作，需要使用OPTIMIZE TABLE来释放空间。 如果是RDS for MySQL Binlog日志文件占用过多，可以清理本地Binlog日志，来释放磁盘空间。 针对大量排序查询导致的临时文件过大，建议优化SQL查询。 查询数据库慢SQL和Top SQL，分析数据量大，行数多，响应时间长的SQL语句，并进行优化。 您还可以订阅实例健康日报来获取SQL及性能分析结果，包括慢SQL分析、全量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证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
