MySQLの「Sending data」はクライアントへのデータ転送ではない・・・
MySQLのshow processlistで「Sending data」と表示されている処理はデータ転送だと思っていたが、そうではなかった・・・。先入観って恐ろしい。
今日はサーバが重かったので調べてみたらすべてのコネクションが「Sending data」となっており、処理に3分以上かかっていた。slow queryのログを見ると「limit 1」の検索ばかり。転送なんてあっという間のはず。と思って調べてみたら「Sending data」はクライアントへのデータ転送ではなかった。
「This is quite a misleading status. It should be called "reading and filtering data".」
「データの読み込みとフィルタリング」ということだ。データを保存している場所を主語として「Sending data 」と表現しているのかな。わからないでもないけど、MySQLの処理なんだから誤解しやすい。
updated_atが更新されなくて困った話
「変更がなくてもupdated_atを強制的に更新して欲しい」というクライアントの要望に応えるためにwill_change!を使用したが、うまくいかない時があったのでメモ。
update!の前に、「在庫数が変更されるよ!」というフラグを立てる1行を追加した。
@zaiko.num_will_change! @zaiko.update!(zaiko_params)
しかし、updated_atは更新されない。変だなーと思ってrails consoleで調べてみたら、以下のようになった。
irb(main):080:0* z.num => 2 irb(main):081:0> z.num_will_change! => 2 irb(main):082:0> z.num_changed? => true irb(main):083:0> z.attributes = {:num=>2} => {:num=>2} irb(main):084:0> z.num_changed? => false
num_will_change!を使った後、そのnumを再設定してしまうと、以前のフラグが消えてしまい再度判定されてしまう。ということは、再設定される可能性がない属性に対してwill_change!をしなければならない。候補は、id, created_at, updated_atしかない。idは変な動きをされてしまうと嫌なので却下。まあ、ここはupdated_atを変更したいのだから、updated_at_will_change!を使うのが無難なのかな。ということで、採用したが、これがうまくいかない。というのも、updated文は実行されるが、前と同じ値が設定されてしまう。updated_atを明示的に設定したと判断されてしまうようだ。では、created_atを採用した場合はどうか、というと、この時に実行されるupdate文ではcreated_atも変更されてしまう。もちろん、変更前と同じ値なので無害ではあるのだけど、何だか気持ちが悪い。
ということで、結論は、updated_atを明示的に設定する!
@zaiko.updated_at = Time.now @zaiko.update!(zaiko_params)
なお、@zaiko.touchも考えたが、実際に変更があった場合は2回SQLが実行されることになるので却下した。
なおなお、save!の時は、save!前に属性の設定をしているから問題にならない。
# save!前に属性への設定 @zaiko.num_will_change! @zaiko.save!
vmware fusionが遅いから調べてみた
起動してしばらくは通常どおり動くのだけど、4時間くらいすると遅くて使い物にならない状態だった。このような症状はYosemiteに変更して、vmware fusion 8にした時くらいからで、私はvmwareのバージョンアップが影響していると思っていました。
そのため、毎日2回再起動していたという。。。よく我慢していたな。。。
ふと思い立って「vmware + fusion + yosemite + 遅い」で調べたら皆さん既に解決されていたようで、私も同様の方法で解決できました。
コンソール上で以下を実行してMacを再起動する。
$ sudo nvram boot-args="debug=0x10"
以下、設定を確認する方法。
$ sudo nvram boot-args boot-args debug=0x10
以下、設定を戻す方法。
$ sudo nvram -d boot-args
参考 Yosemite and Fusion 7 - Very Very Slow | VMware Communities
2015/04/26追記
改善された、というのは勘違いだった。。。やっぱり、1日放置しておくと、動作がもっさりしてくる。違う事象だった。何なんだこれは。