Richard, then it is possible that all the crashes are caused by SHOW CREATE TABLE. The memory corruption bug can crash InnoDB at any place, it is not always caught by an assertion like in the error log. Since the bug is nondeterministic, it is well possible it appears only under some specific database load.
Lenz of MySQL AB is working hard to get good Linux builds of 3.23.51 and 4.0.2 done. Let us hope we finally get the new releases soon. 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 ----- Original Message ----- From: "Richard Clarke" <[EMAIL PROTECTED]> To: "MYSQL" <[EMAIL PROTECTED]>; "Heikki Tuuri" <[EMAIL PROTECTED]> Sent: Sunday, May 19, 2002 3:25 PM Subject: Re: 4.0.1 Bugs > Heikki, > > My set of queries performs about 4/5 "show create table" queries each > hour. The purpose being to drop it then recreate it automatically. Last time > I tried truncate it was as slow as delete, but that was near the begining of > my development and never saw reason to retry it after show > create/drop/create ... worked fine. > Even though these show creates happen 4/5 hours could they be the cause of > it somehow only crashing every 4/5 days? Or is it more likely that the > crashes I experience are a set of bugs. Maybe one day the assertion failure > crashes it, then a few days after another "bug" crashes it?. Near the > beginning of the development I experienced problems where Mysql would crash > coz it bugged out on virtual memory. Doubling the virtual memory stopped > this. I don't think the error is related to this since it used to singal 11 > every time when that was happening. > > As for the memory consumption, > > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU > COMMAND > > > 44577 mysql 31 0 1085M 79544K RUN 1 34.6H 5.37% 5.37% mysql > > This would suggest that memory consumption has decreased (to 79megs?) yet > virtual memory has bloated to 1085-79?. This is on the other server mind > you. The two servers that are crashing, crashed very recently, but I think > they also will begin to exhibit the virtual memory increase, real memory > decrease syndrome over the next couple of days. > > Ric. > > > ----- Original Message ----- > From: "Heikki Tuuri" <[EMAIL PROTECTED]> > To: "Richard Clarke" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Sunday, May 19, 2002 1:01 PM > Subject: Re: 4.0.1 Bugs > > > > Richard, > > > > the assertion failure below is very probably caused by the SHOW CREATE > TABLE > > memory corruption bug which was fixed in 3.23.48, but not yet in 4.0.1. It > > is usually caused by mysqldump. The regularity of the crashes suggests > they > > might be connected to mysqldumps. > > > > If the memory consumption of mysqld does not increase linearly over many > > days (does it?), then it is probably not a memory leak. If the crashes are > > connected to memory consumption you could try making the InnoDB buffer > pool > > slightly smaller and test if the crashes occur less frequently. > > > > I will look at the UNION problem later. > > > > 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 > > > > ----- Original Message ----- > > From: "Richard Clarke" <[EMAIL PROTECTED]> > > To: "Heikki Tuuri" <[EMAIL PROTECTED]> > > Sent: Sunday, May 19, 2002 12:02 PM > > Subject: Re: 4.0.1 Bugs > > > > > > > Heikki, > > > As for my crashes. This one is a little hard, see, we have two > > machines > > > that do this. Both however, display little to no information in the log. > > One > > > server just says mysql restarted followed by mysql was shut down > > > incorrectly. The second server once gave an error like this, > > > 020426 12:26:31 InnoDB: Started > > > /usr/local/mysql-4.0.1-alpha/libexec/mysqld: ready for connections > > > 020511 1:09:25 read_key: Got error 146 when reading table > > > './counter/br_type' > > > 020516 2:27:31 read_key: Got error 146 when reading table > > > './counter/br_type' > > > 020518 1:25:36 read_key: Got error 146 when reading table > > > './counter/br_type' > > > InnoDB: Error: undo->id is 136712960 > > > InnoDB: Assertion failure in thread 869069824 in file trx0undo.c line > 1316 > > > InnoDB: We intentionally generate a memory trap. > > > InnoDB: Send a detailed bug report to [EMAIL PROTECTED] > > > 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=16773120 > > > record_buffer=1044480 > > > sort_buffer=1048568 > > > max_used_connections=190 > > > max_connections=500 > > > threads_connected=90 > > > It is possible that mysqld could use up to > > > key_buffer_size + (record_buffer + sort_buffer)*max_connections = > 1038376 > > K > > > bytes of memory > > > Hope that's ok; if not, decrease some variables in the equation. > > > > > > 020518 01:30:27 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 589 1379690513 > > > InnoDB: Doing recovery: scanned up to log sequence number 589 1379756032 > > > InnoDB: Doing recovery: scanned up to log sequence number 589 1379821568 > > > InnoDB: Doing recovery: scanned up to log sequence number 589 1379887104 > > > InnoDB: Doing recovery: scanned up to log sequence number 589 1379952640 > > > InnoDB: Doing recovery: scanned up to log sequence number 589 1380018176 > > > InnoDB: Doing recovery: scanned up to log sequence number 589 1380083712 > > > > > > The 146 errors can be ignore, they were deadlocks ocurring in a > > > select/insert being run simultaneously. This server only gave this > signal > > 11 > > > once. The other times it just did its restart/recover routine as > described > > > above. One thing I have noticed, though not something I have monitored > > > specifically is the memory usage of mysql. When the daemon first starts > it > > > has a size of about 800megs and a res(ources) of about 700/800. Over > time > > > however the size can grow to 1gig and the res drop to around 200. We > have > > a > > > third mysql box which doesn't seem to crash, currently it is reporting. > > > > > > last pid: 47508; load averages: 0.60, 0.40, 0.25 > > > up 47+19:17:15 08:49:53 > > > 116 processes: 3 running, 111 sleeping, 2 zombie > > > CPU states: 21.4% user, 0.0% nice, 4.5% system, 0.0% interrupt, 74.1% > > > idle > > > Mem: 244M Active, 246M Inact, 107M Wired, 33M Cache, 112M Buf, 373M Free > > > Swap: 1012M Total, 713M Used, 299M Free, 70% Inuse > > > > > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU > COMMAND > > > 44577 mysql 31 0 1085M 79544K RUN 1 34.6H 5.37% 5.37% mysql > > > > > > This server is also 4.0.1, though its not crashing. It does however play > a > > > different role in our system and hence it doesn't perform the same > queries > > > as the other two. > > > I have iteratively developed the queries on the other server, all the > > while > > > monitoring innodb monitor output amongst other things. I am certain no > > > transactions are stuck or otherwise. > > > One of the crashing systems crashed yesterday infact, the log output > just > > > said restared/shutdown incorrectly etc (no caught signals). Whether its > > any > > > help or not, I don't know but here is some innodb_monitor output. > > > > > > --------------------------------------------------------------------- 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
