SideCIの自動rubocop PRが羨ましかったので、自分で作った
MySQL 5.6でロックの状態を詳細に見たい場合
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年に引き続きおせち作りました。
買い出しは一週間前から開始しています。
完成品はこちら
なると、かまぼこ、栗きんとん、酢だこは既成品です。
松前漬け
スルメイカ 3枚 昆布 スルメと同量くらい 人参 1/2本 たれ 酒 300cc 醤油(関東濃い口) 150cc みりん 150cc
30日
- 酒 300cc、醤油 150cc、みりん 150ccを火にかけひと煮立ちさせて冷ましておく
- スルメイカ、昆布はそのままキッチンバサミで5mm幅程度に切っておく(ここは適当)
- 人参は千切りにしておく
- 上記を全部混ぜる
- 半日位で混ぜなおす
- 出来上がり
今回は31日に味付き数の子をいれた。
最終的な出来栄え
美味しかった。
来年もこのレシピでいく。
黒豆
黒豆 250g 煮汁 砂糖 170g 水 800c 醤油(薄口醤油) 大さじ 1 塩 小さじ半分
29日
- 煮汁を合わせておいて、沸騰させる
- 黒豆を流水で洗う(やさしく洗う!皮がむけてしまう)
- 沸騰したら火を止めて、すぐに黒豆を投入
- 一晩寝かせる
30日
- 圧力鍋で20分火を入れる(今回は強でかけた)
今回は20分以上強で圧力をかけてしまっていて柔らかくなりすぎた。
最終的な出来栄え
美味しかったが、少し柔らかかった。 もしかしたら15分くらい圧力かけて、あとで煮込んで調整してもよいかも。
田作り(去年とは違うレシピ)
田作り 50g位(ライフで買った。一袋まるまる入れた) たれ 水 大さじ2 砂糖 大さじ2 醤油(九州 甘口) 大さじ1 + 1/2 みりん 大さじ1
31日
- 田作りをかりかりになるまで煎る(電子レンジで一分) -> 冷やす
- たれを中火にかけて、とろみがつくまで煮込む
- たれができたら、煎った田作りをいれてあえる
- バットに広げて冷ます
最終的な出来栄え
美味しかった。 前回に比べて、砂糖を多めに入れた結果、甘さがちょうど良くなった。 電子レンジで煎ると臭くなるので要注意
なます
大根 1/2本(細いのだった) 人参 1/3本 たれ 米酢 100cc 砂糖 大さじ3 だし 100cc
31日
- 大根と人参を千切りにする
- 千切りにした大根と人参を塩を振って水出しする
- 水がでたら、よく絞る
- たれを混ぜて完了
色どり的に 大根 3: 人参 1 がよい。
今回水出し忘れて、二回たれにつけている。
最終的な出来栄え
普通。
まあ、来年も同じようなレシピで。
お煮しめ
里芋 小ぶりなものが12個位 ごぼう 1本 人参 2/3本 こんにゃく 一枚 しいたけ 8個 たけのこ 穂先だけのを4つ 蓮根 2ブロックくらい 豆腐 一丁(厚揚げにした) 味付け用調味料 だし3カップ半 醤油(薄口) 大さじ4 醤油(濃い口) 大さじ1 酒 大さじ3 砂糖 大さじ2 みりん 大さじ1 塩 小さじ1/2 人参につける出汁 だし カップ1 砂糖 小さじ1 塩 1つまみ
26日くらい
- 里芋を洗わずに皮をむいて、洗って半分にして下茹で
- 冷凍
30日
- しいたけを水でもどしておく
- 蓮根の皮むき、飾り切り、酢水(深皿に水入れて、お酢を垂らす程度)につけておく
- ごぼうの皮むきして、蓮根とごぼうを下茹で(10分位)
- 人参を飾り切りして、塩入れて下茹で(10分くらい)
- 人参の出汁を沸騰させて、粗熱をとっておく
- ゆでた人参を人参の出汁に浸けて冷蔵庫にいれておく
- だし3カップ半で人参以外の具材を10分炊く
- 出汁味付け用調味料を入れて更に15分炊く
絹さやがあったら、人参と同じように下茹でして使う
最終的な出来栄え
普通
ニシンの昆布巻き
身欠きにしん 10本(そのうち8本を使った) 日高昆布 10枚(昆布はすぐにもどるのでにしんの量に合わせてもどせばよい) かんぴょう 適量 だし 昆布戻し汁3カップ〜3と1/2カップ 米酢 大さじ2 酒 1/2カップ たれ 砂糖 大さじ4(きび砂糖のほうがよさそう) 本みりん 大さじ2(後で大さじ2程度追加) しょうゆ 大さじ3(後で大さじ3程度追加)
28日(晩から)
- 身欠きにしんを米と昆布と一緒に水につける
29日(晩)
- 水を替えておく
30日
- 昆布は表面の汚れをさっと拭き取り、3〜4カップの水で戻す。柔らかく巻けるくらいになればよい。戻しすぎない。
- かんぴょうはさっと洗い、塩でもんで5分くらい水につけて戻しておく。これも戻しすぎないように。
- 昆布でにしんを巻き、昆布の幅に応じてかんぴょうを2〜3ヶ所、2巻きして結ぶ。(かんぴょうはゆるめに巻く。)
- 圧力鍋に巻いた昆布を隙間なく並べ、だしの材料を入れて蓋をする。火にかけ、沸騰したら中火にし、12分圧力をかけ、火を止める。
- 圧が下がったらふたを開け、たれを加え、弱火で約20分煮含める。焦げないように注意
そもそも、半量のレシピを参考にして、そのままの調味料の量で味付けしたため、最初味が薄かった。
後で、醤油、みりんで味を整えた。
最終的な出来栄え
もうすこし甘くてもよかったかと。
砂糖も二倍量入れれば、ちょうどよかったかなと。
海老の旨煮
甘エビはふるさと納税でGETしました。
甘エビ(有頭) 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.エビを入れる。時々ひっくり返しながら、中火で4~5分煮る。
- 冷やして完成(冷やしている時に、味が染み込む。)
最終的な出来栄え
普通 来年は甘エビじゃなくて、車海老にしようかな。。(赤の出方と、ボリューム感で)
伊達巻
家の玉子焼き器で二枚分くらいのレシピ
ハンペン 1枚(80g) 玉子4個 たれ みりん 小さじ1(よりちょっと多めくらい) 砂糖 大さじ2 塩 少々 麺つゆ(3倍濃縮) 小さじ1と1/2 だし 60 cc位いれたかな 醤油 少々
- 卵を4つ割り入れる
- フードプロセッサー(ナイフカッター使用)に、卵、ハンペン(手でちぎる程度でOK)、たれをいれて一分程度ミキサーにかける
- アルミホイルで蓋を作っておく
- 玉子焼き器(テフロン加工したやつ)に卵を流し込む(だいたい半分位をいれる)
- 強火で10秒かけた後に、アルミホイルの蓋をかぶせて弱火で10分位火にかける(匂いでこげていそうだったら)
- 表側が少し凸凹でもきにしない。あまりにも火が通っていない感じがしたらひっくり返す(最終手段、火を入れちゃうと出汁のジュワッと感がへります。)
- 鬼簾がないので、普通のすだれで巻いた。
最終的な出来栄え
伊達巻は最高だった
食べた感じの、出しがいい感じに染み出てくる感と、甘さがちょうど良かった。
にしんの甘露煮
身欠きにしん 2本 水 1 + 1/2カップ 酒 1/2カップ たれ 砂糖 大さじ3 しょうゆ 大さじ2 みりん 大さじ1
- 昆布巻き用に戻した、身欠きにしんを使う。
- 鍋に水と酒とにしんを入れて火にかける。煮立ったら弱めの中火にし、ホイルなどで落としぶたをして10分煮る。
- たれを入れてとろみが付くまで煮込む。(だいたい20分くらい)
最終的な出来栄え
美味しかった。 年越しそばに添えました。
数の子のからしマヨネーズ和え
数の子はふるさと納税でGET。
数の子(味付き) 適量 マヨネーズ 適量 和からし 少々
- 数の子、マヨネーズ、和からしを混ぜて完了
最終的な出来栄え
おつまみとしてはよい。
来年への課題
きび砂糖を買っておく。 重箱を買っておく。 緑をうまい具合に入れる。
nginxのconfの内容をdumpする
nginxのconfですが、includeとか大量にしていると、うっかり上書きされててハマったことないですか?
自分は最近ドハマりして、イラッとして、confをdumpできるようにならなかと調べてみました。
で、最新のnginxのソースcloneして読んでたらもうあるじゃんと思ったのですが、 自分のマシンに入ってたnginx(1.6.2)にないので、調べてみたら20150/05/15に入った変更だったのですね。。。
で、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を書いています
unicornのwokerのbusy数とidle数の比率がわからなくて、うっかりworkerが枯渇して大変なことになったので、workerの状況を返すエンドポイントを追加するrackミドルウェアを書いています。
ぶっちゃけkazeburoさんのPlack-Middleware-ServerStatus-Liteのruby版です。
この中で使っているkazuhoさん製のParallel-Scoreboardも移植しました。(まだREADMEがない。。。)
元は下記です。
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を使って待たされていた時間の割合 |
http://blog.suusuke.info/2011/10/24/365/
hiboma/Linuxカーネル解読室-3-1.md at master · hiboma/hiboma · GitHub
O'Reilly Japan - 詳解 システム・パフォーマンス
の 6.3.6
6.6.3
も合わせて参照
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の接続数 |
http://wiki.nginx.org/HttpStubStatusModule#stub_status
MySQL
変数の参照はここ
MySQL :: MySQL 5.6 リファレンスマニュアル :: 5.1.6 サーバーステータス変数
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 |
http://mysql.stu.edu.tw/doc/refman/5.1-olh/ja/general-thread-states.html
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 | データファイルでの次のレコードを読み取った回数。 テーブルスキャンが多く実行されると、この値が大きくなる。(要チューニング) |
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 の page のうち disk に flush されてない page の比率
ここが増加していると、diskへの書込みが追いついていない
https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos_dirty_page
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領域にある未破棄のトランザクション数 |
参照
mpstat
CPUごとの使用状況
-P ALL
ですべてのコアの情報を表示する
vmstat
unix domain socketのstatus
cat /proc/net/unixの中身
項目 | 説明 | 例 |
---|---|---|
Num | カーネルのテーブルスロット | ffff8800798ec0c0 |
RefCount | ソケットを使用しているユーザー数 | 00000002 |
Protocol | いまのところいつも 0 | |
Flags | ソケット の状態を保持しているカーネル内部のフラグ | |
Type | always '1' とかいてあるが2もある。。。 | 0001 |
St | ソケットの内部状態 | 01 02 03 https://github.com/torvalds/linux/blob/master/include/uapi/linux/net.h#L47 |
Inode | ||
Path | (もしあれば) ソケットのパス名 |