Using SHOW PROCESSLIST and mysqladmin debug Output in Conjunction with SHOW INNODB STATUS

When InnoDB appears hung, I know the natural reaction is to check SHOW ENGINE INNODB STATUS.

In fact, it’s the first thing I check when InnoDB tables are involved.

However, I just want to iterate how valuable SHOW FULL PROCESSLIST and/or mysqladmin debug outputs can be even when it seems mysqld is hung on on InnoDB table.

Two recent cases I’ve encountered illustrate why.

Case #1:

MySQL appeared hung on the following simple, single-row INSERT:

---TRANSACTION 0 2035648699, ACTIVE 76629 sec, process no 9047,
OS thread id 3069426592, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
...
INSERT INTO test (id, parent, text) VALUES (180370, 70122, 'test table')

At least that’s what it seemed per the INNODB STATUS, but unfortunately, there wasn’t any further information to go on.

The next time it occurred, SHOW FULL PROCESSLIST was captured at the time.

Turns out, there was a *very* long SELECT running, but not from the same table, and no foreign keys (FKs) either. Turned out it was some crazy, auto-generated query that self-joined itself 548 times. So there were no locks, per se. This query itself held up everything, and thus also the INSERT.

Case #2:

This was a table that was also hanging on a certain, simple UPDATE. The UPDATE was based on te PK, so only one row was to be updated.

Yet, it hung, and it hung, longer than wait_timeout, interactive_timeout, and innodb_lock_wait_timeout. And there were no other transactions running in the INNODB STATUS.

Turned out, another client had issued a LOCK TABLE command on the table. Since LOCK TABLE is handled outside of the InnoDB storage engine, the lock doesn’t appear in SHOW INNODB STATUS output.

Using mysqladmin debug output, coupled with SHOW PROCESSLIST helped catch this offender.

At any rate, hope this helps, and happy troubleshooting. :)

 
 

Tags: , , , , , , , , , , , , ,

3 Responses to “Using SHOW PROCESSLIST and mysqladmin debug Output in Conjunction with SHOW INNODB STATUS”

  1. sbester says:

    about the LOCK TABLE situation, you can set “lock_wait_timeout” to a reasonably small value so a timeout will happen. The default is 1 year, probably too much.

    ————-
    #session 1:
    ————-
    mysql> create table t1(a int)engine=myisam;
    Query OK, 0 rows affected (0.08 sec)

    mysql> lock table t1 write;
    Query OK, 0 rows affected (0.00 sec)

    mysql> set global lock_wait_timeout=10;
    Query OK, 0 rows affected (0.00 sec)

    ————-
    #session 2:
    ————-
    mysql> insert into t1 values (1);
    ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
    mysql>

  2. Cédric says:

    Thx Chris.
    The first thing I check is processlist.
    I think it provides a most relevant overview of what happens.

  3. Wagner says:

    I agree with you about the importance of SHOW PROCESSLIST. This is the first command I’ve used when starts a new day work. SHOW ENGINE INNODB STATUS might be part of my third or fourth command to verify a MySQL instance. As @Cédric said, SHOW [FULL] PROCESSLIST really provides a relevant overview of what is happening this time in MySQL.


Period Panties by Period Panteez Menstrual Underwear Menstruation PMS Panty