← Back to team overview

percona-discussion team mailing list archive

Re: [Bug 378100] Re: Innodb locks up under largeINSERT load

 

Hi Mark,
   I'm able to recreate the problem, but when I try to run the stack trace or if I just go into gdb and try to attach to the process, I keep getting this error:

Reading symbols from /usr/local/mysql-5.1.34-xtradb/bin/mysqld...done.
Using host libthread_db library "/lib/power6/libthread_db.so.1".
Cannot access memory at address 0x400000382d8

I've talked to my sys guys and my developers, but no one seems to have a
good idea on why I'm getting this error. Would you or anyone else know
what this means?

Lee

-----Original Message-----
From: bounces@xxxxxxxxxxxxx [mailto:bounces@xxxxxxxxxxxxx] On Behalf Of Mark Callaghan
Sent: Monday, May 18, 2009 5:00 PM
To: Lee Margulin
Subject: Re: [Percona-discussion] [Bug 378100] Re: Innodb locks up under largeINSERT load

On Mon, May 18, 2009 at 4:23 PM, LCM <lmargulin@xxxxxxxxxx> wrote:
> I didn't do much. I exported my existing 4.1 db. Each table is exported
> to a separate file that is gzipped. On my new 5.1 instance with the
> XtraDB build, I am running multiple sessions. Each session is just
> importing a different subset of tables.
>
> In experimenting with this, it seems as though there may be something
> happening with the innodb log file. I initial had 3 log files, each
> 1,000MB with a INNODB_MAX_DIRTY_PAGES_PCT of 15. Running 6 table
> imports, the db would lock up after about 3 minutes. I went to 128MB X 3
> log files and DIRTY_PAGES=90 and the db would lock in a few seconds,
> again with 6 imports running. I have been able to recreate the lock up
> with as few as 3 imports, but it does take longer to run into the
> problem.
>
> I built the initial innodb data file at 600GB. I have about 550 tables
> to import. All of these tables with indexes use up about 550GB of disk
> space. I initial built this server with MySQL 5.0 and didn't experience
> any of these problems.
>
> Let me know if there is any additional info I can provide that would be
> helpful. I was hoping to use the XtraDB engine to find some
> performance/stability over the 5.1 from MySQL. Since we are having other
> crash issues with the standard MySQL 5.1 release
>
> Lee

Can you get thread stacks when it gets stuck?

See this for the gdb command line to get thread stacks from a running server:
http://dammit.lt/2009/02/15/poor-mans-contention-profiling/

-- 
Mark Callaghan
mdcallag@xxxxxxxxx

-- 
Innodb locks up under large INSERT load
https://bugs.launchpad.net/bugs/378100
You received this bug notification because you are a direct subscriber
of the bug.

Status in Percona XtraDB Storage Engine for MySQL: New

Bug description:
While trying to load a new db on the 5.1.34-xtradb build, the Innodb engine locks up after a few minutes with multiple table loads running.

I can still log into the server, but I don't get any data back from the
SHOW ENGINE INNODB STATUS command. I also can't kill any of the existing
INSERT commands. I can reproduce the problem with as few as 3
simulateous loads (INSERT) occurring.

I am running this on SuSE version 10 with 8 processors and 126GB of RAM.

Can I get some help in troubleshooting this? There are no messages being
written to the error log.

-- 
Innodb locks up under large INSERT load
https://bugs.launchpad.net/bugs/378100
You received this bug notification because you are a member of Percona
developers, which is the registrant for Percona-XtraDB.

Status in Percona XtraDB Storage Engine for MySQL: New

Bug description:
While trying to load a new db on the 5.1.34-xtradb build, the Innodb engine locks up after a few minutes with multiple table loads running.

I can still log into the server, but I don't get any data back from the SHOW ENGINE INNODB STATUS command. I also can't kill any of the existing INSERT commands. I can reproduce the problem with as few as 3 simulateous loads (INSERT) occurring.

I am running this on SuSE version 10 with 8 processors and 126GB of RAM. 

Can I get some help in troubleshooting this? There are no messages being written to the error log.



Follow ups

References