MySQL线程池内幕

检查线程组的负载情况进行工作线程的唤醒与创建。
检查与处理超时的客户端连接。

这里重要介绍第一部分工作也就是Check Stall机制。Timer Thread周期性地检查线程组内的线程是否被壅塞(stall)，所谓壅塞也就是新来了义务然则线程组内没有线程来处理。Timer Thread经由过程queue_event_count和IO义务队列是否为空来断定线程组是否为壅塞状况，每次工作线程检索义务的时刻queue_event_count都邑累加，累加意味着义务被正常处理，工作线程正常工作，在每一次check_stall之后queue_event_count会被清零，是以如不雅在一准时光距离(stall_limit)后的下一次迭代中，IO义务队列不为空并且queue_event_count为空，则解释这段时光距离内都没有工作线程来处理IO义务了，那么Check Stall机制会测验测验着唤醒或创建一个工作线程，唤醒线程的逻辑很简单，如不雅waiting_threads中有余暇线程则唤醒一个余暇线程，不然须要测验测验创建一个工作线程，创建线程不必定会创建成功，我们看看创建线程的前提：

如不雅没有余暇线程且没有活泼线程则立马创建，这个时刻可能是因为没有任何工作线程或者工作线程都被壅塞了，或者是存在潜在的逝世锁。
不然如不雅距离前次创建的时光大年夜于必定阈值才创建线程，这个阈值由线程组内的线程数决定。

阈值与线程组内线程数的关系如下：

线程数阈值 < 4 0 < 8 50 * 1000 < 16 100 * 1000 >= 16 200 * 1000

阈值机制可以或许有效的防止线程创建过于频繁。这里遗留个问题，为什么阈值依附于线程池的线程数?阈值是否能依附于thread_pool_stall_limit的值?Check Stall机制可以被认为一个专门的线程做专门的工作，毕竟线程组内部逻辑也是蛮纷乱的。

义务队列

义务队列也就是listener每次大年夜poolfd轮训出来的就绪义务，分为优先义务队列(high_prio_queue)和通俗义务队列(queue)，优先队列中的IO义务会先被处理，然后通俗队列中的义务才能够被处理。那么什么样的义务会被认为是优先义务呢?官方列出了两个前提：

连接处于事务中。
连接接洽关系的priority tickets值大年夜于0。

参数priority tickets(thread_pool_high_prio_tickets)的设计是为了防止高优先级的义务老是被处理，而一些非高优先级的义务处于较长时光的饥饿状况，毕竟工作线程的创建也是有前提的，当高优先级的义务每一次被放入高优先级队列之后都邑对priority tickets的值进行减一，是以达到必定次数priority tickets的值必定会小于等于0，是以避免了永远高优先级的问题。别的队列的应用受参数thread_pool_high_prio_mode影响，可参考对参数thread_pool_high_prio_mode介绍的部分。当就绪IO义务被轮训出来放入队列之后会对io_event_count进行累加，当IO义务大年夜队列掏出处理的时刻会对queue_event_coun进行计数。

Listener线程

Listener做的工作主如果大年夜poolfd中轮训与其绑定的socket句柄的就绪IO事宜，事宜以义务的情势被放入义务队列并做响应处理，如不雅listener攫取了一些IO义务之后，该怎么办呢?下面基于两个问题答复：

listener应当本身处理这些义务吗?照样将这些义务放入队列让工作线程处理?
如不雅义务队列不为空，我们须要唤醒若干个工作线程?

对于第一个问题，平日我们不想经常改变listener的等待和唤醒的状况，因为listener刚被唤醒，是以我们更偏向于让listener应用它的时光片去做一些工作。如不雅listener不本身处理工作，这意味着其他线程要被唤醒去做这个工作，这显然不是很好。而让listener去做义务潜在的问题是线程组有可能一段时光收集义务无法及时被处理，这不是重要的问题，因为stall将被Timer Thread检查。然而老是依附Timer Thread也是不好的，因为stall_limit有可能被设置比较长的时光。我们应用下面的策略，如不雅义务队列不空，我们义务收集义务此时可能比较多，让其他线程来处理义务，不然listener本身处理义务。

对于第二个问题，我们平日为每一个线程组保持一个晃荡线程(晃荡线程包含正在做义务的线程)，是以唤醒一个工作线程的前提为当前活泼前程数为0，如不雅没有线程被唤醒，在只能依附Timer Thread来检查stall并进行唤醒了。

膳绫擎可以看出，如不雅义务队列不为空，也不必定会有线程来及时处理义务，这就导致了耗时义务影响了后来义务的履行，将来可能经由过程摒弃每个线程组只保持一个活泼线程的规矩来避免收集义务长时光得不到处理。

总结

应用MySQL线程池可以进步数据库的机能，设计者对线程池的创建与义务的处理机制进行精心的设计，然而同时也带来了一些潜在的问题，最明显的就是耗时义务对其他义务调剂的影响，尽管有不足之处然则应用者仍然可以经由过程控制线程池的内部细节以及深刻懂得开放参数的含义，经由过程参数的调剂来在必定程度上对MySQL线程池的应用进行优化。学乃至用，到这里，您是否可以或许应用膳绫擎介绍的一些常识来解决一些实际问题了呢?

【编辑推荐】

十招搞定MySQL大年夜范围数据库的机能和伸缩性优化
MySQL EXPLAIN详解
MySQL逝世锁与日记二三事
MySQL多列索引的应用
MySQL InnoDB内存压力断定以及存在的疑问
3/4 首页上一页 1 2 3 4 下一页尾页

　　推荐阅读

　　李红：数字化转型将重塑企业信息化使命

2017年7月22日，由中国新一代IT家当推动联盟指导，CIO时代学院、IT趣学社结合主办，CIO时代APP承办的“西部家当互联网岑岭论坛暨2017CIO时代中国行西安站”晃荡在“古城&r>>>详细阅读

本文标题：MySQL线程池内幕

地址：http://www.17bianji.com/lsqh/36583.html

1/2 1