I've been trying to upgrade to 4.0.3 mysql from 3.23.38. I've used the binary for 4.0.3 on a linux box (SuSE 8.0) with dual 1.4GHZ pIII's and 2GB RAM. We run a pretty busy e-commerce site, and the 3.23.38 box is a Solaris7. Each time I move the linux box into production, I'm over-rum with an inordinate amount of processes (threads) and some updates doing a system lock, which stops nearly all requests, and eventually kills the mysqld.
My mysql.err file reports: 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=268431360 read_buffer_size=1044480 sort_buffer_size=8388600 max_used_connections=369 max_connections=1500 threads_connected=370 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 149721 6 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. You seem to be running 32-bit Linux and have 370 concurrent connections. If you have not changed STACK_SIZE in LinuxThreads and built the binary yourself, LinuxThreads is quite likely to steal a part of the global heap for the thread stack. Please read http://www.mysql.com/doc/L/i/Linux.html thd=0x50c155a8 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=0x923ff438, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x806f26b 0x82e5f68 0x831594f 0x80a9514 0x8078d2e 0x8077d0a 0x807754e 0x82e397a 0x831bd1a New value of fp=(nil) failed sanity check, terminating stack trace! 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 (nil) is invalid pointer thd->thread_id=1181 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 1181 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. I've adjusted my params to keep the wait_timeout=15, thread_cache_max=40 (tried others above and below), what else do I need to try Desperate in Da Admin's chair! ===== Gary Every "None Better, Few as Good" --------------------------------------------------------------------- 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
