Bookmarks

Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries

sqldatasource dal, wwwxxxenden, convert raid5 to raid 10 mdadm, apache force chunked, nrao wwwxxx, xxxxxdup, procmail change subject header, wwwXxx not20, Wwwxxx.doks sas, linux raid resync after reboot

Links

XODOX
Impressum

#1: Crash After Setting "wait_timeout" Parameter

Posted on 2011-09-30 16:29:08 by Emre Hasegeli

--------------080302080109090303020908
Content-Type: multipart/alternative;
boundary="------------010501010901040002020505"


--------------010501010901040002020505
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Our master database server crashed first time after two years. We are
using Debian GNU/Linux 6.0 with Linux 2.6.32-5-amd64. We have updated
the MySQL server to 5.5.11 two months ago from MySQL binaries. All of
the tables use InnoDB storage engine. The server responds in average 2k
query per second.

"wait_timeout" parameter had set to 120 from 300 on the morning of the
day the crash happened. The server crashed at the evening and restart
itself successfully. We could not find anything significant about the
crash. There were nothing unusual, no load, not many connections, not
any log query. Is there any chance that the "wait_timeout" parameter
caused the crash?

The error log of the server for the crash is attached.

--
Emre Hasegeli
Veri Tabanñ Yöneticisi
Tart ðnternet Teknolojileri AÃÂ
tart.com.tr



--------------010501010901040002020505
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Our master database server crashed first time after two years. We
are using Debian GNU/Linux 6.0 with Linux 2.6.32-5-amd64. We have
updated the MySQL server to 5.5.11 two months ago from MySQL
binaries. All of the tables use InnoDB storage engine. The server
responds in average 2k query per second.<br>
<br>
"wait_timeout" parameter had set to 120 from 300 on the morning of
the day the crash happened. The server crashed at the evening and
restart itself successfully. We could not find anything significant
about the crash. There were nothing unusual, <span
class="Apple-style-span" style="border-collapse: separate; color:
rgb(0, 0, 0); font-family: Arial,Helvetica,sans-serif; font-size:
12px; font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;"></span>no load, not many
connections, not any log query. Is there any chance that the
"wait_timeout" parameter caused the crash?<br>
<br>
The error log of the server for the crash is attached.<br>
<pre class="moz-signature" cols="72">
--
Emre Hasegeli
Veri Tabanñ Yöneticisi
Tart ðnternet Teknolojileri AÃÂ
tart.com.tr

</pre>
</body>
</html>

--------------010501010901040002020505--

--------------080302080109090303020908
Content-Type: text/x-log;
name="error.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="error.log"

110929 18:02:59 - 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=33554432
read_buffer_size=2097152
max_used_connections=576
max_threads=575
thread_count=145
connection_count=145
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 5927313 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7fa284d0d8e0
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 = 0x7fa283d1fe80 thread_stack 0x30000
/system/mysql/bin/mysqld(my_print_stacktrace+0x39)[0x795f29]
/system/mysql/bin/mysqld(handle_segfault+0x380)[0x4fce00]
/lib/libpthread.so.0(+0xef60)[0x7fb638854f60]
/system/mysql/bin/mysqld(_ZN5Field10make_fieldEP10Send_field +0x19)[0x64dea9]
/system/mysql/bin/mysqld(_ZN10Item_field10make_fieldEP10Send _field+0x26)[0x670be6]
/system/mysql/bin/mysqld(_ZN8Protocol24send_result_set_metad ataEP4ListI4ItemEj+0x10b)[0x50c34b]
/system/mysql/bin/mysqld(_ZN11select_send24send_result_set_m etadataER4ListI4ItemEj+0x1d)[0x5474fd]
/system/mysql/bin/mysqld(_ZN28Select_fetch_protocol_binary24 send_result_set_metadataER4ListI4ItemEj+0x2e)[0x58431e]
/system/mysql/bin/mysqld(_ZN19Materialized_cursor4openEP4JOI N+0x103)[0x74dd73]
/system/mysql/bin/mysqld(_Z17mysql_open_cursorP3THDP13select _resultPP18Server_side_cursor+0x188)[0x74e558]
/system/mysql/bin/mysqld(_ZN18Prepared_statement7executeEP6S tringb+0x1e0)[0x584b00]
/system/mysql/bin/mysqld(_ZN18Prepared_statement12execute_lo opEP6StringbPhS2_+0x7c)[0x587a2c]
/system/mysql/bin/mysqld(_Z19mysqld_stmt_executeP3THDPcj+0x1 75)[0x587fb5]
/system/mysql/bin/mysqld(_Z16dispatch_command19enum_server_c ommandP3THDPcj+0xc71)[0x578ea1]
/system/mysql/bin/mysqld(_Z24do_handle_one_connectionP3THD+0 x337)[0x60d077]
/system/mysql/bin/mysqld(handle_one_connection+0x54)[0x60d0e 4]
/lib/libpthread.so.0(+0x68ba)[0x7fb63884c8ba]
/lib/libc.so.6(clone+0x6d)[0x7fb637aee02d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x98a8b478): SHOW DATABASES
Connection ID (thread ID): 284732004
Status: 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.
110929 18:03:02 mysqld_safe Number of processes running now: 0
110929 18:03:02 mysqld_safe mysqld restarted



--------------080302080109090303020908
Content-Type: text/plain; charset=us-ascii


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
--------------080302080109090303020908--

Report this message