Contents

SHOWENGINE INNODB STATUS is introduced in detail.

Many people have used SHOW ENGINE INNODB STATUS to view server information and locate problems, but its output is complicated and difficult to understand. There are basically no introductory materials in this regard online – especially in Chinese.

The following sections of this article describe in detail the meaning of this information, as well as the causes and consequences of some of the information. I hope it can be helpful to you, and I also hope that readers will correct the mistakes in the text.

Header

This part simply prints, the output time, and the interval time since the last output.

1 =====================================

2 07091310:31:48 INNODB MONITOR OUTPUT

3 =====================================

4 Persecond averages calculated from the last 49 seconds

SEMAPHORES

If you have a high concurrency system, you need to pay attention to the output of this section.

It consists of two parts, event counters, and optional output, the current waits.

An example output is given below.

1 ----------

2 SEMAPHORES

3 ----------

4 OSWAIT ARRAY INFO: reservation count 13569, signal count 11421

5 --Thread1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds

the semaphore:

6 Mutexat 0x2a957858b8 created file buf0buf.c line 517, lock var 0

7 waitersflag 0

8 waitis ending

9 --Thread1147709792 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds

the semaphore:

10 Mutexat 0x2a957858b8 created file buf0buf.c line 517, lock var 0

11 waitersflag 0

12 waitis ending

13 Mutexspin waits 5672442, rounds 3899888, OS waits 4719

14 RW-sharedspins 5920, OS waits 2918; RW-excl spins 3463, OS waits 3163

Line 4 indicates the information of OS WAIT, reservation count indicates how many times Innodb has generated OS WAIT, and signal count indicates how many times the thread that performs OS WAIT has received a signal (singal) to wake up.

If you see the value of the signal is very large, usually hundreds of thousands, millions. It shows that there may be a lot of I/O waiting, or Innodb contention (contention). Regarding the contention problem, it may be related to the process scheduling of the OS. You can try to reduce the innodb_thread_concurrency parameter.

In the next, before the following introduction, it is necessary to understand what is OS Wait and what is spin wait.

To understand this, you must first understand how Innodb handles mutexes and what is a two-step approach to acquiring locks. The first process, trying to acquire a lock, if the lock is occupied by someone else. It will execute the so-called spin wait, which is the so-called circular query "Is the lock released?". If in the loop process, the lock release information has not been obtained, it is transferred to OS WAIT, that is, the so-called thread enters the suspended (suspended) state. Until the lock is released, the thread is woken up by a signal (singal).

Mutex spin waits is the spin wait that the thread cannot acquire the lock and enters
rounds is the number of times spin wait polls to check Mutextes
OS waits are threads giving up spin-wait and entering a suspended state

The consumption of Spin wait is much less than OS waits. Spinwait uses the idle time of the CPU to check the status of the lock. OS Wait will have a so-called content switch to swap out the current execution thread from the CPU core for use by other threads. You can balance spin wait and os wait with the innodb_sync_spin_loops parameter.

http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_sync_spin_loops

Lines 5-12 show the specific contention (contention) waiting event, which requires you to be familiar with MySQL code.

As in the example, buf0buf.c actually indicates that the server has buffer pool contention.

13-14 shows more detailed lock (Mutexes) information, such as RW-shared for shared locks, RW-excl for exclusive locks

LATEST DETECTED DEADLOCK

This section will show up when your server is in a deadlock situation. The usual causes of deadlocks are complex, but this section will only show the last two transactions that deadlocked, although there may be other transactions involved in the deadlock process. However, although the information is truncated, you can usually find the cause of the deadlock with this information.

An example is given below:

1 ------------------------

2 LATESTDETECTED DEADLOCK

3 ------------------------

4 07091311:14:21

5 ***(1) TRANSACTION:

6 TRANSACTION0 3793488, ACTIVE 2 sec, process no 5488, OS thread id 1141287232

startingindex read

7 mysqltables in use 1, locked 1

8 LOCKWAIT 4 lock struct(s), heap size 1216

9 MySQLthread id 11, query id 350 localhost baron Updating

10 UPDATEtest.tiny_dl SET a = 0 WHERE a <> 0

11 ***(1) WAITING FOR THIS LOCK TO BE GRANTED:

12 RECORDLOCKS space id 0 page no 3662 n bits 72 index `GEN_CLUST_INDEX` of table

