私の歴史と今

振り返ると恥ずかしくなるのが私の歴史。だけどそのときは真面目に書いていた訳でね。そんな今の私を書いていく。

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".」

http://stackoverflow.com/questions/10347193/what-does-it-mean-when-mysql-is-in-the-state-sending-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日放置しておくと、動作がもっさりしてくる。違う事象だった。何なんだこれは。