How the mysql> show engine innodb status command is processed internally in InnoDB

mysql> show engine innodb status 这个命令在innodb内部是如何处理的？ srv_printf_innodb_monitor调用处理所有全部信息的打印工作

===================================== 100908 14:45:53 INNODB MONITOR OUTPUT ===================================== Per second averages calculated from the last 47 seconds 这个是输出的第一部分 100908 14:45:53 这个是时间戳，由ut_print_timestamp调用生成（innobase/ut/ut0ut.c） code: fprintf(file,"%02d%02d%02d %2d:%02d:%02d", cal_tm_ptr->tm_year % 100, cal_tm_ptr->tm_mon + 1, cal_tm_ptr->tm_mday, cal_tm_ptr->tm_hour, cal_tm_ptr->tm_min, cal_tm_ptr->tm_sec);

输出的第二部分 Per second averages calculated from the last 47 seconds Code: srv_printf_innodb_monitor current_time = time(NULL); time_elapsed = difftime(current_time, srv_last_monitor_time) + 0.001; srv_last_monitor_time = time(NULL); fprintf(file, " INNODB MONITOR OUTPUT" "=====================================" "Per second averages calculated from the last %lu seconds", (ulong)time_elapsed); 这里time_elapsed是两次运行show engine innodb status命令的时间差，或者....

因为这个srv_last_monitor_time参数对于srv_printf_innodb_monitor调用并不是不变的，换句话说 srv_last_monitor_time参数被srv_error_monitor_thread调用重置，时间大概在60S左右 Code srv_error_monitor_thread if (difftime(time(NULL), srv_last_monitor_time) > 60) { srv_refresh_innodb_monitor_stats(); } srv_refresh_innodb_monitor_stats srv_last_monitor_time = time(NULL); 当2次输出的间隔时间大于1分钟，那么这个时间就是上次thread刷新这个time参数的时间，如果小于1分钟，那么就是2次输出间隔的时间这个时间是用于统计每秒的平均量的

信号量部分 ---------- SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 30132, signal count 30124 Mutex spin waits 0, rounds 70204, OS waits 783 RW-shared spins 60295, OS waits 29303; RW-excl spins 39, OS waits 36 Code srv_printf_innodb_monitor fputs("----------" "SEMAPHORES" "----------", file); sync_print(file);

输出的第一部分 OS WAIT ARRAY INFO: reservation count 30132, signal count 30124 这部分是sync_array_print_info调用产生的（innobase/sync/sync0arr.c） Code sync_array_output_info fprintf(file, "OS WAIT ARRAY INFO: reservation count %ld, signal count %ld", (long) arr->res_count, (long) arr->sg_count); arr->res_count,arr->sg_count 这两个字段来自 wait array 结构 (innobase/sync/sync0arr.c ) struct sync_array_struct { ...... ulint sg_count; ulint res_count; } sg_count 表示给对象发送信号的累计数 res_count 表示 wait array 创建以来 slot 使用的总量（源代码写成 cell)

这两个参数在什么时候会累积？ sg_count mutex_exit调用 mutex_signal_object mutex_signal_object调用sync_array_object_signalled Code sync_array_object_signalled sync_array_enter(arr); arr->sg_count++; sync_array_exit(arr); 也就是说当 mutex 释放的时候 sg_count 会增加那么这个量反映了 mutex 释放的次数

res_count rw_lock_s_lock_spin,rw_lock_x_lock_func, mutex_spin_wait三个调用会调用 sync_array_reserve_cell code sync_array_reserve_cell arr->res_count++; 也就是说只有在获取读写的 S/X 锁 , 或者 mutex 的时候才会递增 res_count 参数举个例子，看下 rw_lock_s_lock_spin 中的代码

