[MySQL 5.6] Innodb 新特性之 multi purge thread

在做5.6.12 vs 5.6.11的性能对比时,大量update产生了很长的purge history list。手贱把innodb_fast_shutdowns设置为0了,结果Purge线程一直干活了,差不多两个小时才结束….

我们知道,在MySQL5.5版本中,就已经开始将purge 任务从master线程中独立出来,而到了5.6,已经支持多个purge线程同时进行,简单的理了下代码逻辑.

////////////////////////////////////////////////////////


在5.6中,提供了参数Innodb_purge_threads来控制做purge操作的后台线程数,最大允许设置为32.

purge线程被分为两类,一类是coordinator thread,只有一个这样的线程,另外的Innodb_purge_threads-1个是worker线程.

线程在Innodb启动时创建
quoted code in innobase_start_or_create_for_mysql:
2584         if (!srv_read_only_mode
2585             && srv_force_recovery < SRV_FORCE_NO_BACKGROUND) {
2586
2587                 os_thread_create(
2588                         srv_purge_coordinator_thread,
2589                         NULL, thread_ids + 5 + SRV_MAX_N_IO_THREADS);
2590
2591                 ut_a(UT_ARR_SIZE(thread_ids)
2592                      > 5 + srv_n_purge_threads + SRV_MAX_N_IO_THREADS);
2593
2594                 /* We've already created the purge coordinator thread above. */
2595                 for (i = 1; i < srv_n_purge_threads; ++i) {
2596                         os_thread_create(
2597                                 srv_worker_thread, NULL,
2598                                 thread_ids + 5 + i + SRV_MAX_N_IO_THREADS);
2599                 }
2600
2601                 srv_start_wait_for_purge_to_start();
2602
2603         } else {
2604                 purge_sys->state = PURGE_STATE_DISABLED;
2605         }
a. coordinator thread
协调线程的入口函数是srv_purge_coordinator_thread

分为三个阶段:
正常工作阶段,在一个while循环中调用:
2754                 rseg_history_len = srv_do_purge(
2755                         srv_n_purge_threads, &n_total_purged);

 

从while break的条件由函数srv_purge_should_exit确定,这里有一个特殊情况,当innodb_fast_shutdown设置为0时,如果上一次purge的Page数不为0,则返回false,表示不退出循环,这是因为当fast shutdown为0时,需要做完所有的purge操作才会结束线程任务


第二个阶段是确认innodb_fast_shutdown被设置为0时,所有的记录都被purge掉了;这可以避免在退出上述循环后,有新的记录加入。这里已经不再使用worker线程了(trx_purge的第一个参数为1)

2769         while (srv_fast_shutdown == 0 && n_pages_purged > 0) {
2770                 n_pages_purged = trx_purge(1, srv_purge_batch_size, false);
2771         }
最后对history list做一次truncate,并确保所有worker线程退出

2773         /* Force a truncate of the history list. */
2774         n_pages_purged = trx_purge(1, srv_purge_batch_size, true);
这里有两个需要关注的函数:

a1)srv_do_purge:

在协调线程的主要工作都是在这个函数中,注意,不是有多少工作线程,就会用多少的,这里 实际上是把多余的线程当做一个池子,只有purge跟不上更新的时候,才会去调度这些线程:

调整n_use_threads
>>当trx_sys->rseg_history_len相比上次purge有增长时,或者超过了innodb_max_purge_lag_delay(不为0),++n_use_threads
>>否则,如果存在activity(srv_check_activity),–n_use_threads

执行purge调度
2577                 n_pages_purged = trx_purge(
2578                         n_use_threads, srv_purge_batch_size, false);

每128次purge, truncate一次history list,这也是为什么我们每隔一会,才看到history list长度变小的原因

2580                 if (!(count++ % TRX_SYS_N_RSEGS)) {
2581                         /* Force a truncate of the history list. */
2582                         n_pages_purged += trx_purge(
2583                                 1, srv_purge_batch_size, true);
2584                 }
a2)  trx_purge
trx_purge是purge任务调度的核心函数,包含三个参数:
* n_purge_threads —>使用到的worker线程数
* batch_size  —-> 由innodb_purge_batch_size控制,表示一次Purge的记录数
* truncate —>是否truncate history list 

持有purge_sys->latch的x锁,并建立read view,然后释放锁
purge_sys->view = read_view_purge_open(purge_sys->heap);

读取需要purge的undo记录,记录数不超过batch size,这些purge任务被指派给n_purge_threads个thr
1213         /* Fetch the UNDO recs that need to be purged. */
1214         n_pages_handled = trx_purge_attach_undo_recs(
1215                 n_purge_threads, purge_sys, &purge_sys->limit, batch_size);
当n_purge_threads>1时,会将n_purge_threads-1个thr加入到工作队列,由worker线程来消费

1221                 /* Submit the tasks to the work queue. */
1222                 for (i = 0; i < n_purge_threads - 1; ++i) {
1223                         thr = que_fork_scheduler_round_robin(
1224                                 purge_sys->query, thr);
1225
1226                         ut_a(thr != NULL);
1227
1228                         srv_que_task_enqueue_low(thr);
1229                 }

 

调度线程同样也需要运行一个thr任务,而不是仅仅只做分配;完成后,还需要等待其他worker线程完成任务
1243 run_synchronously:
1244                 ++purge_sys->n_submitted;
1245
1246                 que_run_threads(thr);
1247
1248                 os_atomic_inc_ulint(
1249                         &purge_sys->bh_mutex, &purge_sys->n_completed, 1);
1250
1251                 if (n_purge_threads > 1) {
1252                         trx_purge_wait_for_workers_to_complete(purge_sys);
1253                 }

当truncate为true时,还需要调用trx_purge_truncate–>trx_purge_truncate_history从回滚段中移除历史记录。


b.worker thread


入口函数是srv_worker_thread
2473         do {
2474                 srv_suspend_thread(slot);
2475
2476                 os_event_wait(slot->event);
2477
2478                 if (srv_task_execute()) {
2479
2480                         /* If there are tasks in the queue, wakeup
2481                         the purge coordinator thread. */
2482
2483                         srv_wake_purge_thread_if_not_active();
2484                 }
2485
2486                 /* Note: we are checking the state without holding the
2487                 purge_sys->latch here. */
2488         } while (purge_sys->state != PURGE_STATE_EXIT);
purge_sys->state是协调线程在将要退出前设置成PURGE_STATE_EXIT。因此worker线程总是在coordinator线程退出之后再退出


srv_task_execute()的工作流程也很简单: 持有srv_sys->tasks_mutex锁,从srv_sys->tasks中取出一个thr,然后释放tasks_mutex。再调用que_run_threads(thr)完成purge

原创文章,转载请注明: 转载自Simple Life

本文链接地址: [MySQL 5.6] Innodb 新特性之 multi purge thread

Post Footer automatically generated by wp-posturl plugin for wordpress.


Comments

Leave a Reply

Your email address will not be published. Name and email are required


Current month ye@r day *