SHOW INNODB STATUS Quest

[INNODB Series]--SHOW INNODB STATUS Quest SHOW INNODB STATUS Quest reprint: Http://imysql.com/2008_05_22_walk_through_show_innodb_status

Original translation from: http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/

A lot of people let me explain the output of show INNODB status , understand what the show INNODB status is outputting, and what information we can get from this information to improve MySQL performance.

First, let's look at the basics of the SHOW INNODB STATUS output, which prints a lot of counters, statistics, transactional information about INNODB internal performance. In MySQL 5, the performance statistics of InnoDB are also shown in the show STATUS results. Most of the other information is the same as SHOW INNODB STATUS, which is not available in the previous version.

Many of the stats in SHOW INNODB STATUS are updated every second, so it's best to count the results over time if you're going to take advantage of these stats. InnoDB first outputs the following information:

1.=====================================2.060717  3:07:56 INNODB MONITOR output3.============================== =======4.per second averages calculated from the last seconds

First make sure that this is a sample data that is at least 20-30 seconds in statistics. If the average statistic interval is 0 or 1 seconds, then the result is meaningless.
Honestly, I don't like the average value provided by INNODB, because it's hard to get a reasonable average interval statistic, and if you're writing a script to get the SHOW INNODB STATUS results, it's best to get a global statistic and then get the average. Of course, it is also useful to view the output information directly.

The next section shows information about the signal (semaphores):

1.----------2.semaphores3.----------4.OS WAIT ARRAY info:reservation count 13569, signal count 114215.--thread 1152170336 have waited at./... /include/buf0buf.ic Line 630 for 0.00 seconds The Semaphore:6.mutex in 0x2a957858b8 created file BUF0BUF.C line 517, lock VAR 07.waiters flag 08.wait is Ending9.--thread 1147709792 have waited at./.  /include/buf0buf.ic Line 630 for 0.00 seconds The Semaphore:10.mutex in 0x2a957858b8 created file BUF0BUF.C line 517, lock VAR 011.waiters flag 012.wait is ENDING13. Mutex spin waits 5672442, Rounds 3899888, OS waits 471914.rw-shared spins 5920, OS waits 2918; Rw-excl spins 3463, OS waits 3163 

This paragraph can be divided into 2 parts. Part of this is the current wait, which only contains all the records in a highly concurrent environment, so InnoDB often fall back to the system waiting. If the wait is resolved by a spin lock, then this information will not be displayed.

With this piece of information, you'll know where the hot spots are in the system load. But this needs to know the source-related knowledge-from the above information can be seen in which source file which line (different version results may be different), but from here do not see any information. Still, you can guess something from the file name-in this case, the filename "buf0buf.ic" is indicative of a relationship with some buffer pool contention. If you want to know more, see the source.

There are some more details about the wait. "Lock Var" represents the value of the current mutex object (locked = 1/release = 0), and "Waiters flag" indicates the current number of waits. Also, in this example, you can see the wait state information "Wait is ending", which means that the mutex has been freed, but the system dispatch thread is still processing.

The second block is event statistics-"Reservation count" and "signal count" show how often the InnoDB uses an internal synchronization array for activity-time slice (slot) allocations and how frequently the thread signal uses the synchronization array. These statistics can be used to indicate how often innodb fall back to the system wait. There is also direct information about the system wait, you can see the "OS Waits" Mutex (mutexes), as well as the read-write lock. mutexes and shared locks are displayed in this information. System wait and "hold (reservation)" is not exactly the same, before fallback to the complex wait mode with Sync_array, InnoDB will try to "output" to the system, I hope the next scheduled time object in the named thread has been released. System waits are relatively slow and may be problematic if tens of thousands of system waits per second occur. Another way to observe is to view the context Exchange frequency in the system state.

Another important piece of information is the number of "Spin Waits" and "Spin rounds". The spin lock is a low-cost wait compared to the system wait; but it is an active wait that wastes some CPU resources. So if you see a lot of spin waits and spin rotations, it's obvious that it wastes a lot of CPU resources. Wasting CPU time and unnecessary context switching can be balanced with innodb_sync_spin_loops .

The following section shows the deadlock condition:

