云服务器内容精选

  • 解决方案 随着业务数据的增加,原来申请的数据库磁盘容量可能会不足,建议用户扩容磁盘空间,确保磁盘空间足够。 如果原有规格的磁盘已是最大,请先升级规格。 云盘实例可以设置存储空间自动扩容,在实例存储空间达到阈值时,会触发自动扩容。 针对数据空间过大,可以删除无用的历史表数据。 如果实例变为只读状态,您需要先联系客服解除只读状态;如果实例非只读状态,则可以直接执行删除操作。 查看物理文件大小Top50库表,识别可以删除的历史表数据,具体操作请参见容量预估。 可在业务低峰期对碎片率高的表执行optimize优化,以便释放空间: 清理整张表使用DROP或TRUNCATE操作;删除部分数据,使用DELETE操作,如果是执行DELETE操作,需要使用OPTIMIZE TABLE来释放空间。 如果是RDS for MySQL Binlog日志文件占用过多,可以清理本地Binlog日志,来释放磁盘空间。 针对大量排序查询导致的临时文件过大,建议优化SQL查询。 查询数据库慢SQL和Top SQL,分析数据量大,行数多,响应时间长的SQL语句,并进行优化。 您还可以订阅实例健康日报来获取SQL及性能分析结果,包括慢SQL分析、全量SQL分析、性能 & 磁盘分析、性能指标趋势图,当发生风险点时及时收到诊断报告。 具体操作请参见诊断日报。
  • 原因分析 查看内存利用率监控指标,实例的内存使用率在16:30左右率突增,触发OOM后实例重启,内存使用率骤降。 图1 内存利用率 查看该时间段慢SQL数监控指标,确认该时间段慢SQL数量突增。 图2 慢SQL数 查看磁盘吞吐相关指标,发现磁盘此时有大量读写操作。 图3 磁盘吞吐 分析对应时间点的慢日志记录,该时间点有大量的多值批量插入语句,该插入方式会导致每个会话申请较多的SESSION级内存,并发高,很容易引起实例OOM。 图4 慢日志
  • 解决方案 针对多值插入方式引起的OOM,建议减少单次插入数据量,分多次插入,且及时断开重连会话以释放内存。可执行show full processlist查看是否有明显占用内存高的会话。 合理设置SESSION级内存参数大小,可大体根据全局内存+会话级内存*最大会话数来预估可能最大的内存。注意开启“performance_schema”也会带来内存开销。 升级实例规格,将内存利用率维持在合理范围,防止业务突增导致实例OOM。
  • GaussDB (for MySQL)内存说明 GaussDB(for MySQL)的内存大体可以分为GLOBAL级的共享内存和SESSION级的私有内存两部分: 共享内存是实例创建时根据参数即分配的内存空间,并且是所有连接共享的。 私有内存用于每个连接到GaussDB(for MySQL)服务器时才分配各自的缓存,且只有断开连接才会释放。 低效的SQL语句或数据库参数设置不当都可能会导致内存利用率升高,遇到突发业务高峰时,可能会导致云数据库内存OOM(Out Of Memory)。
  • 解决方案 建议新上业务时,提前对关键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下降到正常水平,业务恢复。
  • 内存使用率高的排查思路 以下排查思路根据原因的出现概率进行排序,建议您从高频率原因往低频率原因排查,从而帮助您快速找到问题的原因。 如果解决完某个可能原因仍未解决问题,请继续排查其他可能原因。 图1 内存使用率高的排查思路 序号 可能原因 解决方案 1 内存相关参数设置不合理。 请参见原因一:内存相关参数设置不合理。 2 存在大量消耗内存的查询语句。 请参见原因二:存在大量消耗内存的查询语句。 3 开启了消耗内存的特性。 请参见原因三:开启了消耗内存的特性。
  • 原因三:开启了消耗内存的特性 部分特性开启会占用一定的内存空间。例如对小规格实例(如:2U4GB),开启performance_schema会带来一定的内存开销,可能会导致内存占用比例明显增大。 针对上述原因,您可以采取以下处理措施: 排查是否开启了消耗内存的特性,如performance_schema、plan cache、ptrc等。根据实际情况,考虑是否需要关闭相应特性。 结合业务情况扩大实例规格。
  • 原因一:内存相关参数设置不合理 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。 结合业务情况扩大实例规格。
  • 原因分析 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; 通过审计日志或慢日志,检查是否存在大事务一次性插入大量数据。