`test/tiny_dl`trx id 0 3793488 lock_mode X waiting

13 Recordlock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0

14 0:len 6; hex 000000000501 ...[ omitted ] ...

16 ***(2) TRANSACTION:

17 TRANSACTION0 3793489, ACTIVE 2 sec, process no 5488, OS thread id 1141422400

startingindex read, thread declared inside InnoDB 500

18 mysqltables in use 1, locked 1

19 4lock struct(s), heap size 1216

20 MySQLthread id 12, query id 351 localhost baron Updating

21 UPDATEtest.tiny_dl SET a = 1 WHERE a <> 1

22 ***(2) HOLDS THE LOCK(S):

23 RECORDLOCKS space id 0 page no 3662 n bits 72 index `GEN_CLUST_INDEX` of table

`test/tiny_dl`trx id 0 3793489 lock mode S

24 Recordlock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0

25 0:... [ omitted ] ...

27 ***(2) WAITING FOR THIS LOCK TO BE GRANTED:

SHOW INNODB STATUS | 571

28 RECORDLOCKS space id 0 page no 3662 n bits 72 index `GEN_CLUST_INDEX` of table

`test/tiny_dl`trx id 0 3793489 lock_mode X waiting

29 Recordlock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0

30 0:len 6; hex 000000000501 ...[ omitted ] ...

32 *** WE ROLL BACK TRANSACTION (2)

Line 4 shows when the deadlock occurred. Lines 5-10, show the first transaction of the first deadlock, and I will continue to elaborate on what it means in the next section.

Lines 11-15 show the lock that transaction 1 was waiting for when the deadlock occurred. Line 14 can be ignored, the information displayed is only useful when debugging Innodb. The important thing is line 12, which shows that the transaction wants to obtain the X exclusive lock corresponding to the GEN_CLUST_INDEX* index of the test.tiny_dl table (it is necessary to explain that the lock of Innodb is related to the index. For details, see my blog about Innodb locks introduction).

Lines 16-21 show the status of transaction 2, 22-26 show the locks acquired by transaction 2, and 27-31 show the locks that transaction 2 is waiting for.

Innodb will not show the current transaction has acquired and waiting locks, but it gives enough information, such as the index used by the current query, it will help you locate the problem and how to avoid deadlocks. Of course, this kind of information is usually not so intuitive. You can find the problem code and analyze it by printing out the SQL statement, index and other information.

Line 32 shows which transaction it chooses to roll back to avoid an indefinite deadlock wait. In this regard, Innodb has an inherent deadlock detection mechanism that rolls back one of the transactions when the deadlock waits for more than a certain amount of time. innodb_lock_wait_timeout configures the waiting timeout for deadlocks.

TRANSACTIONS

This section contains statistics on Innodb transactions (transactions), as well as a list of currently active transactions.

Next, let's introduce the statistical part of the beginning

1 ------------

2 TRANSACTIONS

3 ------------

4 Trx id counter 080157601

5 Purge done fortrx's n:o <0 80154573 undo n:o <0 0

6 History listlength 6

7 Total number oflock structs in row lock hash table 0

Line 4 shows the current transaction id, which is a system variable that increases every time a new transaction occurs.

Line 5 shows the transaction ID of the ongoing purge operation. You can see where transactions that are not purged are falling behind by looking at the difference between the IDs in rows 4 and 5. Regarding what a purge operation is, I explain it in detail below.

Line 6 records the number of unpurged transactions in undo spaces.

(Note: Someone with a heart may calculate the difference between the IDs of rows 4 and 5, and when compared with the value in row 6, they may find that they do not match at all. I have been confused about this for a while. In fact, the ID of the transaction is not based on Purged sequentially, so it is possible that the transaction whose ID is greater than the ID of the current purge in row 5 has already been purged earlier. The principle of purge is that the record is not used by other transactions.)

Line 7, the original English explanation is as follows, I don't understand this. the number of lock structs. Each lock struct usually holds many row locks, so this is not the same as the number of rows locked.

What is the purge operation

To understand what a purge operation is, you have to understand what is multi-version control of transactions, ie MVCC (multi-version concurrency control). In order to implement MVCC, Innodb needs to save the old version of the record information in the tablespace, which is stored in the rollback segment. The so-called rollback segment is the record of the UNDO log in physical storage.

