Hello,
I am having trouble with Mysqld unexpectedly crashing.
I am running mysqld in a situation where there is a nearly constant
load on 6 databases, each with about 20 open connections (mostly
inserts and selects, occasionally a delete). Once every 3-4 days, at
seemingly random points (i.e. in several crashes, it has yet to crash
on the same SQL query), one of the mysqld processes crashes and posts
to the mysqld.log, complaining of receiving either a signal 11 or a
signal 4.
One of the running mysqld processes becomes listed as defunct, and the
rest just seem to hang there. Stopping the mysqld
(/etc/rc.d/init.d/mysqld stop) does not kill the mysql processes. The
reset procedure is to kill all of the running clients, re-stop the
server, and then start the server.
The only thought I have is that I am running Red Hat Linux 7.2, and
thus as a result, /usr/bin/safe_mysqld by default forces mysqld to run
with --skip-locking (apparently due to locking issues in some Linux
systems). -- maybe the combination of a heavy load on the database
and running without locking is causing some serious problems.
Has anyone out there exerienced a similar problem, or have a better
explanation for what's going on?
Many thanks,
john Siirola
[EMAIL PROTECTED]
Attached below are excerpts from mysqld.log (with stack
traces), as well as other information generated by mysqlbug:
--
--
mysqld got signal 11;
[.]
key_buffer_size=8388600
record_buffer=131072
sort_buffer=2097144
max_used_connections=110
max_connections=255
threads_connected=94
It is possible that mysqld could use up to
key_buffer_size + (record_buffer + sort_buffer)*max_connections = 563070 K
bytes of memory
[Note: the server is running with 1024 MB RAM, so this should not be
a problem.]
[.]
Stack range sanity check OK, backtrace follows:
0x80cf68d
0x400287fc
0x400232c4
0x829ae29
0x8283f61
0x82834ab
0x8278df3
0x8116fc8
0x80f4b8e
0x80f42f6
0x80f43a4
0x80f3fa9
0x80eca3d
0x80d5a9f
0x80d8dd3
0x80d4cb0
0x80d4210
Stack trace seems successful - bottom reached
[.]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd-query at 0x87368c0 = SELECT COUNT(ID) FROM data INNER JOIN
request ON data.ReqID = request.ReqID WHERE request.AgentID 7
thd-thread_id=214476
Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 214476 did to cause the crash. In some cases of
really
bad corruption, the values shown above may be invalid
--
Other crashes reported slightly different stack traces:
--
mysqld got signal 11;
[.]
Stack range sanity check OK, backtrace follows:
0x80cf68d
0x400287fc
0x400232d0
0x829aef9
0x81298dd
0x827edd8
0x827e398
0x811725c
0x811150d
0x80f43c9
0x80f3fa9
0x80eca3d
0x80d5a9f
0x80d8dd3
0x80d4cb0
0x80d4210
Stack trace seems successful - bottom reached
[.]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd-query at 0x83eda20 = SELECT COUNT(ID) FROM data WHERE
(C1+CLen)=-3.79606 AND (C1-CLen)=-3.79604 AND (C2+CLen)=-7.91645 AND
(C2-CLen)=-7.91643 AND (C3+CLen)=0.921768 AND (C3-CLen)=0.921788 AND
(C4+CLen)=-12.31881 AND (C4-CLen)=-12.31879 AND (C5+CLen)=17.04139 AND
(C5-CLen)=17.04141 AND (C6+CLen)=13.84509 AND (C6-CLen)=13.84511 AND
(C7+CLen)=-2.66293 AND (C7-CLen)=-2.66291 AND (C8+CLen)=-9.66253 AND
(C8-CLen)=-9.66251 AND (C9+CLen)=-16.68791 AND (C9-CLen)=-16.68789 AND
(C10+CLen)=17.53459 AND (C10-CLen)=17.53461
thd-thread_id=267084
Successfully dumped variables[.]
--
mysqld got signal 4;
[.]
Stack range sanity check OK, backtrace follows:
0x80cf68d
0x40026a85
0x400279ec
0x40024cfe
0x829b67f
0x827caf7
0x8279503
0x8279924
0x8278d44
0x8116fc8
0x80f4b8e
0x80f42f6
0x80f43a4
0x80f3fa9
0x80eca3d
0x80d5a9f
0x80d8dd3
0x80d4cb0
0x80d4210
Stack trace seems successful - bottom reached
[.]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd-query at 0x8678428 = SELECT data.ID, F1 , X1, X2, X3, X4, X5, X6, X7,
X8, X9, X10 FROM data INNER JOIN request AS R ON data.ReqID = R.ReqID
WHERE R.AgentID 4
thd-thread_id=469679
Successfully dumped variables[.]
--
mysqld got signal 4;
[.]
Stack range sanity check OK, backtrace follows:
0x80cf68d
0x40026a85
0x80ca915
0x80cabef
0x80d4892
0x80d4210
Stack trace seems successful - bottom reached
[.]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd-query at (nil) is invalid pointer
thd-thread_id=8319
Successfully dumped variables[.]
