博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【案例】说说time_zone 带来的性能问题
阅读量:5965 次
发布时间:2019-06-19

本文共 2587 字,大约阅读时间需要 8 分钟。

一 背景  
   相信大家对time_zone参数的意义和使用方式并不陌生,MySQL 通过设置 time_zone来控制时区,不过本文从另外一个角度来了解该参数对系统性能的影响。认识到这个问题的起因是因为数据库出现usr cpu 增大,load 上升 ,thread running陡高等现象。还有另外一个同事发现的问题一个应用接口调用分布到不同的机器,但是性能存在差异。
二 分析过程
2.1 timezone的参数设置
我们常用的time_zone 有两种设置方式  SYSTEM  和UTC具体的时区比如+08:00,设置为SYSTEM表示数据库系统的时区和os 系统的时区一致。对于国内而言 我们一般选择东八区也即'+08:00' ,更加具体详细的信息请移步官方手册
 
2.2 性能压测

为了直观表现性能差异,这里使用mysqlslap 对同一个实例进行压测:80个并发会话 执行1000w次 select now()查询,得到不同参数模式下,消耗的时间。

[3306-RW-2Inst@rac1 ~] $mysql -uroot -e 'select @@time_zone' +-------------+| @@time_zone |+-------------+| SYSTEM |+-------------+[3306-RW-2Inst@rac1 ~]$mysqlslap --no-defaults -uroot --create-schema=test -S/u01/my3306/run/mysql.sock --number-of-queries=10000000 --concurrency=80 ' --query=select now()' Benchmark        Average number of seconds to run all queries: 47.706 seconds        Minimum number of seconds to run all queries: 47.706 seconds        Maximum number of seconds to run all queries: 47.706 seconds        Number of clients running queries: 80        Average number of queries per client: 125000
结果说明 time_zone设置为SYSTEM时,80个并发会话查询1000w次 需要47.7秒。

[3306-RW-2Inst@rac1 ~] $mysql -uroot -e 'select @@time_zone' +-------------+| @@time_zone |+-------------+| +08:00 |+-------------+[3306-RW-2Inst@rac1 ~]$mysqlslap --no-defaults -uroot --create-schema=test -S/u01/my3306/run/mysql.sock --number-of-queries=10000000 --concurrency=80 '--query=select now()' Benchmark        Average number of seconds to run all queries: 30.039 seconds        Minimum number of seconds to run all queries: 30.039 seconds        Maximum number of seconds to run all queries: 30.039 seconds        Number of clients running queries: 80        Average number of queries per client: 125000
结果说明 time_zone设置为+08:00时,80个并发会话查询1000w次 需要30秒,
性能明显比前者更好,有
30%+左右的提升
2.3 使用pt-pmp工具分析 
设置SYSTEM时 MySQL 比设置为+08:00 模式多了 一层时间转化的函数调用,
__tz_convert,Time_zone_system::gmt_sec_to_TIME,gmt_sec_to_TIME,set_datetime导致cpu 使用率上升 ,sql执行时间变长 引发一些列的性能风暴效应。
$pt-pmp -p 150842
Sun Oct 11 16:10:05 CST 2015
61 __lll_lock_wait_private,_L_lock_2163,__tz_convert,Time_zone_system::gmt_sec_to_TIME,gmt_sec_to_TIME,set_datetime,Item_func_now::fix_length_and_dec,Item_func::fix_fields,setup_fields,JOIN::prepare,mysql_prepare_select,mysql_select,handle_select,execute_sqlcom_select,mysql_execute_command,mysql_parse,dispatch_command,do_handle_one_connection,handle_one_connection,start_thread,clone
搜索MySQL bugs 查看到一个  中有一样的现象,设置为非系统默认的时区的性能比默认的高很多。
time_zone='SYSTEM'的pt-pmp 分析结果
time_zone='+08:00'的pt-pmp 分析结果
三 结论
 
  1  任何性能现象细致入微之后,满满的都是问题,需要细心深挖,探究问题本质。
  2  推荐大家将系统的time_zone修改为非默认值 ,比如+08:00 ,避免性能隐患。

转载地址:http://mvxax.baihongyu.com/

你可能感兴趣的文章
iis6 zencart1.39 伪静态规则
查看>>
SQL Server代理(3/12):代理警报和操作员
查看>>
Linux备份ifcfg-eth0文件导致的网络故障问题
查看>>
2018年尾总结——稳中成长
查看>>
JFreeChart开发_用JFreeChart增强JSP报表的用户体验
查看>>
度量时间差
查看>>
通过jsp请求Servlet来操作HBASE
查看>>
Shell编程基础
查看>>
Shell之Sed常用用法
查看>>
<气场>读书笔记
查看>>
Centos下基于Hadoop安装Spark(分布式)
查看>>
3D地图的定时高亮和点击事件(基于echarts)
查看>>
mysql开启binlog
查看>>
设置Eclipse编码方式
查看>>
分布式系统唯一ID生成方案汇总【转】
查看>>
并查集hdu1232
查看>>
Mysql 监视工具
查看>>
Linux Namespace系列(09):利用Namespace创建一个简单可用的容器
查看>>
博客搬家了
查看>>
Python中使用ElementTree解析xml
查看>>