Hello everyone. I've got a MySQL server that behaves wonderfully...most of the time. It has crashed three times this week and I'm at a loss for why.
Below I've included all the following: error.log os info memory check results from resolve_stack_dump my.cnf Does the information point toward a problem you can see? Thanks in advance. >>> >>> >>> >>> >>> error.log 050510 15:57:48 InnoDB: Started 050510 15:57:49 Found invalid password for user: '5014'@'10.0.%'; Ignoring user /usr/libexec/mysqld: ready for connections. Version: '4.0.23a-log' socket: '/var/run/mysql/mysql.sock' port: 3306 Source distribution 050511 14:52:19 Found invalid password for user: '5014'@'10.0.%'; Ignoring user 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=1073741824 read_buffer_size=1044480 max_used_connections=125 max_connections=150 threads_connected=65 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3659174 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=(nil) 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... Cannot determine thread, fp=0xbffff068, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81048f1 0xb7f83c85 0xb7e4633e 0xb7e437a3 0x82d0163 0x82ce417 0x82cfee1 0x80f9080 0x81065ea 0x8105964 0xb7df7469 0x80b62b1 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. 050512 9:43:47 InnoDB: Started 050512 9:43:47 Found invalid password for user: '5014'@'10.0.%'; Ignoring user /usr/libexec/mysqld: ready for connections. Version: '4.0.23a-log' socket: '/var/run/mysql/mysql.sock' port: 3306 Source distribution >>> >>> >>> >>> >>> slackware linux info uname - a Linux b5 2.6.11 #1 SMP Sat Apr 16 23:35:33 MDT 2005 i686 unknown unknown GNU/Linux >>> >>> >>> >>> >>> memory check: googled "3659174 KB in MB "==> 3 659 174 kilobytes = 3 573.41211 megabytes this machine has 4GB RAM 4GB in MB ==> 4 gigabytes = 4 096 megabytes 4 096 - 3 573.41211 = 522.58789 1/2GB RAM available for non-mysql functionality is more than enough, right? >>> >>> >>> >>> >>> i ran resolve_stack_dump on the backtrace from error.log per http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html resolve_stack_dump -s ./mysqld.sym -n ./mysqld.stack and got the results below, but the information provided doesn't mean anything to me now what? 0x81048f1 handle_segfault + 641 0xb7f83c85 _end + -1346321187 0xb7e4633e _end + -1347621994 0xb7e437a3 _end + -1347633157 0x82d0163 my_malloc + 35 0x82ce417 init_io_cache + 295 0x82cfee1 open_cached_file + 145 0x80f9080 _ZN3THDC1Ev + 928 0x81065ea handle_connections_sockets + 666 0x8105964 main + 2180 0xb7df7469 _end + -1347945279 0x80b62b1 _start + 33 >>> >>> >>> >>> >>> my.cnf [mysqld] # BASICS datadir=/var/lib/mysql pid_file=/var/run/mysql/mysql.pid port=3306 socket=/var/run/mysql/mysql.sock tmpdir=/tmp/ tmp_table_size=64M max_connections=150 # IMHO, long_query_time=6 is too big...but we'll lower this after nailing the worst offenders long_query_time=6 log_long_format # /var/log/mysqld doesn't exist by default, so i created it and ran chown mysql:mysql on it log_slow_queries=/var/log/mysqld/slow.log log_error=/var/log/mysqld/error.log # discourages brute force attacks, unblock blocked hosts with FLUSH HOSTS max_connect_errors=5 # # REPLICATION server_id=1 read_only=OFF # security hazard...a client with the SUPER privilege can disable binary logging of its own statements by using a SET SQL_LOG_BIN=0 log_bin=b5 # *ignores errors re: revokation of non-existent grants Error: 1147 SQLSTATE: 42000 slave-skip-errors=1147 max_allowed_packet=16M character_set=latin1 # # PERFORMANCE TUNING (low_priority_updates, max_join_size and max_seeks_for_key feel a bit bleeding-edge and should be removed if the results suck) # low_priority_updates makes INSERT, UPDATE AND lower priority than SELECT and LOCK TABLE low_priority_updates=ON max_join_size=32M max_seeks_for_key=100 # caches table_cache=768 max_binlog_cache_size=2GB binlog_cache_size=999MB thread_cache_size=50 # wait_timeout=300 # buffers key_buffer_size=1GB sort_buffer_size=16M read_buffer_size=1M # # ADMINISTRATION # when skip_networking is not commented connectivity happens only through direct access to the file specified in `socket` # skip_networking # [client] port=3306 socket=/var/run/mysql/mysql.sock -- I detest life-insurance agents; they always argue that I shall some day die, which is not so. * Stephen Leacock (1869 - 1944) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
