読者です 読者をやめる 読者になる 読者になる

CubicLouve

Spring_MTの技術ブログです。https://github.com/SpringMT (http://spring-mt.tumblr.com/ からの移転)

MySQL 5.6から導入されたoptimizer_traceを使ってみる

mysql

きっかけは下のブログ

rkmathi.hatenablog.com

実際に使われるindexはSQLオプティマイザがコスト計算した結果で変わると思われる。

http://dbstudy.info/files/20120310/mysql_costcalc.pdf

コスト計算の結果は、MySQL 5.6から導入されたoptimizer_traceを使えば分かります。(多分)

MySQL :: MySQL 5.6 リファレンスマニュアル :: 21.11 INFORMATION_SCHEMA OPTIMIZER_TRACE テーブル

optimizer_traceはset optimizer_trace='enabled=on';でonにできる。

mysql>  show variables like 'optimizer_trace';
+-----------------+--------------------------+
| Variable_name   | Value                    |
+-----------------+--------------------------+
| optimizer_trace | enabled=off,one_line=off |
+-----------------+--------------------------+
1 row in set (0.00 sec)

mysql> set optimizer_trace='enabled=on';
Query OK, 0 rows affected (0.00 sec)

mysql>  show variables like 'optimizer_trace';
+-----------------+-------------------------+
| Variable_name   | Value                   |
+-----------------+-------------------------+
| optimizer_trace | enabled=on,one_line=off |
+-----------------+-------------------------+
1 row in set (0.01 sec)

optimizer_traceの結果はSELECT * FROM information_schema.OPTIMIZER_TRACE; で取得できる。

上記ブログのテーブルを少し行数を減らしてEXPLAINした時の、optimizer_traceの結果を比べてみた。

Using index conditionとなる場合

gist03a9f09fb154cf24442a

table_scanのコストが101258。

idx_datetimeを使ったコストが100671。

Using whereとなる場合

gistaa3e50cbf1a9563aa95f

table_scanのコストが101258。

idx_datetimeを使ったコストが109235。

table_scanのコストの方が低くなっているのがわかる。

SideCIの自動rubocop PRが羨ましかったので、自分で作った

ruby

blog-ja.sideci.com

これを見て。

SideCIはGitHub Enterpriseに対応していない(2016/02/13現在)ので、自分で作った。

github.com

サーバー上げて、githubweb hookに仕込むだけでPRを送ったら、自動的にrubocopで自動修正した内容を別PRにして送ってくれます。

こんな感じ f:id:Spring_MT:20160214011516p:plain

以前にhoundを導入したが、吠えるだけだとうざいだけになるので、今回は噛み付いてみました。

今は単純にrackupで動かして様子見しています。

突貫で愚直に書いたツールなので、コードがイマイチなのはご容赦を。。。

MySQL 5.6でロックの状態を詳細に見たい場合

mysql

innodb_lock_monitorを有効にする

有効にする場合

CREATE TABLE innodb_lock_monitor (a INT) ENGINE=INNODB;

そして、

SHOW ENGINE INNODB STATUS;

と打てば、TRANSACTIONSのセクションの中に、ロックの詳細情報が入るようになる。

終わったら、テーブルを落とす。

DROP TABLE innodb_lock_monitor;

項目

TRANSACTIONの項目をみてみる

サンプルのテーブル

CREATE TABLE `test_lock` (
  `id` bigint(20) unsigned NOT NULL,
  `count` tinyint(3) unsigned DEFAULT 0,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

試したSQL

UPDATE test_lock SET count = count +1 WHERE id IN (3,13);

結果

TABLE LOCK table `test`.`test_lock` trx id 19883768 lock mode IX

これは、lock mode IX(インテンション排他ロック)というテーブルロックがかかっている。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.2.3 InnoDB のロックモード

RECORD LOCKS space id 64731 page no 3 n bits 88 index `PRIMARY` of table `test`.`test_lock` trx id 19883768 lock_mode X locks rec but not gap

このケースでは、locks rec but not gap -> レコードロック、ギャップロックではない。

ロックは、

Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 8; hex 0000000000000003; asc         ;;
 1: len 6; hex 0000012f66f8; asc    /f ;;
 2: len 7; hex 040000034d2a36; asc     M*6;;
 3: len 1; hex 02; asc  ;;

Record lock, heap no 8 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 8; hex 000000000000000d; asc         ;;
 1: len 6; hex 0000012f66f8; asc    /f ;;
 2: len 7; hex 040000034d2a5a; asc     M*Z;;
 3: len 1; hex 02; asc  ;;

2015年おせち料理

料理

2014年に引き続きおせち作りました。

買い出しは一週間前から開始しています。

完成品はこちら

f:id:Spring_MT:20160103000404j:plain

なると、かまぼこ、栗きんとん、酢だこは既成品です。

松前漬

スルメイカ 3枚
昆布 スルメと同量くらい
人参 1/2本

たれ
酒 300cc
醤油(関東濃い口) 150cc
みりん 150cc

30日

  1. 酒 300cc、醤油 150cc、みりん 150ccを火にかけひと煮立ちさせて冷ましておく
  2. スルメイカ、昆布はそのままキッチンバサミで5mm幅程度に切っておく(ここは適当)
  3. 人参は千切りにしておく
  4. 上記を全部混ぜる
  5. 半日位で混ぜなおす
  6. 出来上がり

今回は31日に味付き数の子をいれた。

最終的な出来栄え

美味しかった。

来年もこのレシピでいく。

黒豆

黒豆 250g

煮汁
砂糖 170g
水 800c
醤油(薄口醤油) 大さじ 1
塩 小さじ半分

29日

  1. 煮汁を合わせておいて、沸騰させる
  2. 黒豆を流水で洗う(やさしく洗う!皮がむけてしまう)
  3. 沸騰したら火を止めて、すぐに黒豆を投入
  4. 一晩寝かせる

30日

  1. 圧力鍋で20分火を入れる(今回は強でかけた)

今回は20分以上強で圧力をかけてしまっていて柔らかくなりすぎた。

最終的な出来栄え

美味しかったが、少し柔らかかった。 もしかしたら15分くらい圧力かけて、あとで煮込んで調整してもよいかも。

田作り(去年とは違うレシピ)

田作り 50g位(ライフで買った。一袋まるまる入れた)

たれ
水 大さじ2
砂糖 大さじ2
醤油(九州 甘口) 大さじ1 + 1/2
みりん 大さじ1

31日

  1. 田作りをかりかりになるまで煎る(電子レンジで一分) -> 冷やす
  2. たれを中火にかけて、とろみがつくまで煮込む
  3. たれができたら、煎った田作りをいれてあえる
  4. バットに広げて冷ます

最終的な出来栄え

美味しかった。 前回に比べて、砂糖を多めに入れた結果、甘さがちょうど良くなった。 電子レンジで煎ると臭くなるので要注意

なます

大根 1/2本(細いのだった)  
人参 1/3本

たれ
米酢 100cc
砂糖 大さじ3
だし 100cc

31日

  1. 大根と人参を千切りにする
  2. 千切りにした大根と人参を塩を振って水出しする
  3. 水がでたら、よく絞る
  4. たれを混ぜて完了

色どり的に 大根 3: 人参 1 がよい。

今回水出し忘れて、二回たれにつけている。

最終的な出来栄え

普通。

まあ、来年も同じようなレシピで。

お煮しめ

里芋 小ぶりなものが12個位
ごぼう 1本
人参 2/3本
こんにゃく 一枚
しいたけ 8個
たけのこ 穂先だけのを4つ
蓮根 2ブロックくらい
豆腐 一丁(厚揚げにした)

味付け用調味料
だし3カップ半
醤油(薄口) 大さじ4
醤油(濃い口) 大さじ1
酒 大さじ3
砂糖 大さじ2
みりん 大さじ1
塩 小さじ1/2

人参につける出汁
だし カップ1
砂糖 小さじ1
塩 1つまみ

26日くらい

  1. 里芋を洗わずに皮をむいて、洗って半分にして下茹で
  2. 冷凍

30日

  1. しいたけを水でもどしておく
  2. 蓮根の皮むき、飾り切り、酢水(深皿に水入れて、お酢を垂らす程度)につけておく
  3. ごぼうの皮むきして、蓮根とごぼうを下茹で(10分位)
  4. 人参を飾り切りして、塩入れて下茹で(10分くらい)
  5. 人参の出汁を沸騰させて、粗熱をとっておく
  6. ゆでた人参を人参の出汁に浸けて冷蔵庫にいれておく
  7. だし3カップ半で人参以外の具材を10分炊く
  8. 出汁味付け用調味料を入れて更に15分炊く

絹さやがあったら、人参と同じように下茹でして使う

最終的な出来栄え

普通

ニシンの昆布巻き

身欠きにしん 10本(そのうち8本を使った)
日高昆布 10枚(昆布はすぐにもどるのでにしんの量に合わせてもどせばよい)
かんぴょう 適量

だし
昆布戻し汁3カップ〜3と1/2カップ
米酢 大さじ2
酒 1/2カップ

たれ
砂糖 大さじ4(きび砂糖のほうがよさそう)
本みりん 大さじ2(後で大さじ2程度追加)
しょうゆ 大さじ3(後で大さじ3程度追加)

28日(晩から)

  1. 身欠きにしんを米と昆布と一緒に水につける

29日(晩)

  1. 水を替えておく

30日

  1. 昆布は表面の汚れをさっと拭き取り、3〜4カップの水で戻す。柔らかく巻けるくらいになればよい。戻しすぎない。
  2. かんぴょうはさっと洗い、塩でもんで5分くらい水につけて戻しておく。これも戻しすぎないように。
  3. 昆布でにしんを巻き、昆布の幅に応じてかんぴょうを2〜3ヶ所、2巻きして結ぶ。(かんぴょうはゆるめに巻く。)
  4. 圧力鍋に巻いた昆布を隙間なく並べ、だしの材料を入れて蓋をする。火にかけ、沸騰したら中火にし、12分圧力をかけ、火を止める。
  5. 圧が下がったらふたを開け、たれを加え、弱火で約20分煮含める。焦げないように注意

そもそも、半量のレシピを参考にして、そのままの調味料の量で味付けしたため、最初味が薄かった。

後で、醤油、みりんで味を整えた。

最終的な出来栄え

もうすこし甘くてもよかったかと。

砂糖も二倍量入れれば、ちょうどよかったかなと。

海老の旨煮

甘エビはふるさと納税でGETしました。

www.furusato-tax.jp

甘エビ(有頭) 8尾

たれ
だし 100cc(水でも可)
白出汁 小さじ1 (http://www.amazon.co.jp/%E3%83%95%E3%83%B3%E3%83%89%E3%83%BC%E3%82%AD%E3%83%B3-%E7%99%BD%E3%81%A0%E3%81%97-1000mL/dp/B008ZWP55A)
みりん 大さじ1
酒 大さじ1
醤油 大さじ2
  1. 海老の下ごしらえをする(背わた、ひげを取る)
  2. 鍋にたれを入れ中火にかける。沸騰したら火を弱める。 1.エビを入れる。時々ひっくり返しながら、中火で4~5分煮る。
  3. 冷やして完成(冷やしている時に、味が染み込む。)

最終的な出来栄え

普通 来年は甘エビじゃなくて、車海老にしようかな。。(赤の出方と、ボリューム感で)

伊達巻

家の玉子焼き器で二枚分くらいのレシピ

ハンペン 1枚(80g)
玉子4個

たれ
みりん 小さじ1(よりちょっと多めくらい)
砂糖 大さじ2
塩 少々
麺つゆ(3倍濃縮) 小さじ1と1/2
だし 60 cc位いれたかな
醤油 少々
  1. 卵を4つ割り入れる
  2. フードプロセッサー(ナイフカッター使用)に、卵、ハンペン(手でちぎる程度でOK)、たれをいれて一分程度ミキサーにかける
  3. アルミホイルで蓋を作っておく
  4. 玉子焼き器(テフロン加工したやつ)に卵を流し込む(だいたい半分位をいれる)
  5. 強火で10秒かけた後に、アルミホイルの蓋をかぶせて弱火で10分位火にかける(匂いでこげていそうだったら)
  6. 表側が少し凸凹でもきにしない。あまりにも火が通っていない感じがしたらひっくり返す(最終手段、火を入れちゃうと出汁のジュワッと感がへります。)
  7. 鬼簾がないので、普通のすだれで巻いた。

最終的な出来栄え

伊達巻は最高だった

食べた感じの、出しがいい感じに染み出てくる感と、甘さがちょうど良かった。

にしんの甘露煮

身欠きにしん 2本

水 1 + 1/2カップ
酒 1/2カップ

たれ
砂糖 大さじ3
しょうゆ 大さじ2
みりん 大さじ1
  1. 昆布巻き用に戻した、身欠きにしんを使う。
  2. 鍋に水と酒とにしんを入れて火にかける。煮立ったら弱めの中火にし、ホイルなどで落としぶたをして10分煮る。
  3. たれを入れてとろみが付くまで煮込む。(だいたい20分くらい)

最終的な出来栄え

美味しかった。 年越しそばに添えました。

f:id:Spring_MT:20160103151043j:plain

数の子のからしマヨネーズ和え

数の子はふるさと納税でGET。

数の子(味付き) 適量
マヨネーズ 適量
和からし 少々
  1. 数の子、マヨネーズ、和からしを混ぜて完了

最終的な出来栄え

おつまみとしてはよい。

来年への課題

きび砂糖を買っておく。 重箱を買っておく。 緑をうまい具合に入れる。

nginxのconfの内容をdumpする

nginx

nginxのconfですが、includeとか大量にしていると、うっかり上書きされててハマったことないですか?

自分は最近ドハマりして、イラッとして、confをdumpできるようにならなかと調べてみました。

で、最新のnginxのソースcloneして読んでたらもうあるじゃんと思ったのですが、 自分のマシンに入ってたnginx(1.6.2)にないので、調べてみたら20150/05/15に入った変更だったのですね。。。

github.com

で、1.9.3を手元でコンパイルして試してみました。

nginxのコマンドオプションに-Tが追加されて、これを使うと、confファイルが吐出されるようになります。

# /foo/bar/nginx-1.9.3/objs/nginx -h
nginx version: nginx/1.9.3
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]

Options:
  -?,-h         : this help
  -v            : show version and exit
  -V            : show version and configure options then exit
  -t            : test configuration and exit
  -T            : test configuration, dump it and exit
  -q            : suppress non-error messages during configuration testing
  -s signal     : send signal to a master process: stop, quit, reopen, reload
  -p prefix     : set prefix path (default: /usr/local/nginx/)
  -c filename   : set configuration file (default: conf/nginx.conf)
  -g directives : set global directives out of configuration file

dumpされる内容はこんな感じ。

# configuration file /nginx.conf:
include ../hoge.conf;
worker_processes 8;

events {
    accept_mutex off;
    worker_connections 8192;
    use epoll;
}

http {
    server_names_hash_bucket_size 64;
    upstream hoge {
        server 127.0.0.1:3000;
    }

    server {
        include ../hoge1.conf;
        listen 80;
        client_max_body_size 500M;
        location / {
            proxy_pass http://hoge;
        }
        keepalive_timeout 5;
        keepalive_requests 5;
    }
}

# configuration file ../hoge.conf:
pid                   /var/run/nginx.pid;
user                  nginx;
worker_rlimit_nofile  65535;

# configuration file ../hoge1.conf:
include           ../mime.types;
default_type               application/octet-stream;

gzip                       on;


# configuration file ../mime.types:

types {
    text/html                             html htm shtml;
    text/css                              css;
    text/xml                              xml;
    image/gif                             gif;
    image/jpeg                            jpeg jpg;
    application/x-javascript              js;
    application/atom+xml                  atom;
    application/rss+xml                   rss;
}

とりあえずconfファイルを出すだけなのか。。。

ネストされている、confも全部だしてくれます。

includeされたファイルを反映させて、最終的に適用される値が出てくるわけではないので、もう一工夫いるなあ。

workerの枯渇状況が分かるrack-server_statusというgemを書いています

ruby

unicornのwokerのbusy数とidle数の比率がわからなくて、うっかりworkerが枯渇して大変なことになったので、workerの状況を返すエンドポイントを追加するrackミドルウェアを書いています。

github.com

ぶっちゃけkazeburoさんのPlack-Middleware-ServerStatus-Liteのruby版です。

github.com

この中で使っているkazuhoさん製のParallel-Scoreboardも移植しました。(まだREADMEがない。。。)

github.com

元は下記です。

github.com

Kazuho@Cybozu Labs: Parallel::Scoreboard でワーカープロセスをモニタリングする方法

使い方

config.ruに下記の用に書く。

# In config.ru
use Rack::ServerStatus, scoreboard_path: './tmp'

それでrackサーバーを立ち上げるて、/server-statusというエンドポイント叩くと、workerの状態を返してくれます。(jsonでも返すように指定できます。)

% curl http://server:port/server-status
Uptime: 1432227723 (12 seconds)
BusyWorkers: 1
IdleWorkers: 3
--
pid status remote_addr host method uri protocol ss
55091 _  -    0
55092 _  -    1
55093 A 127.0.0.1 localhost:3000 GET /server-status HTTP/1.1 0
55094 _  -    0

# JSON format
% curl http://server:port/server-status?json
{"Uptime":1432388968,"BusyWorkers":1,"IdleWorkers":3,"stats":[{"remote_addr":null,"host":"-","method":null,"uri":null,"protocol":null,"pid":87240,"status":"_","ss":2},{"remote_addr":"127.0.0.1","host":"localhost:3000","method":"GET","uri":"/server-status?json","protocol":"HTTP/1.1","pid":87241,"status":"A","ss":0},{"remote_addr":null,"host":"-","method":null,"uri":null,"protocol":null,"pid":87242,"status":"_","ss":3},{"remote_addr":null,"host":"-","method":null,"uri":null,"protocol":null,"pid":87243,"status":"_","ss":3}]}

まだ、本番環境に投入していないですが、もうそろそろ投入予定です。

投入してみて、運用実績ができたらまた報告します。

2015/06/30 本番に投入して様子見中

サーバーの状態やMySQLの状態の指標のまとめ

指標に関していつもググってばっかりいたので、まとめてみました。

ツッコミ大歓迎。

CPU usage

name detail
User ユーザ空間(アプリケーション)でCPUが使われた時間の割合
Nice 優先度を変更された(nice値が変更された)プロセスにより、ユーザ空間でCPUが使われた時間の割合
System カーネル空間でCPUが使われた時間の割合
Idle CPUが何も処理をせずに待機していたCPUの時間の割合(ディスクI/O待ち以外)
Wait(iowait) CPUがディスクI/O、またはネットワークI/Oの結果を待っていた時間の割合(I/O処理中で、その終了を待機している時間)
Intr 割り込み
SoftIRQ ソフト割り込み
Steal 仮想サーバがCPUを使って待たされていた時間の割合

suusuke - blog - サーバが重い時の負荷の正体を突き止める

hiboma/Linuxカーネル解読室-3-1.md at master · hiboma/hiboma · GitHub

Memory Usage

name detail
used 使用している物理メモリ量
buffer ファイルなどのメタデータをキャッシュしている物理メモリ量
cached ページキャッシュに使用されているメモリ量
avail real 利用可能な物理メモリの量
total real 総物理メモリの量
used swap Swap領域で使用している量

cached も buffers も空きメモリの一部 状況に応じてflushされる

Nginx

name detail
Reading nginxはリクエストヘッダーを読み込んでいる数
Writing nginxはリクエストボディーを読み込んでいる、リクエストを処理中、またはクライアントへ返信している数。upstreamから結果を受け取ってクライアントに返し中なのか、upstreamからの回答待ちであるかが区別されてないっぽいのが困る。
Waiting リクエスト処理を待っているクライアントのコネクション数 (idle client connections waiting for a request.) keep-aliveの接続数

HttpStubStatusModule - Nginx Community

MySQL

MySQL Threads

name detail
Cached キャッシュされているスレッド数(スレッドは使いまわされる)
Connected 現在の接続数
Running スリープ状態になっていないスレッドの数

Threads_created 接続を処理するために生成されたスレッド数(この値が増えまくるなら、cached が足りていない)

Threads_cached + Threads_connected が thread_cache_sizeの値より小さければ想定内。

MySQLのスレッドとか接続数とか - @bayashi Wiki

MySQL Processlist

name detail
State Closing Tables 変更されたテーブルデータをディスクにフラッシュし、使用されたテーブルを閉じているスレッド数
State Copying To Tmp Tables メモリー内の一時テーブルにコピーしているスレッド数
State End ALTER TABLE、CREATE VIEW、DELETE、INSERT、SELECT、または UPDATE ステートメントの最後、ただしクリーンアップの前に発生しまる状態のスレッド数
State Freeing Items コマンドの実行を完了したスレッド数、通常、この状態のあとは cleaning up になります
State Init ALTER TABLE、DELETE、INSERT、SELECT、または UPDATE ステートメントの初期化の前に発生する状態のスレッド数
State Locked 別のクエリーによってロックされているスレッド数
State Login クライアントが正常に認証されるまでの初期状態のスレッド数
State Reading From Net ネットワークからパケットを読み込んでるスレッド数
State Sending Data SELECT ステートメントのために行を作成し、また、クライアントにデータを送っているスレッド数
State Sorting Result
State Statistics クエリー実行計画を開発する統計を計算しているスレッド数
State Updating 更新する行を探していて、それらを更新しているスレッド数
State Writing To Net ネットワークにパケットを書き込んでいるスレッド数
State None Stateのないスレッド数 例えば SLEEP中のスレッド
State Other

MySQL :: MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 4.5.6.2 一般的なスレッド状態

MyISM Indexes

name detail
Key Read Requests
Key Reads
Key Writes Requests
Key Writes

MySQL Handlers

クエリの I/O 動作

name detail
Handler Write INSERTの回数
Handler Update UPDATEの回数
Handler Delete DELETEの回数
Handler Read First テーブルやインデックスの全件検索(インデックスフルスキャン)の際にまず最初に先頭レコードの取得するが、その回数。フルスキャンが多いとこの回数が増える。(要チューニング)
Handler Read Key インデックスに基づく読み込み回数。これが多い場合は適切にインデックスが貼られている。
Handler Read Next インデックスに基づいて行を特定した後、後続の行を読んだ回数。範囲指定のインデックススキャンの場合に増えます。
Handler Read Prev インデックスに基づいて行を特定した後、その前の行を読んだ回数。範囲指定のインデックススキャンの場合に増えます。
Handler Read Rnd 固定位置に基づくレコード読んだの回数(handler::rnd_pos()が呼ばれた回数)。固定位置に基づくレコードの読み込みとは、Random Readのこと。結果のソートを必要とするクエリを多く実行すると、この値が大きくなる。(要チューニング)
Handler Read Rnd Next データファイルでの次のレコードを読み取った回数。 テーブルスキャンが多く実行されると、この値が大きくなる。(要チューニング)

www.percona.com

MySQL Select Types

name detail
Select Full Join インデックスのないカラムで JOINした回数
Select Full Range Join 範囲指定の効果はあるがインデックスは使わず JOINした回数
Select Range WHERE などの指定によって範囲が限定された探索を行った回数
Select Range Check インデクッスなしのJOIN数
Select Scan テーブル(またはインデックスでも)の先頭行から全件検索(スキャン)をした回数

JOINに関してはEXPLAINしてtypeがeq_refになるようにする。

MySQL Sorts

name detail
Sort Rows ソートしたレコード数
Sort Range 範囲検索ソートの回数
Sort Merge Passes ソートで必要としたマージパスの回数
Sort Scan テーブルスキャンでソートした回数

MySQL Temporary Objects

name detail
Created Tmp Tables 作成した一時テーブルの数
Created Tmp Disk Tables ディスク上に作成した一時テーブルの数
Created Tmp Files 作成した一時ファイルの数

sort_buffer_sizeを超える大きなORDER BYなどで作成される。

漢(オトコ)のコンピュータ道: Using filesort

MySQL Transaction Handle

name detail
Handler Commit コミットの要求数
Handler Rollback ロールバックの要求数
Handler Savepoint セーブポイントの要求数
Handler Savepoint Rollback セーブポイントロールバックの要求数

Cache hit rate

name detail
key cache
query cache
table lock immediate
thread cache
tmp table on memory

Dirty page rate

Buffer Pool Activity

name detail
Page Created 作成されたページの数
Page Read 読み込まれたページの数
Page Written 書き込まれたページの数

Checkpoint Age

Current Lock Wait

トランザクションのロック開放待ち時間の合計秒数

InnoDB I/O

InnoDB I/O Pending

Lock Structures

開放まちLock structの数

InnoDB Log

name detail
Innodb Log Buffer Size ログバッファのサイズ
Log Byte Written ログに書き込まれたデータ量
Log Byte Flushed ロクから書き出されたデータ量
Unflushed Log ログから書き出されていないデータ量

Row Lock Time

行ロック獲得のための所用総時間(msec)

Row Lock Waits

行ロック獲得待機回数

InnoDB Tables In Use

name detail
InnnoDB Tables In Use 実行中のトランザクションが利用しているテーブル数の合計数
InnnoDB Locked Tables 実行中のトランザクションがロックしているテーブル数の合計数

InnoDB Transactions

name detail
InnnoDB Transactions 生成されたトランザクション
History List undo領域にある未破棄のトランザクション

参照