On Monday 21 May 2001 13:50, Cody Swanson wrote:
> Hey,
>
> We just got a new Dell Poweredge 6450 preloaded with redhat 6.2. Our
intention
> is to move the database off a smaller machine and load it into this one. We
> currently have MySQL 3.23.38 using the innobase driver on redhat 6.2 with
kernel
> 2.4.4. This is on a dual PIII650 with 1 gig of ram and it runs fine. Here
is a
> copy of a status readout in mysql:
>
> mysql Ver 11.15 Distrib 3.23.38, for pc-linux-gnu (i686)
>
> Connection id: 232107
> Current database:
> Current user: root@localhost
> Current pager: stdout
> Using outfile: ''
> Server version: 3.23.38
> Protocol version: 10
> Connection: Localhost via UNIX socket
> Client characterset: latin1
> Server characterset: latin1
> UNIX socket: /tmp/mysql.sock
> Uptime: 1 day 19 hours 23 min 39 sec
>
> Threads: 55 Questions: 70609984 Slow queries: 15 Opens: 203 Flush
tables: 1
> Open tables: 155 Queries per second avg: 451.994
>
>
> As you can see we have quite a load on this poor machine, this is why we
wanted
> to move to a bigger badder machine so we could push more out of MySQL.
Anyway,
> as mentioned before, our machine is a Poweredge 6450 with 4 Xeon 750mhz
> processors and 4gb of ram. We also have a dell 4 channel PercRaid card that
does
> a raid 5 onto 4 36gb scsi disks. So we loaded Mysql 3.23.38 onto the machine
> with no extra tweeks, just with the raw install from dell, setup the
Innobase
> driver and imported our data. Once we moved the site onto the new server
> everything worked great, we could do super heavy queries in no time, it was
> great! Then a day later I was looking at the .err log and noticed that
MySQL had
> crashed several times! Each time it crashes it restarts itself and the
innobase
> tables fix themselves. Innobase is verry cool! But this is a real problem!
>
> So I took the .err file and parsed the stack trace against the symbol file
for
> mysql like the manual says. Here is a copy of the .err file with the stack
dump
> from one crash. This one is from kernel 2.4.3:
>
> mysqld got signal 11;
> The manual section 'Debugging a MySQL server' tells you how to use a
> stack trace and/or the core file to produce a readable backtrace that may
> help in finding out why mysqld died.
> 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:
> 0x81c508a
> 0x80f4ca5
> 0x80f44d4
> 0x80f823e
> 0x80f4021
> 0x80caee6
> 0x80c4a2d
> 0x809bdbf
> 0x8097de1
> 0x8097522
> 0x8098177
> 0x80abede
> 0x8084967
> 0x80877fd
> 0x8082ba9
> 0x80820d6
> Stack trace successful, trying to get some variables.
> Some pointers may be invalid and cause the dump to abort...
> thd->query at 0xb91044a8 is invalid pointer
> thd->thread_id = 6230
> Successfully dumped variables, if you ran with --log,
> take a look at the details of what thread 6230 did to cause the crash.
> In some cases of really bad corruption, this value may be invalid
> Please use the information above to create a repeatable
> test case for the crash, and send it to [EMAIL PROTECTED]
>
> Number of processes running now: 0
> 010516 15:55:52 mysqld restarted
> InnoDB: Database was not shut down normally.
> InnoDB: Starting recovery from log files...
> InnoDB: Starting log scan based on checkpoint at
> InnoDB: log sequence number 0 2512947858
> InnoDB: Doing recovery: scanned up to log sequence number 0 2512963
>
>
>
> Here is the results of running stackresolve:
>
> [root@cobalt /tmp]# /usr/local/mysql/bin/resolve_stack_dump -s
/tmp/mysqld.sym
> -n /tmp/mysql.stack
> 0x81c508a pthread_sighandler + 150
> 0x80f4ca5 dict_col_add_to_cache + 153
> 0x80f44d4 dict_table_add_to_cache + 1128
> 0x80f823e dict_load_table + 3326
> 0x80f4021 dict_table_get + 169
> 0x80caee6 open__11ha_innobasePCciUi + 310
> 0x80c4a2d ha_open__7handlerPCcii + 33
> 0x809bdbf openfrm__FPCcT0UiUiUiP8st_table + 4959
> 0x8097de1 open_unireg_entry__FP3THDP8st_tablePCcN22b + 69
> 0x8097522 open_table__FP3THDPCcN21Pb + 950
> 0x8098177 open_ltable__FP3THDP13st_table_list13thr_lock_type + 71
> 0x80abede
>
mysql_insert__FP3THDP13st_table_listRt4List1Z4ItemRt4List1Zt4List1Z4Item15enum_duplicates13thr_lock_type
> + 302
> 0x8084967 mysql_execute_command__Fv + 5339
> 0x80877fd mysql_parse__FP3THDPcUi + 209
> 0x8082ba9 do_command__FP3THD + 1305
> 0x80820d6 handle_one_connection__FPv + 578
>
>
> We have tried 2.2.x kernels and all kinds of memory configs but we are at a
> loss for what to do. It seems to be a machine problem because the same data
on a
> different machine works fine. If anyone has any ideas I would love it!
Thanks.
>
>
Thanks for a good bug report. Looks like you are using InnoDB tables. Please
be aware that although we have tested them, they are not quite 100%
production ready, although they are getting better and better. Let's hope the
above stack trace leads Heikki to finding the bug and the fix ( this is his
code).
Heikki - any comments?
--
MySQL Development Team
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
---------------------------------------------------------------------
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
