我的应用程序是数据库密集型应用程序,所以我非常努力地确保应用程序和MySQL数据库尽可能高效地协同工作。
目前,我正在调优MySQL查询缓存,使其与服务器上运行的查询的特征保持一致。
query_cache_size
是可以存储在缓存中的最大数据量,query_cache_limit
是缓存中单个结果集的最大大小。
我当前的MySQL查询缓存配置如下:
query_cache_size=128M
query_cache_limit=1M
tuning-primer.sh
给了我以下关于正在运行的系统的调优提示:
QUERY CACHE
Query cache is enabled
Current query_cache_size = 128 M
Current query_cache_used = 127 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 99.95 %
Current query_cache_min_res_unit = 4 K
However, 21278 queries have been removed from the query cache due to lack of memory
Perhaps you should raise query_cache_size
MySQL won't cache query results that are larger than query_cache_limit in size
mysqltuner.pl
给出了以下调优提示:
[OK] Query cache efficiency: 31.3% (39K cached / 125K selects)
[!!] Query cache prunes per day: 2300654
Variables to adjust:
query_cache_size (> 128M)
两个调优脚本都建议我提高query_cache_size
。但是,根据mysqltuner.pl
(请参阅http://mysqltuner.pl/),将query_cache size
增加到128M以上可能会降低性能。
你将如何解决这个问题?你会无视mysqltuner.pl
的警告而增加query_cache_size,还是尝试以某种方式调整查询逻辑?大多数数据访问都是由Hibernate处理的,但在应用程序中也使用了相当多的手工编码的SQL。
发布于 2010-01-20 01:53:13
通常,“缓存太大”警告是在假设您的物理内存很少,缓存本身需要交换或将占用OS
所需的资源(如文件缓存)的情况下发出的。
如果您有足够的内存,增加query_cache size
是安全的(我见过使用1GB
查询缓存的安装)。
但是您确定您使用的查询缓存是正确的吗?是否有很多逐字重复的查询?你能给出一个典型查询的例子吗?
发布于 2011-11-28 07:24:54
mysqltuner.py发出的警告实际上是相关的,即使您的缓存没有被交换的风险。它在以下方面得到了很好的解释:http://blogs.oracle.com/dlutz/entry/mysql_query_cache_sizing
基本上,缓存越大,MySQL花在整理缓存上的时间就越多,而且即使在中等的写负载下(查询经常被清除),缓存也是非常不稳定的,所以将缓存放得太大会对应用程序性能产生不利影响。调整应用程序的query_cache_size
和query_cache_limit
,尝试找到每次插入命中率最高、lowmem_prunes
数量较少的临界点,同时密切关注数据库服务器的负载。
发布于 2013-03-28 00:32:38
你应该容易地增加你的缓存,这不仅仅是一个“没有那么多可用内存”的事情!
读一下实例the manual,你会得到这样的引用:
要小心,不要将查询缓存调整得过大,这会增加维护缓存所需的开销,可能会超出启用缓存的好处。以数十兆字节为单位的大小通常是有益的。数百兆字节的大小可能不是。
还有其他的sources你可以去看看!
如果修剪率不为零,则表示您应该增加查询缓存的大小。但是,请记住,维护缓存的开销可能会随着缓存大小的增加而增加,因此请以较小的增量执行此操作,并监视结果。如果您需要大幅增加高速缓存的大小以消除剪枝,则您的工作负载很可能与查询高速缓存不匹配。
因此,不要只在查询缓存中放入尽可能多内容!
最好的办法是逐渐增加查询缓存,并测量站点的性能。这在性能问题中是默认的,但在像这样的情况下,“测试”是你能做的最好的事情之一。
https://stackoverflow.com/questions/2095614
复制相似问题