4台机器,硬件,os,mysql,所有配置均相同,但只有这一台的mysql每天crash好几次,其它机器正常。TOP:
Mem:   2074480k total,  2020780k used,    53700k free,    43620k buffers
Swap:  2105272k total,     8404k used,  2096868k free,   985916k cached  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                 
 4966 mysql     16   0 1271m 862m 2448 S    1 42.6   2:46.67 mysqld                                                                           
 5084 mysql     16   0 1271m 862m 2448 D    1 42.6   0:13.20 mysqld                                                                           
 5087 mysql     15   0 1271m 862m 2448 S    1 42.6   2:20.70 mysqld uname -a:
Linux 2.6.16.21-0.8 #1 SMP Fri Jan 12 10:49:15 CST 2007 i686 i686 i386 GNU/Linuxmysql version:
Server version          4.0.21-standard
Protocol version        10table in mysql:  30 database X 200 tables = 6000 tablesmysqladmin status:
Uptime: 42039  Threads: 11  Questions: 7078436  Slow queries: 61  Opens: 9350  Flush tables: 1  Open tables: 5120  Queries per second avg: 168.378some my.cnf:
skip-locking
key_buffer = 384M
max_allowed_packet = 1M
table_cache = 5120
default-table-type = InnoDB
sort_buffer_size = 2M
read_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache = 32
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 32innodb_data_file_path = ibdata1:2000M;ibdata2:2000M;.....ibdata32:2000M:autoextend
innodb_buffer_pool_size = 700M
innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_files_in_group = 20
innodb_log_file_size = 50M
innodb_log_buffer_size = 16M
innodb_flush_log_at_trx_commit = 0
innodb_thread_concurrency = 32
innodb_flush_method = O_DSYNC
#innodb_lock_wait_timeout = 50
mysql error log:
Number of processes running now: 0
070325 16:41:02  mysqld restarted
070325 16:41:02 Warning: Asked for 196608 thread stack, but got 126976
070325 16:41:02  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 18 1373351472
InnoDB: Doing recovery: scanned up to log sequence number 18 1378594304
InnoDB: Doing recovery: scanned up to log sequence number 18 1383837184
InnoDB: Doing recovery: scanned up to log sequence number 18 1389080064
InnoDB: Doing recovery: scanned up to log sequence number 18 1394189894
070325 16:41:03  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
070325 16:47:02  InnoDB: Flushing modified pages from the buffer pool...
070325 16:47:53  InnoDB: Started
/usr/local/mysql/bin/mysqld: ready for connections.
Version: '4.0.21-standard'  socket: '/tmp/mysql.sock'  port: 3306  Official MySQL-standard binary
070325 23:30:11InnoDB: Assertion failure in thread 77844 in file btr0cur.c line 3565
InnoDB: Failing assertion: copied_len < local_len + extern_len
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. See section 6.1 of
InnoDB: http://www.innodb.com/ibman.php about forcing recovery.
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=402653184
read_buffer_size=2093056
max_used_connections=10
max_connections=100
threads_connected=11
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.thd=0x699759e0
InnoDB: Thread 36874 stopped in file os0sync.c line 501
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=0xbfbfe2a8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8070c40
0x8261678
0x816e27e
0x816e41f
0x813649d
0x813a7f7
0x80ccf44
0x80cd19f
InnoDB: Thread 53262 stopped in file ha_innodb.cc line 472
InnoDB: Thread 40971 stopped in file ha_innodb.cc line 472
....
0x825ee2c
0x82948eaNew value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x9743f90 = SELECT /*!40001 SQL_NO_CACHE */ * FROM `UserIdx_21`
thd->thread_id=651
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.
InnoDB: Thread 57359 stopped in file ha_innodb.cc line 472