一次数据库上云迁移性能下降的排查

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

背景介绍:

某客户目前正在将本地的业务系统迁移上云,测试过程中发现后台运营系统,在rds上运行时间明显要比线下PC上自建数据库运行时间要慢1倍,导致客户系统割接延期的风险。用户线下一台PC服务器的性能居然还比顶配的RDS跑的快,这让用户对RDS的性能产生了质疑,需要立刻调查原因。

问题分析:

通常SQL的执行时间在同等数据量的情况下发生变化主要有以下一些场景,其主要原因是由于优化器生成的执行计划发生了改变,这样则会导致SQL的执行时间发生较大的变化,当然可能变慢,也有可能变快,变慢是我们不想看到的场景:

1、  数据库跨平台迁移(PG->MySQL、ORALCE->MySQL)

多次遇到数据库从Oracle迁移到MySQL后,由于MySQL的优化器在低版本(5.6以下版本)对子查询的优化较差,导致系统迁移到MySQL后,系统中大量的子查询SQL堆积一直没有返回,导致数据库连接数跑满,数据库的CPU 100%。

2、  跨版本升级(MySQL:5.1->5.5、5.5->5.6)

也曾经遇到由于数据库在版本(5.5->5.6)升级后原先正常执行的SQL变得奇慢务必,导致整个升级迁移不得不回退,其主要原因高版本(5.6)的优化器策略与低版本(5.5)不同,导致了SQL执行计划发生变化,进而导致了sql的性能急剧下降;

问题排查:

1.确定优化器版本:

先确认用户本地的数据库版本和RDS的版本是否是一致的:用户本地的版本5.6.25,RDS的版本5.6.16,所以在大版本上没有太大的区别;由于在小版本上有一些差异,需要确认一下优化器中支持的优化类型是否一致,发现优化类型没有区别:

OPTIMIZER_SWITCH:

index_merge=on,index_merge_union=on,index_merge_sort_union=on,

index_merge_intersection=on,engine_condition_pushdown=on,

index_condition_pushdown=on,mrr=on,mrr_cost_based=on,

block_nested_loop=on,batched_key_access=off,materialization=on,

semijoin=on,loosescan=on,firstmatch=on,

subquery_materialization_cost_based=on,use_index_extensions=on

2.确定SQL执行计划:

既然优化器的版本是一致的,所以接下来在确认以下SQL的执行计划是否一致,由于这些SQL都是后台运行统计分析使用,所以都非常的复杂,有可能某些表的统计信息不准确,则可能导致执行计划发生变化。对比用户和RDS两边的SQL执行计划,并没有发现执行计划发生了特别大的变化,一些小表的执行顺序发生了一些变化,不过没有太大的影响,因为执行计划的所涉及总rows没有太大的变化:rows=39900*1*1*140*285*1*1*1*1*1*1*1;

3.确定参数配置:

在优化器以及SQL执行计划上没有太多的进展后,我们又开始关注用户的数据库参数配置与RDS是否有差异,因为RDS的一些性能参数是保持官方默认的配置,是否在这里出了问题,所以将用户本地数据库的配置文件拉出来进行了对比,发现了重大线索,用户的参数文件中特意调大很多会话级别的内存参数,而在RDS这些参数都是默认的配置:

用户配置:

join_buffer_size = 128M

read_rnd_buffer_size = 128M

tmp_table_size = 128M

RDS配置

join_buffer_size = 1M

read_buffer_size = 1M

tmp_table_size =256K

可以看到用户调整的这些会话级别的内存参数,可以帮助每一个查询的中间计算结果尽可能的在内存中完成,避免查询的中间结果落盘导致性能的下降,但由于这些参数都是会话级别的参数,一个查询就会分配对应大小的内存,则会导致数据库的内存消耗非常快,可能会导致数据库出现OOM,当然如果是一些后台执行不是很频繁的查询,通过调整相关的参数,确实可以提升SQL的执行性能。在调整了上述参数后,尤其是tmp_table_size与用户配置一致后大部分的SQL性能与用户本地的持平,该参数用于决定内部内存临时表的最大值,每个线程都要分配(实际起限制作用的是tmp_table_size和max_heap_table_size的最小值),如果内存临时表超出了限制,MySQL就会自动地把它转化为基于磁盘的MyISAM表,优化查询语句的时候,要避免使用临时表,如果实在避免不了的话,要保证这些临时表是存在内存中的。如果需要的话并且你有很多group by语句,并且你有很多内存,增大tmp_table_size(和max_heap_table_size)的值。

4.确定硬件配置:

在解决了大部分查询性能后,还发现还有一些SQL的执时间还是存在一些差异,所以在软件配置上没有太大的斩获后,我们的思路想到了是否是硬件配置出现了问题。由于数据库的内存配置都是比较大的,我们自然而然的想到了CPU的配置是否是一致,对比发现用户本地的PC服务器的CPU主频配置比RDS的CPU主频配置高出了20%,同时使用纯CPU计算的SQL在两边的环境进行压测,压测中也发现用户环境SQL的执行时间是RDS的一倍,所以解决办法就是升级主机的CPU主频配置,或者从业务或者数据库层面对SQL进行优化。