1.------------------------2.LATEST detected DEADLOCK3.------------------------4.060717 4:16:485.*** (1) TRANSACTION : 6.TRANSACTION 0 42313619, ACTIVE sec, Process no 10099, OS thread ID 3771312 starting index read7.mysql tables in use 1, Locked 18.LOCK WAIT 3 LOCK struct (s), heap size 3209.MySQL thread ID 30898, query id 100626 localhost root updating10.u pdate iz set pad= ' A ' where i=211.*** (1) Waiting for this LOCK to be Granted:12.record LOCKS Space ID 0 page no 16403 n bi TS index ' PRIMARY ' of table ' Test/iz ' Trx ID 0 42313619 lock_mode X Locks Rec but not gap waiting13. Record Lock, Heap No 5 physical record:n_fields 4; Compact format; Info bits 014. 0:len 4; Hex 80000002; ASC;; 1:len 6; Hex 00000285a78f; ASC;; 2:len 7; Hex 00000040150110; ASC @;; 3:len 10; Hex 61202020202020202020; ASC A;;  16.*** (2) transaction:17.transaction 0 42313620, ACTIVE sec, Process no 10099, OS thread ID 4078512 starting index Read, thread declared inside InnoDB50018.mysql tables in use 1, locked 119.3 lock struct (s), heap size 32020.MySQL thread ID 30899, query ID 100627 localhost Root updating21.update iz set pad= ' A ' where i=122.*** (2) holds the LOCK (S): 23.RECORD LOCKS Space ID 0 page no 16403 n bi TS index ' PRIMARY ' of table ' Test/iz ' Trx ID 0 42313620 lock_mode X locks Rec but not gap24. Record Lock, Heap No 5 physical record:n_fields 4; Compact format; Info bits 025. 0:len 4; Hex 80000002; ASC;; 1:len 6; Hex 00000285a78f; ASC;; 2:len 7; Hex 00000040150110; ASC @;; 3:len 10; Hex 61202020202020202020; ASC A;; 27.*** (2) waiting for this LOCK to be Granted:28.record LOCKS Space ID 0 page no 16403 n bits, index ' PRIMARY ' of t Able ' Test/iz ' Trx ID 0 42313620 lock_mode X Locks Rec but not gap waiting29. Record Lock, Heap No 4 physical record:n_fields 4; Compact format; Info bits 030. 0:len 4; Hex 80000001; ASC;; 1:len 6; Hex 00000285a78e; ASC;; 2:len 7; Hex 000000003411d9; ASC 4;; 3:Len 10; Hex 61202020202020202020; ASC A;; 32.*** WE Roll Back TRANSACTION (2)

This shows that Innodb last detected a deadlock caused by a transaction, including the state at the time of the deadlock, what locks were added, what locks are waiting to be released, and INNODB determines which transaction will be rolled back. Note that the InnoDB only shows simple information about the lock that the transaction holds. And only the last statement executed by each transaction is displayed, and the record of the deadlock occurs because of these statements. Viewing the complex deadlock information also requires viewing the log file to find the statement that actually caused the conflict. In most cases, show INNODB STATUS shows enough information.

The following is information about the deadlock caused by a foreign KEY constraint:

1.------------------------2.LATEST FOREIGN KEY ERROR3.------------------------4.060717 4:29:00 Transaction:5. TRANSACTION 0 336342767, ACTIVE 0 sec, Process no 3946, OS thread id 1151088992 inserting, thread declared inside InnoDB 5 006.mysql tables in use 1, locked 17.3 lock struct (s), heap size 368, undo log Entries 18.MySQL thread ID 9697561, query i d 188161264 localhost root update9.insert into child values (2,2) 10.Foreign key constraint fails for table ' Test/child ': 11.  , 12. CONSTRAINT ' Child_ibfk_1 ' FOREIGN KEY (' parent_id ') REFERENCES ' parent ' (' id ') on DELETE CASCADE13. Trying to add in child table, in index ' Par_ind ' Tuple:14.data tuple:2 fields;15. 0:len 4; Hex 80000002; ASC;; 1:len 6; Hex 000000000401; ASC;; 17.But in the parent table ' Test/parent ', in the index ' PRIMARY ', 18.the closest match we can find is record:19.physical record : N_fields 3; 1-byte offs TRUE; Info bits 020. 0:len 4; Hex 80000001; ASC;; 1:len 6; Hex 0000140c2d8f; ASC-;; 2:len 7; Hex 80009c40050084; ASC @;;

