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/
