出典について
この記事はThe Percona Data Performance Blog内のAlexey Stroganov氏、Laurynas Biveinis氏、Vadim Tkachenko氏によるPercona Server 5.7 performance improvements(2016/3/17)を翻訳したものです。
このブログ投稿は、Percona Server 5.7のパフォーマンスの改善についての記事です。
Percona Server 5.6のリリースから、同時並行度が高いI/Oバウンドの負荷に対するパフォーマンスの問題への対処に役立ついくつかの大きな変更をしてきました。我々の調査および改良はMySQL 5.7に再実装されており、これはMySQLのリリースの中で最高傑作の1つです。MySQL 5.7はスケーラビリティーおよびパフォーマンスの様々な面で進化しているものの、I/Oバウンドの負荷に対する制約をさらに大きなものにする可能性があると思います。
Percona Server 5.7.11では、現在時点でこの領域に対して主に2つの性能上の特徴があります。
- LRUフラッシュのマルチスレッド化。この機能はPercona Server 5.6にも限定的に取り込まれています。我々はLRUをフラッシュするスレッドを既存のページクリーナースレッドから分離し、現在は単にフラッシュリストをフラッシュするだけのものとなりました。他の重要な変更と合わさり、これによりI/Oバウンドの負荷に対するパフォーマンスが劇的に改善しました。MySQL 5.7もページクリーナースレッドのプールを導入し性能が改善され、これによってフラッシュの並列化も改善しています。しかしながら、我々は現在のアプローチは十分ではないと考えています。とりわけLRUのフラッシュに関してです。我々の次のPercona Server 5.7のパフォーマンス改善に関する投稿のいずれかの中で、マルチスレッドのフラッシュ、それからマルチスレッド化されたLRUを独立にフラッシュさせるのがなぜ特に重要となるのか、について述べる予定です。
- パラレルダブルライトバッファー。長年にわたり、MySQLはデータページをフラッシュするのに1つしかダブルライトバッファーを持っていませんでした。従って、仮にフラッシュ用に幾つかのスレッドがあったとしてもこれを効率的に利用することができませんでした。ダブルライトバッファーがすぐにボトルネックとなるためです。我々はそれぞれのバッファプールインスタンスに対し2つのダブルライトバッファーを割り当てることでこれを変更しました。それぞれのタイプのページフラッシュ(LRUおよびフラッシュリスト)に対して1つです。これによってフラッシュ用のスレッド数に関わらず、ダブルライトバッファーの競合を完全に回避します。我々はまた、ダブルバッファーをパスを設定できるようにシステム表領域の外に移動しました。
sysbenchのOLTP_RW、I/Oバウンドのシナリオの結果を見てみましょう。下記が我々がテストに利用した設定です。
- データセット100GB
- innodb_buffer_pool_size=25GB
- innodb_doublewrite=1
- innodb_flush_log_at_trx_commit=1
MySQL 5.7 RCを評価していた時はI/Oバウンドの負荷でパフォーマンスの低下が観測され、これはMySQL 5.6ととてもよく似た挙動にみえました。このパフォーマンス低下の原因はバッファープール内のフリーページ不足です。ページクリーナースレッドがLRUのフラッシュを必要とされるレベルに対し十分に実施できず、クエリースレッドが単一ページのフラッシュをしようとするためです。これにより全てのフラッシュ関連の構造体(特にダブルライトバッファー)がより競合する結果となります。
長年にわたり(Vadim氏は10年前に議論していました)、InnoDBはほとんどのスケーラビリティーの問題に対して共通のワークアラウンドを行っていました。innodb_thread_concurrencyシステム変数です。この変数はInnoDBにおけるアクティブなスレッド数を制限するもので、これにより共通リソースの競合が軽減されます。しかしながら、潜在的なパフォーマンスの最大値もまた制限されてしまうトレードオフがありました。
この影響を理解するために、InnoDBの同時実行の異なる2つの設定で2度テストを実行しました。
- innodb_thread_concurrency=0: このデフォルト値でPercona Server 5.7では最善の結果がみられました。一方、MySQL 5.7ではクライアントが64並列以上になった際に急激なパフォーマンス低下がみられます。
- innodb_thread_concurrency=64: InnoDB内部のスレッド数を制限することで、Percona Serverについてはスループットがわずかに変化します(デフォルトの設定から少し低くなります)が、MySQLの場合はこれにより大きく改善します。64スレッド以上になった際にパフォーマンスは低下せず、このパフォーマンスレベルは4000スレッドまで維持可能です(多少は前後します)。
詳細についての理解を深めるために、512スレッドの場合のテスト結果を拡大してみましょう。
上記のグラフから、競合が発生すると同時並行度に制限がない場合のスループットに大きな影響があり、レイテンシーに対してはさらに悪い影響があることが分かります。同時並行度を制限すれば競合発生が抑えられますが、この条件においてもPercona Serverの方が15% - 20%よい性能となります。
下記に上記のそれぞれの計測に対する競合の状況を示します。 グラフは同期オブジェクトごとの(単位秒あたりの)全スレッドの待機時間の累積値を示しています。例えば、MySQL 5.7.11(同時並行スレッド数の制限なしの場合)ダブルライトのミューテックスはすべてのグラフで常に一番大きく目立ったものです。クライアントのスレッドが512並列の場合、単位時間あたり約17秒の待機時間が発生します。
mysqlサーバーの設定
innodb_log_file_size=10G
innodb_doublewrite=1
innodb_flush_log_at_trx_commit=1
innodb_buffer_pool_instances=8
innodb_change_buffering=none
innodb_adaptive_hash_index=OFF
innodb_flush_method=O_DIRECT
innodb_flush_neighbors=0
innodb_read_io_threads=8
innodb_write_io_threads=8
innodb_lru_scan_depth=8192
innodb_io_capacity=15000
innodb_io_capacity_max=25000
loose-innodb-page-cleaners=4
table_open_cache_instances=64
table_open_cache=5000
loose-innodb-log_checksum-algorithm=crc32
loose-innodb-checksum-algorithm=strict_crc32
max_connections=50000
skip_name_resolve=ON
loose-performance_schema=ON
loose-performance-schema-instrument='wait/synch/%=ON',
結論
すでに5.7をお試しであれば、とりわけご利用環境がI/Oバウンドの負荷の場合、Percona Serverを使ってみることをご検討ください。我々はPercona Server 5.7のパフォーマンス改善に懸命に取り組んできました。 次の投稿で、我々はLRUフラッシュとダブルライトバッファーに関する変更について技術的に掘り下げる予定です。
