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
を使用しているかどうか、またはSELECT
ingデータを使用しているかどうかわからない場合は、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
これまでにあなたがくれたものから
InnoDBは連続してバッファープールを割り当てるので、バッファープール内でデータとインデックスページの断片化が何らかの形で存在する場合にのみ想像できます。他に何か?また、システムテーブルスペースファイル(ibdata1
として知られている)にマージされる前に、最初にバッファプール内にポストされる一意でないセカンダリインデックスの更新もあります。 InnoDB Architecture
内のバッファの挿入に注意してください。
バッファプールを大きくするとディスクI/Oを減らすことができますが、バッファプールが大きすぎると、先ほど述べた断片化の問題などの問題が発生する可能性があります。
おそらく、スパースメモリは連続していますが、良いことでもありません。私はOct 22, 2012
でその性質について話し合いました: mysql innodb_buffer_pool_sizeはどのくらいの大きさである必要がありますか?
バッファプール内のその他のページ( Innodb_buffer_pool_pages_misc )に気づきました。これには235 MB(16384 * 15022)かかります。インデックス作成と行ロックのオーバーヘッドの一部。それにもかかわらず、これは大量のかなりの空のギャップを持つ大きなバッファプールによって犠牲にされる可能性があります。
バッファプールを占有するのは、データページとインデックスページだけではありません。彼らがスペースを共有しなければならない迷惑な隣人は挿入バッファです。バッファプールのそのセクションには、すべての一意でないインデックスの変更が含まれています。各InnoDBテーブルにあるインデックスの数に応じて、バッファプールの最大半分まで使用できます。これは、すべてのInnoDBテーブルを調べて、冗長なインデックスを削除することを覚えておくとよいでしょう。
冗長なインデックスを探す方法と、それらを取り除く理由を説明する他の投稿は次のとおりです。
Jan 26, 2012
: MySql-冗長なインデックスを検索Dec 10, 2011
: 重複するキーインデックスはありますか?Sep 07, 2011
: MySQL CPU使用率May 17, 2011
: フィールドに複数列のインデックスが既に存在する場合、テーブルに新しい単一列のインデックスを追加する必要がありますか?考えてみてください:テーブルに冗長なインデックスがある場合、テーブルへの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に保つことです。
以前は、innodb_buffer_pool_sizeは総メモリの55%から65%の間である必要があると言っていました。 (MySQLがすべてのメモリを盗んだため)システムが適切に動作するのに十分なメモリがない可能性があり、システムが常に優先されます。
システムに問題がある場合、MySQLサーバーも問題になります:)