Percona监控MySQL模板详解

InnoDB Adaptive Hash Index

显示了“自适应哈希索引”的使用情况,哈希索引只能用来搜索等值的查询.

# Hash table size 17700827, node heap has 35112 buffer(s)
# 3577.42 hash searches/s, 507.49 non-hash searches/s

• Hash Index Cells Total 自适应哈希表的槽数=innodb_buffer_pool_size/256
• Hash Index Cells Used 用到自适应哈希表的查询个数

InnoDB Buffer Pool Activity

显示Innodb缓冲池的内部活动,页的创建,读取,写入.如果有突然的增加或者减少,需要检查应用

• Pages Created
• Pages Read
• Pages Written

InnoDB Buffer Pool

• Pool Size InnoDB缓冲池的页数量,每页大小16K
• Database Pages 数据页大小
• Free Pages 空闲页大小
• Modified Pages "脏"数据页.如果脏数据页太多,则需要检查磁盘IO状态.

InnoDB Checkpoint Age

• Uncheckpointed Bytes
  显示了未写入磁盘的数据量.如果该值的大小接近innodb_log_file_size * n 的总大小,则需要增加innodb_log_file_size的值,但是要注意,如果发生宕机,则需要更长的回复时间.(从redolog恢复)

InnoDB Current Lock Waits

• InnoDB Lock Wait Secs
  显示每秒处于锁等待的innodb事务总数.如果有一个非常大的值,应该检查LOCK WAIT transactions,请看下面的模板

InnoDB I/O

• File Reads 显示每秒文件的读次数
• File Writes 显示每秒文件的写次数
• Log Writes 写日志的次数
• File Fsyncs 调用fsync()函数的次数.与innodb_flush_log_at_trx_commit值的设置有关.

InnoDB I/O Pending

显示了InnoDB挂起的同步或异步IO操作.如果挂起的操作太多,则需要更大的RAM,更大的缓冲池,更快的磁盘.

• Pending Aio Log Ios
• Pending Aio Sync Ios
• Pending Buf Pool Flushes
• Pending Chkp Writes
• Pending Ibuf Aio Reads
• Pending Log Flushe
• Pending Log Writes
• Pending Normal Aio Reads
• Pending Normal Aio Writes

InnoDB Insert Buffer

插入缓冲,并不是缓存的一部分,而是物理页,对于非聚集索引的插入或更新操作,不是每一次直接插入索引页.而是先判断插入的非聚集索引页是否在缓冲池中.如果在,则直接插入,如果不再,则先放入一个插入缓冲区中.然后再以一定的频率执行插入缓冲和非聚集索引页子节点的合并操作.
使用条件:非聚集索引,非唯一

• Ibuf Inserts
  插入的记录数
• Ibuf Merged
  合并的页的数量
• Ibuf Merges
  合并的次数
  如果merges/merged的值等于3/1,则代表插入缓冲对于非聚集索引页的IO请求大约降低了3倍

InnoDB Insert Buffer Usage

• Ibuf Cell Count
  分段大小
• Ibuf Used Cells
  插入缓冲区的大小
• Ibuf Free Cells
  "自由列表"的长度

InnoDB Internal Hash Memory Usage

显示了InnoDB内部各种哈希结构(不可人工干预),占用的内存大小.

• Adaptive Hash Memory
  自适应哈希索引占用的内存大小
• Page Hash Memory
• Dictionary Cache Memory
• File System Memory
• Lock System Memory
• Recovery System Memory
• Thread Hash Memory

InnoDB Lock Structures

• InnoDB Lock Structs
  该图形显示了在innodb内部有多少锁结构(不是死锁).这大致与当前事务锁住的行数有关系.可以用来判断是否存在锁争用.
  对于数量多少算好或者算坏,没有硬性的规定.实际情况下,大量的事务在等待锁,很明显,该值越小越好.

这个数据来源是SHOW ENGINE INNODB STATUS;
# 23 lock struct(s), heap size 3024, undo log entries 27
# LOCK WAIT 12 lock struct(s), heap size 3024, undo log entries 5
# LOCK WAIT 2 lock struct(s), heap size 368

InnoDB Log

相关变量:innodb_log_buffer_size

• InnoDB Log Buffer Size
• Log Bytes Written
  Log sequence number
  当前日志的位置
• Log Bytes Flushed
  Log flushed up to
  日志已经刷新的位置
• Unflushed Log
  是log_bytes_written与log_bytes_flushed的差值,表示日志缓存区里还有多少数据没被刷新到日志文件里.
  如果这个差值超过了innodb_log_buffer_size设置的30%,则需要考虑是否加大该参数值.

InnoDB Memory Allocation

