mysql数据库负载很高_MySQL数据库负载很高连接数很多怎么处理 • zhangyiling’s Tech Blog...

这时怎么办呢?

第一:先限制Innodb的并发处理

如果innodb_thread_concurrency = 0可以先改成 16或是64 看机器压力,如果非常大,先改成16让机器的压力下来,然后慢慢增达,适

应自已的业务。

处理方法: set global innodb_thread_concurrency=16;mysql> show variables like '%innodb_thread_c%';

+---------------------------+-------+

| Variable_name | Value |

+---------------------------+-------+

| innodb_thread_concurrency | 8 |

+---------------------------+-------+

innodb_thread_concurrency对InnoDB中可以运行的线程数量有限制。 5.5中的默认值为0，表示“无限数量的线程”，但在某些工作

负载中，限制该值可以使用某些性能优势。正如我们所说，设置基准测试，以确定哪些调整参数为您的工作负载提供最大的收益。

thread_concurrency 引起了很多混乱，有一些MySQL调优howtos解释了如何调整变量以获得更好的性能。如果你的my.cnf中的变量不 要紧张，因为它什么也没有，你只会失去一些宝贵的时间来调整它。

thread_concurrency变量是针对于Solaris 8及低版本的系统，设置了这个变量mysqld会调用thr_setconcurrency()函数。这个函数允

许应用程序给同一时间运行的线程系统提示所需数量的线程。当前的Solaris 版本中这个参数已经没有作用了。这个参数在mysql 5.6.1中

已经被标记为过时，在5.7.2版本的mysql中被移除.

InnoDB使用操作系统线程来处理用户的事务请求。(在事务提交或回滚之前可能给InnoDB引擎带来很多的请求)。在现代化操作系统和多核

处理器的服务器，上下文切换是有效的，大多数工作负载运行没有任何并发线程数量的限制。在MySQL 5.5及以上版本中，MySQL做了可伸缩

性的改进，它减少了这种在InnoDB内部限制并发执行线程数量的需要。

它有助于在最小化的情况下进行线程之间的上下文切换，InnoDB可以使用各种技术来限制操作系统并发执行线程的数量(因此大批量的请求可以在任何一个时间得到处理)。当InnoDB从用户会话收到一个新的请求，如果线程并发执行的数量达到预定义的限制，那么新的请求会先睡眠一段时间后再次尝试。在睡眠后不能按计划执行的请求会被放入先入/先出队列，并最终处理。那些等待获取锁的线程则不会被计入到并发执行线程的数量中。

我们可以通过设置配置参数innodb_thread_concurrency来限制并发线程的数量，一旦执行线程的数量达到这个限制，额外的线程在被放置到对队列中之前，会睡眠数 微秒，可以通过设定参数innodb_thread_sleep_delay来配置睡眠时间。

在官方doc上，对于innodb_thread_concurrency的使用，也给出了一些建议，如下：

如果一个工作负载中，并发用户线程的数量小于64，建议设置innodb_thread_concurrency=0；

如果工作负载一直较为严重甚至偶尔达到顶峰，建议先设置innodb_thread_concurrency=128，并通过不断的降低这个参数，96, 80, 64

等等，直到发现能够提供最佳性能的线程数，例如，假设系统通常有40到50个用户，但定期的数量增加至60，70，甚至200。你会发现，性能

在80个并发用户设置时表现稳定，如果高于这个数，性能反而下降。在这种情况下，建议设置innodb_thread_concurrency参数为80，以

避免影响性能。

如果你不希望InnoDB使用的虚拟CPU数量比用户线程使用的虚拟CPU更多(比如20个虚拟CPU)，建议通过设置

innodb_thread_concurrency 参数为这个值(也可能更低，这取决于性能体现)，如果你的目标是将MySQL与其他应用隔离，你可以考虑

绑定mysqld进程到专有的虚拟CPU。但是需 要注意的是，这种绑定，在myslqd进程一直不是很忙的情况下，可能会导致非最优的硬件使用

率。在这种情况下，你可能会设置mysqld进程绑定的虚拟 CPU，允许其他应用程序使用虚拟CPU的一部分或全部。

在某些情况下，最佳的innodb_thread_concurrency参数设置可以比虚拟CPU的数量小。

定期检测和分析系统，负载量、用户数或者工作环境的改变可能都需要对innodb_thread_concurrency参数的设置进行调整。

第二: 限制一下连接数

对于连接数已经超过600或是更多的情况,可以考虑适当的限制一下连接数,让前端报一下错,也别让DB挂了,DB在了,总是可以用来加载一下数

据,当数据加载到了nosql里了,慢慢的DB压力也会降下来的。

限制单用户连接数在500以下. 如:

set global max_user_connections=500;

(MySQL随着连接数的增加性能会是下降的,这也是thread_pool出现的原因)

另外对于有的监控程序会读取information_schema下面的表的程序可以考虑关闭下面的参数

innodb_stats_on_metadata=0

set global innodb_stats_on_metadata=0;

这个参数主要防止对读取information_schema时造成大量读取磁盘进行信息统计(如果慢查询中出现关于information_schema中表时,也

可以考虑禁用该参数)

处理依据:

当学校的一个食堂一分钟只能为两个打饭, 忽然来了100个时人来打饭,又没排队, 不出会现了打饭的师傅要用点时间

去选择为那个用户服务了, 人越多,场面就越乱, 难免出现用户大吼该他的场面, 最后有可能就出现不是打饭了,而时之间相互

打架了,打饭的师傅也将收到同时有90个以上的 Server too busy. 如果能排一下队.最多也就50分钟能处理完了。

以前办法,应该可以让MySQLD不会挂掉.如果业务支撑受到限制,还是想办法处理一下。

问题:

高峰期的业务支撑数就是服务器的最终需求数吗?