max_heap_table_size の値を増やすと MySQL がクラッシュする

Question 1

120 GB のメモリがある場合、マシンに複数の物理 CPU と Non-Uniform Memory Access (NUMA) アーキテクチャが搭載されている可能性もあります...その場合、使用可能なメモリは十分にある可能性がありますが、直感に反して、使用可能なメモリがまだ十分ではない可能性があります。

これまでのところ私の推測が正しいとすれば、この問題は、MySQL がテーブルに割り当てられたメモリを増やそうとしたときに発生する可能性があります。このとき、MEMORYLinux がこのアーキテクチャで実行しているときにメモリ割り当てを処理する方法に関連するエラーが発生します。つまり、マザーボード上の他の物理メモリが空いているにもかかわらず、メモリ要求が処理される「1 つ」としてある程度恣意的に選択された特定の CPU に直接接続されているメモリスティック上の使用可能なメモリのみを考慮します。

NUMA は理論的には問題ありませんが、MySQL の場合のように、大量のメモリを必要とする単一のプロセスには適していない可能性があります... ただし、回避策があります。

mysqld_safe修正するには、次の行を追加してスクリプトを変更します。

cmd="/usr/bin/numactl --interleave all $cmd"

...すぐに後この行...

cmd="$NOHUP_NICENESS"

理由は、このアーキテクチャのMySQLサーバーが空きメモリがあるにもかかわらずスワップを大量に発生させる理由を説明するために書かれた優れた記事で説明されています。しかし、それは著者が指摘したより大きな問題の兆候でした。その後「これは完全にスワッピングの問題ではない」と指摘し、スワップを無効にしても「メモリ割り当ての失敗」が含まれる可能性があると述べた。

http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

もちろん、これがあなたのシステムに当てはまるかどうかは推測ですが、可能性としてはありそうです。私は、新しい128GBのマシンで64GBのInnoDBバッファプールをプロビジョニングしようとしたときに、MySQLが64GBの空き容量を見つけられなかったという問題に遭遇したときに、まさにこの修正を使用しました。何もない他に実行中のものはありません。私がうまく使用できる最高の値は、4つのコアを持つ16コアマシンの合計メモリの1/4未満であることに気づきました。物理的なプロセッサ... あなたが遭遇しているようなもの... 問題の本質について私が情報をまとめたとき、それが分かりました。

Answer

120 GB のメモリがある場合、マシンに複数の物理 CPU と Non-Uniform Memory Access (NUMA) アーキテクチャが搭載されている可能性もあります...その場合、使用可能なメモリは十分にある可能性がありますが、直感に反して、使用可能なメモリがまだ十分ではない可能性があります。

これまでのところ私の推測が正しいとすれば、この問題は、MySQL がテーブルに割り当てられたメモリを増やそうとしたときに発生する可能性があります。このとき、MEMORYLinux がこのアーキテクチャで実行しているときにメモリ割り当てを処理する方法に関連するエラーが発生します。つまり、マザーボード上の他の物理メモリが空いているにもかかわらず、メモリ要求が処理される「1 つ」としてある程度恣意的に選択された特定の CPU に直接接続されているメモリスティック上の使用可能なメモリのみを考慮します。

NUMA は理論的には問題ありませんが、MySQL の場合のように、大量のメモリを必要とする単一のプロセスには適していない可能性があります... ただし、回避策があります。

mysqld_safe修正するには、次の行を追加してスクリプトを変更します。

cmd="/usr/bin/numactl --interleave all $cmd"

...すぐに後この行...

cmd="$NOHUP_NICENESS"

理由は、このアーキテクチャのMySQLサーバーが空きメモリがあるにもかかわらずスワップを大量に発生させる理由を説明するために書かれた優れた記事で説明されています。しかし、それは著者が指摘したより大きな問題の兆候でした。その後「これは完全にスワッピングの問題ではない」と指摘し、スワップを無効にしても「メモリ割り当ての失敗」が含まれる可能性があると述べた。

http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

もちろん、これがあなたのシステムに当てはまるかどうかは推測ですが、可能性としてはありそうです。私は、新しい128GBのマシンで64GBのInnoDBバッファプールをプロビジョニングしようとしたときに、MySQLが64GBの空き容量を見つけられなかったという問題に遭遇したときに、まさにこの修正を使用しました。何もない他に実行中のものはありません。私がうまく使用できる最高の値は、4つのコアを持つ16コアマシンの合計メモリの1/4未満であることに気づきました。物理的なプロセッサ... あなたが遭遇しているようなもの... 問題の本質について私が情報をまとめたとき、それが分かりました。

Question 2

ドキュメントtmp_テーブルサイズこの設定は一時テーブルの最大サイズですメモリ内このサイズを超えても、テーブルがいっぱいであるというエラーは発生しません。メモリ内のテーブルの使用からディスク上の MyISAM テーブルの使用への変更がトリガーされます。

システムがクラッシュするのは、一時テーブルが本来よりも多くのメモリを使用することを許可しているためです。メモリテーブルについても同様です。

tmp_table_sizeを削除する必要があります方法ダウンします。この設定は全体の最大値ではなく、一時テーブルごとの最大値であることに注意してください。非常に大きな一時テーブルを作成するクエリが 5 つある場合 (それぞれ 20 GB 未満など)、一時テーブルが RAM の 100 GB を使用することになります。6 つ目を追加すると、サーバーの合計よりも多くの RAM が使用されることになります。

スクリプトが実際に MEMORY ストレージエンジンを使用している場合は、MyISAM ファイルにデータを書き込む前に、その変更を検討する必要があります。その大きさの一時テーブルでその高速パフォーマンスが本当に必要な場合は、より高速なストレージ (例:フュージョン-io、ヴィリデントなど)。それらが過剰であったり高価すぎる場合は、少なくとも消費者向けグレードの SSD を検討します。

MyISAM は、データがシステムメモリ (未使用の RAM) にキャッシュされているときに最高のパフォーマンスを発揮します。スクリプトが巨大なクエリ (MEMORY エンジンを使用) を実行するたびにキャッシュを使い果たしてしまうと、MyISAM のパフォーマンスが低下します。

スクリプトは MEMORY ストレージエンジンを使用してパフォーマンスを「向上」させているように見えますが、実際にはパフォーマンスを低下させています。一時テーブルの場合は、一時テーブルを使用する必要があり、tmp_table_size はもっと小さい値に設定して、tmp_table_size を超えたらディスクに強制的に書き込む必要があります。

max_heap_table_size と tmp_table_size のデフォルトはどちらも 16 MB です。可能であれば、設定をデフォルトに戻すことをお勧めします。リソース使用量 (ディスク I/O、合計メモリ使用量、CPU 使用量など) を監視しながら、データセットに適した設定が見つかるまで少しずつ上方に調整します。

Answer