Code: rw_lock_s_lock_spin 首先是自旋等待 while (rw_lock_get_writer(lock) != RW_LOCK_NOT_LOCKED && i < SYNC_SPIN_ROUNDS) { if (srv_spin_wait_delay) { ut_delay(ut_rnd_interval(0, srv_spin_wait_delay)); } i++; } 自旋等待的时间耗完后放弃时间片，也就是让调度线程调度别的线程运行 if (i == SYNC_SPIN_ROUNDS) { os_thread_yield(); } 如果再次获得运行，则试图再次获得锁，如果失败则申请wait array cell if (TRUE == rw_lock_s_lock_low(lock, pass, file_name, line)) { mutex_exit(rw_lock_get_mutex(lock)); return; /* Success */ } else { ...... sync_array_reserve_cell(sync_primary_wait_array, lock, RW_LOCK_SHARED, file_name, line, &index);

注意到从自旋等待到申请wait array cell 最后代码是回到开头的自旋等待的，那么在申请wait array cell到回到开头执行自旋等待代码之间发生了什么？ Code rw_lock_s_lock_spin sync_array_wait_event(sync_primary_wait_array, index); sync_array_wait_event 得到刚申请的 cell cell = sync_array_get_nth_cell(arr, index); ...... event = ((rw_lock_t*) cell->wait_object)->event; ...... os_event_wait_low(event, cell->signal_count); 利用 cell 的信息来调用 os_event_wait_low ，那么在 os_event_wait_low 中又发生了什么？

code: os_event_wait_low 一直测试是否等待的事件被 set ，或者有信号发送，也就是说 thread 会阻塞在这里，直到条件满足才会返回，来执行释放 cell 的调用 for (;;) { if (event->is_set == TRUE || event->signal_count != old_signal_count) { os_fast_mutex_unlock(&(event->os_mutex)); if (srv_shutdown_state == SRV_SHUTDOWN_EXIT_THREADS) { os_thread_exit(NULL); } /* Ok, we may return */ return; } pthread_cond_wait(&(event->cond_var), &(event->os_mutex)); }

那么其他两个调用也是一样的情况当并发两比较大的时候wait array 有可见的被使用的cell，这时，输出可以看到这些被使用的cell的细节 --Thread 1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore: 6 Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0 7 waiters flag 0 8 wait is ending Code sync_array_output_info i = 0; count = 0; while (count < arr->n_reserved) { cell = sync_array_get_nth_cell(arr, i); if (cell->wait_object != NULL) { count++; sync_array_cell_print(file, cell); } i++; }

code sync_array_cell_print fprintf(file, "--Thread %lu has waited at %s line %lu" " for %.2f seconds the semaphore:", (ulong) os_thread_pf(cell->thread), cell->file, (ulong) cell->line, difftime(time(NULL), cell->reservation_time)); 那么第1个是thread id,第2，3个参数是申请锁的位置，第4个是保留这个cell的时间，也就是距离申请wait array cell的时间 fprintf(file, "Mutex at %p created file %s line %lu, lock var %lu" "waiters flag %lu", (void*) mutex, mutex->cfile_name, (ulong) mutex->cline, (ulong) mutex->lock_word,(ulong) mutex->waiters); 第1个参数mutex的内存位置，第2，3个参数为mutex创建的位置,第4个参数是test and set原子操作的目标值，第5个参数为是否有threads在mutex上等待（1为有threads等待）

输出的第二部分 sync_print_wait_info调用打印等待读写S/X锁和mutex的信息 Code: sync_print_wait_info fprintf(file, "Mutex spin waits %lu, rounds %lu, OS waits %lu" "RW-shared spins %lu, OS waits %lu;" " RW-excl spins %lu, OS waits %lu", (ulong) mutex_spin_wait_count, (ulong) mutex_spin_round_count, (ulong) mutex_os_wait_count, (ulong) rw_s_spin_wait_count, (ulong) rw_s_os_wait_count, (ulong) rw_x_spin_wait_count, (ulong) rw_x_os_wait_count); 关于读写 s/x 锁， spin_wait 表示耗费 CPU 循环自旋等待的次数， os_wait 表示申请 wait array cell ，并等待信号量的次数，相比 CPU 耗费的自旋等待，系统的信号量分配操作更耗资源，另外关于 mutex 的 spin_wait 和 os_wait 解释同上， mutex_spin_round_count 表示什么？

事务部分 ------------ TRANSACTIONS ------------ Trx id counter 0 48406123 Purge done for trx's n:o < 0 48406107 undo n:o < 0 0 History list length 16 Total number of lock structs in row lock hash table 0 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 0 0, not started, process no 24942, OS thread id 1175292224 MySQL thread id 1193, query id 28543840 localhost root show engine innodb status ---TRANSACTION 0 48406039, not started, process no 24942, OS thread id 107810643 2 MySQL thread id 1190, query id 28543359 172.16.16.14 ecp ...... MySQL thread id 25, query id 28543836 Has read all relay log; waiting for the slave I/O thread to update it

Trx id counter 0 48406123 Purge done for trx's n:o < 0 48406107 undo n:o < 0 0 History list length 16 Total number of lock structs in row lock hash table 0 Code lock_print_info_summary fputs("------------" "TRANSACTIONS" "------------", file); fprintf(file, "Trx id counter %lu %lu", (ulong) ut_dulint_get_high(trx_sys->max_trx_id), (ulong) ut_dulint_get_low(trx_sys->max_trx_id)); 第 1 行显示的是未分配事务号，也就是即将分配给下一个新事务的事务号。事务系统结构 (trx_sys) 中的 max_trx_id 是个 double unsigned long int (64 位 ) 这里分别打印高 32 位值和低 32 位值

Code fprintf(file, "Purge done for trx's n:o < %lu %lu undo n:o < %lu %lu", (ulong) ut_dulint_get_high(purge_sys->purge_trx_no), (ulong) ut_dulint_get_low(purge_sys->purge_trx_no), (ulong) ut_dulint_get_high(purge_sys->purge_undo_no), (ulong) ut_dulint_get_low(purge_sys->purge_undo_no)); 这里打印的是purge系统的指针信息，第1个是所有id小于purge_trx_no的事务都已经被清理。第2个是所有undo no小于purge_undo_no的undo 记录都已经被清理，同样这2个值都是double unsigned long int类型

Code fprintf(file, "History list length %lu", (ulong) trx_sys->rseg_history_len); 这部分打印 history list 的长度，那么 history list 是什么，打个比方来说 history list 就是个存放垃圾的垃圾场，那么垃圾是什么，垃圾就是已经提交，并且有对记录做改动的事务，也就是产生 undo log 的事务 , 而清洁工就是 purge thread, 当它清理完一个事务的时候就减少 history list 的长度，而当有新的更新事务提交的时候这个垃圾场的垃圾量 (history list length) 就增加

Code fprintf(file, "Total number of lock structs in row lock hash table %lu", (ulong) lock_get_n_rec_locks()); lock_get_n_rec_locks(void) { lock_t* lock; ulint n_locks = 0; ulint i; ut_ad(mutex_own(&kernel_mutex)); for (i = 0; i < hash_get_n_cells(lock_sys->rec_hash); i++) { lock = HASH_GET_FIRST(lock_sys->rec_hash, i); while (lock) { n_locks++; lock = HASH_GET_NEXT(hash, lock); } } return(n_locks); }

Code struct lock_sys_struct{ hash_table_t* rec_hash; } rec_hash 存储的是 lock_struct,lock_struct 中的 hash 存储的是 record ????? 那么由代码可以知道统计的是这个 rec_hash 中存储的锁结构的数目（注意这里不是记录锁的个数，一个锁结构中用一个 hash 记录所有该结构中的 record lock), 见下面代码 Code struct lock_struct { ...... hash_node_t hash; 用于记录锁 dict_index_t* index; 用于记录锁 union { lock_table_t tab_lock;/* table lock */ lock_rec_t rec_lock;/* record lock */ } un_member; };

