MySQLに複数のコアを使用させることは可能ですか？

Question

シングルコア以上を使用しない専用のMySQLサーバーがいくつか提示されました。私はMySQLのDBAよりも開発者なので、助けが必要です

セットアップ

サーバーはOLAP/DataWarehouse（DW）タイプの負荷でかなり高負荷です。

プライマリ：96GB RAM、8コア+シングルRAID 10アレイ
テスト：32GB RAM 4コア
最大のDBは540 GBで、合計は約1.1 TBで、ほとんどがInnoDBテーブルです。
Solaris 10 Intel-64
MySQL 5.5.x

注：最大のDBは、OLTP DRサーバーから複製されたDBであり、DWはこれからロードされます。完全なDWではありません。最後の6か月から6週間だけなので、より小さくなります。 OLTP DB。

テストサーバーでの観察

3つの別々の接続
それぞれに同時（および異なる）ALTER TABLE...DROP KEY...ADD INDEX
3つのテーブルには、250万、380万、450万の行があります。
CPU使用率が最大25％（1つのコアが最大になる）になり、それ以上にならない
3つのALTERには12〜25分かかります（最小のシングルに4.5かかります）

ご質問

複数のコアを使用できるようにするには、どの設定またはパッチが必要ですか？
つまり、MySQLが利用可能なすべてのコアを使用しないのはなぜですか？（他のRDBMSと同様）
レプリケーションの結果ですか？

その他の注意事項

RDBMSの「スレッド」とOSの「スレッド」の違いを理解しています
どんな形の並列処理についても質問していません
InnoDBおよびスレッドのシステム変数の一部は最適ではない
（迅速な勝利を求めて）
短期的には、ディスクレイアウトを変更できません
OSは必要に応じて調整できます
最小のテーブルでの単一のALTER TABLEには4.5分かかります（衝撃的なIMO）

編集1

innodb_thread_concurrencyは両方で8に設定されています。はい、それは間違っていますが、MySQLが複数のコアを使用することはありません
innodb_buffer_pool_sizeはプライマリで80 GB、テストで10 GBです（別のインスタンスはシャットダウンされます）。これは今のところ大丈夫です。
innodb_file_per_table = ON

編集2

innodb_flush_log_at_trx_commit = 2
innodb_use_sys_malloc = ON
innodb_flush_methodはO_DIRECTでなければなりません（ただし、SHOW VARIABLESはこれを表示しません）
innodb_doublewrite = OFF
ファイルシステム= ZFS（そして私のシステム管理者はこれを見つけました： http://blogs.Oracle.com/realneel/entry/mysql_innodb_zfs_best_practices ）

テストする

innodb_flush_methodがO_DIRECTとして表示されない
rolandoMySQLDBAの設定に従います

重要な情報を逃した場合はお知らせください

乾杯

更新

RolandoMySQLDBAの回答のinnodb_flush_method + 3 xスレッド設定を変更
結果：>テストに使用された1コア=肯定的な結果

RolandoMySQLDBA · Accepted Answer

2011年5月に開催されたPercona Live NYCカンファレンスで実際にinnodb_thread_concurrencyをMySQLエキスパートと話し合った。

私は驚くべきことを学びました：ドキュメントにもかかわらず、それを残すことをお勧めします innodb_thread_concurrency 0（無限の同時実行）。このようにして、InnoDBが最適な数を決定します innodb_concurrency_tickets 指定されたMySQLインスタンスのセットアップで開く。

設定したらinnodb_thread_concurrencyは0に設定できます innodb_read_io_threads および innodb_write_io_threads （両方ともMySQL 5.1.38以降）最大値64に設定します。これにより、より多くのコアが使用されるようになります。

Derek Downey · Answer

MySQLは自動的に複数のコアを使用するため、25％の負荷は偶然です。¹ またはSolarisでの潜在的な設定ミス。私はソラリスをチューニングする方法を知るふりはしませんが、これはいくつかのソラリス固有のチューニング情報について説明する記事です。

InnoDBチューニングページはMySQL 5.5でオーバーホールされたので、そこにもいくつかの良い情報があります。 InnoDBディスクIOヒントから：

UnixのトップツールまたはWindowsのタスクマネージャーで、ワークロードのCPU使用率が70％未満であることが示された場合、ワークロードはおそらくディスクにバインドされています。トランザクションコミットが多すぎるか、バッファプールが小さすぎる可能性があります。バッファプールを大きくすると効果的ですが、物理メモリの80％以上に設定しないでください。

その他の確認事項：