Total memory allocated 8824815616; in additional pool allocated 0

• Total Mem Alloc
  InnoDB申请的总内存量,单位字节
• Additional Pool Alloc
  分配给额外内存的总量,单位字节

InnoDB Row Lock Time

• InnoDB Row Lock Time
  该模板读取的Innodb_row_lock_time状态变量,表示InnoDB引擎在每次申请数据行锁定时等待的总时间(以毫秒为单位).

InnoDB Row Lock Waits

• InnoDB Row Lock Waits
  读取的Innodb_row_lock_waits状态变量,表示InnoDB经过这么长时间才获得一个行锁.(毫秒)

InnoDB Row Operations

Number of rows inserted 50678311, updated 66425915, deleted 20605903, read 454561562

大致能表现InnoDB内部的操作

• Row Read
• Row Deleted
• Row Updated
• Row Inserted

InnoDB Semaphores Wait Time

• InnoDB Sem Wait Time Ms
  显示当前正在等待互斥量的InnoDB线程的等待时间的总耗时(毫秒).
  分析:
  正常情况下,InnoDB Semaphores Wait Time和 InnoDB Semaphores Waits应该是空的.除非服务器运行着高并发的工作负载,它促使InnoDB采取让操作系统等待的措施.信息位于SHOW ENGINE INNODB STATUS的SEMAPHORES片段.
  相关php脚本代码部分如下:

elseif (strpos($line, 'seconds the semaphore:') > 0) {
# --Thread 907205 has waited at handler/ha_innodb.cc line 7156 for 1.00 seconds the semaphore:
increment($results, 'innodb_sem_waits', 1);
increment($results, 'innodb_sem_wait_time_ms', to_int($row[9]) * 1000);
}

其中innodb_sem_waits的值是多少,表示有多少线程在等待,而innodb_sem_wait_time_ms表示所有线程等待的时间,默认单位是秒,在脚本中乘以1000,所以监控图中的单位是毫秒.

• 应对这个问题
  InnoDB采取多阶段等待策略.首先,尝试对锁进行循环等待.如果经过了一个预设的循环等待周期(innodb_sync_spin_loops = 30,当前配置文件默认为30次)之后还没有成功,就会退到更昂贵更复杂的等待阵列里,如果并发量太大的话,则导致系统负载突增.
  循环等待的成本相对比较低,但是需要不停地检查一个资源是否被锁定,消耗CPU周期,也就是说,当另外一条线程能处理事情时,循环等待也会独占处理器.
  循环等待的替换方案就是让操作系统做上下文切换(等待阵列),每秒钟几千次的切换会引发大量的系统开销.
• 解决办法
  根据具体的应用,调整参数;或者优化应用,减少并发.

InnoDB Semaphores Waits

• InnoDB Sem Waits
  显示当前正在等待互斥量的InnoDB线程的数量.

• InnoDB Semaphores
  显示innodb内部的信号活动状态.
  包括Mutex spin waits,RW-shared spins,RW-excl spins等各种信号量的数量总和.

• Spin Rounds
  InnoDB内部预设的互斥量信号数量

• Spin Waits
  InnoDB内部对锁进行循环等待的数量(与innodb_sync_spin_loops参数有关)

• Os Wait系统等待
  事务退到操作系统的等待阵列的数量
  在高并发的情况,会发现这个值有尖峰状,不稳定.图像主要显示了,不合理的设计情况下,不同的连接类型之间的行锁或互斥锁的争用.

InnoDB Tables In Use

# mysql tables in use 2, locked 2

• InnoDB Tables In Use
  所有事务用到的表的数量
• InnoDB Locked Tables
  所有事务锁定的表的数量

InnoDB Transactions Active/Locked

该图显示了InnoDB事务的状态数量.

• Active Transactions
  正在执行的事务数量
• Locked Transactions
  锁住的事务数量
• Current Transactions
  当前的事务数量(包括not started,ACTIVE,...等各种状态)
  not started # 事务已经提交到磁盘
  ACTIVE # 正在执行的事务
• Read Views(待更新)
  read views open inside InnoDB

InnoDB Transactions

显示了InnoDB事务相关的信息

• InnoDB Transactions
  InnoDB内部的事务总数.由以下数值计算出:
  Trx id counter 89F56195 # 当前事务ID,每创建一个新事务就会累加

Purge done for trx's n:o < 89F5609C undo n:o < 0 -- InnoDB清除旧版本MVCC时所用的事务ID.这个ID之前的老版本数据已经清除.

该数值就是由当前事务ID减去清除旧数据的事务ID再由十六进制转成十进制的值.(参考ss_get_mysql_stats.php脚本902行)

