云服务器内容精选

  • 内存使用率高的排查思路 以下排查思路根据原因的出现概率进行排序,建议您从高频率原因往低频率原因排查,从而帮助您快速找到问题的原因。 如果解决完某个可能原因仍未解决问题,请继续排查其他可能原因。 图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; 通过审计日志或慢日志,检查是否存在大事务一次性插入大量数据。