云服务器内容精选

  • RDS for MySQL内存使用率高的问题处理 对于用户核心业务相关的库 请扩容实例规格,具体请参见变更实例的CPU内存规格。 对于非用户核心业务相关的库 查看本地计算机的内存使用率,如果使用率曲线持续平缓,则无需处理。 对于用户核心业务相关但是数据库规格配置很高的库 在业务低峰期,将数据库参数“performance_schema”的值调整为“OFF”,对于RDS for MySQL 5.6及以下版本,需要重启数据库才能生效。 通过智能DBA助手查看实例的内存使用情况,具体请参见查看实例性能指标。 如果实例的内存使用率仍持续保持较高: 请扩容实例规格。 调整数据库参数“innodb_buffer_pool_size”的值。参数建议值见表1,实际可修改的取值范围以RDS界面为准。 表1 不同内存规格对应的参数建议值 内存(GB) 5.6建议值 5.7建议值 8.0建议值 2 536,870,912 Byte(512 MB) 536,870,912 Byte(512 MB) 536,870,912 Byte(512 MB) 4 1,073,741,824 Byte(1 GB) 1,073,741,824 Byte(1 GB) 1,073,741,824 Byte(1 GB) 8 4,294,967,296 Byte(4 GB) 4,294,967,296 Byte(4 GB) 5,368,709,120 Byte(5 GB) 16 8,589,934,592 Byte(8 GB) 8,589,934,592 Byte(8 GB) 9,663,676,416 Byte(9 GB) 32 22,548,578,304 Byte(21 GB) 22,548,578,304 Byte(21 GB) 21,474,836,480 Byte(20 GB) 64 47,244,640,256 Byte(44 GB) 47,244,640,256 Byte(44 GB) 47,244,640,256 Byte(44 GB) 128 96,636,764,160 Byte(90 GB) 94,489,280,512 Byte(88 GB) 94,489,280,512 Byte(88 GB) 192 146,028,888,064 Byte(136 GB) 146,028,888,064 Byte(136 GB) 146,028,888,064 Byte(136 GB) 256 193,273,528,320 Byte(180 GB) 193,273,528,320 Byte(180 GB) 193,273,528,320 Byte(180 GB) 384 298,500,227,072 Byte(278 GB) 300,647,710,720 Byte(280 GB) 300,647,710,720 Byte(280 GB) 512 412,316,860,416 Byte(384 GB) 412,316,860,416 Byte(384 GB) 412,316,860,416 Byte(384 GB) 768 618,475,290,624 Byte(576 GB) 618,475,290,624 Byte(576 GB) 618,475,290,624 Byte(576 GB) 1024 824,633,720,832 Byte(768 GB) 824,633,720,832 Byte(768 GB) 824,633,720,832 Byte(768 GB) 请根据业务实际情况,调整参数“innodb_buffer_pool_size”的值。 MySQL本身具有内存动态平衡机制,内存使用率在90%以下您可无需关注,同时建议内存使用率告警阈值设置不低于90%。 在业务运行中缓冲池内存会逐渐增大至“innodb_buffer_pool_size”的值,可通过监控指标“缓冲池利用率”查看缓冲池内存的增长趋势。 RDS for MySQL的内存分配可划分为Engine层与Server层。 Engine层的内存包括InnoDB Buffer Pool、Log Buffer、Full Text Index Cache,其中InnoDB Buffer Pool为常驻内存,占用内存较大。 InnoDB缓冲池是一个内存区域,用于保存InnoDB表、索引和其他辅助缓冲区的缓存数据,可以通过参数“innodb_buffer_pool_size”定义缓冲池大小。 Server层的内存占用较高的包括Thread Cache、BinLog Cache、Sort Buffer、Read Buffer、Join Buffer等线程缓存,这类缓存非常驻内存,往往会随着连接关闭而释放。 以上内存的分配导致RDS for MySQ L实例 运行时内存使用率在80%左右。 父主题: 常见性能问题
  • 解决方法一 分析慢SQL日志以及CPU使用率指标来定位效率低的查询,再优化查询效率低的语句。 查看慢SQL日志来确定是否存在运行缓慢的SQL查询以及各个查询的性能特征(如果有),从而定位查询运行缓慢的原因。 查询RDS for MySQL日志,请参见查询慢SQL。 查看实例的CPU使用率指标,协助定位问题。 请参见查看性能指标。 创建只读实例专门负责查询。减轻主实例负载,分担数据库压力。 多表关联查询时,关联字段要加上索引。 尽量避免用select*语句进行全表扫描,可以指定字段或者添加where条件。
  • 实例瓶颈 原因及现象 实例到达瓶颈的原因一般有如下几种: 业务量持续增长而没有扩容。 硬件老化,性能有损耗。 数据量一直增加,数据结构也有变化,导致原来不慢的SQL变成慢SQL。 您可以在控制台的查看实例的资源使用情况。如果资源使用率各项指标都接近100%,可能是实例到达了瓶颈。具体操作,请参见查看实例性能指标。 解决方案 确认实例到达瓶颈后,建议升级实例规格。具体操作,请参见变更实例的CPU和内存规格。
  • 定时任务 原因及现象 如果实例负载随时间有规律性变化,可能是存在定时任务。 您可以在控制台查看实例的Delete语句执行频率、Insert语句执行频率、Insert_Select语句执行频率、Replace语句执行频率、Replace_Selection语句执行频率、Select语句执行频率、Update语句执行频率等指标,判断是否有规律性变化。具体操作,请参见查看监控指标。 解决方案 调整定时任务的执行时间,建议在业务低峰期执行,并修改可维护时间段为业务低峰期。具体操作,请参见设置可维护时间段。