专注系统运维、网络架构,研究技术凯发app官方网站的解决方案,记录我的思想轨迹、工作学习、生活和关注的领域
分类: mysql/postgresql
2012-11-30 13:34:13
mysql 的优化方案,在互联网上可以查找到非常多资料,今天对mysql缓存碎片和命中率作了详细了解,个人作了简单整理。
一、mysql查询缓存碎片和缓存命中率。
mysql 查询缓存变量
变量名 | 说明 |
qcache_free_blocks | 缓存中相邻内存块的个数。数目大说明可能有碎片。flush query cache 会对缓存中的碎片进行整理,从而得到一个空闲块。 |
qcache_free_memory | 缓存中的空闲内存。 |
qcache_hits | 每次查询在缓存中命中时就增大。 |
qcache_inserts | 每次插入一个查询时就增大。命中次数除以插入次数就是不中比率;用 1 减去这个值就是命中率。在上面这个例子中,大约有 87% 的查询都在缓存中命中。 |
qcache_lowmem_prunes | 缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个数字在不断增长,就表示可能碎片非常严重,或者内存很少。(上面的 free_blocks 和 free_memory 可以告诉您属于哪种情况)。 |
qcache_not_cached | 不适合进行缓存的查询的数量,通常是由于这些查询不是 select 语句。 |
qcache_queries_in_cache | 当前缓存的查询(和响应)的数量。 |
qcache_total_blocks | 缓存中块的数量。 |
query_cache_min_res_unit 查询缓存分配的最小块的大小(字节)
query_alloc_block_size 为查询分析和执行过程中创建的对象分配的内存块大小
qcache_free_blocks 代表内存自由块的多少,反映了内存碎片的情况
==========================
1)当查询进行的时候,mysql把查询结果保存在qurey cache中,但如果要保存的结果比较大,超过query_cache_min_res_unit的值 ,这时候mysql将一边检索结果,一边进行保存结果,所以,有时候并不是把所有结果全部得到后再进行一次性保存,而是每次分配一块 query_cache_min_res_unit 大小的内存空间保存结果集,使用完后,接着再分配一个这样的块,如果还不不够,接着再分配一个块,依此类推,也就是说,有可能在一次查询中,mysql要 进行多次内存分配的操作。
2)内存碎片的产生。当一块分配的内存没有完全使用时,mysql会把这块内存trim掉,把没有使用的那部分归还以重 复利用。比如,第一次分配4kb,只用了3kb,剩1kb,第二次连续操作,分配4kb,用了2kb,剩2kb,这两次连续操作共剩下的 1kb 2kb=3kb,不足以做个一个内存单元分配, 这时候,内存碎片便产生了。
3)使用flush query cache,可以消除碎片
4)如果qcache_free_blocks值过大,可能是query_cache_min_res_unit值过大,应该调小些
5)query_cache_min_res_unit的估计值:(query_cache_size - qcache_free_memory) / qcache_queries_in_cache
检查查询缓存使用情况
检查是否从查询缓存中受益的最简单的办法就是检查缓存命中率
当服务器收到select 语句的时候,qcache_hits 和com_select 这两个变量会根据查询缓存
的情况进行递增
查询缓存命中率的计算公式是:qcache_hits/(qcache_hits com_select)。
mysql> show status like '%com_select%';
--------------- -------
| variable_name | value |
--------------- -------
| com_select | 1 |
--------------- -------
1 row in set (0.00 sec)
此时的查询缓存命中率:3/(3 1)=75%;由于个人的测试数据库,查询较少,更行更少,命中率颇高。
二、监控缓存命中率
通过nagios pnp4nagios来监控缓存命中率,并通过图表来展示。
1、监控脚本: check_mysql_qch.sh.sh
2、生成报表
pnp4nagios templates:check_mysql_qch.php
结果:
(监控状态)
(pnp4nagios图)