What the hell did Purge do? In fact, it is equivalent to a garbage collector. For example, when the user next command, such as "DELETE FROM t WHERE c = 1;", InnoDB will not delete the corresponding record immediately, it will do the following three things:

it marks this record for deletion (by deleting the flag bit)
Store raw records in UNDO log
Update the record column DB_TRX_ID and DB_ROLL_PTR (these columns are added by Innodb on the original record column) . DB_TRX_ID records the transaction ID of the last operation record. DB_ROLL_PTR is also called a rollback pointer, which points to the UNDO log record. This UNDO Log records the information of the original record, which can be used to reconstruct the original record (such as when a rollback occurs). If the operation is an insert, there will also be a DB_ROW_ID，这个指明了新记录的行号.

When the transaction is committed, the records marked for deletion and the records in UNDOLog will not be cleared immediately. These records can be reused or shared by other transactions. These records will be purged only when no transactions share these records. This is the so-called purge operation. In order to improve the operational efficiency of the database, the purge operation is performed asynchronously by another thread. This is why there are unpurged transactions as you saw earlier.

Next, is the list of transactions, there is an example below.

1 ---TRANSACTION0 80157600, ACTIVE 4 sec, process no 3396, OS thread id 1148250464,

thread declared inside InnoDB 442

2 mysqltables in use 1, locked 0

3 MySQLthread id 8079, query id 728899 localhost baron Sending data

4 selectsql_calc_found_rows * from b limit 5

5 Trxread view will not see trx with id>= 0 80157601, sees <0 80157597

Line 1 shows the transaction ID. ACTIVE 4 sec means that the transaction has been in the ACTIVE state for 4 seconds. Other possible states include "not started," "active," "prepared," and "committed in memory" (once it commits to disk, the state will change to "not started")

"threaddeclared inside InnoDB 442" means that this thread is in the InnoDB core and there are 422 tickets available. There is a parameter, innodb_concurrency_tickets, that configures the number of tickets available for a thread.

What is the number of tickets? When the Innodb internal thread reaches the innodb_thread_concurrency limit, the new thread needs to be queued in the thread queue for Innodb kernel execution. Thread tickets allow threads that have been running Innodb kernels to execute multiple times (that is, execute a time slice cycle multiple times), and the number of times is determined by tickets. This thread will not swap out cores into the queue until it runs out of tickets. The purpose of this is to avoid the so-called threadthrashing problem, which prevents threads from constantly swapping in and out of the kernel.

A common example is if you have long-executing SQL statements that cannot be completed within the specified tickets, they will be swapped out of the kernel. The overhead of such an increased thread context switch is staggering. In this case, consider increasing the value of tickets.

Line 2, showing the data table locked by the current transaction

Line 3 shows the thread id, which is the same value as the process id displayed in the show full processlist command.

Line 4 shows the SQL statement executed by the current transaction.

Line 5, shows MVCC, the information for multi-version concurrency control, which indicates which other transactions can see this record and which cannot.

FILE I / O

The FILE I/O section shows the status of the I/O Helper thread, including some statistics

1 --------

2 FILES

3 --------

4 I/Othread 0 state: waiting for i/o request (insert buffer thread)

5 I/Othread 1 state: waiting for i/o request (log thread)

6 I/Othread 2 state: waiting for i/o request (read thread)

7 I/Othread 3 state: waiting for i/o request (write thread)

8 Pendingnormal aio reads: 0, aio writes: 0,

9 ibufaio reads: 0, log i/o's: 0, sync i/o's: 0

10 Pendingflushes (fsync) log: 0; buffer pool: 0

11 17909940OS file reads, 22088963 OS file writes, 1743764 OS fsyncs

12 0.20 reads/s, 16384 avg bytes/read, 5.00 writes/s, 0.80fsyncs/s

Lines 4-7 show the status of the I/O helper thread.

Lines 8-10 show the pending operations of each I/O helper thread, the pending log and the fsync() call of the buffer pool thread. I will dedicate another chapter to explaining what an fsync() call is and why there is an fsync call. Please wait for the next update of my blog.

Line 11 shows the number of reads, writes, and fsync() calls.

Line 12 shows statistics per second

