• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Showinnodbstatus公开
 

Showinnodbstatus公开

on

  • 393 views

show engine innodb status\G 输出内容解释。

show engine innodb status\G 输出内容解释。

Statistics

Views

Total Views
393
Views on SlideShare
393
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Showinnodbstatus公开 Showinnodbstatus公开 Presentation Transcript

    • show engine innodb status http://blog.csdn.net/longxibendi
    • 宏观认识4个问题:1.mysql io1.mysql并发低,是因为io io的问题么?2. 为什么相同硬件,oracle mysql qps oracle mysql的 qps高? oracle比mysql3. 如果一次物理io, io, 500nm io,耗时500nm 500nm,那会怎样?4. buffer_pool 36G, mysqld 36G,没有连接进来,mysqld mysqld占用内存要多一些 ?
    • 宏观认识1. INNODB MONITOR OUTPUT2. SEMAPHORES3. LASTEST DETECTED DEADLOCK
    • 宏观认识1.TRANSACTIONS
    • 宏观认识1.FIFE I/O2.INSERT BUFFER AND ADAPTIVE HASH INDEX3.LOG
    • 宏观认识1.BUFFER POOL AND MEMORY2.ROW OPERATIONS 6
    • INNODB MONITOR OUTPUT1. 显示当前时间点。2.计算最近的43秒内的部分参数的平均值。(不受用户控制,一般不会超过60秒)1. innodb_status_file=1,会每隔15s,将show engine innodb status输出结果,存放到var/innodb_status.pid 文件中,pid是进程ID. 7
    • SEMAPHORES 1. Semaphores .进程间相互通信,避免多个进程共享资源时发生冲突。(起并发控制作用)Innodb 的并发控制:1.Innodb mutex : 特点,不可重入;短期持有; 作用,保护系统中的全局资源,临界区; 例如,buffer pool mutex; 对整个buffer_pool 加mutex.比如页面分裂、btree调整。 buffer header mutex; 对页面的操作,需要持有该mutex。 Adaptive Hash Index mutex。 log sys mutex; 写事物日志,串行写入,非并行。group commit?. 8
    • SEMAPHORES1. Semaphores .进程间相互通信,避免多个进程共享资源时发生冲突。(起并发控制作用)Innodb 的并发控制:2.Innodb latch : 特点,读写锁 (RW_LOCK); 作用,保护系统中的共享buffer; 例如,page latch.对一个page 进行read/write。 9
    • SEMAPHORES1. Semaphores .进程间相互通信,避免多个进程共享资源时发生冲突。(起并发控制作用)Innodb 的并发控制:3.Innodb pin : 特点,一个标识,一个在mutex保护下的count值,不是一个锁; 作用,如果count !=0,内存中的page不能被替换出; 例如,page pin count。 10
    • SEMAPHORES1. Semaphores .进程间相互通信,避免多个进程共享资源时发生冲突。(起并发控制作用)Innodb 的并发控制:4.mysql 其他lock : 特点,锁住mysql/innodb资源; 作用,锁表,锁数据; 例如,select * from game.user where id <= 10024 for update ;(锁数据) flush tables with read lock;( 所有表 只读) lock table game.user write ;( 表置写锁)1. innodb_status_file=1,会每隔15s,将show engine innodb status输出结果,存放到var/innodb_status.pid 文件中,pid是进程ID. 11
    • SEMAPHORES1. Semaphores .进程间相互通信,避免多个进程共享资源时发生冲突。(起并发控制作用)1.各种mutex & rw_lock.2.Kernel mutex. 5.6拆了。 12
    • SEMAPHORES1. Semaphores .进程间相互通信,避免多个进程共享资源时发生冲突。(起并发控制作用)各种故事:1.(空表加字段,会获取table cache锁,一个全局锁,整个instance都会被锁住,当多个ddl提交的时候,且bufferpool超大的时候,每个ddl都会触发一个bufferpool扫描,那就类似于一个超长锁了。整个应用处于僵死状态。)(MySQL加字段,一直采用的是Create Tmp Table + Rename + Drop Old Table的方式,而在Drop OldTable阶段,InnoDB会两次遍历Buffer Pool,此时加Buffer Pool Mutex遍历,会引起一定时间的Hang。)2.mysql 5.0.51b ,80天的binlog.(一天5G)。调整expire_logs_days=7; 执行flush logs;阻塞写。2.3.drop table ,阻塞 其他表写。3.4.自适应hash索引;ibbackup 备份程序;子查询 锁。 13
    • SEMAPHORES1. Semaphores .进程间相互通信,避免多个进程共享资源时发生冲突。(起并发控制作用)Innodb 的并发控制 参数:Innodb_thread_concurrency (默认是8, 0~1000)(innodb内核并发线程参数)Innodb_sync_spin_loops (默认是20,0~4,294,967,295)(在thread被挂起之前,等待innodb mutex被释放的 等待次数)1.大量的thread等待信号量原因是: 磁盘io读写问题,innodb 内部的 上下文切换导致。 14
    • SEMAPHORES1. Semaphores .进程间相互通信,避免多个进程共享资源时发生冲突。(起并发控制作用)Kernel mutex & 争用:spin-wait, 一个线程获取mutex,且 没有得到。就是一次check 。spin-wait cycle,一个线程,在不断获取mutex,不断的check,就是一个spin-wait cycle。OS wait, 线程放弃 spin-wait,进入sleep,至少消耗一个OS wait。Innodb_sync_spin_loops (默认是20,0~4,294,967,295)。innodb_spin_wait_delay(默认是6, 0 ~4,294,967,295)举例:check,check,check,check; sleep ;sleep;sleep ,;check,check,check,check;Innodb_sync_spin_loops,线程在一个spin-wait cycle中,check的次数。本例为 4。Innodb_spin_wait_delay,线程在相邻spin-wait cycle的时间。单位为us。本例为3。1.会不会因为innodb_sync_spin_loops太少,导致占用更多cpu上下文切换,大小是多少比较合适?2.Linux,一个cpu周期(时间片),耗时多长,一个spin-wait cycle耗时多长? 15
    • SEMAPHORES1. Semaphores .进程间相互通信,避免多个进程共享资源时发生冲突。(起并发控制作用)几个字段:Mutex spin waits :一个线程获取mutex,但mutex不可用(没获取到),线程在一个spin wait 执行check的次数。Rounds:线程在spin-wait cycle中 ,执行check mutex的总数。Rw-share 共享锁,RW-excl 排他锁(exclusive)。OS waits:线程放弃spin waiting,进行sleep的总数。signal count 22133482=OS waits 13850218+ OS waits 8365537+ OS waits 3279461.大量的thread等待信号量原因是: 磁盘io读写问题,innodb 内部的 上下文切换导致。 16
    • SEMAPHORES----------SEMAPHORES----------OS WAIT ARRAY INFO: reservation count 13569, signal count 11421--Thread 1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0waiters flag 0wait is ending--Thread 1147709792 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0waiters flag 0wait is endingMutex spin waits 5672442, rounds 3899888, OS waits 4719RW-shared spins 5920, OS waits 2918; RW-excl spins 3463, OS waits 3163几个字段:Lock var 0, mutex状态标志,locked=1,free=0。Waiters flag 0, 当前waiter的编号。Wait is ending,waiter状态。 表示,当前的mutex是free状态,等待该mutex的线程的等待状态 为0,都在等待该mutex.但该mutex已经是free,只不过调度器还没有让线程处于运行状态。线程等待调度器运行。1.大量的thread等待信号量原因是: 磁盘io读写问题,innodb 内部的 上下文切换导致。 17
    • SEMAPHORESKernel_mutex 的例子:------------Thread 140370743510784 has waited at trx0trx.c line 1184 for 0.0000 seconds the semaphore:Mutex at 0x2b0ccc8 &kernel_mutex, lock var 1waiters flag 0--Thread 140370752542464 has waited at trx0trx.c line 1772 for 0.0000 seconds the semaphore:Mutex at 0x2b0ccc8 &kernel_mutex, lock var 1 waiters flag 0--Thread 140088222295808 has waited at trx0trx.c line 1184 for 0.0000 seconds the semaphore:Mutex at 0x2b0ccc8 &kernel_mutex, lock var 1waiters flag 0几个字段:Lock var 0, mutex状态标志,locked=1,free=0。Waiters flag 0, 当前waiter的编号。Wait is ending,waiter状态。 表示,当前的kernel_mutex是lock状态,等待该mutex的线程的等待状态 为0,都在等待该mutex.1.大量的thread等待信号量原因是: 磁盘io读写问题,innodb 内部的 上下文切换导致。 18
    • SEMAPHORES1. Semaphores .进程间相互通信,避免多个进程共享资源时发生冲突。(起并发控制作用) 19
    • LATEST FOREIGN KEY ERRORForeign key error 原因:1.update/delete/insert 的数据 ,依赖其他表中的行数据。2. 删除/修改 一列时,这个列会关联到其他表。3.Rename /drop table。1.Error 150 , Error 1451, Error 1452 ,foreign key constraint failed2.Error 1025 ,rename/drop table3.准入不允许 foreign key 。 20
    • LATEST FOREIGN KEY ERRORForeign key error 原因:1.update/delete/insert 的数据 ,依赖其他表中的行数据。2. 删除/修改 一列时,这个列会关联到其他表。3.Rename /drop table。1.Error 150 ,Error 1451,Error 1452 ,foreign key constraint failed2.Error 1025 ,rename/drop table3.准入不允许 foreign key 。 21
    • LATEST DETECTED DEADLOCK几个ID:1. process no 13744 , mysqld 进程的PID 。(pstree mysql –p |grep mysqld)2. OS thread id 1179187552 , 操作系统 线程 id。(一个mysql 连接,对应一个)3.MySQL thread id 96237550 , connect id 。(show processlist; 第一个字段)4.query id 2547648761 , 本次query id。(同一个链接,发一些 sql,每次 sql对应一个) 22
    • LATEST DETECTED DEADLOCK1.ERROR 1213(40001) 23
    • LATEST DETECTED DEADLOCK1.回滚开销小的事物。2.如何减少、消除死锁。3.死锁的影响 。为什么主库 cpu使用率高?4.在不改mysql代码的情况下,如何提高并发量? 24
    • TRANSACTIONS------------TRANSACTIONS------------Trx id counter 0 3638031820Purge done for trxs n:o < 0 3637930396 undo n:o < 0 0History list length 19988Total number of lock structs in row lock hash table 0LIST OF TRANSACTIONS FOR EACH SESSION:---TRANSACTION 0 0, not started, process no 20150, OS thread id 1162877280MySQL thread id 119512286, query id 46504256930 localhost rootshow engine innodb status---TRANSACTION 0 3638031818, not started, process no 20150, OS thread id 1196996960MySQL thread id 119512319, query id 46504256929 10.36.125.38 vs_ipad几个字段:Trx id counter 0 3638031820 。 当前事务ID可用最大值 。下一个事物从这个ID 开始。一直增加。Purge done for trx‘s n:o < 0 3637930396 undo n:o < 0 0。事物ID小于此值的,已完成flush dirty data及清理undo。History list length 19988。在undo空间,没有purge的事物数。Total number of lock structs in row lock hash table 0。所有事物持有行锁的结构体个数。每个行锁结构体有多行数据。 25
    • TRANSACTIONS---TRANSACTION 0 80157600, ACTIVE 4 sec, process no 3396, OS thread id 1148250464, thread declared inside InnoDB442mysql tables in use 1, locked 0MySQL thread id 8079, query id 728899 localhost root Sending dataselect sql_calc_found_rows * from b limit 5Trx read view will not see trx with id >= 0 80157601, sees < 0 80157597---TRANSACTION 0 80157599, ACTIVE 5 sec, process no 3396, OS thread id 1150142816 fetching rows, thread declaredinside InnoDB 166几个字段:ACTIVE/not started 。 每个TRANSACTION都会是这2个状态中的一种。TRANSACTION能够是ACTIVE,即使这个连接是SLEEP状态(这个事物,会执行多个sql)。Sending data,fetching rows。发送data,获取数据。Insite InnoDB 442。线程正在innodb 内核 ,还有 442个tickets使用。Use 1,locked 0。有1个表,在被访问,0个lock.Innodb 线程三种状态:Running Inside Innodb,sleeping before joining InnoDB queue 和waiting in InnoDB queue.1. innodb_thread_sleep_delay ,在进入innodb queue,需要等待的时间。默认10,000us.2. innodb_thread_concurrency innodb_thread_concurrency。 26
    • TRANSACTIONSif (thread->n_tickets_to_enter_innodb > 0){ thread->n_tickets_to_enter_innodb--; 只要tickets不为0,都可以自由进出innodb内核。 ENTER;}retry:if (entered_thread < innodb_thread_concurrency){ entered_threads++; thread->n_tickets_to_enter_innodb = innodb_concurrency_tickets; ENTER;} if (innodb_thread_sleep_delay > 0){ innodb_thread_sleep_delay thread_sleep(innodb_thread_sleep_delay innodb_thread_sleep_delay);}goto retry; // (only once) (onlyWAIT_IN_FIFO_QUEUE; thread->n_tickets_to_enter_innodb = innodb_concurrency_tickets;ENTER;1. innodb_thread_sleep_delay check innodb_thread_sleep_delay。线程先check delay check是否可以进入内核,如果不可以,delay delay这么长时间,再check check check一次,如果还不能进入,则线程进入一个FIFO FIFO FIFO队列中。2. innodb_concurrency_tickets 默认为500. 500. 27
    • FILE I/O--------I/O thread 0 state: waiting for i/o request (insert buffer thread)I/O thread 1 state: waiting for i/o request (log thread)I/O thread 2 state: waiting for i/o request (read thread)I/O thread 3 state: waiting for i/o request (write thread)Pending normal aio reads: 256, aio writes: 0,ibuf aio reads: 0, log i/o’s: 0, sync i/o’s: 0Pending flushes (fsync) log: 0; buffer pool: 0112084404 OS file reads, 29836003 OS file writes, 2038246 OS fsyncs286.27 reads/s, 82658 avg bytes/read, 2.96 writes/s, 0.71 fsyncs/s几个字段:4个IO线程,其功能见之前分享。Pending normal aio reads, aio writes: 。 异步读、写 PAGE 的个数。Ibuf aio reads: insert buffer 。 异步读次数,log i/o’s 日志i/o,sync i/o 。Pending flushes (fsync) log: 0; buffer pool: 0 。 同步写log次数;写bp次数。112084404 OS file reads, 29836003 OS file writes, 2038246 OS fsyncs 。 OS 级别、读、写总次数。OS级别fsync次数。286.27 reads/s, 82658 avg bytes/read, 2.96 writes/s, 0.71 fsyncs/s 。过去这段时间的均值。1. 同步写,异步写。sync/fsync sync只是将所有修改过的块的缓存排入写队列,然后就返回, sync/fsync sync/fsync。它并不等待实际I / O操作结束。数fsync只引用单个文件,它等待I / O结束,然后返回。2. 哪些异步写,哪些同步写?3.这里区分 随机、顺序 io 了么? 28
    • INSERT BUFFER AND ADAPTIVE HASH INDEX-------------------------------------INSERT BUFFER AND ADAPTIVE HASH INDEX-------------------------------------Ibuf: size 1, free list len 12, seg size 14,483766 inserts, 483766 merged recs, 449532 mergesHash table size 50999537, node heap has 7589 buffer(s)16377.23 hash searches/s, 1572.67 non-hash searches/s几个字段:Ibuf: size 1, free list len 12, seg size 14。Insert buffer,已使用1,空闲length 12, 一共14.单位page.483766 inserts, 483766 merged recs, 449532 merges。 一共insert数,merge条数,merge次数。Hash table size 50999537, node heap has 7589 buffer(s)。16377.23 hash searches/s, 1572.67 non-hash searches/s。通过/没通过 hash找到的page。1. Adaptive hash,维护索引叶页面中所有记录的索引键值(或键值前缀)到索引叶页面位置的Hash映射关系,能够根据索引键值(前缀)快速定位到叶页面满足条件记录的Offset,减少了B+树Search Path的代价,将B+树从Root页面至Leaf页面的路径定位,优化为Hash Index的快速查询。2. Adaptive,意味着不是所有的叶页面都会以Hash索引维护,叶页面进入Hash索引的条件是:同种类型的操作(Scan/Insert…),命中同一叶页面的次数,超过此页面记录数量的1/16,则可将当前叶页面加入Hash索引,用以优化后续可能的相同Search Path?3.整个Adaptive Hash Index使用一个mutex保护。有什么问题? 29
    • LOG---LOG---Log sequence number 84 3000620880 当前LSN (LSN单位本身是b)Log flushed up to 84 3000611265 FLUSH LSN 。已刷到磁盘的LSN。Last checkpoint at 84 2939889199 LAST CHK 。Data和log都刷到磁盘的LSN。0 pending log writes, 0 pending chkp writes14073669 log i/os done, 10.90 log i/os/second1. Innodb的 checkpoint 分类。2. 为什么有checkpoint,可以不掉不。起什么作用。3. (3000620880 – 3000611265)/1024= 9Kb . 没刷到磁盘。 30% of log buffer size being unflushed youmay want to increase it4. innodb_flush_logs_at_trx_commit。 30
    • BUFFER POOL AND MEMORY---------------------BUFFER POOL AND MEMORY----------------------Total memory allocated 42376766570; in additional pool allocated 21381888Dictionary memory allocated 1394720Buffer pool size 2359296Free buffers 0Database pages 2346920Modified db pages 198995Pending reads 0Pending writes: LRU 0, flush list 0, single page 0Pages read 497948034, created 5732505, written 2670362718.88 reads/s, 0.02 creates/s, 4.75 writes/sBuffer pool hit rate 998 / 1000几个字段Total memory allocated 42376766570; 。当前mysqld进程 使用物理内存,单位字节。in additional pool allocated 21381888 。innodb_additional_mem_pool_size 大小,单位字节。Buffer pool size 2359296 。BP ,单位是page。Pages read 497948034, created 5732505, written 267036271。读、写、创建 总page。不断增加。8.88 reads/s, 0.02 creates/s, 4.75 writes/s。过去43秒,平均读、写、创建page个数。Buffer pool hit rate 998 / 1000。BP命中率。1. Innodb的 checkpoint 分类。2. 为什么有checkpoint,可以去掉不。起什么作用。 31
    • BUFFER POOL AND MEMORY1. 每个page占用 800字节内存,作为buffer header。42376766570怎么得出的? 32
    • ROW OPERATIONS--------------ROW OPERATIONS--------------0 queries inside InnoDB, 0 queries in queue1 read views open inside InnoDBMain thread process no. 10099, id 88021936, state: waiting for server activityNumber of rows inserted 143, updated 3000041, deleted 0, read 248655630.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s几个字段0 queries inside InnoDB, 0 queries in queue。Innodb内核query,队列中的query。1 read views open inside InnoDB。1个事物已经开始,但不是处于active状态。Buffer pool size 262144 。BP ,单位是page。Main thread process no. 10099, id 88021936, state: waiting for server activity。主线程在等server发请求。Number of rows inserted 143, updated 3000041, deleted 0, read 24865563。mysql启动之后,i/u/d/r 行数。0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s。过去43秒,i/u/d/r 行数。 33
    • 总结1.单行数据大,有什么问题?2.参数、软件&硬件平衡,最大化利用硬件资源。http://www.mysqlperformanceblog.com/2011/12/02/kernel_mutex-problem-or-double-throughput-with-single-variable/http://www.mysqlperformanceblog.com/2010/05/24/tuning-innodb-concurrency-tickets/ 34
    • 谢谢http://blog.csdn.net/longxibendi 35