mysql thread running 一般多大

100。

在使用MySQL数据库的时候，经常会遇到这么一个问题，就是“CannotconnecttoMySQLserver.Toomanyconnections”-mysql1040错误，这是因为访问MySQL且还未释放的连接数目已经达到MySQL的上限。

通常，mysql的最大连接数默认是100,最大可以达到16384。

https://blog.51cto.com/dadaman/1957229

可以看到，当前表的碎片率超高了，50.6%。

有三种办法整理碎片

这三种 *** 作都是先创建一个临时表复制完成后再删除旧表，所以在执行 *** 作的过程中磁盘会先增大。

会锁表

https://dev.mysql.com/doc/refman/5.6/en/

https://dev.mysql.com/doc/refman/5.6/en/optimize-table.html

会锁表

pt-online-schema-change - ALTER tables 无需锁表。

整理结果很明显，整理后碎片率0.3%。

这里有几个参数需要介绍一下：

--dry-run

这个参数不建立触发器，不拷贝数据，也不会替换原表。只是创建和更改新表。

--execute

表明你已经阅读了文档，并且确认要 alter the table。你必须配置这个参数来 alter the table。如果你不配置，那么工具将只进行一些安全检查然后就退出了。这帮助确保你已经阅读了文档，并且了解如何使用该工具。如果你没有阅读这些文档，那么不会设置该参数。

--critical-load

每次chunk *** 作前后，会根据show global status统计指定的状态量的变化，默认是统计Thread_running。目的是为了安全，防止原始表上的触发器引起负载过高。这也是为了防止在线DDL对线上的影响。超过设置的阀值，就会终止 *** 作，在线DDL就会中断。提示的异常如上报错信息。

--max-lag

type: timedefault: 1s

lag 滞后偏移

暂停数据拷贝，直到所有replicas的lag值低于该值。在每个 data-copy query (each chunk)后，工具会通过Seconds_Behind_Master查询所有replica的 replication lag 。如果任何replica lag大于该值，那么工具会sleep --check-interval 秒，然后再次检查所有replica。如果你指定 --check-slave-lag ，那么工具会检查那台server，而不是所有server。如果你想控制哪个提供工具的监控，配置DSN值 --recursion-method 。

工具会等待直到replicas停止lagging。如果任一replica停止，工具会一直处于等待状态直到该replica启动。 在所有replicas运行并且lagging不大的情况下，数据拷贝继续。

工具在等待的时候，会打印进程报告。如果replica停止了，会立即打印进程报告，然后在每个进程报告期间重复。

--check-interval

type: timedefault: 1

Sleep time between checks for --max-lag .

--max-load

选项定义一个阀值，在每次chunk *** 作后，查看show global status状态值是否高于指定的阀值。该参数接受一个mysql status状态变量以及一个阀值，如果没有给定阀值，则定义一个阀值为为高于当前值的20%。注意这个参数不会像--critical-load终止 *** 作，而只是暂停 *** 作。当status值低于阀值时，则继续往下 *** 作。是暂停还是终止 *** 作这是--max-load和--critical-load的差别。

--charset

简写: -Atype: string

设置默认字符集。如果值为 utf8，设置 Perl’s binmode on STDOUT to utf8，传送 mysql_enable_utf8 参数到 DBD::mysql，然后在连接到MySQL后运行 SET NAMES UTF8 。其他的值也是在STDOUT设置 binmode，然后在连到MySQL后运行 SET NAMES 。

--check-replication-filters

检查复制中是否设置了过滤条件，如果设置了，程序将退出

--nocheck-replication-filters

不检查复制中是否设置了过滤条件

--set-vars

设置mysql的变量值

--check-slave-lag

检查主从延迟

--no-version-check

不检查版本，在阿里云服务器中一般加入此参数，否则会报错

MySQL里面为了提高客户端请求创建连接过程的性能,提供了一个连接池也就是

Thread_Cache池,将空闲的连接线程放在连接池中,而不是立即销毁.这样的好处就是,当又有一个新的请求的时候,mysql不会立即去创建连接

线程,而是先去Thread_Cache中去查找空闲的连接线程,如果存在则直接使用,不存在才创建新的连接线程.

有关Thread_Cache在MySQL有几个重要的参数,简单介绍如下:

thread_cache_size

Thread_Cache

中存放的最大连接线程数.在短连接的应用中Thread_Cache的功效非常明显,因为在应用中数据库的连接和创建是非常频繁的,如果不使用

Thread_Cache那么消耗的资源是非常可观的!在长连接中虽然带来的改善没有短连接的那么明显,但是好处是显而易见的.但并不是越大越好大了反而

浪费资源这个的确定一般认为和物理内存有一定关系,如下:

复制代码 代码如下:

1G —>8

2G —>16

3G —>32

>3G —>64

如果短连接多的话可以适当加大.

thread_stack

每个连接被创建的时候,mysql分配给它的内存.这个值一般认为默认就可以应用于大部分场景了,除非必要非则不要动它.

thread_handing

运用Thread_Cache处理连接的方式,5.1.19添加的新特性.有两个值可选[no-threads|one-thread-per-

connection] 看字面意思大家也该猜出八九分了,呵呵,no-threads

服务器使用一个线程,one-thread-per-connection

服务器为每个客户端请求使用一个线程.原手册中提到,no-threads是在Linux下调试用的.

复制代码 代码如下:

mysql>show variables like 'thread%'

+——————-+—————————+

| Variable_name | Value |

+——————-+—————————+

| thread_cache_size | 32|

| thread_handling | one-thread-per-connection |

| thread_stack | 196608|

+——————-+—————————+

3 rows in set (0.01 sec)

mysql>show status like '%connections%'

+———————-+——–+

| Variable_name| Value |

+———————-+——–+

| Connections | 199156 |

| Max_used_connections | 31 |

+———————-+——–+

2 rows in set (0.00 sec)

mysql>show status like '%thread%'

+————————+——–+

| Variable_name | Value |

+————————+——–+

| Delayed_insert_threads | 0 |

| Slow_launch_threads| 0 |

| Threads_cached | 3 |

| Threads_connected | 6 |

| Threads_created| 8689 |

| Threads_running| 5 |

+————————+——–+

6 rows in set (0.00 sec)

通过以上3个命令,可以看到服务器的 thread_cache池中最多可以存放32个连接线程,为每个客户端球使用一个线程.为每个连接的线程分配192k的内存空间.

服 务器总共有199156次连接,最大并发连接数为31,当前在thread_cashe池中的连接数为3个,连接数为6个,处于活跃状态的有5个,共创建 了8689次连接.显然这里以短连接为主.可以算出thread_cache命中率,公式为:

复制代码 代码如下:

Thread_Cache_Hit=(Connections-Thread_created)/Connections*100%

当前服务器的Thread_cache命中率约为95.6%这个结果我还是比较满意的.但是可以看出 thread_cache_size有点多余改成16或8更合理一些.

---