自己做的网站怎么放到网上去,求一个做烧肉的网站,asp网站建设报告书,阿里云怎么安装wordpress【问题】最近查看MySQL的error log文件时#xff0c;发现有很多服务器的文件中有大量的如下日志#xff0c;内容很长(大小在200K左右)#xff0c;从记录的内容看#xff0c;并没有明显的异常信息。有一台测试服务器也有类似的问题#xff0c;为什么会记录这些信息#xf…【问题】最近查看MySQL的error log文件时发现有很多服务器的文件中有大量的如下日志内容很长(大小在200K左右)从记录的内容看并没有明显的异常信息。有一台测试服务器也有类似的问题为什么会记录这些信息是谁记录的这些信息分析的过程比较周折。Status information:Current dir:Running threads: 2452 Stack size: 262144Current locks:lock: 0x7f783f5233f0:Key caches:defaultBuffer_size: 8388608Block_size: 1024Division_limit: 100Age_limit: 300blocks used: 10not flushed: 0w_requests: 6619writes: 1r_requests: 275574reads: 1235handler status:read_key: 32241480828read_next: 451035381896read_rnd 149361175read_first: 1090473write: 4838429521delete 12155820update: 3331297842【分析过程】1、首先在官方文档中查到当mysqld进程收到SIGHUP信号量时就会输出类似的信息On Unix, signals can be sent to processes.mysqldresponds to signals sent to it as follows:SIGHUPcauses the server to reload the grant tables and to flush tables, logs, the thread cache, and the host cache. These actions are like various forms of theFLUSHstatement. The server also writes a status report to the error log that has this format:2、有别的程序在kill mysqld进程吗用systemtap脚本监控kill命令probe nd_syscall.kill{target[tid()] uint_arg(1);signal[tid()] uint_arg(2);}probe nd_syscall.kill.return{if (target[tid()] ! 0) {printf(%-6d %-12s %-5d %-6d %6d\n, pid(), execname(),signal[tid()], target[tid()], int_arg(1));delete target[tid()];delete signal[tid()];}}用下面命令测试确实会在error log中记录日志kill -SIGHUP 12455从systemtap的输出看到12455就是mysqld进程被kill掉了信号量是1对应的就是SIGHUP不过在测试环境后面问题重现时却没有抓到SIGHUP的信号量。FROM COMMAND SIG TO RESULT17010 who 0 12153 134042960036681 bash 1 12455 6423、看来并不是kill导致的后面用gdb attach到mysqld进程上在error log的三个入口函数sql_print_errorsql_print_warningsql_print_information加上断点但是在问题重现时程序并没有停在断点处4、写error log还有别的分支吗翻源码找到了答案原来是通过mysql_print_status函数直接写到error log中void mysql_print_status(){char current_dir[FN_REFLEN];STATUS_VAR current_global_status_var;printf(\nStatus information:\n\n);(void) my_getwd(current_dir, sizeof(current_dir),MYF(0));printf(Current dir: %s\n, current_dir);printf(Running threads: %u Stack size: %ld\n,Global_THD_manager::get_instance()-get_thd_count(),(long) my_thread_stack_size);…puts();fflush(stdout);}5、再次用gdb attach到mysqld进程上在mysql_print_status函数上加断点在问题重现时线程停在断点处通过ps的结果多次对比判断是pt-stalk工具运行时调用了mysql_print_status6、从堆栈中看到dispatch_command调用了mysql_print_status下面是具体的逻辑当commandCOM_DEBUG时就会执行到mysql_print_statuscase COM_DEBUG:thd-status_var.com_other;if (check_global_access(thd, SUPER_ACL))break; /* purecov: inspected */mysql_print_status();query_logger.general_log_print(thd, command, NullS);my_eof(thd);break;7、查看pt-stalk的代码if [ $mysql_error_log -a ! $OPT_MYSQL_ONLY ]; thenlog The MySQL error log seems to be $mysql_error_logtail -f $mysql_error_log $d/$p-log_error tail_error_log_pid$!$CMD_MYSQLADMIN $EXT_ARGV debugelselog Could not find the MySQL error log在调用mysqladmin时使用了debug模式debug Instruct server to write debug information to log8、在percona官网上搜到了相关的bug描述目前bug还未修复会在下个版本中3.0.13中修复。https://jira.percona.com/browse/PT-1340【解决方案】定位到问题后实际修复也比较简单将pt-stalk脚本中$CMD_MYSQLADMIN $EXT_ARGV debug中的debug去掉就可以了测试生效。
