Joe, ----- Original Message ----- From: ""Jennifer Goodie"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.mysql Sent: Friday, March 21, 2003 9:45 PM Subject: RE: mysqld got signal 11; (CRASH max-3.23.51) What do I need to do to clean up?
> I wouldn't run 3.23.51, there have been major security patches since then. > I always mess up the byte math, but it looks to me like you have 2 gigs of > ram in your box and you are allocating 2.3 gigs to mysql. With 263 > connections you would have been using about 1.4 gigs, if you have anything > else running on the box, this might be a problem. Whenever I've had a > server getting the signal 11 crash adjusting my my.cnf has solved the > problem. I would read the manual section on server tuning. I don't think > you want mysql to use swap, I don't know, I try to stick with just under the > total amount of ram in a box that is only running mySQL and under 40% in a > box that is not dedicated (depending on what else is running). Of course > there's not really any real logic, math or science to that, it's just what I > have found works on our boxes. > > -----Original Message----- > From: Joe Smith [mailto:[EMAIL PROTECTED] > Sent: Friday, March 21, 2003 10:53 AM > To: [EMAIL PROTECTED] > Subject: mysqld got signal 11; (CRASH max-3.23.51) What do I need to do > to clean up? > > > Had my first mysqld crash today after a solid 4 month uptime. The details > are below. > > The DB restarted, and I haven't been able to detect any corruption. Is > there anything I should be running to ensure the integrity of the Innodb > databases? > > Running: mysql-max-3.23.51, Innodb databases, Dual Intel 933s 2 Gigs ram 2 > gigs swap > > 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=402649088 > record_buffer=2093056 > sort_buffer=2097144 > max_used_connections=263 > max_connections=500 > threads_connected=31 > It is possible that mysqld could use up to > key_buffer_size + (record_buffer + sort_buffer)*max_connections = 2439208 K > bytes of memory > Hope that's ok, if not, decrease some variables in the equation > > 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... > Stack range sanity check OK, backtrace follows: > 0x806bb15 > 0x82c1328 > 0x82c28c3 > 0x82bfb44 > 0x80cbb40 > 0x8073a4d > 0x80753c8 > 0x8071324 > 0x80707f7 > Stack trace seems successful - bottom reached > Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow > instr > uctions 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 0x6a856288 is invalid pointer > thd->thread_id=42019698 > > Successfully dumped variables, if you ran with --log, take a look at the > details of what thread 42019698 did to cause the crash. In some cases of > really > bad corruption, the values shown above may be invalid > > The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains > information that should help you find out what is causing the crash > > Number of processes running now: 0 > > ---- > > /prod/mysql-max-3.23.51-log/bin/resolve_stack_dump -s mysqld.sym -n > stack.trace > 0x806bb15 handle_segfault__Fi + 425 > 0x82c1328 pthread_sighandler + 184 > 0x82c28c3 __pthread_unlock + 147 > 0x82bfb44 pthread_mutex_unlock + 164 > 0x80cbb40 mysqld_list_processes__FP3THDPCcb + 1780 > 0x8073a4d mysql_execute_command__Fv + 7161 > 0x80753c8 mysql_parse__FP3THDPcUi + 72 > 0x8071324 do_command__FP3THD + 1316 > 0x80707f7 handle_one_connection__FPv + 659 > > > Is this a known issue? I'm guessing I should upgrade to mysql-4.12 now... Jennifer already gave very relevant advice. I can add that Monty fixed a crash in SHOW PROCESSLIST some 3 months ago. An upgrade could solve the crash problem. Your crash probably was a clean one and InnoDB recovered without problems. But best to run CHECK TABLE on your tables to be sure. > Thanks! > > Joe Best regards, Heikki Tuuri Innobase Oy --- Order technical MySQL/InnoDB support at https://order.mysql.com/ See http://www.innodb.com for the online manual and latest news on InnoDB sql query --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