Lines 8-9 can be used to detect I/O-bound problems. If there are many pending operations, it is very likely that your server has I/O-bound problems. The acronym "aio" stands for "asynchronous I/O (asynchronous I/O)."

INSERT BUFFER AND ADAPTIVE HASHINDEX

1 -------------------------------------

2 INSERTBUFFER AND ADAPTIVE HASH INDEX

3 -------------------------------------

4 Ibuffor space 0: size 1, free list len 887, seg size 889, is not empty

5 Ibuffor space 0: size 1, free list len 887, seg size 889,

6 2431891inserts, 2672643 merged recs, 1059730 merges

7 Hashtable size 8850487, used cells 2381348, node heap has 4091 buffer(s)

8 2208.17 hash searches/s, 175.05 non-hash searches/s

Line 4 shows some information about insertbuffer, including free list, segment size

Among them, space 0 means that there may be multiple insert buffers, such as space 0, space 1, etc. But actually MySQL doesn't have multiple insert buffers, so you can see 4,5 rows are repeated. This is considered a redundant output. In the new version, this output is removed.

Line 6 shows how many buffer operations were performed by Innodb. By comparing inserts and merges, you can see the efficiency of the insert buffer

Line 7 shows some information about the hash table

Line 8 shows how many hash searches are done per second, as well as non-hash searches

LOG

This records the information of the tansaction log subsystem (if you don't remember, see the I/O Helper Thread in the FILE I/O section)

1 ---

2 LOG

3 ---

4 Logsequence number 84 3000620880

5 Logflushed up to 84 3000611265

6 Lastcheckpoint at 84 2939889199

7 0pending log writes, 0 pending chkp writes

8 14073669 log i/o's done, 10.90 log i/o's/second

Line 4, shows the current log sequencenumber. Log sequence number indicates how many bytes are written to the log file

Line 5, shows the logs that have been flushed (written to disk)

Line 6, shows the logs of the last checkpoint

Lines 7 and 8 show the statistics of the pending log

BUFFER POOL AND MEMORY

1 ----------------------

2 BUFFERPOOL AND MEMORY

3 ----------------------

4 Totalmemory allocated 4648979546; in additional pool allocated 16773888

5 Bufferpool size 262144

6 Freebuffers 0

7 Databasepages 258053

8 Modifieddb pages 37491

9 Pendingreads 0

10 Pendingwrites: LRU 0, flush list 0, single page 0

11 Pagesread 57973114, created 251137, written 10761167

12 9.79reads/s, 0.31 creates/s, 6.00 writes/s

13 Buffer pool hit rate 999 / 1000

Line 4 shows the size of the memory allocated to Innodb, and the size used by the additional pool (if not used, it will be displayed as 0)

Lines 5-8 show buffer pool information. Shows the Buffer pool size, free buffers, database pages, dirty pages (dirty pages). You will see that the buffer pool size is larger than the database pages, because the buffer pool also stores some other system information such as lock index, hash index, etc.

Lines 9-10 show pending reads and writes

Line 11 shows the pages read, written and created by Innodb

Line 13 shows Innodb's buffer pool hit rate, which is usually guaranteed to be above 998/1000. If not, consider increasing the buffer pool size and optimizing your queries

ROW OPERATIONS

This section shows rowoperation and some other statistics

1 --------------

2 ROWOPERATIONS

3 --------------

4 0queries inside InnoDB, 0 queries in queue

5 1read views open inside InnoDB

6 Mainthread process no. 10099, id 88021936, state: waiting for server activity

7 Numberof rows inserted 143, updated 3000041, deleted 0, read 24865563

8 0.00inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s

9 ----------------------------

10 ENDOF INNODB MONITOR OUTPUT

11 ============================

Line 4 shows how many threads are in the Innodb core (recall the chapter on transactions)

Line 5 shows how many read views are open, a read view is an MVCC "snapshot" with consistency guarantees

Line 6 shows the status information of the main thread of the kernel, and the remaining possible statuses are:

archiving log (if log archive is on)

doing background droptables

doing insert buffer merge

flushing buffer pool pages

flushing log

making checkpoint

purging

reserving kernel mutex

sleeping

suspending

waiting for buffer poolflush to end

waiting forser veractivity

Lines 7-8 show some statistics for row operations.

refer：http://blog.51cto.com/louisyang/1379813

show engine innodb status details