MySQLキルルがスレッドを外れない原因
背景
日常の使用中に、時々個別に遭遇したり、大量の接続がMySQLに蓄積されたりする現象があります。この場合、基本的には、これらの長い間積み重ねられた接続を強制的に殺して、接続数とデータベースサーバのCPUリソースをできるだけ早く解放することが考えられます。
問題の説明
実際にキルコマンドを操作すると、接続が最初にキルに落とされたわけではなく、プロシーズの中で見られますが、表示されているCommandはKilledで、通常のQueryやExecuteなどではありません。たとえば:
何かあったらまず公式文書を翻訳してはいけません。ここで一部の公式文書の内容を摘出します。
When you use KILL、a thread-speciifickill ffliag is set for the thread.In most cases、itmighttae some time for the thread to die because the kill fll ffflashsh ischecemitervals：During SESESEfrerererererefffrererererererereftttttttttttttttttttttfffffrererererererererererererererererererererererererererererererererererererererefs s s s s、FFFFFFFFFFFflags is set、the statement is aboted.
ALTER TABLE operations that make a table copy check the kill flags periodically for each few copied rows read from the original table.If the kill flags set，the statement is aboted and the temporary Table.
The KILL statement returns without waiting for confirmation、but the kill flags check abors the operation within a reasonable small amount of time.Aborting the operation to perform any neceary cleanup alsome。
During UPDATE or DELETE operations、the kill flags check after each block read and after each udated or deleted row.If the kill flags set、the statement is aboted.If you are nousing trantions、the changereet
GET_LOCK()aborts and returns NULL.
If the thread is in the table lock handler(state:Locked)、the table lock is quickly aboted.
If the thread is waiting for free disk space in a write call，the write is aboted with a“disk full”error message.
公式文書の第1段目から、「キルル」の役割メカニズムを明確に説明しました。接続スレッドにスレッドレベルのキルルマークを設定します。次の「マーク検出」の時に有効になります。これは、次の「マーク検出」が遅々として発生しないと、問題記述中の現象が発生する可能性があるということです。
公式文書には多くの場面が挙げられていますが、ここでは公式の説明に基づいていくつかの一般的な問題シーンを挙げます。 select文でorder byを行い、group byを行う場合、サーバCPUリソースが緊張すると、データの読み込み／取得時間が長くなり、次の「マーク検出」の時間に影響を与えます。 大量のデータをDMMLで操作すると、キルルというSQL文は、事務のロールバックを起こします。 キルオールが操作する場合、サーバーの負荷が高いと、一連のデータを操作する時間が長くなり、次の「マーク検出」の時間に影響を与えます。 実は、キルルの作用メカニズムを参考にして、要約的な説明をすれば、どのような渋滞/減速SQL文でも正常に実行される行為は、次の「マーク検出」が遅延され、発生できなくなり、結局はキルル操作の失敗を招きます。
シミュレーションしてみます
ここで一つのパラメータを借りる。スリーロード.concurrencyは、SQL文のブロックを正常に実行するシーンをシミュレートする。
Defines the maximnumber of threads permitted inside of InnoDB.A value of 0(the default)is interpreted as infinite concurrency.This variable inted for performance nitun higness.sys。
公式文書の説明を参照してください。このパラメータを低く設定すると、数量制限を超えたInnoDBクエリがブロックされます。従って，今回のシミュレーションでは，このパラメータは非常に低い値を設定した。
まとめてみます
MySQLのキルル操作は思ったより直接的にデータベース接続を終了することではなく、終了信号を送りました。もしSQL自身の実行効率が遅すぎたり、他の要因に影響されたりしたら、このキルルの操作は直ちに終了できないかもしれません。むしろ、プログラム側の接続が切断された後に再接続がトリガされ、より多くの非効率なクエリが生成され、さらにデータベースをドラッグします。
以上はMySQL Killがスレッドを落とさない原因の詳細です。MySQL Killスレッドに関する資料は他の関連記事に注目してください。
日常の使用中に、時々個別に遭遇したり、大量の接続がMySQLに蓄積されたりする現象があります。この場合、基本的には、これらの長い間積み重ねられた接続を強制的に殺して、接続数とデータベースサーバのCPUリソースをできるだけ早く解放することが考えられます。
問題の説明
実際にキルコマンドを操作すると、接続が最初にキルに落とされたわけではなく、プロシーズの中で見られますが、表示されているCommandはKilledで、通常のQueryやExecuteなどではありません。たとえば:
mysql> show processlist;
+----+------+--------------------+--------+---------+------+--------------+---------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+--------------------+--------+---------+------+--------------+---------------------------------+
| 31 | root | 192.168.1.10:50410 | sbtest | Query | 0 | starting | show processlist |
| 32 | root | 192.168.1.10:50412 | sbtest | Query | 62 | User sleep | select sleep(3600) from sbtest1 |
| 35 | root | 192.168.1.10:51252 | sbtest | Killed | 47 | Sending data | select sleep(100) from sbtest1 |
| 36 | root | 192.168.1.10:51304 | sbtest | Query | 20 | Sending data | select sleep(3600) from sbtest1 |
+----+------+--------------------+--------+---------+------+--------------+---------------------------------+何かあったらまず公式文書を翻訳してはいけません。ここで一部の公式文書の内容を摘出します。
When you use KILL、a thread-speciifickill ffliag is set for the thread.In most cases、itmighttae some time for the thread to die because the kill fll ffflashsh ischecemitervals：During SESESEfrerererererefffrererererererereftttttttttttttttttttttfffffrererererererererererererererererererererererererererererererererererererererefs s s s s、FFFFFFFFFFFflags is set、the statement is aboted.
ALTER TABLE operations that make a table copy check the kill flags periodically for each few copied rows read from the original table.If the kill flags set，the statement is aboted and the temporary Table.
The KILL statement returns without waiting for confirmation、but the kill flags check abors the operation within a reasonable small amount of time.Aborting the operation to perform any neceary cleanup alsome。
During UPDATE or DELETE operations、the kill flags check after each block read and after each udated or deleted row.If the kill flags set、the statement is aboted.If you are nousing trantions、the changereet
GET_LOCK()aborts and returns NULL.
If the thread is in the table lock handler(state:Locked)、the table lock is quickly aboted.
If the thread is waiting for free disk space in a write call，the write is aboted with a“disk full”error message.
公式文書の第1段目から、「キルル」の役割メカニズムを明確に説明しました。接続スレッドにスレッドレベルのキルルマークを設定します。次の「マーク検出」の時に有効になります。これは、次の「マーク検出」が遅々として発生しないと、問題記述中の現象が発生する可能性があるということです。
公式文書には多くの場面が挙げられていますが、ここでは公式の説明に基づいていくつかの一般的な問題シーンを挙げます。
ここで一つのパラメータを借りる。スリーロード.concurrencyは、SQL文のブロックを正常に実行するシーンをシミュレートする。
Defines the maximnumber of threads permitted inside of InnoDB.A value of 0(the default)is interpreted as infinite concurrency.This variable inted for performance nitun higness.sys。
公式文書の説明を参照してください。このパラメータを低く設定すると、数量制限を超えたInnoDBクエリがブロックされます。従って，今回のシミュレーションでは，このパラメータは非常に低い値を設定した。
mysql> show variables like '%innodb_thread_concurrency%';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| innodb_thread_concurrency | 1 |
+---------------------------+-------+
1 row in set (0.00 sec)select sleep(3600) from sbtest.sbtest1文を実行し、3番目の接続において、Session 2のクエリをkillする。
Session 1：
mysql> select sleep(3600) from sbtest.sbtest1;
Session 2：
mysql> select sleep(3600) from sbtest.sbtest1;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
Session 3：
mysql> show processlist;
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
| 44 | root | 172.16.64.10:39290 | NULL | Query | 17 | User sleep | select sleep(3600) from sbtest.sbtest1 |
| 45 | root | 172.16.64.10:39292 | NULL | Query | 0 | starting | show processlist |
| 46 | root | 172.16.64.10:39294 | NULL | Query | 5 | Sending data | select sleep(3600) from sbtest.sbtest1 |
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
3 rows in set (0.00 sec)
mysql> kill 46;
Query OK, 0 rows affected (0.00 sec)
mysql> show processlist;
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
| 44 | root | 172.16.64.10:39290 | NULL | Query | 26 | User sleep | select sleep(3600) from sbtest.sbtest1 |
| 45 | root | 172.16.64.10:39292 | NULL | Query | 0 | starting | show processlist |
| 46 | root | 172.16.64.10:39294 | NULL | Killed | 14 | Sending data | select sleep(3600) from sbtest.sbtest1 |
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
3 rows in set (0.00 sec)
mysql>innodb_thread_concurrencyというパラメータによって類似の問題が生じた場合、set globalのコマンドを直接使用して上限を高くしたり、直接0に設定したりすれば解決できます。このパラメータの変更はリアルタイムですべての接続に有効になります。まとめてみます
MySQLのキルル操作は思ったより直接的にデータベース接続を終了することではなく、終了信号を送りました。もしSQL自身の実行効率が遅すぎたり、他の要因に影響されたりしたら、このキルルの操作は直ちに終了できないかもしれません。むしろ、プログラム側の接続が切断された後に再接続がトリガされ、より多くの非効率なクエリが生成され、さらにデータベースをドラッグします。
以上はMySQL Killがスレッドを落とさない原因の詳細です。MySQL Killスレッドに関する資料は他の関連記事に注目してください。