总结:

  1. 本次排查问题的过程中,在SQL执行计划上耗费了较多时间,可以对比执行计划中消耗的rows来判断执行计划是否存在较多的问题;
  2. 参数的不一致是导致此次问题的重要原因,由于有一些SQL不会受限于这些参数的影响,导致没有对这些参数进行深入的测试;
  3. 硬件问题是此次问题没有想到的一个点,所以当性能出现问题后,不仅要对比软件配置,同时也需要关注硬件上的配置是否一致。
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
3天前
|
SQL Oracle 关系型数据库
担心YashanDB异构数据库迁移踩“坑”?听听大咖们怎么说
文章围绕异构数据库迁移展开,探讨了避免数据丢失、保障数据完整性、注意兼容性、提升迁移效率、做好反向演练等问题。包括迁移前完整性检查与备份,YashanDB 从内核设计和配套工具保障数据,对兼容性进行大量测试,通过合理评估和技术手段提升迁移效率,以及处理回退等内容。
|
3天前
|
Oracle 关系型数据库 网络安全
崖山异构数据库迁移利器YMP初体验-Oracle迁移YashanDB
文章是作者小草对崖山异构数据库迁移利器 YMP 的初体验分享,包括背景、YMP 简介、体验环境说明、YMP 部署(含安装前准备、安装、卸载、启动与停止)、数据迁移及遇到的问题与解决过程。重点介绍了 YMP 功能、部署的诸多细节和数据迁移流程,还提到了安装和迁移中遇到的问题及解决办法。
|
3天前
|
SQL 关系型数据库 MySQL
MySQL生产环境迁移至YashanDB数据库深度体验
这篇文章是作者将 MySQL 生产环境迁移至 YashanDB 数据库的深度体验。介绍了 YashanDB 迁移平台 YMP 的产品相关信息、安装步骤、迁移中遇到的各种兼容问题及解决方案,最后总结了迁移体验,包括工具部署和操作特点,也指出功能有优化空间及暂不支持的部分,期待其不断优化。
|
7天前
|
SQL Oracle 关系型数据库
迁移方案详解 | 使用YMP从异构数据库迁移到YashanDB
迁移方案详解 | 使用YMP从异构数据库迁移到YashanDB
|
14天前
|
Cloud Native 关系型数据库 分布式数据库
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
|
15天前
|
Cloud Native 关系型数据库 分布式数据库
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
|
16天前
|
Cloud Native 关系型数据库 分布式数据库
刷新世界纪录!阿里云登顶全球数据库性能及性价比排行榜
阿里云PolarDB云原生数据库在TPC-C测试中登顶全球性能及性价比排行榜。此次突破展示了PolarDB在单核性能、横向扩展及软硬件结合上的创新,标志着中国基础软件的重大成就。
|
16天前
|
Cloud Native 关系型数据库 分布式数据库
世界第一!阿里云PolarDB登顶全球数据库性能及性价比排行榜!
2月26日,阿里云PolarDB在2025开发者大会上登顶全球数据库性能及性价比排行榜。此次突破标志着中国基础软件取得里程碑成就,PolarDB凭借创新的云原生架构,成功应对全球最大规模并发交易峰值,在性能、可扩展性等方面领先全球。
|
17天前
|
数据库
【YashanDB 知识库】误配置 SYSTEM 级别的 STATISTICS_LEVEL 参数为 ALL 导致数据库性能下降
**标题:误配置 SYSTEM 级别的 STATISTICS_LEVEL 参数为 ALL 导致数据库性能下降** **简介:** 数据库性能骤降至正常水平的百分之一,主要表现为大量 free buffer wait 等待事件。原因是系统级别 STATISTICS_LEVEL 被误设为 ALL。解决方法是将其恢复为默认值 TYPICAL,执行命令:`ALTER SYSTEM SET statistics_level='TYPICAL' SCOPE=BOTH;` 以恢复正常性能。
|
17天前
|
SQL 数据建模 BI
【YashanDB 知识库】用 yasldr 配置 Bulkload 模式作单线程迁移 300G 的业务数据到分布式数据库,迁移任务频繁出错
问题描述 详细版本:YashanDB Server Enterprise Edition Release 23.2.4.100 x86_64 6db1237 影响范围: 离线数据迁移场景,影响业务数据入库。 外场将部分 NewCIS 的报表业务放到分布式数据库,验证 SQL 性能水平。 操作系统环境配置: 125G 内存 32C CPU 2T 的 HDD 磁盘 问题出现的步骤/操作: 1、部署崖山分布式数据库 1mm 1cn 3dn 单线启动 yasldr 数据迁移任务,设置 32 线程的 bulk load 模式 2、观察 yasldr.log 是否出现如下错

热门文章

最新文章