mysql无故重启

lys0212linux

我昨晚将key_buffer_size由原来的512M调为1G，今天凌晨没自动重启了，我不知是巧合还是什么，继续观察。另外我这两天用mysqlreport和top命令每隔10分钟采集一次数据，并将数据导入到一个数据库中。正在分析这些数据的变化规律，特别是重启前后的变化。很快就有初步的分析结果了，分析出的结果敬请大家跟帖帮我解惑。

lys0212linux

通过mysqlreport三天的采集数据，初步分析到在重启前变化较大的有
Com_            3.95M   262.8/s          108.92
  set_option    1.33M    88.6/s           36.71
  stmt_prepar 490.89k    32.7/s           13.55
  execute_sql 490.89k    32.7/s           13.55变为
Com_            4.05M   259.3/s          107.64
  set_option    1.37M    87.7/s           36.41
  stmt_prepar 502.70k    32.2/s           13.37
  prepare_sql 502.70k    32.2/s           13.37也就是说execute_sql 变成了prepare_sql
正常时一直都是execute_sql没有prepare_sql 这栏，但这几天的3次重启前几分钟都出现execute_sql 变成了prepare_sql
我现在还搞不清mysql的prepare_sql 究竟做了什么操作。安装官方文档说Com_这个值应该比较低才好，可是从采集的信息看Com_比DMS的值还高。

__ Questions ___________________________________________________________
Total           3.62M   241.3/s
  Com_          3.95M   262.8/s  %Total: 108.92
  -Unknown      3.44M   229.4/s           95.07
  DMS           1.72M   114.4/s           47.39
  COM_QUIT    841.96k    56.1/s           23.24
  QC Hits     562.03k    37.4/s           15.52
Slow 1 s        1.34k     0.1/s            0.04  %DMS:   0.08  Log: OFF

Com_   和  -Unknown 占%Total: 竟然是DMS两倍还多，太不正常了。

lys0212linux

这两次自动重启的信息有了点变化，难道真是压力大造成mysql自动重启？
100915  3:34:47 - mysqld got signal 11 ;
100915 03:34:48 mysqld_safe Number of processes running now: 0
100915 03:34:48 mysqld_safe mysqld restarted
100915  3:34:48 [Warning] '--default-character-set' is deprecated and will be removed in a future release. Please use '--character-s
et-server' instead.
100915  3:34:49 [Warning] '--skip-locking' is deprecated and will be removed in a future release. Please use '--skip-external-lockin
g' instead.
100915  3:34:49  InnoDB: Started; log sequence number 0 44233
100915  3:34:49 [Warning] Storage engine 'SPHINX' has conflicting typecode. Assigning value 42.
100915  3:34:49 [Note] Recovering after a crash using mysql-bin
100915  3:34:54 [Note] Starting crash recovery...
100915  3:34:54 [Note] Crash recovery finished.
100915  3:34:54 [Warning] 'user' entry '@mysql.baicai.com' ignored in --skip-name-resolve mode.
100915  3:34:54 [Warning] 'user' entry 'ftpusers@*' ignored in --skip-name-resolve mode.
100915  3:34:54 [Warning] 'user' entry 'ftpusers@192.168.2.135,192.168.2.134,192.168.2.133' ignored in --skip-name-resolve mode.
100915  3:34:54 [Warning] 'db' entry 'ftpusers ftpusers@*' ignored in --skip-name-resolve mode.
100915  3:34:54 [Warning] 'db' entry 'ftpusers ftpusers@192.168.2.135,192.168.2.134,192.168.2.133' ignored in --skip-name-resolve mo
de.
100915  3:34:54 [Note] Event Scheduler: Loaded 0 events
100915  3:34:54 [Note] /web/software/mysql/libexec/mysqld: ready for connections.
100915  3:34:56 [ERROR] /web/software/mysql/libexec/mysqld: Table './jobui_snatch/tb_snatch_position_info_48' is marked as crashed a
nd should be repaired

cindy9902

遇到这样的问题，可不可以通过生成core-file，然后用gdb看stack trace来得到一些有用信息呢？至少可以知道mysql在crash前做了些什么事情。
不知道在具体的应用中，会不会开core-file这个选项。。。

lys0212linux

通过采集数据发现重启前系统负载由3,3,3（这个数为大约数)升为30.60, 30.16, 25.72 ，mysql占的cpu由40左右升到200左右，10几分钟后mysql就重启了。平常的cpu占用一般在40左右。
还有一点值得注意的是，重启前10分钟current used key_buffer的值由100%下降到60%以下，重启后在一两个小时后又上升到100%。搞不明白重启前key_buffer的使用为什么会下降。

lys0212linux

回复 24# cindy9902


    用gdb看stack trace，老兄，能不能详细说下

cindy9902

这个需要在启动的时候配置文件里添加core-file的启动选项。。而且在crash后需要一段时间去进行core dump, 所以我也不知道在实际应用中有没有把这个选项打开，有没有必要进行代码级别的分析。。。
也想听听大家的意见。。

litdong

gdb [exec file] [core file]
gdb ./test test.core
再执行bt

或者用dbx也可以

daveyhook

看你的日志
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 33837648 K

33837648 K是多少M，自己算一下。- -!

max_threads=2048
蛋疼啊，设置这么大。

trt2008

楼主的问题解决了吗