2024年10月高性能mysql（高性能MySQL：测试何种指标）
⑴高性能mysql（高性能MySQL：测试何种指标
⑵本文目录高性能MySQL：测试何种指标高性能MySQL：捕获诊断数据（高性能MySQL：使用strace高性能MySQL：测试何种指标测试何种指标在开始执行甚至是在设计基准测试之前需要先明确测试的目标测试目标决定了选择什么样的测试工具和技术以获得精确而有意义的测试结果可以将测试目标细化为一系列的问题比如这种CPU是否比另外一种要快,这个工具并不清楚需要从其他的地方来入手从前面的堆栈跟踪和oprofile报表来看如果不是MySQL和InnoDB源码方面的专家这种类型的分析很难进行如果用户在进行此类分析时碰到问题通常需要求助于这样的专家才行在下面的例子中通过剖析和等待分析都无法发现服务器的问题需要使用另外一种不同的诊断技术??????返回目录高性能MySQL??????推荐??????ASP开发培训视频教程数据仓库与数据挖掘培训视频教程lishixinzhi/Article/program/MySQL//高性能MySQL：使用strace使用stracestrace工具可调查系统调用的情况有好几种可以使用的方法其中一种是计算系统调用的时间并打印出来$stracecfp$（pidofmysqldProcessattachedwiththreadsinterrupttoquit^CProcessdetached%timesecondsusecs/callcallserrorssyscallselectfutexreadunlinkwritepread_llseektotal这种用法和oprofile有点像但是oprofile还可以剖析程序的内部符号而不仅仅是系统调用另外strace拦截系统调用使用的是不同于oprofile的技术这会有一些不可预期性开销也更大些strace度量时使用的是实际时间而oprofile使用的是花费的CPU周期举个例子当I/O等待出现问题的时候strace能将它们显示出来因为它从诸如read或者pread这样的系统调用开始计时直到调用结束但oprofile不会这样因为I/O系统调用并不会真正地消耗CPU周期而只是等待I/O完成而已我们会在需要的时候使用oprofile因为strace对像mysqld这样有大量线程的场景会产生一些副作用当strace附加上去后mysqld的运行会变得很慢因此不适合在产品环境中使用但在某些场景中strace还是相当有用的PerconaToolkit中有一个叫做ptioprofile的工具就是使用strace来生成I/O活动的剖析报告的这个工具很有帮助可以证明或者驳斥某些难以测量的情况下的一些观点此时其他方法很难达到目的（如果运行的是MySQL使用PerformanceSchema也可以达到目的??????返回目录高性能MySQL??????推荐??????ASPMVC框架揭秘???????Oracle索引技术??????ASP开发培训视频教程lishixinzhi/Article/program/MySQL//,有时候需要用不同的方法测试不同的指标比如针对延迟（latency和吞吐量（throughput就需要采用不同的测试方法请考虑以下指标看看如何满足测试的需求吞吐量吞吐量指的是单位时间内的事务处理数这一直是经典的数据库应用测试指标一些标准的基准测试被广泛地引用如TP（参考//tpc而且很多数据库厂商都努力争取在这些测试中取得好成绩这类基准测试主要针对在线事务处理（OLTP的吞吐量非常适用于多用户的交互式应用常用的测试单位是每秒事务数（TPS有些也采用每分钟事务数（TPM响应时间或者延迟这个指标用于测试任务所需的整体时间根据具体的应用测试的时间单位可能是微秒毫秒秒或者分钟根据不同的时间单位可以计算出平均响应时间最小响应时间最大响应时间和所占百分比最大响应时间通常意义不大因为测试时间越长最大响应时间也可能越大而且其结果通常不可重复每次测试都可能得到不同的最大响应时间因此通常可以使用百分比响应时间（percentileresponsetime来替代最大响应时间例如如果%的响应时间都是毫秒则表示任务在%的时间段内都可以在毫秒之内完成使用图表有助于理解测试结果可以将测试结果绘制成折线图（比如平均值折线或者%百分比折线或者散点图直观地表现数据结果集的分布情况通过这些图可以发现长时间测试的趋势本章后面将更详细地讨论这一点并发性并发性是一个非常重要又经常被误解和误用的指标例如它经常被表示成多少用户在同一时间浏览一个Web站点经常使用的指标是有多少个会话注然而HTTP协议是无状态的大多数用户只是简单地读取浏览器上显示的信息这并不等同于Web服务器的并发性而且Web服务器的并发性也不等同于数据库的并发性而仅仅只表示会话存储机制可以处理多少数据的能力Web服务器的并发性更准确的度量指标应该是在任意时间有多少同时发生的并发请求在应用的不同环节都可以测量相应的并发性Web服务器的高并发一般也会导致数据库的高并发但服务器采用的语言和工具集对此都会有影响注意不要将创建数据库连接和并发性搞混淆一个设计良好的应用同时可以打开成百上千个MySQL数据库服务器连接但可能同时只有少数连接在执行查询所以说一个Web站点同时有个用户访问却可能只有～个并发请求到MySQL数据库换句话说并发性基准测试需要关注的是正在工作中的并发操作或者是同时工作中的线程数或者连接数当并发性增加时需要测量吞吐量是否下降响应时间是否变长如果是这样应用可能就无法处理峰值压力并发性的测量完全不同于响应时间和吞吐量它不像是一个结果而更像是设置基准测试的一种属性并发性测试通常不是为了测试应用能达到的并发度而是为了测试应用在不同并发下的性能当然数据库的并发性还是需要测量的可以通过sy***ench指定或者个线程的测试然后在测试期间记录MySQL数据库的Threads_running状态值在第章将讨论这个指标对容量规划的影响可扩展性在系统的业务压力可能发生变化的情况下测试可扩展性就非常必要了第章将更进一步讨论可扩展性的话题简单地说可扩展性指的是给系统增加一倍的工作在理想情况下就能获得两倍的结果（即吞吐量增加一倍或者说给系统增加一倍的资源（比如两倍的CPU数就可以获得两倍的吞吐量当然同时性能（响应时间也必须在可以接受的范围内大多数系统是无法做到如此理想的线性扩展的随着压力的变化吞吐量和性能都可能越来越差可扩展性指标对于容量规范非常有用它可以提供其他测试无法提供的信息来帮助发现应用的瓶颈比如如果系统是基于单个用户的响应时间测试（这是一个很糟糕的测试策略设计的虽然测试的结果很好但当并发度增加时系统的性能有可能变得非常糟糕而一个基于不断增加用户连接的情况下的响应时间测试则可以发现这个问题一些任务比如从细粒度数据创建汇总表的批量工作需要的是周期性的快速响应时间当然也可以测试这些任务纯粹的响应时间但要注意考虑这些任务之间的相互影响批量工作可能导致相互之间有影响的查询性能变差反之亦然归根结底应该测试那些对用户来说最重要的指标因此应该尽可能地去收集一些需求比如什么样的响应时间是可以接受的期待多少的并发性等等然后基于这些需求来设计基准测试避免目光短浅地只关注部分指标而忽略其他指标??????返回目录高性能MySQL??????推荐??????ASP开发培训视频教程数据仓库与数据挖掘培训视频教程lishixinzhi/Article/program/MySQL//高性能MySQL：捕获诊断数据（捕获诊断数据（堆栈需要自下而上来看也就是说线程当前正在执行的是pthread_cond_wait函数这是由os_event_wait_low调用的继续往下看起来是线程试图进入到InnoDB内核（srv_conc_enter_innodb但被放入了一个内部队列中（os_event_wait_low原因应该是内核中的线程数已经超过innodb_thread_concurrency的限制当然要真正地发挥堆栈跟踪的价值需要将很多的信息聚合在一起来看这种技术是由DomasMituzas推广的他以前是MySQL的支持工程师开发了著名的穷人剖析器poormansprofiler他目前在Facebook工作和其他人一起开发了更多的收集和分析堆栈跟踪的工具可以从他的这个网站发现更多的信息//poormansprofiler在PerconaToolkit中我们也开发了一个类似的穷人剖析器叫做ptpmp这是一个用shell和awk脚本编写的工具可以将类似的堆栈跟踪输出合并到一起然后通过sort|uniq|sort将最常见的条目在最前面输出下面是一个堆栈跟踪的完整例子通过此工具将重要的信息展示了出来使用了l选项指定了堆栈跟踪不超过层以免因太多前面部分相同而后面部分不同的跟踪信息而导致无法聚合到一起的情况这样才能更好地显示到底在哪里产生了等待$ptpmplstacktracestxtpthread_cond_waitone_thread_per_connection_endhandle_one_connectionstart_threadclonepthread_cond_waitos_event_wait_lowsrv_conc_enter_innodbinnodb_srv_conc_enter_innodbha_innodb::index_readpthread_cond_waitos_event_wait_lowsync_array_wait_eventmutex_spin_waitmutex_enter_funcpthread_cond_waitos_event_wait_lowos_aio_simulated_handlefil_aio_waitio_handler_threadpthread_cond_waitos_event_wait_lowsrv_conc_enter_innodbinnodb_srv_conc_enter_innodbha_innodb::general_fetchpthread_cond_waitos_event_wait_lowsync_array_wait_eventrw_lock_s_lock_spinrw_lock_s_lock_funcsigwaitsignal_handstart_threadclone??selectos_thread_sleepsrv_lock_timeout_and_monitor_threadstart_threadcloneselectos_thread_sleepsrv_error_monitor_threadstart_threadcloneselecthandle_connections_socketsmainreadvio_read_buff::??my__readcli_safe_readpthread_cond_waitos_event_wait_lowsync_array_wait_eventrw_lock_x_lock_lowrw_lock_x_lock_funcpthread_cond_waitMYSQL_BIN_LOG::wait_for_updatemysql_binlog_senddispatch_manddo_mandfsyncos_file_fsyncos_file_flushfil_flushlog_write_up_to第一行是MySQL中非常典型的空闲线程的一种特征所以可以忽略第二行才是最有意思的地方看起来大量的线程正在准备进入到InnoDB内核中但都被阻塞了从第三行则可以看到许多线程都在等待某些互斥锁但具体的是什么锁不清楚因为堆栈跟踪更深的层次被截断了如果需要确切地知道是什么互斥锁则需要使用更大的l选项重跑一次一般来说这个堆栈跟踪显示很多线程都在等待进入到InnoDB这是为什么呢,或新索引是否比当前索引性能更好。
⑶高性能MySQL：测试何种指标
⑷在开始执行甚至是在设计基准测试之前需要先明确测试的目标测试目标决定了选择什么样的测试工具和技术以获得精确而有意义的测试结果可以将测试目标细化为一系列的问题比如这种CPU是否比另外一种要快？或新索引是否比当前索引性能更好？
⑸有时候需要用不同的方法测试不同的指标比如针对延迟（latency和吞吐量（throughput就需要采用不同的测试方法
⑹请考虑以下指标看看如何满足测试的需求
⑺吞吐量指的是单位时间内的事务处理数这一直是经典的数据库应用测试指标一些标准的基准测试被广泛地引用如TP（参考//tpc而且很多数据库厂商都努力争取在这些测试中取得好成绩这类基准测试主要针对在线事务处理（OLTP的吞吐量非常适用于多用户的交互式应用常用的测试单位是每秒事务数（TPS有些也采用每分钟事务数（TPM
⑻这个指标用于测试任务所需的整体时间根据具体的应用测试的时间单位可能是微秒毫秒秒或者分钟根据不同的时间单位可以计算出平均响应时间最小响应时间最大响应时间和所占百分比最大响应时间通常意义不大因为测试时间越长最大响应时间也可能越大而且其结果通常不可重复每次测试都可能得到不同的最大响应时间因此通常可以使用百分比响应时间（percentileresponsetime来替代最大响应时间例如如果%的响应时间都是毫秒则表示任务在%的时间段内都可以在毫秒之内完成
⑼使用图表有助于理解测试结果可以将测试结果绘制成折线图（比如平均值折线或者%百分比折线或者散点图直观地表现数据结果集的分布情况通过这些图可以发现长时间测试的趋势本章后面将更详细地讨论这一点
⑽并发性是一个非常重要又经常被误解和误用的指标例如它经常被表示成多少用户在同一时间浏览一个Web站点经常使用的指标是有多少个会话注然而HTTP协议是无状态的大多数用户只是简单地读取浏览器上显示的信息这并不等同于Web服务器的并发性而且Web服务器的并发性也不等同于数据库的并发性而仅仅只表示会话存储机制可以处理多少数据的能力Web服务器的并发性更准确的度量指标应该是在任意时间有多少同时发生的并发请求
⑾在应用的不同环节都可以测量相应的并发性Web服务器的高并发一般也会导致数据库的高并发但服务器采用的语言和工具集对此都会有影响注意不要将创建数据库连接和并发性搞混淆一个设计良好的应用同时可以打开成百上千个MySQL数据库服务器连接但可能同时只有少数连接在执行查询所以说一个Web站点同时有个用户访问却可能只有～个并发请求到MySQL数据库
⑿换句话说并发性基准测试需要关注的是正在工作中的并发操作或者是同时工作中的线程数或者连接数当并发性增加时需要测量吞吐量是否下降响应时间是否变长如果是这样应用可能就无法处理峰值压力
⒀并发性的测量完全不同于响应时间和吞吐量它不像是一个结果而更像是设置基准测试的一种属性并发性测试通常不是为了测试应用能达到的并发度而是为了测试应用在不同并发下的性能当然数据库的并发性还是需要测量的可以通过sy***ench指定或者个线程的测试然后在测试期间记录MySQL数据库的Threads_running状态值在第章将讨论这个指标对容量规划的影响
⒁在系统的业务压力可能发生变化的情况下测试可扩展性就非常必要了第章将更进一步讨论可扩展性的话题简单地说可扩展性指的是给系统增加一倍的工作在理想情况下就能获得两倍的结果（即吞吐量增加一倍或者说给系统增加一倍的资源（比如两倍的CPU数就可以获得两倍的吞吐量当然同时性能（响应时间也必须在可以接受的范围内大多数系统是无法做到如此理想的线性扩展的随着压力的变化吞吐量和性能都可能越来越差
⒂可扩展性指标对于容量规范非常有用它可以提供其他测试无法提供的信息来帮助发现应用的瓶颈比如如果系统是基于单个用户的响应时间测试（这是一个很糟糕的测试策略设计的虽然测试的结果很好但当并发度增加时系统的性能有可能变得非常糟糕而一个基于不断增加用户连接的情况下的响应时间测试则可以发现这个问题
⒃一些任务比如从细粒度数据创建汇总表的批量工作需要的是周期性的快速响应时间当然也可以测试这些任务纯粹的响应时间但要注意考虑这些任务之间的相互影响批量工作可能导致相互之间有影响的查询性能变差反之亦然
⒄归根结底应该测试那些对用户来说最重要的指标因此应该尽可能地去收集一些需求比如什么样的响应时间是可以接受的期待多少的并发性等等然后基于这些需求来设计基准测试避免目光短浅地只关注部分指标而忽略其他指标
⒅返回目录高性能MySQL
⒆ASP开发培训视频教程
⒇数据仓库与数据挖掘培训视频教程lishixinzhi/Article/program/MySQL//
⒈高性能MySQL：捕获诊断数据（
⒉堆栈需要自下而上来看也就是说线程当前正在执行的是pthread_cond_wait函数这是由os_event_wait_low调用的继续往下看起来是线程试图进入到InnoDB内核（srv_conc_enter_innodb但被放入了一个内部队列中（os_event_wait_low原因应该是内核中的线程数已经超过innodb_thread_concurrency的限制当然要真正地发挥堆栈跟踪的价值需要将很多的信息聚合在一起来看这种技术是由DomasMituzas推广的他以前是MySQL的支持工程师开发了著名的穷人剖析器poormansprofiler他目前在Facebook工作和其他人一起开发了更多的收集和分析堆栈跟踪的工具可以从他的这个网站发现更多的信息//poormansprofiler
⒊在PerconaToolkit中我们也开发了一个类似的穷人剖析器叫做ptpmp这是一个用shell和awk脚本编写的工具可以将类似的堆栈跟踪输出合并到一起然后通过sort|uniq|sort将最常见的条目在最前面输出下面是一个堆栈跟踪的完整例子通过此工具将重要的信息展示了出来使用了l选项指定了堆栈跟踪不超过层以免因太多前面部分相同而后面部分不同的跟踪信息而导致无法聚合到一起的情况这样才能更好地显示到底在哪里产生了等待
⒋$ptpmplstacktracestxt
⒌pthread_cond_waitone_thread_per_connection_endhandle_one_connection
⒍start_threadclone
⒎pthread_cond_waitos_event_wait_lowsrv_conc_enter_innodb
⒏innodb_srv_conc_enter_innodbha_innodb::index_read
⒐pthread_cond_waitos_event_wait_lowsync_array_wait_eventmutex_spin_wait
⒑mutex_enter_func
⒒pthread_cond_waitos_event_wait_lowos_aio_simulated_handlefil_aio_wait
⒓io_handler_thread
⒔pthread_cond_waitos_event_wait_lowsrv_conc_enter_innodb
⒕innodb_srv_conc_enter_innodbha_innodb::general_fetch
⒖pthread_cond_waitos_event_wait_lowsync_array_wait_eventrw_lock_s_lock_spin
⒗rw_lock_s_lock_func
⒘sigwaitsignal_handstart_threadclone??
⒙selectos_thread_sleepsrv_lock_timeout_and_monitor_threadstart_threadclone
⒚selectos_thread_sleepsrv_error_monitor_threadstart_threadclone
⒛selecthandle_connections_socketsmain
readvio_read_buff::??my__readcli_safe_read
pthread_cond_waitos_event_wait_lowsync_array_wait_eventrw_lock_x_lock_low
rw_lock_x_lock_func
pthread_cond_waitMYSQL_BIN_LOG::wait_for_updatemysql_binlog_send
dispatch_manddo_mand
fsyncos_file_fsyncos_file_flushfil_flushlog_write_up_to
第一行是MySQL中非常典型的空闲线程的一种特征所以可以忽略第二行才是最有意思的地方看起来大量的线程正在准备进入到InnoDB内核中但都被阻塞了从第三行则可以看到许多线程都在等待某些互斥锁但具体的是什么锁不清楚因为堆栈跟踪更深的层次被截断了如果需要确切地知道是什么互斥锁则需要使用更大的l选项重跑一次一般来说这个堆栈跟踪显示很多线程都在等待进入到InnoDB这是为什么呢？这个工具并不清楚需要从其他的地方来入手
从前面的堆栈跟踪和oprofile报表来看如果不是MySQL和InnoDB源码方面的专家这种类型的分析很难进行如果用户在进行此类分析时碰到问题通常需要求助于这样的专家才行
在下面的例子中通过剖析和等待分析都无法发现服务器的问题需要使用另外一种不同的诊断技术
返回目录高性能MySQL
ASP开发培训视频教程
数据仓库与数据挖掘培训视频教程lishixinzhi/Article/program/MySQL//
高性能MySQL：使用strace
strace工具可调查系统调用的情况有好几种可以使用的方法其中一种是计算系统调用的时间并打印出来
$stracecfp$（pidofmysqld
Processattachedwiththreadsinterrupttoquit
^CProcessdetached
%timesecondsusecs/callcallserrorssyscall
这种用法和oprofile有点像但是oprofile还可以剖析程序的内部符号而不仅仅是系统调用另外strace拦截系统调用使用的是不同于oprofile的技术这会有一些不可预期性开销也更大些strace度量时使用的是实际时间而oprofile使用的是花费的CPU周期举个例子当I/O等待出现问题的时候strace能将它们显示出来因为它从诸如read或者pread这样的系统调用开始计时直到调用结束但oprofile不会这样因为I/O系统调用并不会真正地消耗CPU周期而只是等待I/O完成而已
我们会在需要的时候使用oprofile因为strace对像mysqld这样有大量线程的场景会产生一些副作用当strace附加上去后mysqld的运行会变得很慢因此不适合在产品环境中使用但在某些场景中strace还是相当有用的PerconaToolkit中有一个叫做ptioprofile的工具就是使用strace来生成I/O活动的剖析报告的这个工具很有帮助可以证明或者驳斥某些难以测量的情况下的一些观点此时其他方法很难达到目的（如果运行的是MySQL使用PerformanceSchema也可以达到目的
返回目录高性能MySQL
ASPMVC框架揭秘
Oracle索引技术
ASP开发培训视频教程lishixinzhi/Article/program/MySQL//