The INNODB will display the statement that raised the error. FOREIGN KEY constraints define failures and define the most closely related parent table. Many of the embedded information is represented in 16 notation, but it is not very important for problem diagnosis, they are mainly used for INNODB developers to view or for debugging purposes.

The next step is to display the currently active transactions for INNODB:

1.------------2.transactions3.------------4.Trx ID counter 0 801576015.Purge done for Trx ' s n:o <0 80154573 undo N:o &l T;0 06.History List length 67.Total number of lock structs in row lock hash table 08.LIST of transactions for each session:9.-  --transaction 0 0, not started, process no 3396, OS thread ID 115244067210.MySQL thread ID 8080, query ID 728900 localhost Root11.show InnoDB status12.---TRANSACTION 0 80157600, ACTIVE 4 sec, Process no 3396, OS thread ID 1148250464, Thread Dec Lared inside InnoDB 44213.mysql tables in use 1, locked 014.MySQL thread ID 8079, query ID 728899 localhost root sending D Ata15.select sql_calc_found_rows * from B limit 516.Trx read view would not see Trx with id>= 0 80157601, sees <0 80 15759717.---TRANSACTION 0 80157599, ACTIVE 5 sec, Process no 3396, OS thread ID 1150142816 fetching rows, thread declared Inside InnoDB 16618.mysql tables in use 1, locked 019.MySQL thread ID 8078, query ID 728898 localhost root sending data20. Select Sql_calc_founD_rows * from B limit 521.Trx read view won't see Trx with id>= 0 80157600, sees <0 8015759622.---TRANSACTION 0 80157598, ACTIVE 7 sec, Process no 3396, OS thread ID 1147980128 fetching rows, thread declared inside InnoDB 11423.mysql   Tables in use 1, locked 024.MySQL thread ID 8077, query ID 728897 localhost root sending data25.select sql_calc_found_rows * from B limit 526.Trx read view won't see Trx with id>= 0 80157599, sees <0 8015759527.---TRANSACTION 0 801575  $, ACTIVE 7 sec, Process no 3396, OS thread ID 1152305504 fetching rows, thread declared inside InnoDB 40028.mysql tables In use 1, locked 029.MySQL thread ID 8076, query ID 728896 localhost root sending data30.select sql_calc_found_rows * fr Om b limit 531.Trx read view won't see Trx with id>= 0 80157598, sees <0 80157594

If the current connection is not many, the entire list of transactions is displayed, and if there is a large number of connections, INNODB will only display their number, reducing the output list information so that the output will not be too much.

The transaction ID is the identity of the current transaction, and the ID of the transaction is incremented each time. Purge done for Trx ' s N:o refers to the number of transactions that the Purge (purge) thread has completed. InnoDB only clears older versions of data that are not needed by the current transaction. Old, uncommitted transactions can block cleansing threads and consume resources. You can see if this happens by looking at the difference in the number of cleared transactions by 2 times. In a few cases, the cleansing thread may be difficult to keep up with the update speed, and the difference between the 2 view values may be increasing; thenInnodb_max_purge_lag will come in handy. "Undo N:o" shows the rollback log number currently being processed by the cleansing thread, and its value is 0 if it is not currently active.

History List length 6 refers to the number of non-purged transactions in the rollback space. As the transaction commits, its value increases, and its value decreases as the thread is cleared to run.

Total number of lock structs in row lock hash table refers to the total number of row lock structures that the transaction has allocated. It is not necessarily equal to the total number of rows that have been locked, usually a lock structure corresponding to multiple rows of records.

In MySQL, if there is no active transaction for each connection, its state is Not started, if there is an active transaction, it is ACTIVE。 Note that although the transaction is active, the state of its connection may be "sleep"-if it is in a transaction with multiple statements. INNODB displays both the system's thread number and the process number, which can be useful for debugging or other similar purposes using GDB. In addition, the state of the transaction is displayed according to the current actual state, for example "read record (fetching rows)",em> "Update (updating)" and so on."Thread declared inside InnoDB" This means that the Innodb kernel is running the thread and requires 400 more tickets. Innodb will be based on innodb_thread_concurrency Value to limit the number of concurrent threads that do not exceed it. If the thread is not currently running in the kernel of INNODB, its state may be"Waiting in InnoDB queue" Or "Sleeping before joining InnoDB queue"。 The latter state is a bit of a meaning-Innodb to avoid having too many threads at the same time rushing into the run queue, they try to get these threads into a wait state if there are not enough free slots (slots). This can cause the number of threads currently active in the Innodb kernel to be more likely than innodb_thread_concurrency The value is also small. In some load environment, this may help reduce the time that threads enter the queue. can be adjusted byInnodb_thread_sleep_delay To achieve it, the unit is subtle.