接下来的部分是打印目前执行事务的具体信息 Code lock_print_info_all_transactions fprintf(file, "LIST OF TRANSACTIONS FOR EACH SESSION:"); trx = UT_LIST_GET_FIRST(trx_sys->mysql_trx_list); while (trx) { if (trx->conc_state == TRX_NOT_STARTED) { fputs("---", file); trx_print(file, trx, 600); } trx = UT_LIST_GET_NEXT(mysql_trx_list, trx); } 首先打印的是未开始的事务，具体打印代码在 trx_print 调用中

---TRANSACTION 0 48412790 , not started, process no 24942 , OS thread id 1078106432 Code t rx_print fprintf(f, "TRANSACTION %lu %lu", (ulong) ut_dulint_get_high(trx->id), (ulong) ut_dulint_get_low(trx->id)); switch (trx->conc_state) { case TRX_NOT_STARTED: fputs(", not started", f); Break; ...... fprintf(f, ", process no %lu", trx->mysql_process_no); fprintf(f, ", OS thread id %lu", (ulong) os_thread_pf(trx->mysql_thread_id)); 第一个参数为事务 id, 第 2 个参数为 mysql 进程 id, 第 3 个为该事务的 OS 线程 id （？？）

MySQL thread id 1190 , query id 28655384 172.16.16.14 ecp Code innobase_mysql_print_thd fputs(thd_security_context(thd, buffer, sizeof(buffer), max_query_len), f); thd_security_context len= my_snprintf(header, sizeof(header), "MySQL thread id %lu, query id %lu", thd->thread_id, (ulong) thd->query_id); 第 1 个参数是 mysql 线程 id, 第 2 个参数是查询 id, 后面的是访问信息

How the mysql> show engine innodb status command is processed internally in InnoDB

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to How the mysql> show engine innodb status command is processed internally in InnoDB

Similar to How the mysql> show engine innodb status command is processed internally in InnoDB (20)

Recently uploaded

Recently uploaded (20)

How the mysql> show engine innodb status command is processed internally in InnoDB