- 论坛徽章:
- 0
|
我的论坛服务器跑的是apache2.0.55加php4加mysql5.0.22
配置是至强3.0gcpu，8g内存，上面就跑了个论坛
这段时间来mysql会每隔一段时间，7，8个小时或是几天就会自动重启，日志如下贴出，那位知道是什么原因引起的吗？
Apr 10 14:16:03 xa26 mysqld[3845]: mysqld got signal 11;
Apr 10 14:16:03 xa26 mysqld[3845]: This could be because you hit a bug. It is also possible that this binary
Apr 10 14:16:03 xa26 mysqld[3845]: or one of the libraries it was linked against is corrupt, improperly built,
Apr 10 14:16:03 xa26 mysqld[3845]: or misconfigured. This error can also be caused by malfunctioning hardware.
Apr 10 14:16:03 xa26 mysqld[3845]: We will try our best to scrape up some info that will hopefully help diagnose
Apr 10 14:16:03 xa26 mysqld[3845]: the problem, but since we have already crashed, something is definitely wrong
Apr 10 14:16:03 xa26 mysqld[3845]: and this may fail.
Apr 10 14:16:03 xa26 mysqld[3845]:
Apr 10 14:16:03 xa26 mysqld[3845]: key_buffer_size=268435456
Apr 10 14:16:03 xa26 mysqld[3845]: read_buffer_size=1044480
Apr 10 14:16:03 xa26 mysqld[3845]: max_used_connections=39
Apr 10 14:16:03 xa26 mysqld[3845]: max_connections=768
Apr 10 14:16:03 xa26 mysqld[3845]: threads_connected=4
Apr 10 14:16:03 xa26 mysqld[3845]: It is possible that mysqld could use up to
Apr 10 14:16:03 xa26 mysqld[3845]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2618362 K
Apr 10 14:16:03 xa26 mysqld[3845]: bytes of memory
Apr 10 14:16:03 xa26 mysqld[3845]: Hope that's ok; if not, decrease some variables in the equation.
Apr 10 14:16:03 xa26 mysqld[3845]:
Apr 10 14:16:03 xa26 mysqld[3845]: thd=0x885fb4b0
Apr 10 14:16:03 xa26 mysqld[3845]: Attempting backtrace. You can use the following information to find out
Apr 10 14:16:03 xa26 mysqld[3845]: where mysqld died. If you see no messages after this, something went
Apr 10 14:16:03 xa26 mysqld[3845]: terribly wrong...
Apr 10 14:16:03 xa26 mysqld[3845]: Cannot determine thread, fp=0x9a6f6b38, backtrace may not be correct.
Apr 10 14:16:03 xa26 mysqld[3845]: Stack range sanity check OK, backtrace follows:
Apr 10 14:16:03 xa26 mysqld[3845]: 0x8189e29
Apr 10 14:16:03 xa26 mysqld[3845]: 0xffffe420
Apr 10 14:16:03 xa26 mysqld[3845]: (nil)
Apr 10 14:16:03 xa26 mysqld[3845]: 0x8221884
Apr 10 14:16:03 xa26 mysqld[3845]: 0x822160a
Apr 10 14:16:03 xa26 mysqld[3845]: 0x8221f05
Apr 10 14:16:03 xa26 mysqld[3845]: 0x81dedbe
Apr 10 14:16:03 xa26 mysqld[3845]: 0x81df764
Apr 10 14:16:03 xa26 mysqld[3845]: 0x81e5de4
Apr 10 14:16:03 xa26 mysqld[3845]: 0x81e66df
Apr 10 14:16:03 xa26 mysqld[3845]: 0x819ccaf
Apr 10 14:16:03 xa26 mysqld[3845]: 0x81a2835
Apr 10 14:16:03 xa26 mysqld[3845]: 0x81a2dff
Apr 10 14:16:03 xa26 mysqld[3845]: 0x81a3f36
Apr 10 14:16:03 xa26 mysqld[3845]: 0x81a48e1
Apr 10 14:16:03 xa26 mysqld[3845]: 0xb7f40341
Apr 10 14:16:03 xa26 mysqld[3845]: 0xb7d914ee
Apr 10 14:16:03 xa26 mysqld[3845]: New value of fp=(nil) failed sanity check, terminating stack trace!
Apr 10 14:16:03 xa26 mysqld[3845]: Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
Apr 10 14:16:03 xa26 mysqld[3845]: stack trace is much more helpful in diagnosing the problem, so please do
Apr 10 14:16:03 xa26 mysqld[3845]: resolve it
Apr 10 14:16:03 xa26 mysqld[3845]: Trying to get some variables.
Apr 10 14:16:03 xa26 mysqld[3845]: Some pointers may be invalid and cause the dump to abort...
Apr 10 14:16:03 xa26 mysqld[3845]: thd->query at 0x8b8fa18 = SELECT DISTINCT t.tid FROM pw_posts t WHERE t.fid NOT IN (-999,12,21,73,89,97,123,150,152,196,205,206,208,232) AND ifcheck=1 AND t.authorid IN(71) ORDER BY tid DESC LIMIT 500
Apr 10 14:16:03 xa26 mysqld[3845]: thd->thread_id=255993
Apr 10 14:16:03 xa26 mysqld[3845]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Apr 10 14:16:03 xa26 mysqld[3845]: information that should help you find out what is causing the crash.
Apr 10 14:16:03 xa26 mysqld_safe[16611]: Number of processes running now: 0
Apr 10 14:16:03 xa26 mysqld_safe[16613]: restarted
Apr 10 14:16:03 xa26 mysqld[16616]: 070410 14:16:03 InnoDB: Database was not shut down normally!
Apr 10 14:16:03 xa26 mysqld[16616]: InnoDB: Starting crash recovery.
Apr 10 14:16:03 xa26 mysqld[16616]: InnoDB: Reading tablespace information from the .ibd files...
Apr 10 14:16:03 xa26 mysqld[16616]: InnoDB: Restoring possible half-written data pages from the doublewrite
Apr 10 14:16:03 xa26 mysqld[16616]: InnoDB: buffer...
Apr 10 14:16:03 xa26 mysqld[16616]: 070410 14:16:03 InnoDB: Starting log scan based on checkpoint at
Apr 10 14:16:03 xa26 mysqld[16616]: InnoDB: log sequence number 7 585835023.
Apr 10 14:16:03 xa26 mysqld[16616]: InnoDB: Doing recovery: scanned up to log sequence number 7 585836134
Apr 10 14:16:03 xa26 mysqld[16616]: 070410 14:16:03 InnoDB: Starting an apply batch of log records to the database...
Apr 10 14:16:04 xa26 mysqld[16616]: InnoDB: Progress in percents: 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
Apr 10 14:16:04 xa26 mysqld[16616]: InnoDB: Apply batch completed
Apr 10 14:16:04 xa26 mysqld[16616]: InnoDB: Last MySQL binlog file position 0 124092, file name /var/log/mysql/mysql-bin.000031
Apr 10 14:16:04 xa26 mysqld[16616]: 070410 14:16:04 InnoDB: Started; log sequence number 7 585836134
Apr 10 14:16:04 xa26 mysqld[16616]: 070410 14:16:04 [Note] /usr/sbin/mysqld: ready for connections.
Apr 10 14:16:04 xa26 mysqld[16616]: Version: '5.0.22-Debian_0ubuntu6.06.2-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Debian Etch distribution
Apr 10 14:16:09 xa26 mysqld[16616]: mysqld got signal 11;
Apr 10 14:16:09 xa26 mysqld[16616]: This could be because you hit a bug. It is also possible that this binary
Apr 10 14:16:09 xa26 mysqld[16616]: or one of the libraries it was linked against is corrupt, improperly built,
Apr 10 14:16:09 xa26 mysqld[16616]: or misconfigured. This error can also be caused by malfunctioning hardware.
Apr 10 14:16:09 xa26 mysqld[16616]: We will try our best to scrape up some info that will hopefully help diagnose
Apr 10 14:16:09 xa26 mysqld[16616]: the problem, but since we have already crashed, something is definitely wrong
Apr 10 14:16:09 xa26 mysqld[16616]: and this may fail.
Apr 10 14:16:09 xa26 mysqld[16616]:
Apr 10 14:16:09 xa26 mysqld[16616]: key_buffer_size=268435456
Apr 10 14:16:09 xa26 mysqld[16616]: read_buffer_size=1044480
Apr 10 14:16:09 xa26 mysqld[16616]: max_used_connections=5
Apr 10 14:16:09 xa26 mysqld[16616]: max_connections=768
Apr 10 14:16:09 xa26 mysqld[16616]: threads_connected=2
Apr 10 14:16:09 xa26 mysqld[16616]: It is possible that mysqld could use up to
Apr 10 14:16:09 xa26 mysqld[16616]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2618362 K
Apr 10 14:16:09 xa26 mysqld[16616]: bytes of memory
Apr 10 14:16:09 xa26 mysqld[16616]: Hope that's ok; if not, decrease some variables in the equation.
Apr 10 14:16:09 xa26 mysqld[16616]:
Apr 10 14:16:09 xa26 mysqld[16616]: thd=0x8afd018
Apr 10 14:16:09 xa26 mysqld[16616]: Attempting backtrace. You can use the following information to find out
Apr 10 14:16:09 xa26 mysqld[16616]: where mysqld died. If you see no messages after this, something went
Apr 10 14:16:09 xa26 mysqld[16616]: terribly wrong...
Apr 10 14:16:09 xa26 mysqld[16616]: Cannot determine thread, fp=0x9a787b38, backtrace may not be correct.
Apr 10 14:16:09 xa26 mysqld[16616]: Stack range sanity check OK, backtrace follows:
Apr 10 14:16:09 xa26 mysqld[16616]: 0x8189e29
Apr 10 14:16:09 xa26 mysqld[16616]: 0xffffe420
Apr 10 14:16:09 xa26 mysqld[16616]: (nil)
Apr 10 14:16:09 xa26 mysqld[16616]: 0x8221884
Apr 10 14:16:09 xa26 mysqld[16616]: 0x822160a
Apr 10 14:16:09 xa26 mysqld[16616]: 0x8221f05
Apr 10 14:16:09 xa26 mysqld[16616]: 0x81dedbe
Apr 10 14:16:09 xa26 mysqld[16616]: 0x81df764
Apr 10 14:16:09 xa26 mysqld[16616]: 0x81e5de4
Apr 10 14:16:09 xa26 mysqld[16616]: 0x81e66df
Apr 10 14:16:09 xa26 mysqld[16616]: 0x819ccaf
Apr 10 14:16:09 xa26 mysqld[16616]: 0x81a2835
Apr 10 14:16:09 xa26 mysqld[16616]: 0x81a2dff
Apr 10 14:16:09 xa26 mysqld[16616]: 0x81a3f36
Apr 10 14:16:09 xa26 mysqld[16616]: 0x81a48e1
Apr 10 14:16:09 xa26 mysqld[16616]: 0xb7ecd341
Apr 10 14:16:09 xa26 mysqld[16616]: 0xb7d1e4ee
Apr 10 14:16:09 xa26 mysqld[16616]: New value of fp=(nil) failed sanity check, terminating stack trace!
Apr 10 14:16:09 xa26 mysqld[16616]: Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
Apr 10 14:16:09 xa26 mysqld[16616]: stack trace is much more helpful in diagnosing the problem, so please do
Apr 10 14:16:09 xa26 mysqld[16616]: resolve it
Apr 10 14:16:09 xa26 mysqld[16616]: Trying to get some variables.
Apr 10 14:16:09 xa26 mysqld[16616]: Some pointers may be invalid and cause the dump to abort...
Apr 10 14:16:09 xa26 mysqld[16616]: thd->query at 0x8b664a0 = SELECT DISTINCT t.tid FROM pw_posts t WHERE t.fid NOT IN (-999,12,21,73,89,97,123,150,152,196,205,206,208,232) AND ifcheck=1 AND t.authorid IN(71) ORDER BY tid DESC LIMIT 500
Apr 10 14:16:09 xa26 mysqld[16616]: thd->thread_id=24
Apr 10 14:16:09 xa26 mysqld[16616]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Apr 10 14:16:09 xa26 mysqld[16616]: information that should help you find out what is causing the crash.
Apr 10 14:16:09 xa26 mysqld_safe[16637]: Number of processes running now: 0
Apr 10 14:16:09 xa26 mysqld_safe[16639]: restarted
Apr 10 14:16:09 xa26 mysqld[16642]: 070410 14:16:09 InnoDB: Database was not shut down normally!
Apr 10 14:16:09 xa26 mysqld[16642]: InnoDB: Starting crash recovery.
Apr 10 14:16:09 xa26 mysqld[16642]: InnoDB: Reading tablespace information from the .ibd files...
Apr 10 14:16:09 xa26 mysqld[16642]: InnoDB: Restoring possible half-written data pages from the doublewrite
Apr 10 14:16:09 xa26 mysqld[16642]: InnoDB: buffer...
Apr 10 14:16:09 xa26 mysqld[16642]: 070410 14:16:09 InnoDB: Starting log scan based on checkpoint at
Apr 10 14:16:09 xa26 mysqld[16642]: InnoDB: log sequence number 7 585835023.
Apr 10 14:16:09 xa26 mysqld[16642]: InnoDB: Doing recovery: scanned up to log sequence number 7 585838965
Apr 10 14:16:09 xa26 mysqld[16642]: 070410 14:16:09 InnoDB: Starting an apply batch of log records to the database...
Apr 10 14:16:09 xa26 mysqld[16642]: InnoDB: Progress in percents: 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
Apr 10 14:16:09 xa26 mysqld[16642]: InnoDB: Apply batch completed
Apr 10 14:16:09 xa26 mysqld[16642]: InnoDB: Last MySQL binlog file position 0 124092, file name /var/log/mysql/mysql-bin.000031
Apr 10 14:16:09 xa26 mysqld[16642]: 070410 14:16:09 InnoDB: Started; log sequence number 7 585838965
Apr 10 14:16:09 xa26 mysqld[16642]: 070410 14:16:09 [Note] /usr/sbin/mysqld: ready for connections.
Apr 10 14:16:09 xa26 mysqld[16642]: Version: '5.0.22-Debian_0ubuntu6.06.2-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Debian Etch distribution
Apr 10 14:16:11 xa26 mysqld[16642]: mysqld got signal 11;
Apr 10 14:16:11 xa26 mysqld[16642]: This could be because you hit a bug. It is also possible that this binary
Apr 10 14:16:11 xa26 mysqld[16642]: or one of the libraries it was linked against is corrupt, improperly built,
Apr 10 14:16:11 xa26 mysqld[16642]: or misconfigured. This error can also be caused by malfunctioning hardware.
Apr 10 14:16:11 xa26 mysqld[16642]: We will try our best to scrape up some info that will hopefully help diagnose
Apr 10 14:16:11 xa26 mysqld[16642]: the problem, but since we have already crashed, something is definitely wrong
Apr 10 14:16:11 xa26 mysqld[16642]: and this may fail.
Apr 10 14:16:11 xa26 mysqld[16642]:
Apr 10 14:16:11 xa26 mysqld[16642]: key_buffer_size=268435456
Apr 10 14:16:11 xa26 mysqld[16642]: read_buffer_size=1044480
Apr 10 14:16:11 xa26 mysqld[16642]: max_used_connections=4
Apr 10 14:16:11 xa26 mysqld[16642]: max_connections=768
Apr 10 14:16:11 xa26 mysqld[16642]: threads_connected=2
Apr 10 14:16:11 xa26 mysqld[16642]: It is possible that mysqld could use up to
Apr 10 14:16:11 xa26 mysqld[16642]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2618362 K
Apr 10 14:16:11 xa26 mysqld[16642]: bytes of memory
Apr 10 14:16:11 xa26 mysqld[16642]: Hope that's ok; if not, decrease some variables in the equation.
Apr 10 14:16:11 xa26 mysqld[16642]:
Apr 10 14:16:11 xa26 mysqld[16642]: thd=0x8bc9098
Apr 10 14:16:11 xa26 mysqld[16642]: Attempting backtrace. You can use the following information to find out
Apr 10 14:16:11 xa26 mysqld[16642]: where mysqld died. If you see no messages after this, something went
Apr 10 14:16:11 xa26 mysqld[16642]: terribly wrong...
Apr 10 14:16:11 xa26 mysqld[16642]: Cannot determine thread, fp=0x88f0fb38, backtrace may not be correct.
Apr 10 14:16:11 xa26 mysqld[16642]: Stack range sanity check OK, backtrace follows:
Apr 10 14:16:11 xa26 mysqld[16642]: 0x8189e29
Apr 10 14:16:11 xa26 mysqld[16642]: 0xffffe420
Apr 10 14:16:11 xa26 mysqld[16642]: (nil)
Apr 10 14:16:11 xa26 mysqld[16642]: 0x8221884
Apr 10 14:16:11 xa26 mysqld[16642]: 0x822160a
Apr 10 14:16:11 xa26 mysqld[16642]: 0x8221f05
Apr 10 14:16:11 xa26 mysqld[16642]: Stack trace seems successful - bottom reached
Apr 10 14:16:11 xa26 mysqld[16642]: Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
Apr 10 14:16:11 xa26 mysqld[16642]: stack trace is much more helpful in diagnosing the problem, so please do
Apr 10 14:16:11 xa26 mysqld[16642]: resolve it
Apr 10 14:16:11 xa26 mysqld[16642]: Trying to get some variables.
Apr 10 14:16:11 xa26 mysqld[16642]: Some pointers may be invalid and cause the dump to abort...
Apr 10 14:16:11 xa26 mysqld[16642]: thd->query at 0x8b88008 = SELECT DISTINCT t.tid FROM pw_posts t WHERE t.fid NOT IN (-999,12,21,73,89,97,123,150,152,196,205,206,208,232) AND ifcheck=1 AND t.authorid IN(71) ORDER BY tid DESC LIMIT 500
Apr 10 14:16:11 xa26 mysqld[16642]: thd->thread_id=9
Apr 10 14:16:11 xa26 mysqld[16642]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Apr 10 14:16:11 xa26 mysqld[16642]: information that should help you find out what is causing the crash.
Apr 10 14:16:11 xa26 mysqld_safe[16662]: Number of processes running now: 0
Apr 10 14:16:11 xa26 mysqld_safe[16664]: restarted
Apr 10 14:16:11 xa26 mysqld[16667]: 070410 14:16:11 InnoDB: Database was not shut down normally!
Apr 10 14:16:11 xa26 mysqld[16667]: InnoDB: Starting crash recovery.
Apr 10 14:16:11 xa26 mysqld[16667]: InnoDB: Reading tablespace information from the .ibd files...
Apr 10 14:16:11 xa26 mysqld[16667]: InnoDB: Restoring possible half-written data pages from the doublewrite
Apr 10 14:16:11 xa26 mysqld[16667]: InnoDB: buffer...
Apr 10 14:16:11 xa26 mysqld[16667]: 070410 14:16:11 InnoDB: Starting log scan based on checkpoint at
Apr 10 14:16:11 xa26 mysqld[16667]: InnoDB: log sequence number 7 585835023.
Apr 10 14:16:11 xa26 mysqld[16667]: InnoDB: Doing recovery: scanned up to log sequence number 7 585840929
Apr 10 14:16:11 xa26 mysqld[16667]: 070410 14:16:11 InnoDB: Starting an apply batch of log records to the database...
Apr 10 14:16:11 xa26 mysqld[16667]: InnoDB: Progress in percents: 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
Apr 10 14:16:11 xa26 mysqld[16667]: InnoDB: Apply batch completed
Apr 10 14:16:11 xa26 mysqld[16667]: InnoDB: Last MySQL binlog file position 0 124092, file name /var/log/mysql/mysql-bin.000031
Apr 10 14:16:11 xa26 mysqld[16667]: 070410 14:16:11 InnoDB: Started; log sequence number 7 585840929
Apr 10 14:16:11 xa26 mysqld[16667]: 070410 14:16:11 [Note] /usr/sbin/mysqld: ready for connections.
Apr 10 14:16:11 xa26 mysqld[16667]: Version: '5.0.22-Debian_0ubuntu6.06.2-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Debian Etch distribution
我的mysql的配置文件如下：
my.cnf
[mysqld]
back_log = 200
max_connections = 768
interactive_timeout=50
wait_timeout=50
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
join_buffer_size = 2M
net_buffer_length = 64K
myisam_sort_buffer_size = 64M
max_heap_table_size = 128M
thread_cache = 128
thread_cache_size = 32
max_connect_errors = 10000000
thread_concurrency = 8
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
#
# For compatibility to other Debian packages that still use
# libmysqlclient10 and libmysqlclient12.
old_passwords = 1
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
#
# * Fine Tuning
#
key_buffer = 256M
max_allowed_packet = 4M
thread_stack = 256K
#
# * Query Cache Configuration
#
query_cache_limit = 1048576
query_cache_size = 128M
query_cache_type = 1
log-slow-queries = /var/log/mysql/mysql-slow.log
#
# According to an MySQL employee the use of BerkeleyDB is now discouraged
# and support for it will probably cease in the next versions.
skip-bdb
#
# * InnoDB
#
innodb_buffer_pool_size = 256M
innodb_additional_mem_pool_size = 25M |
|
免费注册
发表于 2007-04-10 15:53
发表于 2007-04-10 22:54