MySQL tables in use 1, locked 0 refers to the number of data tables that have been used in a transaction (already visited), and the number of locks. Innodb generally does not lock the table, so the number of lock tables is generally 0 , unless it is an ALTER table or other similar lock TABLES The statement.

In addition to the specific information related to InnoDB, some basic information can be viewed through, for example, what statement is being executed, query ID number, query status, and so on.

The following section shows specific IO-related information:

1.--------2.FILE i/o3.--------4.i/o thread 0 state:waiting for I/O request (insert buffer thread) 5.I/O thread 1 state:w Aiting for I/O request (log thread) 6.I/O thread 2 state:waiting for I/O request (read thread) 7.I/O thread 3 State:waitin G for I/O request (write thread) 8.Pending normal Aio reads:0, Aio writes:0,9. Ibuf Aio reads:0, log I/O ' s:0, sync I/O ' s:010.pending flushes (fsync) log:0; Buffer pool:011.17909940 OS file reads, 22088963 OS file writes, 1743764 os fsyncs12.0.20 reads/s, 16384 avg Bytes/read, 5.00 writes/s, 0.80 fsyncs/s 

This section shows the IO helper thread status-insert buffer thread, log thread, read, write thread. They correspond to insert buffer merge, asynchronous log refresh, read-ahead, and flush dirty data, respectively. The normal read originating from the query is performed by a running query. Under the Unix/linux platform, you can always see 4 threads, which are adjustable by innodb_file_io_threads on Windows. Each thread is ready to see its status: Waiting forI/O request or performing a specific operation.

Each thread shows the number of operations in progress-the number of operations that are being executed or executing. In addition, the number of fsync operations that are being performed is also displayed. When writing data, InnoDB need to make sure that the data is eventually written to disk, but it is not enough to put them in the system cache. This is usually done by calling Fsync (). If its value is always high, it means that the InnoDB may be at a higher IO load state. Note that the IO requests raised by the thread execution request are not counted, so although the system has a high IO load, they may have a value of 0.

The following shows the average statistics for IO operations, which are useful for graphical display or monitoring.
"16384 avg bytes/read" is the average of the read request. Random io, the size of each page is 16K, and the pre-reading of a full-table scan or index Scan can cause this value to increase significantly. Therefore, it embodies the efficiency of pre-reading.

1.-------------------------------------2.INSERT BUFFER and ADAPTIVE HASH INDEX3.-------------------------------------4.Ibuf for Space 0:size 1, free list len 887, seg size 889, was not empty5. Ibuf for Space 0:size 1, free list len 887, seg size 889,6.2431891 inserts, 2672643 merged RECs, 1059730 Merges7. Hash table size 8850487, used cells 2381348, node heap has 4091 buffer (s) 8.2208.17 hash searches/s, 175.05 Non-hash Search es/s

This section shows the status of the insert buffer and the adaptive Hash index. The first line shows the status of the insert buffer-the size of the segment and the free list, as well as how many records are in the buffer. The following shows how many insertions have been completed in the buffer, how many records have been merged, and how many merges have been completed. The ratio of the number of merges divided by the number of insertions can reflect the efficiency of the insert buffer.

InnoDB uses a hash index to establish a memory page index to form an adaptive hash index rather than a b-tree index, which accelerates the retrieval of row Records to memory pages. This shows the size of the hash table, as well as how many cells and buffers are used by the adaptive Hash Index. You can understand the efficiency of a hash index by calculating the number of times it is retrieved using a hash index and the number of times it has not been retrieved.

Currently there is no way to adjust the adaptive hash index, mainly for viewing.

1.---2.log3.---4.Log sequence number 30006208805.Log flushed up to   30006112656.Last checkpoint at  84 293988 91997.0 pending Log writes, 0 pending CHKP writes8.14073669 log I/O ' s done, 10.90 log I/O ' S/second