• History List
  历史记录的长度.位于InnoDB数据文件的撤销空间里的未清除事务的数目.当一个事务执行了更新并提交后,这个数字就会累加,当清除进程移除一个旧版本数据时,它就会递减.

MyISAM Indexs

显示了在MyISAM索引上的读写情况

• Key Reads Requests
  从键缓存读出索引块的读操作的次数
• Key Reads
  从磁盘读出索引块的读操作次数
• Key Write Requests
  向键缓存写一个索引块的请求的个数
• Key Writes
  把索引块写入磁盘的写操作的次数

MyISAM Key Cache

• Key Buffer Size
  键缓存大小
• Key Buf Bytes Used
  同Key_blocks_used变量
  键缓存里已经被使用的缓存块的个数
• Key Buf Bytes Unused
  同Key_blocks_unused
  键缓存里尚未被使用过的缓存块的个数

MySQL Binary/Relay Logs

• Binlog Cache Use
  保存在二进制日志缓存里的事务的个数
• Binlog Cache Disk Use
  超过binlog_cache_size设置的缓存大小,使用磁盘临时文件的事务的个数
• Binlog Log Space
  二进制日志的大小
• Relay Log Space
  中继日志的大小
  如果Binlog Cache Disk Use/Binlog Cache Use的值较大,那么应该尝试增加binlog_cache_size的大小.但是,也不要期望改善过多,如果写临时文件的数量从每秒1个减少到每分钟一个,这已经证明优化的足够好了.没必要耗费大量的内存,来处理binlog_cache_size中的事务.

MySQL Command Counts

命令计数器,显示了MySQL(在过去1秒内)执行各种命令的次数

• Questions
  记录了服务器收到的查询和命令的总数.(Com_*变量的总数不一定相等.)
• Com Select
• Com Delete
• Com Insert
• Com Update
• Com Replace
• Com Load
• Com Delete Multi
• Com Insert Select
• Com Update Multi
• Com Replace Select

MySQL Connections

• Max Connections 允许同时保持在打开状态的客户连接的最大个数
• Max Used Connections 此前曾同时打开处于打开状态的连接的最大个数
• Aborted Clients 因客户端没有正确地关闭而被丢弃的连接的个数
• Aborted Connects 试图连接MySQL服务器但没有成功的次数
• Threads Connectd 现在正处于打开状态的连接的个数
• Connections 试图连接MySQL服务器的尝试次数

MySQL Files and Tables

• Table Cache
• Open Tables 当前处于打开状态的数据表的个数.不包括TEMPORARY
• Open Files 当前处于打开状态的文件的个数,如果与open_files_limit接近,则应该加大open_files_limit的值.
• Opened Tables
  MySQL服务器已打开的数据表总数(包括显式定义的临时表).如果这个值很高,应该慎重考虑,是否加大数据表缓存(table_open_cache).

MySQL Handler

• Handler_writer 向数据表里插入一个数据行的请求的个数
• Handler_update 对数据表里的一个数据行进行修改的请求的个数
• Handler_delete 从数据表删除一个数据行的请求的个数
• Handler_read_first 读取索引中第一个索引项的请求的个数
• Handler_read_key 根据一个索引值而读取一个数据行的请求的个数
• Handler_read_next 按索引顺序读取下一个数据行的请求的个数
• Handler_read_prev 按索引逆序读取前一个数据行的请求的个数
• Handler_read_rnd 根据某个数据行的位置而读取该数据行的请求的个数
• Handler_read_rnd_next 读取下一个数据行的请求的个数.如果这个数字很高,就说明有很多语句需要通过全表扫描才能完成或有很多查询没有使用适当的索引

MySQL Network Traffic

• Bytes Send 发送字节数
• Bytes Received 收到字节数

MySQL Processlist

http://dev.mysql.com/doc/refman/5.5/en/general-thread-states.html

• State Closing Tables
  该线程将已更改的表数据刷新到磁盘，并关闭已使用的表。这应该是一个快速的操作。如果没有，请确认您没有一个完整的磁盘，并且磁盘没有非常重的使用。

• State Copying To Tmp Table
  服务器正在复制到内存中的临时表

• State End
  这发生创建视图、删除、插入、查询或更新语句之最后，但是在修改ALTER TABLE之前

• State Freeing Items
  线程执行了一个命令。在此状态下完成的一些项目将涉及查询缓存。这个状态通常会被清理干净

• State Init
  这发生在ALTER TABLE、DELETE、INSERT、SELECT或UPDATE语句的初始化之前。在这个状态下，服务器所采取的操作包括刷新二进制日志、InnoDB日志和一些查询缓存清理操作。
  对于最终状态，以下操作可能会发生:
  删除表中的数据之后删除查询缓存条目
  将事件写入二进制日志
  释放内存缓冲区，包括blob

