MySWL×SCSK

MySQL ClusterをはじめとするHAソリューションなど、
SCSKが最先端の技術力でソリューションを提供します

見積依頼 資料ダウンロードはこちら

TOPICS

[Amazon Aurora]クエリキャッシュ検証:高速となった理由の考察

!前回のブログ記事では、AWSのAurora MySQL(以下、Aurora)のクエリキャッシュが改善したという点の検証結果を紹介しました。結果としてAuroraとRDS for MySQLを比較すると、Auroraのクエリキャッシュがパフォーマンスに対して有効に機能しているという結果となりました。今回は、その要因について推察して行きたいと思います。

performance_schema設定について

MySQLでは、performanceschemaでより詳細なMySQL内部のパフォーマンス統計が取得可能です。今回のテストでは、以下のperformanceschemaのinstrumentsを有効化し、クエリキャッシュ関連のパフォーマンスメトリクスを取得しました。

  • 有効化したinsturments
    • wait/synch/%Query_cache%
    • stage/sql/checking privileges on cached query
    • stage/sql/checking query cache for query
    • stage/sql/invalidating query cache entries (table)
    • stage/sql/invalidating query cache entries (table list)
    • stage/sql/storing result in query cache
    • stage/sql/Waiting for query cache lock

Aurora版クエリキャッシュ改変の推察

performance_schemaやMySQLステータス変数の結果を分析したところ、「クエリキャッシュのロック競合」がAuroraは発生しておらず、「クエリキャッシュの断片化」が発生が少ないことがわかりました。

1. クエリキャッシュのロック競合について

MySQLのクエリキャッシュは、クエリキャッシュに対するいかなるアクセスでもクエリキャッシュ全体を対象にしたmutexロックが発生します。そこでロック競合の様子を詳しく知るために、以下2つのsysスキーマのテーブルのメトリクスを収集しました。

  • x$hostsummaryby_stages : SQLステートメント実行の要した時間を詳細に見るため
  • x$waitsbyhostbylatency : 待機イベントに関して詳細を見るため

RDS for MySQLのx$hostsummaryby_stagesを見ると、「Waiting for query cache lock」のイベントが発生していましたが、Auroraではこのイベントの発生が確認出来ませんでした。「Waiting for query cache lock」は、文字通りセッションのクエリキャッシュロック取得待ちイベントを示します。つまりAuroraではSQLステートメント実行で、クエリキャッシュロック待ちが発生しなかった事がわかります。

上述の点から、待機イベントに関する統計テーブルでもクエリキャッシュロックについて同じ傾向を示すはずです。x$waitsbyhostbylatencyのテーブルでは、クエリキャッシュ全体を対象としたmutexロックを示す「Query cache structure guard mutex 」と、アクセス対象のテーブルが更新中に取得されるRWロックを示す「Query cache query lock 」が記録されるように設定されています。

そして実際に確認するとやはり、RDS for MySQLでは上述の2つの待機イベントで待機時間が発生していましたが、Auroraでは発生していませんでした。

sysスキーマ クエリキャッシュ関連 total_latency
Aurora MySQL RDS for MySQL
Query Cache Size 1.5GB 1GB 500MB 250MB 1.5GB 1GB 500MB 250MB
Waiting for query cache lock(sec) 0 0 0 0 41,414 41,820 42,165 41,584
Query_cache_query::lock(ms) 0 0 0 0 1,989 2,101 2,400 3,556
Query_cache::structure_guard_mutex(ms) 0 0 0 0 174,094 158,382 168,506 208,317

この結果から今回のワークロードでは、Auroraはクエリキャッシュのロック競合が発生しておらず、従来のMySQLに比べてクエリキャッシュのロック競合によるオーバーヘッドの削減に成功していることがわかりました。

2. クエリキャッシュの断片化について

次にクエリキャッシュの断片化について注目して見ていきます。

MySQLのクエリキャッシュの断片化は、クエリキャッシュが結果をキャッシュする仕組み上、発生してしまいます。キャッシュを格納するブロックについて、MySQLはオンデマンドでシステム変数querycacheminresunitに指定された値の最小サイズで割り当てを行います。クエリキャッシュのエントリは可変長であるため、必然的に断片化が発生します。

このクエリキャッシュの断片化については、MySQLのステータス変数としてQcachefreeblocksに注目します。このステータス変数で、クエリキャッシュ内の空きメモリブロック数が取得出来ます。よって、この値が大きければ大きいほど断片化が多く発生しており、MySQLに与えたquerycachesizeのメモリ領域が有効に利用されていないことになります。

前置きが長くなりましたが、以下のグラフを見るとAuroraがクエリキャッシュを有効利用していることが一目瞭然となりました。Auroraは最大でもQcachefreeblocksが約200blockとなったのに対して、RDS for MySQLは約11万blockとなっています。sysbenchから発行されているクエリにはランダム性がある事を差し置いても、この違いによってAuroraはクエリキャッシュの断片化が少なくなるよう改善されていると言えるでしょう。

Aurora MySQLとRDS for MySQL クエリキャッシュ断片化 ( Qcache_free_blocks )

06_結果クエリキャッシュ断片化.png

Aurora MySQLとRDS for MySQL クエリキャッシュ断片化 時系列 ( Qcache_free_blocks )

07_結果クエリキャッシュ断片化時系列.png

まとめ

二回の記事に分けてAWSのAurora MySQLのクエリキャッシュについて、RDS for MySQLと比較して検証を紹介しました。結果として、AuroraのクエリキャッシュがMySQLに比べて挙動が違うことがわかりました。そして、Auroraのクエリキャッシュサイズに比例してパフォーマンスの向上が確認できました。

その要因について、クエリキャッシュのロック競合と断片化について注目しました。RDS for MySQLと比較して見ると、Auroraはクエリキャッシュのロック競合無いことでオーバーヘッドを削減しています。またクエリキャッシュの断片化という点でも、Auroraは断片化が発生しているブロック数が少なく、クエリキャッシュ領域を有効に利用していると考えられます。

なお、検証実施2017年10月時点での最新版Auroraでの結果となります。またクエリキャッシュは、ワークロードの傾向などによって効果が大きく異るため、実環境での設定は十分に検証を実施した上で行ってください。

以上となります。ここまで読んで頂きありがとうございました。

SCSKだから選ばれる

10年以上にわたるMySQLの取り組み

10年以上にわたるMySQLの取り組み

MySQLオフィシャルトレーニングを多数担当。日本オラクル社のパートナー認定制度「MySQL Specialization」国内第1号取得。オリジナル全文検索ソリューション開発

SCSKの強み

SCSKの強み

オフィシャルトレーニング資格を有する技術者が提供する高い技術力。大規模通信系システム、大規模基幹系システムなども経験。国内企業数百社に対する導入実績。MySQLに関連する全てのサービスをワンストップで提供

お問い合わせ

MySQLやMySQL関連ソリューションに関するお問い合わせ、資料請求、お見積、ご相談などございましたら、こちらよりご連絡下さいませ。

お問い合わせ資料ダウンロード見積依頼

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。