###一、问题来源

这是一位朋友给我的一个截图，说show slave status一直处于Wating for Slave workers to free pending events状态，这个库是MTS从库，版本为5.7.25


###二、关于等待

我曾经在我的主从原理系列中(已经成书)解释过大部分协调线程的等待，如下：

– “Waiting for dependent transaction to commit”

由于协调线程判定本事务由于last commit大于current_lwm因此不能并行回放，协调线程处于等待，大事务会加剧这种情况。

– “Waiting for slave workers to process their queues”

由于没有空闲的工作线程，协调线程会等待。这种情况说明理论上的并行度是理想的，但是可能是参数slave_parallel_workers设置不够。当然设置工作线程的个数应该和服务器的配置和负载相结合考虑。

– “Waiting for Slave Worker queue”

由于工作线程的任务队列已满，协调线程会等待。这种情况前面说过是由于一个事务包含了过多的Event并且工作线程应用Event的速度赶不上协调线程分配Event的速度，导致了积压并且超过了16384个Event。

但是对于Wating for Slave workers to free pending events等待，只是简单的提及了可能涉及到big event，这里想说的就是实际上这个等待可能和两方面有关：

1. 如果涉及到big event，那么要求worker线程当前没有积压的event正在执行

2. 如果不是big event，那么需要判断当前worker线程积压的event大小加上本次进入worker线程对列的event大小之和不能超过参数slave_pending_jobs_size_max的大小

什么是big event呢？很简源码判断如下：

“`

bool big_event= (ev_size > rli->mts_pending_jobs_size_max);

“`

遇到这种问题应该在日志中能够看到

“`

2020-10-28T14:07:49.522388+08:00 14 [Note] Multi-threaded slave statistics for channel ”: seconds elapsed = 676;…..waited due the total size 的大小不为0。

“`

###三、判断的维度

这里我们简单考虑一下判断一下可以进入worker线程队列的维度。首先我们说对于woker线程队列来讲他有一个固定的大小也就是积压不能超过16384个event，这里我们还明白来，这些积压的event还不能太大，如果太大就会出现Wating for Slave workers to free pending events等待，因此总结一下：

– 如果协调线程发现分配的woker线程积压的event个数超过了 16384个event，那么进入Waiting for Slave Worker queue等待

– 如果协调线程发现分配的worker线程积压的event的大小超过了slave_pending_jobs_size_max设置的大小，那么进入Wating for Slave workers to free pending events等待

当然这是从个数和大小两个不同的维度来判断的，如果一个大事务，我们知道这样的事务会形成很多8K左右的event(比如一次delete了1000W的数据)，那么如果只用个数来判断那么就是积压的event大小最多达到(8K*16384=128M)，实际上我们的参数slave_pending_jobs_size_max 默认为16M，这种情况下可能协调线程会先触发Wating for Slave workers to free pending events等待。

因此不管是触发了Waiting for Slave Worker queue等待还是Wating for Slave workers to free pending events等待，我们都需要检查一下worker线程回放event的效率是不是遇到了问题。

###四、关于源码等待

函数入口append_item_to_jobs

– 关于等待，如下：

“`

bool big_event= (ev_size > rli->mts_pending_jobs_size_max);

/*

C waits basing on *data* sizes in the queues.

If it is a big event (event size is greater than

slave_pending_jobs_size_max but less than slave_max_allowed_packet),

it will wait for all the jobs in the workers’s queue to be

completed. If it is normal event (event size is less than

slave_pending_jobs_size_max), then it will wait for

enough empty memory to keep the event in one of the workers’s

queue.

NOTE: Receiver thread (I/O thread) is taking care of restricting

the event size to slave_max_allowed_packet. If an event from

the master is bigger than this value, IO thread will be stopped

with error ER_NET_PACKET_TOO_LARGE.

*/

while ( (!big_event && new_pend_size > rli->mts_pending_jobs_size_max)//条件1

|| (big_event && rli->mts_pending_jobs_size != 0 ))//条件2

{

rli->mts_wq_oversize= TRUE;

rli->wq_size_waits_cnt++; // 增加由于big event或者积压大小过多导致的等待次数

thd->ENTER_COND(&rli->pending_jobs_cond, &rli->pending_jobs_lock,

&stage_slave_waiting_worker_to_free_events, &old_stage);//进入等待状态

mysql_cond_wait(&rli->pending_jobs_cond, &rli->pending_jobs_lock);//等待条件变量

mysql_mutex_unlock(&rli->pending_jobs_lock);

thd->EXIT_COND(&old_stage);

if (thd->killed)

return true;

if (rli->wq_size_waits_cnt % 10 == 1)

sql_print_information(“Multi-threaded slave: Coordinator has waited ”

“%lu times hitting slave_pending_jobs_size_max; ”

“current event size = %zu.”,

rli->wq_size_waits_cnt, ev_size);

mysql_mutex_lock(&rli->pending_jobs_lock);

new_pend_size= rli->mts_pending_jobs_size + ev_size;

}

“`

– 关于唤醒，如下：

当woker线程执行完event后，会进行减去执行完event size的操作如下，入口函数remove_item_from_jobs:

“`

减去执行完event size

rli->mts_pending_jobs_size-= ev->common_header->data_written;

唤醒

/* coordinator can be waiting */

if (rli->mts_pending_jobs_size mts_pending_jobs_size_max &&

rli->mts_wq_oversize) // TODO: unit/general test wq_oversize

{

rli->mts_wq_oversize= FALSE;

mysql_cond_signal(&rli->pending_jobs_cond);

}

“`