|
|
7#

楼主 |
发表于 2010-2-27 09:42:30
|
只看该作者
MYSQL 日志里全不断重启,C大帮我看看是什么原因吧。。。
我是新手,不懂啊。论坛挂了好几天了。
Number of processes running now: 0
100227 00:29:01 mysqld restarted
100227 0:29:01 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
100227 0:29:01 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
100227 0:29:01 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.77' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
100227 0:29:52 - 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=6291456
read_buffer_size=262144
max_used_connections=1
max_connections=64
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 38912 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x8c631f8
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=0xb64fb858, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x818d468
0x8274ff3
0x81eebbe
0x81f1378
0x81f2269
0x81fa2d9
0x81fac8d
0x81a6ec2
0x81ab2cd
0x81ab826
0x81ad808
0xb7d5873b
0xb7b78cfe
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
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8c9b648 = SELECT p.*, m.uid, m.username, m.groupid, m.adminid, m.regdate, m.lastactivity, m.posts, m.threads, m.digestposts, m.oltime,
m.pageviews, m.credits, m.extcredits1, m.extcredits2, m.extcredits3, m.extcredits4, m.extcredits5, m.extcredits6,m.extcredits7, m.extcredits8, m.email, m.gender, m.showemail, m.invisible, mf.nickname, mf.site,
mf.icq, mf.qq, mf.yahoo, mf.msn, mf.taobao, mf.alipay, mf.location, mf.medals,
mf.sightml AS signature, mf.customstatus, mf.spacename
FROM cdb_posts p
LEFT JOIN cdb_members m ON m.uid=p.authorid
LEFT JOIN cdb_memberfields mf ON mf.uid=m.uid
WHERE p.tid='7671' AND p.invisible='0' ORDER BY dateline LIMIT 10, 10
thd->thread_id=10
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.
Number of processes running now: 0
100227
00:29:52 mysqld restarted
100227
对了。phpmyadmin 状态里面 有一段话
1 On a busy server, the byte counters may overrun, so those statistics as reported by the MySQL server may be incorrect. |
|