私のアプリケーションはデータベースを大量に使用するため、アプリケーションと 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
。ただし、 をquery_cache size
128M 以上に増やすと、パフォーマンスが低下する可能性がありますmysqltuner.pl
(http://mysqltuner.pl/)。
この問題にはどのように対処しますか? の警告にもかかわらず query_cache_size を増やしますかmysqltuner.pl
、それとも何らかの方法でクエリ ロジックを調整しますか? データ アクセスのほとんどは Hibernate によって処理されますが、アプリケーションでは手動でコーディングされた SQL もかなり多く使用されます。
ベストアンサー1
mysqltuner.py によって発行される警告は、キャッシュがスワップされるリスクがない場合でも実際には関連があります。これは次のようにわかりやすく説明されています。http://blogs.oracle.com/dlutz/entry/mysql_query_cache_sizing
基本的に、キャッシュが大きいほど、MySQL はキャッシュのグルーミングに多くの時間を費やします。また、キャッシュは中程度の書き込み負荷でも非常に不安定であるため (クエリは頻繁にクリアされます)、キャッシュを大きくしすぎると、アプリケーションのパフォーマンスに悪影響を及ぼします。アプリケーションに合わせてquery_cache_size
と を微調整しquery_cache_limit
、挿入あたりのヒット数が最も多く、 の数が少ない限界点を見つけlowmem_prunes
、その間データベース サーバーの負荷にも注意を払ってください。