The next step is to display information about the InnoDB log subsystem. You can see the current log sequence number-the equivalent of the total number of bytes that InnoDB has written to the log file since the table space began to be created. You can also see which point the log has been flushed to, and you can also calculate how many logs are not flushed to the file based on the last checkpoint. InnoDB uses a fuzzy checkpoint, so this line shows the log sequence number that has been flushed from the buffer pool to the file. Because a higher log sequence number may not be flushed to the log file immediately, the log sequence number cannot be overwritten. By monitoring the log sequence to which log is flushed, you can determine whether the innodb_log_buffer_size setting is reasonable, and if you see more than 30% of the log is not flushed to the log file, you need to consider increasing its value.

In addition, you can see the log writes and the number of checkpoints. Depending on the number of log I/O operations, you can partition the number of IO requests and log IO requests related to the tablespace, and you can determine exactly how many log files are required. Note that the value ofinnodb_flush_log_at_trx_commit can affect the high or low cost of log write operations. If innodb_flush_logs_at_trx_commit=2, the log is written to the system cache and then sequentially written to the log file, so it is relatively much faster.

1.----------------------2.BUFFER POOL and MEMORY3.----------------------4.Total Memory Allocated 4648979546; In additional pool allocated 167738885.Buffer pool size 2621446.Free buffers 07.Database pages 2580538.Modifie D DB pages 374919.Pending reads 010.Pending WRITES:LRU 0, flush list 0, single page 011.Pages read 57973114, created 251 137, written 1076116712.9.79 reads/s, 0.31 creates/s, 6.00 writes/s13. Buffer Pool hit rate 999/1000 

This section shows information about the utilization of the buffer pool and memory. You can see all the memory allocated by InnoDB (sometimes more than you can set), as well as additional memory pool allocations (you can check if it's the right size), how many memory pages there are in total, how many free memory pages there are, how many memory pages the database allocates, and how many dirty memory pages there are. From this information, you can determine whether the memory buffer pool is set reasonable, if there is always a large number of free memory pages, you do not need to set up so much memory, you can appropriately reduce a bit. If the free memory page is 0, in this case the database memory page does not necessarily match the total number of buffer pools, because the buffer pool also needs to hold information such as lock information, adaptive hash Index, and other system structures.

Read-write in wait refers to a memory buffer pool level request. InnoDB may merge multiple file-level requests onto one, so they are different. We can also see the pages in the various types of IO,LRU memory pages that InnoDB commits that need to be refreshed-dirty memory pages that are not accessed for long periods of time; Refresh List-
An old memory page that needs to be refreshed after the checkpoint process has finished processing, and a separate memory page-a separate write memory page.

We can also see how many times memory pages have been read and written. A memory page that has been created is an empty memory page that is created specifically for new data when the contents of the current memory page are not read into the memory buffer pool.

Finally we can see the buffer pool hit rate, which indicates the efficiency of the buffer pool. 1000/1000 equals 100% of the hit rate. However, it is hard to say that the buffer pool hit rate is high enough, depending on the load environment. Typically, 950/1000 is sufficient, and sometimes the hit rate may be 995/1000 in environments with high IO loads.

1.--------------2.ROW OPERATIONS3.--------------4.0 queries inside InnoDB, 0 queries in queue5.1 read views open inside in Nodb6.main thread Process No. 10099, id 88021936, state:waiting for server activity7. Number of rows inserted 143, updated 3000041, deleted 0, read 248655638.0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0. XX reads/s

The last part shows the data row operations and some system information related situations.

The InnoDB thread queue status is displayed at the beginning-how many threads are waiting or active. How many read views are open inside the InnoDB-
This is the case when the transaction begins, but there is currently no active statement, the state of the INNODB main thread controls the number of system operation schedules-flush dirty memory pages, checkpoints, purge threads, flush logs, merge insert buffers, and so on. "State" value indicates the current state of the main thread.

You can then see the number of data row operations and their average values since the system started. They can be conveniently used to monitor and draw system state diagrams, and the number of data row operations can be a good measure of innodb load. Not all data row operations bring the same load, access to 10 bytes of the row is much smaller than the 10Mb rows, but the total number of queries compared to the information is more useful, the difference is very large.

It is also important to note that the SHOW INNODB STATUS is not immutable and may not match at some point in time. Show INNODB status results, different times may show different results, so sometimes conflicting information may be seen. This is due to the need for a global lock to provide consistent information at design time, resulting in significant overhead.

From for notes (Wiz)

SHOW INNODB STATUS Quest