免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
123下一页
最近访问板块 发新帖
查看: 11156 | 回复: 29
打印 上一主题 下一主题

mysql无故重启 [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2010-09-07 11:55 |只看该作者 |倒序浏览
本帖最后由 lys0212linux 于 2010-09-07 13:05 编辑

服务器内存为16G:
日志如下:
00907  3:08:17 [Note] Event Scheduler: Loaded 0 events
100907  3:08:17 [Note] /web/software/mysql/libexec/mysqld: ready for connections.
Version: '5.1.48-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
100907  7:51:42 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=268435456
read_buffer_size=8388608
max_used_connections=414
max_threads=2048
threads_connected=32
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 33837648 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x23581000
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x460890e0 thread_stack 0x40000
/web/software/mysql/libexec/mysqld(my_print_stacktrace+0x24) [0x929a2d]
/web/software/mysql/libexec/mysqld(handle_segfault+0x2f3) [0x62b763]
/lib64/libpthread.so.0 [0x394d40e7c0]
/usr/local/lib/libunwind.so.7 [0x7f0bc449aeb6]
/usr/local/lib/libunwind.so.7 [0x7f0bc4497939]
/usr/local/lib/libunwind.so.7 [0x7f0bc4497794]
/usr/local/lib/libunwind.so.7 [0x7f0bc4497d11]
/usr/local/lib/libunwind.so.7 [0x7f0bc449894d]
/usr/local/lib/libunwind.so.7(_ULx86_64_step+0x1d) [0x7f0bc449bc4d]
/usr/local/lib/libtcmalloc.so.0(GetStackTrace(void**, int, int)+0x92) [0x7f0bc46dda0e]
/usr/local/lib/libtcmalloc.so.0 [0x7f0bc46c296c]
/usr/local/lib/libtcmalloc.so.0(malloc+0x29f) [0x7f0bc46df0e5]
/web/software/mysql/libexec/mysqld(my_malloc+0x24) [0x91796f]
/web/software/mysql/libexec/mysqld(alloc_root+0x77) [0x918017]
/web/software/mysql/libexec/mysqld(Query_arena::alloc(unsigned long)+0x21) [0x553061]
/web/software/mysql/libexec/mysqld [0x54f5ab]
/web/software/mysql/libexec/mysqld(MYSQLlex(void*, void*)+0x13ad) [0x550e49]
/web/software/mysql/libexec/mysqld(MYSQLparse(void*)+0x24 [0x657dd8]
/web/software/mysql/libexec/mysqld(parse_sql(THD*, Parser_state*, Object_creation_ctx*)+0x4c) [0x633a8e]
/web/software/mysql/libexec/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0xd9) [0x64200d]
/web/software/mysql/libexec/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xc6 [0x64376e]
/web/software/mysql/libexec/mysqld(do_command(THD*)+0x146) [0x6449ca]
/web/software/mysql/libexec/mysqld(handle_one_connection+0x156) [0x6334a6]
/lib64/libpthread.so.0 [0x394d4064a7]
/lib64/libc.so.6(clone+0x6d) [0x394ccd3c2d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...

thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
pure virtual method called
terminate called without an active exception
Fatal signal 6 while backtracing
100907 07:51:43 mysqld_safe Number of processes running now: 0
100907 07:51:43 mysqld_safe mysqld restarted
100907  7:51:43 [Warning] '--default-character-set' is deprecated and will be removed in a future release. Please use '--character-set-server' instead.
100907  7:51:43 [Warning] '--skip-locking' is deprecated and will be removed in a future release. Please use '--skip-external-locking' instead.
100907  7:51:44  InnoDB: Started; log sequence number 0 44233
100907  7:51:44 [Warning] Storage engine 'SPHINX' has conflicting typecode. Assigning value 42.
100907  7:51:44 [Note] Recovering after a crash using mysql-bin
100907  7:51:54 [Note] Starting crash recovery...
100907  7:51:54 [Note] Crash recovery finished.
100907  7:51:54 [Warning] 'user' entry '@mysql.baicai.com' ignored in --skip-name-resolve mode.
100907  7:51:54 [Warning] 'user' entry 'ftpusers@*' ignored in --skip-name-resolve mode.
100907  7:51:54 [Warning] 'user' entry 'ftpusers@192.168.2.135,192.168.2.134,192.168.2.133' ignored in --skip-name-resolve mode.
100907  7:51:54 [Warning] 'db' entry 'ftpusers ftpusers@*' ignored in --skip-name-resolve mode.
100907  7:51:54 [Warning] 'db' entry 'ftpusers ftpusers@192.168.2.135,192.168.2.134,192.168.2.133' ignored in --skip-name-resolve mode.
100907  7:51:54 [Note] Event Scheduler: Loaded 0 events
100907  7:51:54 [Note] /web/software/mysql/libexec/mysqld: ready for connections.
Version: '5.1.48-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution

论坛徽章:
0
2 [报告]
发表于 2010-09-07 14:35 |只看该作者
我感觉是key_buffer_size=268435456
read_buffer_size=8388608
这两个参数的问题,对照自己的表的引擎,看key_buffer_size是否设大了。
read_buffer_size=8388608
我感觉是设大了,你设2M,看看

论坛徽章:
0
3 [报告]
发表于 2010-09-07 16:27 |只看该作者
key_buffer_size 260M应该不会大。
read_buffer_size设为2M对性能有什么影响?

论坛徽章:
0
4 [报告]
发表于 2010-09-09 09:26 |只看该作者
换了5.1.50版本,还是出现自动重启问题。
100909  3:34:41 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=536870912
read_buffer_size=8388608
max_used_connections=1441
max_threads=2048
threads_connected=92
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 34099872 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x22b07000
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x4542f0e0 thread_stack 0x40000
/web/software/mysql/libexec/mysqld(my_print_stacktrace+0x24) [0x92cafd]
/web/software/mysql/libexec/mysqld(handle_segfault+0x2f3) [0x62ca0b]
/lib64/libpthread.so.0 [0x394d40e7c0]
/usr/local/lib/libunwind.so.7 [0x7f1060e38eb6]
/usr/local/lib/libunwind.so.7 [0x7f1060e35939]
/usr/local/lib/libunwind.so.7 [0x7f1060e35794]
/usr/local/lib/libunwind.so.7 [0x7f1060e35d11]
/usr/local/lib/libunwind.so.7 [0x7f1060e3694d]
/usr/local/lib/libunwind.so.7(_ULx86_64_step+0x1d) [0x7f1060e39c4d]
/usr/local/lib/libtcmalloc.so.0(GetStackTrace(void**, int, int)+0x92) [0x7f106107ba0e]
/usr/local/lib/libtcmalloc.so.0 [0x7f106106096c]
/usr/local/lib/libtcmalloc.so.0(malloc+0x29f) [0x7f106107d0e5]
/web/software/mysql/libexec/mysqld(my_malloc+0x24) [0x91a91f]
/web/software/mysql/libexec/mysqld(alloc_root+0x77) [0x91afc7]
/web/software/mysql/libexec/mysqld(SQL_SELECT::test_quick_select(THD*, Bitmap<64u>, unsigned long long, unsigned long
long, bool)+0x49f) [0x7443ad]
/web/software/mysql/libexec/mysqld [0x6b7e20]
/web/software/mysql/libexec/mysqld [0x6bc980]
/web/software/mysql/libexec/mysqld(JOIN:ptimize()+0x86b) [0x6bee95]
/web/software/mysql/libexec/mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigne
d int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex
*)+0x22f) [0x6c2d93]
/web/software/mysql/libexec/mysqld(handle_select(THD*, st_lex*, select_result*, unsigned long)+0x1b5) [0x6c7c1d]
/web/software/mysql/libexec/mysqld [0x63a8ac]
/web/software/mysql/libexec/mysqld(mysql_execute_command(THD*)+0x7ab) [0x63b36f]
/web/software/mysql/libexec/mysqld(mysql_parse(THD*, char*, unsigned int, char const**)+0x27f) [0x64347f]
/web/software/mysql/libexec/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xcab) [0x644aa7]
/web/software/mysql/libexec/mysqld(do_command(THD*)+0x146) [0x645d20]
/web/software/mysql/libexec/mysqld(handle_one_connection+0x156) [0x63469e]
/lib64/libpthread.so.0 [0x394d4064a7]
/lib64/libc.so.6(clone+0x6d) [0x394ccd3c2d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x25272010 = SELECT * FROM jobui_snatch.tb_snatch_position_info WHERE SPI_CompanyID =8111485 AND SPI_Sn
atchTime >1283888000000
thd->thread_id=5337777
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
Fatal signal 6 while backtracing
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
mysqld: misc.cpp:103: int __cxa_pure_virtual(): Assertion `!"Aborted: pure virtual method called."' failed.
100909 03:34:44 mysqld_safe Number of processes running now: 0
100909 03:34:44 mysqld_safe mysqld restarted

论坛徽章:
9
每日论坛发贴之星
日期:2016-01-04 06:20:00数据库技术版块每日发帖之星
日期:2016-01-04 06:20:00每日论坛发贴之星
日期:2016-01-04 06:20:00数据库技术版块每日发帖之星
日期:2016-01-04 06:20:00IT运维版块每日发帖之星
日期:2016-01-04 06:20:00IT运维版块每日发帖之星
日期:2016-01-04 06:20:00综合交流区版块每日发帖之星
日期:2016-01-04 06:20:00综合交流区版块每日发帖之星
日期:2016-01-04 06:20:00数据库技术版块每周发帖之星
日期:2016-03-07 16:30:25
5 [报告]
发表于 2010-09-09 10:01 |只看该作者
是什么事件触发的有办法知道吗? sp?还是作业啥的? 想办法找一下重启发生的规律

论坛徽章:
0
6 [报告]
发表于 2010-09-09 10:17 |只看该作者
1、解决这样的问题,需要很扎实的mysql基础知识。

2、定期做个mysql性能监控报告,如mysqlreport mysqlard之类。分析MYSQL的运行状态,是不是MYSQL负载过大,导致运行不正常而crash.

3、细心观察和思考问题都可以解决的,前提你需要了解更多MYSQL的知识。


从楼主的报告中看。

key_buffer_size=268435456 256M
read_buffer_size=8388608
max_used_connections=414  最大连接数414

你的key_buffer只有256m,这个值大小的设置,通常为*.MYI值的大小,它只对MYISAM表起作用,你服务器内存16G。key_buffer却很小!难道你的数据库索引真的很小?


max_used_connections=414
这个明显表示,你的mysql在crash时,mysql存在大量的锁等待情况!写写操作,或读写操作,当你的mysql负载过大,自然会crash.

多学习一下基础知识。这样的问题比较好解决!我们最起码要判断问题所在,自己能解决的就自己解决,自己不能的就给开发人员!

论坛徽章:
0
7 [报告]
发表于 2010-09-09 11:05 |只看该作者
回复 4# lys0212linux


    1、mysql崩溃前,系统资源是否有异常?系统日志是否有报错?
    2、打开慢查询日志,找出可能引起mysql繁忙的语句
    3、从日志看,你没有用到innodb,是使用myisam,这样的话,在遇到更新、插入等操作时,就会锁表,会有很多连接等待
    4、你给mysql分配的内存太少了。换成innodb引擎,把innodb的缓冲池设为12G

论坛徽章:
0
8 [报告]
发表于 2010-09-09 11:16 |只看该作者
回复 6# todayhero


    谢谢您的回答。昨天我把mysql升级为5.1.50后,将key_buffer_size由原来的256M调整为512M后,今早3:45分还是出现自动重启。

论坛徽章:
0
9 [报告]
发表于 2010-09-09 11:52 |只看该作者
回复  lys0212linux


    1、mysql崩溃前,系统资源是否有异常?系统日志是否有报错?
    2、打开慢 ...
moonbingbing_cu 发表于 2010-09-09 11:05



    系统日志没有报错。慢查询日志倒很多内容。

论坛徽章:
0
10 [报告]
发表于 2010-09-09 12:19 |只看该作者
回复 8# lys0212linux


    你为什么把key_buffer_size设置为512M。做什么东西。都要有理有据的,不能乱试乱改的,没任何意思的!

关于内存的分配是

共享内存+(独立内存Xmax_connections)=实际物理内存!

你虽说有16G,实际能不能全被MYSQL用到都是一个未知数。都要通过MYSQL检测报告得到。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP