SHOW [FULL] PROCESSLIST
SHOW PROCESSLIST
はどのスレッドが起動しているかを表示します。mysqladmin
processlist
コマンドを利用してこの情報を手に入れる事もできます。
もし PROCESS
権限を持っていれば、全てのスレッドを見る事ができます。そうでなければ、自分自身のスレッドのみ見る事ができます。(使用中のMySQL
アカウントと関連しているスレッド)詳しくは
項12.5.5.3. 「KILL
構文」 を参照してください。もし
FULL
キーワードを利用しなければ、各ステートメントの最初の100文字だけが
Info
フィールドに表示されます。
MySQL Enterprise. MySQL ネットワーク モニタリングとアドバイス サービス の読者は、プロセスが多すぎる時には、即時通知と専門家のアドバイスを受け取ります。追加情報については http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。
このステートメントは、「too many
connections」 エラー
メッセージを受け取り、何が起こっているのを確認したい時に大変役に立ちます。MySQL
は、管理者がいつでもシステムに接続して確認できる事を保証する為、SUPER
権限を持つアカウントに利用される事ができる接続を1つ余分に確保します。(この権限を全てのユーザには与えていないと仮定しています。)
SHOW PROCESSLIST
のアウトプットは、次のようになるでしょう。
mysql> SHOW FULL PROCESSLIST\G *************************** 1. row *************************** Id: 1 User: system user Host: db: NULL Command: Connect Time: 1030455 State: Waiting for master to send event Info: NULL *************************** 2. row *************************** Id: 2 User: system user Host: db: NULL Command: Connect Time: 1004 State: Has read all relay log; waiting for the slave » I/O thread to update it Info: NULL *************************** 3. row *************************** Id: 3112 User: replikator Host: artemis:2204 db: NULL Command: Binlog Dump Time: 2144 State: Has sent all binlog to slave; waiting for binlog to be updated Info: NULL *************************** 4. row *************************** Id: 3113 User: replikator Host: iconnect2:45781 db: NULL Command: Binlog Dump Time: 2086 State: Has sent all binlog to slave; waiting for binlog to be updated Info: NULL *************************** 5. row *************************** Id: 3123 User: stefan Host: localhost db: apollon Command: Query Time: 0 State: NULL Info: SHOW FULL PROCESSLIST 5 rows in set (0.00 sec)
アウトプット カラムは次の意味を持っています。
Id
接続識別子。
User
ステートメントを発行した MySQL
ユーザ。もしこれが system user
であれば、タスクを内部的に取り扱う為に、サーバによって生み出された非クライアント
スレッドを参照します。これは、複製スレーブか遅れた行のハンドラに利用される
I/O または SQL スレッドになり得ます。
event_scheduler
はスケジュールされたイベントをモニタするスレッドを参照する事ができます。system
user
か event_scheduler
には、Host
カラム内で指定されたホストはありません。
Host
ステートメントを発行するクライアントのホスト名(ホストが無い
system user
以外)。SHOW
PROCESSLIST
は、どのクライアントが何をしているかの究明を簡単にする為に、TCP/IP
接続のホスト名を
フォーマットで報告します。
host_name
:client_port
db
もし選択されれば、これがデフォルト
データベースです。そうでなければ
NULL
です。
Command
クライアント/サーバ プロトコルの
COM_
コマンドに対応するカラムの値。詳しくは
項4.2.5. 「ステータス変数」
を参照してください。
xxx
Command
値は、次のうちのどれかでしょう。Binlog
Dump
, Change
user
、Close
stmt
、Connect
、Connect
Out
、Create
DB
、Daemon
、Debug
、Delayed
insert
、Drop
DB
、Error
、Execute
、Fetch
、Field
List
、Init
DB
、Kill
、Long
Data
、Ping
、Prepare
、Processlist
、Query
、Quit
、Refresh
、Register
Slave
、Reset
stmt
、Set
option
、Shutdown
、Sleep
、Statistics
、Table
Dump
、Time
Time
ステートメントやコマンドの開始から現在までの、秒表示での時間。
State
次のうちのどれかになり得る、アクション、イベント、またはステート:After
create
、Analyzing
、Changing
master
、Checking master
version
、Checking
table
、Connecting to
master
、Copying to group
table
、Copying to tmp
table
、Creating delayed
handler
、Creating
index
、Creating sort
index
、Creating table from master
dump
、Creating tmp
table
、Execution of
init_command
、FULLTEXT
initialization
、Finished reading one
binlog; switching to next
binlog
、Flushing
tables
、Killed
、Killing
slave
、Locked
、Making
temp file
、Opening master dump
table
、Opening
table
、Opening
tables
、Processing
request
、Purging old relay
logs
、Queueing master event to the
relay log
、Reading event from the
relay log
、Reading from
net
、Reading master dump table
data
、Rebuilding the index on master
dump table
、Reconnecting after a
failed binlog dump
request
、Reconnecting after a failed
master event read
、Registering slave
on master
、Removing
duplicates
、Reopen
tables
、Repair by
sorting
、Repair
done
、Repair with
keycache
、Requesting binlog
dump
、Rolling
back
、Saving
state
、Searching rows for
update
、Sending binlog event to
slave
、Sending
data
、Sorting for
group
、Sorting for
order
、Sorting
index
、Sorting
result
、System
lock
、Table
lock
、Thread
initialized
、Updating
、User
lock
、Waiting for
INSERT
、Waiting for master to send
event
、Waiting for master
update
、Waiting for slave mutex on
exit
、Waiting for
table
、Waiting for
tables
、Waiting for the next event in
relay log
、Waiting on
cond
、Waiting to finalize
termination
、Waiting to reconnect
after a failed binlog dump
request
、Waiting to reconnect after a
failed master event read
、Writing to
net
、allocating local
table
、cleaning
up
、closing
tables
、converting HEAP to
MyISAM
、copy to tmp
table
、creating
table
、deleting from main
table
、deleting from reference
tables
、discard_or_import_tablespace
、end
、freeing
items
、got handler
lock
、got old
table
、info
、init
、insert
、logging
slow
query
、login
、preparing
、purging
old relay logs
、query
end
、removing tmp
table
、rename
、rename
result
table
、reschedule
、setup
、starting
slave
、statistics
、storing
row into queue
、unauthenticated
user
、update
、updating
、updating
main table
、updating reference
tables
、upgrading
lock
、waiting for
delay_list
、waiting for handler
insert
、waiting for handler
lock
、waiting for handler
open
、Waiting for event from
ndbcluster
最も一般的な State
値はこのセクションの残りの部分で説明されています。それ以外のほとんどの
State
値は、サーバ内のバグを見つける為にだけ役に立ちます。複製サーバのプロセス
ステートについての追加情報については、項5.5.1. 「レプリケーション実装の詳細」
も参照してください。
SHOW PROCESSLIST
ステートメントに対しては
State
の値は NULL
です。
Info
スレッドが実行中のステートメント、または、もしそれがステートメントを何も実行していなければ
NULL
になります。
SHOW PROCESSLIST
からのアウトプット内で主に見られるいくつかの
State
値
Checking table
スレッドがテーブル チェック操作を行っています。
Closing tables
スレッドが変更されたテーブル データをディスクにフラッシュしている、そして使用されたテーブルを閉じているという意味です。この操作スピードは早いでしょう。もし速くなければ、ディスクがフルではないという事と、ディスクがそれほど頻繁に使用されていないという事を証明しなければいけません。
Connect Out
複製スレーブはそのマスタに接続しています。
Copying to group table
もしステートメントが異なる ORDER
BY
と GROUP BY
基準を持っていたら、行はグループによってソートされ、テンポラリ
テーブルにコピーされます。
Copying to tmp table
サーバはメモリ内のテンポラリ テーブルにコピーしています。
Copying to tmp table on disk
サーバはディスク上のテンポラリ
テーブルにコピーしています。テンポラリ結果セットは
tmp_table_size
よりも大きく、スレッドはメモリを保存する為にテンポラリ
テーブルをイン メモリからディスク
ベース フォーマットに変更しています。
Creating tmp table
スレッドはクエリに結果の一部を保持する為にテンポラリ テーブルを作成しています。
deleting from main table
サーバは複合テーブル削除の最初の部分を実行しています。最初のテーブルからの削除だけを行い、別の(参照)テーブルからの削除に利用されるフィールドとオフセットを保存しています。
deleting from reference tables
サーバは複合テーブル削除の2番目の部分を行っており、別のテーブルから一致したテーブルを削除しています。
Flushing tables
スレッドは FLUSH TABLES
を実行しており、全てのスレッドがそのテーブルを閉じるのを待っています。
FULLTEXT initialization
サーバは自然言語フル テキスト サーチを行う準備をしています。
停止する
誰かがスレッドに KILL
ステートメントを送り、そして次にキル
フラッグを見つけた時異常終了するはずです。そのフラッグは
MySQL
内の主要な各ループ内で確認されますが、場合によってはスレッドが停止するまでに少し時間がかかる場合があります。もしスレッドが別のスレッドにロックされていると、停止作業は別のスレッドがそのロックを解除するとすぐに効果を発揮します。
Locked
クエリは別のクエリによってロックされています。
Sending data
スレッドは SELECT
ステートメントの為に行を作成し、また、クライアントにデータを送っています。
Sorting for group
スレッドは GROUP BY
を満足させる為にソートを行っています。
Sorting for order
スレッドは ORDER BY
を満足させる為にソートを行っています。
Opening tables
スレッドはテーブルをオープンしようと試みています。この操作は、何かにオープンを邪魔されない限り、スピードが速いはずです。例えば、ALTER
TABLE
か LOCK TABLE
ステートメントは、そのステートメントが終了するまでテーブルのオープンを邪魔する事ができます。
Reading from net
サーバはネットワークからパケットを読み込んでいます。
Removing duplicates
クエリは、MySQL
が早い段階で独特な操作を最適化する事ができなくなるような方法で
SELECT DISTINCT
を利用していました。この為、MySQL
は結果をクライアントに送る前に全ての複製行を削除する為の特別な段階を必要とします。
Reopen table
スレッドはテーブルの為にロックを得ましたが、その後基礎となるテーブル構造が変更された事に気が付きました。それはロックを解除し、テーブルを閉じ、そして再度オープンしようとしています。
Repair by sorting
修復コードはインデックスを作成する為にソートを利用しています。
Repair with keycache
修復コードはキー
キャッシュを通してキー作成を1つ1つ利用しています。これは
Repair by sorting
と比べるとかなり遅い作業です。
Searching rows for update
スレッドは、全ての一致する行を更新する前にそれらを見つける為の第一段階を行っています。もし
UPDATE
が、関連する行を見つける為に利用されたインデックスを変更していれば、これが行われなければいけません。
Sleeping
スレッドは新しいステートメントをスレッドにに送る為のクライアントを待っています。
statistics
サーバはクエリ実行計画を開発する統計を計算しています。
スレッドは、テーブルの為の外部システム
ロックを得るのを待っています。もし同じテーブルにアクセスする複数の
mysqld
サーバを利用していなければ、--skip-external-locking
オプションを利用してシステム
ロックを無効にする事ができます。
unauthenticated user
クライアント接続への関連はしたが、そのクライアント ユーザの認証はまだ行われていないスレッドの状態。
Upgrading lock
INSERT DELAYED
ハンドラは行を挿入する為に、テーブルにロックを得ようとしています。
Updating
スレッドは更新する行を探していて、それらを更新しています。
updating main table
サーバは複合テーブル更新の最初の部分を実行しています。最初のテーブルの更新だけを行い、別の(参照)テーブルの更新に利用されるフィールドとオフセットを保存しています。
updating reference tables
サーバは複合テーブル更新の2番目の部分を行っており、別のテーブルから一致したテーブルを更新しています。
User Lock
スレッドは GET_LOCK()
上で待っています。
Waiting for event from ndbcluster
サーバは MySQL クラスタ内の SQL ノードとして機能しており、クラスタ管理ノードに接続されています。
Waiting for tables
スレッドは、テーブルの基礎構造が変更され、その新しい構造を得る為にテーブルを再度オープンしなければいけないという通知を受け取りました。しかし、テーブルを再度オープンするには、他の全てのスレッドが問題になっているテーブルを閉じるまで待たなければいけません。
もし別のスレッドが FLUSH
TABLES
か、次にある問題のテーブル上のステートメントの中のひとつを利用すると、この通知が出されます。FLUSH
TABLES
、tbl_name
ALTER
TABLE
、RENAME
TABLE
、REPAIR
TABLE
、ANALYZE
TABLE
、または OPTIMIZE
TABLE
waiting for handler insert
INSERT DELAYED
ハンドラは全ての未解決の挿入を処理し、新しい物を待っています。
Writing to net
サーバはネットワークにパケットを書き込んでいます。
ほとんどのステートが大変速い操作に対応します。もしスレッドがこれらのステートのどれかに何秒間も留まれば、調査が必要な問題があるかもしれません。