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

単一のコア以上を使用しない専用のMySQLサーバーをいくつか紹介しました。私はMySQLのDBAよりも開発者なので、助けが必要です

セットアップ

サーバーは、OLAP / DataWarehouse（DW）タイプのロードでは非常に大きくなります。

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

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

テストサーバーでの観察

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

ご質問

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

その他の注意事項

• RDBMS「スレッド」とOS「スレッド」の違いを理解しています
• 私はどんな形の並列性についても尋ねていません
• InnoDBとスレッドのシステム変数のいくつかは次善の策です
  （クイックウィンを探しています）
• 短期的には、ディスクレイアウトを変更できません
• 必要に応じてOSを調整できます
• 最小のテーブル上の単一のALTER TABLEには4.5分かかります（IMOに衝撃を与えます）

編集1

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

重要なものを見逃したかどうか教えてください

乾杯

更新

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

実際、2011年5月に開催されたPercona Live NYC会議で、innodb_thread_concurrencyをMySQLの専門家と話しました。

私は驚くべきことを学びました：ドキュメンテーションにもかかわらず、innodb_thread_concurrency0（無限並行性）のままにするのが最善です。このようにして、InnoDBは、innodb_concurrency_tickets特定のMySQLインスタンスのセットアップに対して開く最適な数を決定します。

あなたが設定されたらinnodb_thread_concurrency0に、あなたが設定することができますinnodb_read_io_threadsし、innodb_write_io_threadsより多くのコアを従事すべき64本の最大値（両方のMySQL 5.1.38以降）を。

MySQLは自動的に複数のコアを使用するため、25％の負荷は偶然^1であるか、Solarisでの構成ミスの可能性があります。私は、ソラリスを調整する方法を知っているふりをしませんが、ここでは、ソラリス固有の調整情報について説明する記事があります。

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

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

その他の確認事項：

• スイッチングinnodb_flush_method O_DIRECTにすることは価値がテストです。これが役立つ場合、forcedirectioオプションでファイルシステムをマウントする必要があるかもしれません

• 変更innodb_flush_log_at_trx_commitを（あなたはOSのクラッシュでの最後の秒を失うことを気にしない場合）（あなたはMySQLのクラッシュの最後の秒を失うことを気にしない場合）1から0までまたは2。

• innodb_use_sys_mallocの値を確認します。この記事には、変数に関する詳細情報があります。

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

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

  InnoDBメモリアロケーターが無効になっている場合、InnoDBはパラメーターinnodb_additional_mem_pool_sizeの値を無視することに注意してください。

• レプリケーションが問題の原因となっている可能性があります。私はあなたが並列処理に興味がないことを理解していますが、この作業ログの説明から：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mount -o,remount /data01

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