web-dev-qa-db-ja.com

innodb_buffer_pool_sizeを増やすとMySQLの速度が低下するのはなぜですか？

5.1.68-cll-CentOS上のMySQL Community Server

システムには32GBのRAMが搭載されています。

Innodb_buffer_pool_sizeを10240Mから15360Mに増やしました（10GB-> 15GB）。

一連の同一操作にかかる時間は、720秒から822秒に増加しました（14％増加）。

これは、各設定で1つのテストのみの結果でした。しかし、数か月前に実行された以前の4つのテストでは、726から740の間の時間が発生しました。

8GBでもう一度実行してみたところ、所要時間は719秒でした。

メモリを増やすとプロセスが遅くなるのはなぜですか？

編集：プロセスの詳細

私がテストしているプロセスには、いくつかのテーブルを空にし、既存のテーブルのデータからそれらを再構築することが含まれます。 SELECT INSERTを使用しているかどうか、またはSELECTingデータを使用しているかどうかわからない場合は、PHPを使用して長いINSERTステートメントを作成します。問題は私が見つけることができます。

スキーマ定義の変更は行われていません。

以下は、サーバーが比較的アイドル状態のときのnumactl --hardwareの出力です。

root@server [~]# numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 32740 MB
node 0 free: 6216 MB
node distances:
node   0
  0:  10

そしてfree -m

root@server [~]# free -m
             total       used       free     shared    buffers     cached
Mem:         32081      25864       6216          0       2591      12791
-/+ buffers/cache:      10482      21599
Swap:        15994         16      15977

RolandoMySQLDBAによる編集

このクエリを実行してください

SELECT
    InnoDBSpace / POWER(1024,1) InnoDB_KB,
    InnoDBSpace / POWER(1024,2) InnoDB_MB,
    InnoDBSpace / POWER(1024,3) InnoDB_GB
FROM
(
    SELECT SUM(data_length+index_length) InnoDBSpace
    FROM information_schema.tables
    WHERE ENGINE='InnoDB'
) A;

結果：

InnoDB_KB InnoDB_MB InnoDB_GB
8413536 8216.34375 8.02377319335938

そしてこれ

SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_pages%';

結果：

Innodb_buffer_pool_pages_data
410035
Innodb_buffer_pool_pages_dirty
204
Innodb_buffer_pool_pages_flushed
826954
Innodb_buffer_pool_pages_free
99231
Innodb_buffer_pool_pages_misc
15022
Innodb_buffer_pool_pages_total
524288

プロセスの実行中：

root@server [~]# numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 32740 MB
node 0 free: 5461 MB
node distances:
node   0
  0:  10

そして：

             total       used       free     shared    buffers     cached
Mem:         32081      26658       5423          0       2603      12948
-/+ buffers/cache:      11106      20975
Swap:        15994         16      15977
mysqlinnodbmemorybuffer-pool
3
Buttle Butkus

これまでにあなたがくれたものから

  • CPUは、すべての32GB RAMにアクセスするという輝かしいタスクを持っています。
  • InnoDBのバッファープールは8GB（524288 * 16384）

InnoDBアーキテクチャ

enter image description here

構想＃1

InnoDBは連続してバッファープールを割り当てるので、バッファープール内でデータとインデックスページの断片化が何らかの形で存在する場合にのみ想像できます。他に何か？また、システムテーブルスペースファイル（ibdata1として知られている）にマージされる前に、最初にバッファプール内にポストされる一意でないセカンダリインデックスの更新もあります。 InnoDB Architecture内のバッファの挿入に注意してください。

コンジェクチャー＃2

バッファプールを大きくするとディスクI/Oを減らすことができますが、バッファプールが大きすぎると、先ほど述べた断片化の問題などの問題が発生する可能性があります。

おそらく、スパースメモリは連続していますが、良いことでもありません。私はOct 22, 2012でその性質について話し合いました： mysql innodb_buffer_pool_sizeはどのくらいの大きさである必要がありますか？

バッファプール内のその他のページ（ Innodb_buffer_pool_pages_misc ）に気づきました。これには235 MB（16384 * 15022）かかります。インデックス作成と行ロックのオーバーヘッドの一部。それにもかかわらず、これは大量のかなりの空のギャップを持つ大きなバッファプールによって犠牲にされる可能性があります。

構想＃3

バッファプールを占有するのは、データページとインデックスページだけではありません。彼らがスペースを共有しなければならない迷惑な隣人は挿入バッファです。バッファプールのそのセクションには、すべての一意でないインデックスの変更が含まれています。各InnoDBテーブルにあるインデックスの数に応じて、バッファプールの最大半分まで使用できます。これは、すべてのInnoDBテーブルを調べて、冗長なインデックスを削除することを覚えておくとよいでしょう。

冗長なインデックスを探す方法と、それらを取り除く理由を説明する他の投稿は次のとおりです。

考えてみてください：テーブルに冗長なインデックスがある場合、テーブルへのINSERTとUPDATEにより ツリーページの45％時間（最悪の場合 。このようなツリーのリバランスは、多くのインデックスを持つテーブルで複数回発生します。冗長なインデックスを削除することで、それらの変更を挿入バッファーに、そして各InnoDBテーブルのインデックスページに書き込むために費やす時間を削減します。

バッファープールサイズを増やすと、インデックスが多すぎる、特に冗長なインデックスを持つInnoDBテーブルがある場合に、挿入バッファーが無意味に実行する余地が残ります。このようなテーブルを探す必要があることを示すもう1つの兆候は、次のクエリを実行することです。

SELECT table_schema,table_name,data_length,index_length
FROM information_schema.tables WHERE engine='InnoDB'
AND data_length/(data_length+index_length) < 0.8;

これにより、先行する列の冗長性を調べるためにインデックスを調べる必要があるテーブルの概要がわかります。

エピローグ

バッファプールが保持することに留意してください

  • データページ
  • 索引ページ
  • インデックス変更のためのバッファーの挿入
  • アダプティブハッシュインデックス
  • 開かれたテーブル情報
  • 諸経費
  • InnoDB Architectureを参照してください

バッファプールの無駄なスペースは、特にすべてのRAMを単独で担当するシングルコアの場合、ふるいにかけるのに時間がかかる可能性があります。

私のアドバイスは innodb_buffer_pool_size を10Gに保つことです。

3
RolandoMySQLDBA

以前は、innodb_buffer_pool_sizeは総メモリの55％から65％の間である必要があると言っていました。 （MySQLがすべてのメモリを盗んだため）システムが適切に動作するのに十分なメモリがない可能性があり、システムが常に優先されます。

システムに問題がある場合、MySQLサーバーも問題になります:)

0
Maxime Fouilleul