• State Locked
  查询被另一个查询锁定。
  在MySQL 5.5.3中，这个状态被删除了，因为它相当于表锁状态，不再出现在SHOW PROCESSLIST输出中。

• State Login
  登录
  连接线程的初始状态，直到客户机成功地进行了身份验证。

• State Preparing
  这个状态发生在查询优化期间。

• State Reading From Net
  服务器正在从网络读取一个数据包。

• State Sengding Data
  线程正在读取和处理SELECT语句的行，并将数据发送给客户机。因为在这个状态期间发生的操作往往会执行大量的磁盘访问(读)，所以在给定查询的生命周期中，它通常是运行时间最长的状态。

• State Sorting Result
  对于SELECT语句，这类似于创建排序索引，但对于非临时表

• State Statistics
  服务器正在计算统计数据，以开发查询执行计划。如果一个线程在这个状态中存在很长时间，那么服务器可能会执行其他的工作。

• State Updating
  线程正在寻找更新的行，并正在更新它们

• State Writing To Net
  服务器正在向网络写入一个包。

• State None
  什么都没有的,空的,注意不是NULL状态

• State Other
  其他

MySQL Query Cache

MySQL Query Cache Memory

MySQL Query Response Time (Microseconds)

Percona文档

MySQL Query Time Histogram(Count)

Percona文档

MySQL Replication

默认用SHOW SLAVE STATUS命令获取各状态值

• Slave Running 从服务器的I/O线程和SQL线程是否在运行
• Slave Stopped
• Slave Lag 复制延迟
• Slave Open Tmp Tables 从服务器中的SQL线程曾经打开的临时文件的个数
• Slave Retried Transactions 从服务器中的SQL线程重新尝试执行一个事务的次数

MySQL Select Types

• Select Full Join没有使用索引而完成的多表联接操作的次数.这种情况是性能杀手,最好去优化sql.
• Select Full Range Join利用一个辅助性的参照表(reference table)上的区间搜索(range search)操作而完成的多数据表联接操作的次数.
  该值表示使用了范围查询联接表的次数.
• Select Range利用第一个数据表上的某个区间而完成的多数据表联接操作的次数.
• Select Range Check该变量记录了在联接时,对每一行数据重新检查索引的查询计划的数量,它的开销很大.
  如果该值较高或正在增加,说明一些查询没有找到好索引.
• Select Scan通过对第一个数据表进行全表扫描而完成的多数据表联接操作的次数.

MySQL Sorts

• Sort Rows 对多少行排序
• Sort Range 利用一个区间进行的排序操作的次数
• Sort Merge Passes 查询导致了文件排序的次数.可以优化sql或者适当增加sort_buffer_size变量
• Sort Scan 利用一次全表扫作而完成的排序操作的次数

MySQL Table Locks

• Table Locks Immediate
  无需等待就能够立刻得到满足的数据表锁定请求的个数
• Table Locks Waited
  显示了有多少表被锁住了并且导致服务器级的锁等待(存储引擎级的锁,如InnoDB行级锁,不会使该变量增加).
  如果这个值比较高或者正在增加,那么表明存在严重的并发瓶颈.
• Slow Queries 慢查询的次数(执行时间超过long_query_time值)

MySQL Temporary Objects

• Created_tmp_tables
  MySQL服务器在对SQL查询语句进行处理时在内存里创建的临时数据表的个数.
  如果该值太高,唯一的解决办法是:优化查询语句.
• Created_tmp_disk_tables
  MySQL服务器在对SQL查询语句进行处理时在磁盘上创建的临时数据表的个数,如果这个值比较高,可能的原因:
  a.查询在选择BLOB或者TEXT列的时候创建了临时表
  b.tmp_table_size和max_heap_table_size的值也许太小
• Created_tmp_files MySQL服务器所创建的临时文件的个数

MySQL Threads

• Thread Cache Size
  线程缓存所能容纳的线程的最大个数.断开的mysql连接会放到这个缓存里,新建立的连接就会重复使用它们而不创建新的线程.
  如果缓存中有自由的线程,MySQL就能很快的响应连接请求,不必为每个连接都创建新的线程.每个在缓存中的线程通常消耗256KB内存.
• Thread Created 为处理连接创建的线程总数

MySQL Transaction Handler

• Handler Commit 提交一个事务的请求的个数
• Handler Rollback 回滚一个事务的请求的个数
• Handler Savepoint 创建一个事务保存点的请求的个数
• Handler Savepoint Rollback 回滚到一个事务保存点的请求的个数.