mysql系统调优之thread_cache_size

背景

近期客户的大数据任务调度应用系统出现问题，调度任务失败，任务没有正常执行，产品组同事去看应用日志也没发现错误日志.后来检查msql server日志

发现有很多节点连接报 error reading communication 和time out reading错误

首先查看mysql server连接数

 

引申

当时看了这个参数 11505这个值就觉得不太可能是这个连接数值，就看着从测试环境验证一下

结果39w多，由于测试环境库没什么应用在连，所以这个数字不可能是当前的连接数，直接上官网查定义：

The number of connection attempts (successful or not) to the MySQL server.

应该是历史试图连接到mysql的连接数

所以就查看其他参数 ,用show global status like '%threads%'  命令

 

发现 这个Threads_created 值和connections值很接近，就去查了下其含义：

Threads_created： 为处理连接请求创建过的线程数，如果发现Threads_created值过大的话，表明MySQL服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值，

 

找到目标参数

 

线程缓存未命中率=Threads_created /Connections

这么一算发现 测试环境的未命中率90%以上，然后看thread_cache_size值竟然是0 。所以赶紧去现场环境看看被重装的mysql这个变量设置了没有

还好有设置：

进一步查看

由此计算出现场的未命中率=373/13027 =2%，说明thread_cache_size 设置的还是比较合理的

 

thread_cache_size原理

 

thread_cache_size：当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁(前提是缓存数未达上限)

即可以重新利用保存在缓存中线程的数量，当断开连接时如果缓存中还有空间，那么客户端的线程将被放到缓存中，如果线程重新被请求，那么请求将从缓存中读取，如果缓存中是空的或者是新的请求，那么这个线程将被重新创建，如果有很多新的线程，增加这个值可以改善系统性能。
 

thread_cache_size设置原则

 

thread_cache_size大小的设置：

如果是短连接，适当设置大一点，因为短连接往往需要不停创建，不停销毁，如果大一点，连接线程都处于取用状态，不需要重新创建和销毁，所以对性能肯定是比较大的提升。
对于长连接，不能保证连接的稳定性，所以设置这参数还是有一定必要，可能连接池的问题，会导致连接数据库的不稳定性，也会出现频繁的创建和销毁，但这个情况比较少，如果是长连接，可以设置成小一点，一般在50-100左右。

物理内存设置规则：通过比较Connections 和 Threads_created 状态的变量，可以看到这个变量的作用。(-->表示要调整的值)   根据物理内存设置规则如下：
     1G  ---> 8
     2G  ---> 16
     3G  ---> 32
    >3G  ---> 64

查询thread_cache_size设置

show global status like'thread_cache_size';

设置命令：

1. mysql> set global thread_cache_size=16
2. 编辑/etc/my.cnf 更改/添加 thread_concurrency = 16

附

mysqladmin start slave stop slave kill某个连接到mysqlServer的线程