CPUの数よりも大きいinnodb_buffer_pool_instancesを設定するのは無駄ですか？
innodb_buffer_pool_size 12 CPUコアのサーバーで20GBまで。私の完全なデータベースは11GBですが、そのほとんどはアーカイブテーブルであり、ほとんど使用されていません。照会されるデータの合計は約3 GBで、頻繁に照会されるデータは約1.25 GBです。
何を設定すればよいですかinnodb_buffer_pool_instancesへ？
innodb_buffer_pool_size/クエリされたデータの合計= 6つのプールインスタンスinnodb_buffer_pool_size/頻繁に照会されるデータ= 16個のプールインスタンス
通常はオプション＃2を選択しますが、論理的には、一度に使用できるバッファープールの数は、CPUコアの総数を超えないようです。
設定するのはもったいないinnodb_buffer_pool_instances CPUコアの数を超えていますか？
頻繁に照会されるデータのサイズはそれを正当化するものではないため、照会するデータのためにあまり多くのバッファー・プールを用意する必要はないと思います。もちろん、これは「頻繁に」の定義に依存します。
ここで、innodbバッファープールのページを参照する必要がある適切なドキュメント：
http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-buffer-pools.html
ここで私が焦点を当てている数字は
頻繁に照会されるデータは、約1.25 GBです。
InnoDBバッファーを適切なサイズに維持しようとするときの経験則は、ブロックのリストをできるだけ短くし、バッファーのリストが過度にフェッチされないようにするために、それらを1 GB程度に保つことです。これにより、ただし、常に実際のニーズに依存します。
これはMySQLの推奨事項と一致しています。
最高の効率を得るには、innodb_buffer_pool_instancesとinnodb_buffer_pool_sizeの組み合わせを指定して、各バッファープールインスタンスが少なくとも1ギガバイトになるようにします。
複数のバッファー・プールの要点は、CPUスレッドがデータにアクセスする際の高い競合に対応しないようにすることです。または彼らがそれを置くように：
バッファプールに一度にアクセスしようとする複数のスレッドからボトルネックが発生する場合があります。複数のバッファプールを有効にして、この競合を最小限に抑えることができます。
ただし、この機能は、システムが頻繁に使用する1.25GBとは対照的に、頻繁にアクセスされる大量のデータに適しています。最終的に私があなたの立場にあった場合、すべてのCPUがMySQL関連のタスクのみを実行していると想定して、CPUの数よりも多くのバッファプールを用意する必要はないと思います。また、innodb_old_blocks_timeを使用して、アーカイブされたテーブルに対する不定期のクエリが、何度も使用されるデータのブロックに取って代わらないようにすることの影響についても調べます。
それが役に立てば幸いです。すべてがうまくいく方法を教えてください。
11 GBのデータサイズでは、サーバーが純粋なデータベースであり、RAMを捨てるだけの場合を除き、12 GBのプールサイズと12 GBの1 GBプールを使用することを検討します。
CPUコアよりも...最適化が行き過ぎだと思います。mysqlエンジンルーチン内で他の微妙な制限に達するリスクがあります。
クエリされたデータの合計と頻繁にクエリされたデータは毎日の統計であり、変更される可能性があります。
Mysql開発者は、CPUの競合を回避する重要性を概説し、調整可能なinnodb_buffer_pool_instancesを提供します
12コアと20 Gbプールがあります。私はから始めることをお勧めします
innodb_buffer_pool_instances = 2
開発者のルールを満たし、2つのメモリアリーナで分割された動作中のコア（メトリックを取得しましたか？）があります。
（現在）競合がない場合でも、この「最小限の保護」設定で問題は発生しません。
の承認済みの回答も参照してください。バッファプールインスタンスのサイズと数に関する経験則はありますか？
次に、いくつかのパフォーマンスメトリックを収集し、さらにプールを分割することが有用かどうかを決定します。