innodb_flush_method をO_DIRECTに切り替えることは、テストする価値があります。これが役立つ場合は、forcedirectioオプションを使用してファイルシステムをマウントする必要があるかもしれません
innodb_flush_log_at_trx_commit を1から0（mysqlクラッシュで最後の1秒を失うことを気にしない場合）または2（OSクラッシュで最後の1秒を失うことを気にしない場合）に変更します。
innodb_use_sys_malloc の値を確認します。この記事には、変数について詳細情報が記載されています。

当時、マルチコアCPU用に調整されたメモリアロケーターライブラリはありませんでした。したがって、InnoDBはmemサブシステムに独自のメモリアロケーターを実装しました。このアロケータは、ボトルネックになる可能性がある単一のミューテックスによって保護されています。

ただし、セクションの最後に、変数をオンにすることの意味についていくつかの警告があります（5.5ではデフォルトでオンになっています）。

InnoDBメモリアロケーターが無効になっている場合、InnoDBはパラメーターinnodb_additional_mem_pool_sizeの値を無視することに注意してください。
レプリケーションが問題の原因となっている可能性があります。私はあなたが並列処理に興味がないことを理解していますが、この作業ログの説明から：

現在、レプリケーションはマルチコアマシンで適切に拡張できません。単一のスレーブスレッドはレプリケーションイベントを1つずつ実行し、個別のマスターサーバーのCPUが提供する複数の同時クライアント接続によって生成される負荷に対処できない場合があります。

最終的に、ディスクベースの操作が発生するため、InnoDBはデータウェアハウジングに最適なエンジンではない可能性があります。データウェアハウステーブルを Compressed MyISAM に変更することを検討できます。

¹_{偶然にも、負荷が25％を超えるのを妨げるボトルネックがあることを意味しますが、必ずしも強制的なシングルコアの問題ではありません。}

Rick James · Answer

注：この回答は、複数のコアを使用する単一の接続に関するものです。OPの質問があいまいであり、MySQLが全体として複数のコアを使用できないと誤って想定されていました。他の回答は、3-Alterを正しく指摘していますテストケースは実際にはI/Oにバインドされているため、タイトルの質問を証明できません。

単一の接続は単一のコアのみを使用します。（OK、InnoDBは一部のI/O処理に他のスレッド、つまりコアを使用しますが、それは重要ではありません。）

あなたは3つのALTERを持っているので、3つ以上のコアの価値を使用していませんでした。

残念ながら、PARTITIONでも複数のコアを使用していません。

最近まで、複数の接続は4〜8コア後に最大になります。 PerconaのXtradb（MariaDBに含まれる）は、複数のコアをより効率的に使用しますが、スレッドごとに1つだけです。それらは約32コアで最大になります。

（2015年の更新:) 5.6の複数の接続は、約48コアで最大になります。 5.7はさらに良いことを約束します。（したがって、Oracleのベンチマークはそうです。）しかし、単一の接続に複数のコアを使用することはまだありません。

更新（OracleのOpenWorldに移動した後）：新しいバージョン8.xには並列処理がありません。

さらなるアップデート-8.0.17には、選択された非常に少数のクエリで複数のコアを使用するケースがあります。（つまり、興奮しないでください。）

jfg956 · Answer

IMHOと前述のユースケースでは、複数のコアを使用することはありません。その理由は、ワークロードがIOバウンドであり、CPUバウンドではないためです。3つの接続が新しいインデックスを作成しているため、それぞれがディスクからテーブル全体を読み取る必要があります。これは時間、インデックスを計算していません。

OkezieE · Answer

ボトルネックがファイルシステムのIOパフォーマンスである可能性があることを考慮してください。

@ RolandoMySQLDBAによって提案された設定に加えて、_/etc/fstab_でmysqlデータディレクトリを保持するパーティションのnoatimeマウント設定も設定します（私の場合、_/data01/mysql_、_/dev/sdb1_は_/data01_にマウントされます）。

デフォルトでは、Linuxはすべてのディスクの読み取りまたは書き込みのアクセス時間を記録します。これは、IOパフォーマンス、特にデータベースのような高いIOアプリケーションの場合、パフォーマンスに悪影響を及ぼします。つまり、読み取りファイルからのデータはディスクへの書き込みをトリガーします... WAT！

これを無効にするには、目的のマウントポイントの_/etc/fstab_にnoatimeマウントオプションを次のように追加します（私の場合の例）：

_/dev/sdb1 /data01 ext4 defaults,noatime 0 2 _

次に、パーティションを再マウントします。

_mount -o,remount /data01 _

これにより、そのパーティションを使用するアプリケーションの読み取り/書き込みパフォーマンスが向上します。しかし...メモリにすべてのデータを保持することに勝るものはありません。