いろいろ遊んでいるうちに日付が変わってしまったけれど、きちんと発売日にゲットした。
先日予約したものを26日の午前中受け取りに町田のヨドバシまで。
契約カウンターは満席だったが中には予約無しの人もいたようで、その日にぶらりと行っても買えたようだ。
ただ黒の32GBは自分が係の人と話している間に品切れのアナウンスがあった。
ゲットするやいなやまっすぐ帰宅してそっこーアクティベート。
早速外に持ち出してみる。
やっぱり外でつながるのは便利だなあ。
それだけでも使い道が大幅に広がるし。
ほかにもカメラやらマイクやらGPSやらコンパスやらいろいろと。
できることたくさんで面白い。
てかコンパスカッコイイです。
touchとは面白さが一回り違うなあ。
もともと旅先とかの調べ物とかに使いたいと思っていたので、どんどん外に持ち出して使っていきたいところ。
あとなんか旅に役立つアプリとかできないかなーとか思ってます。
最近管理しているDBサーバで継続的にスロークエリが出るようになったので、チューニングしてみたら気持ちの良い結果が出た。
結論から言うとカラム数が多いテーブルに対しては:selectで取得するカラムを絞るのがかなり有効かと思う。
今回スロークエリの発生していたテーブルの状況を整理したのが以下。
スロークエリになっているのはもっぱら以下のクエリ。
select * from pages order by updated_at limit 100;Railsのコードで見るとこんなかんじ。
Page.all(:order => 'updated_at', :limit => 100)こんな単純なクエリが実行に2秒から10秒程度もかかってスロークエリとして記録されているのは切ない。
インデックスは効いているので問題解決には他のアプローチが必要になる。
考えるに対象は30以上カラムがあってレコードサイズもそこそこ大きいテーブル。
そこで取得するカラムを絞って余計なカラムを取得しないようにしてみたらどうかと思った。
というかクエリが単純すぎてまずはそれくらいしか浮かばなかったわけだけど。
計測なくしてチューニングなしということでベンチマークで使ったのはmybench。
ベンチマークとチューニングは手元の開発環境で実行した。
こちらレコード件数は3万件程度。本番環境より大幅に少ないが十分だろう。たぶん。
全カラム取得とカラムを絞った結果の比較が以下。
10クライアントから100回ずつ、計1000回のリクエストを送るというのを試行回数3回ずつ行った結果。
serialは経過時間（秒）です。
まずは全部まるごと取得している現状のクエリ。
select * from pages order by updated_at limit 100;
# Page.all(:order => 'updated_at', :limit => 100)
serial : 29.173278
serial : 29.433684
serial : 30.258237これを取得カラムを絞ったものにしてみると。
select id, updated_at from pages order by updated_at limit 100;
# Page.all(:select => 'id, updated_at', :order => 'updated_at', :limit => 100)
serial : 16.422306
serial : 17.562543
serial : 16.070013倍近く速くなった。
うつくしい。
いやぁ、チューニングって本当に気持ちがいいものですね。
これを本番環境にアップしたらスロークエリもパッタリなくなり幸せになれました。
select * from pages order by updated_at limit 100;
# Page.all(:order => 'updated_at', :limit => 100)
test: 1000 0.001631 0.060372 0.029173278 29.173278 342.779443571614
clients : 10
queries : 1000
fastest : 0.001631
slowest : 0.060372
average : 0.029173278
serial : 29.173278
q/sec : 342.779443571614
test: 1000 0.001535 0.06981 0.029433684 29.433684 339.746801657584
clients : 10
queries : 1000
fastest : 0.001535
slowest : 0.06981
average : 0.029433684
serial : 29.433684
q/sec : 339.746801657584
test: 1000 0.00298 0.065291 0.030258237 30.258237 330.488521191767
clients : 10
queries : 1000
fastest : 0.00298
slowest : 0.065291
average : 0.030258237
serial : 30.258237
q/sec : 330.488521191767
select id, updated_at from pages order by updated_at limit 100;
# Page.all(:select => 'id, updated_at', :order => 'updated_at', :limit => 100)
test: 1000 0.000327 0.037233 0.016422306 16.422306 608.927881382797
clients : 10
queries : 1000
fastest : 0.000327
slowest : 0.037233
average : 0.016422306
serial : 16.422306
q/sec : 608.927881382797
test: 1000 0.001182 0.050836 0.017562543 17.562543 569.393623691057
clients : 10
queries : 1000
fastest : 0.001182
slowest : 0.050836
average : 0.017562543
serial : 17.562543
q/sec : 569.393623691057
test: 1000 0.000301 0.04706 0.016070013 16.070013 622.277032383234
clients : 10
queries : 1000
fastest : 0.000301
slowest : 0.04706
average : 0.016070013
serial : 16.070013
q/sec : 622.277032383234
tags:activerecord MySQL Rails パフォーマンスチューニング | Permalink
2009-06-25
昨日XenのDomainUのひとつがいつの間にかRead-onlyになっていた。
とりあえずログを見ても原因がわからない。何らかのI/O負荷に伴うものだろうか。
muninのグラフを見ると障害の直前までに徐々に負荷が高まっている様子が確認できたので、なんとなく状況は把握。
この負荷が高まった原因については分かっているけど、すぐに対応できるものではないのでこちらはタスクに放り込んでスルーしておく。
止まっても緊急性のないサーバなのでのんびりと復旧を開始した。
しょっぱなから適当に最強の回復魔法を試してみたのだが撃沈。
どうもブートの途中でひっかかってしまって起動しなくなった。
起動時にfsckが走ることを期待したのだが、そこまでも行かないっぽい。
しかしながらXenのconsoleから確認するとディスクをマウントするところで止まっているっぽいので、やはりまずはfsckをかけたいところだ。
そこでDomain0からイメージファイルの中身を触って修復することにした。
まずディスクイメージをloopデバイスに割り当てる
これにはlosetupを使う。
# losetup /dev/loop0 /var/lib/xen/images/hoge.imgまだこの状態ではfsckかけてもext2じゃないよとか言われて動かないので更にパーティションごとにアクセスできるようにする。
# kpartx -a /dev/loop0これで/dev/mapper/以下にloop0p1からloop0p8までパーティションに応じたデバイスができるので、これらをfsckすることができるようになった。
# e2fsck -c -f /dev/mapper/loop0p1p4が欠番でp3はswapなのでスルーしてp1,p2,p5,p6,p7,p8を順にfsck。
p7とp8でいくつか不良ブロックが見つかったのでyを何回か押して修復完了。
最後に後始末しておしまい。
# kpartx -d /dev/loop0
# losetup -d /dev/loop0これで再度起動すると無事起動して動き出した。
素晴らしい。
個人的にiPhone熱の高まる梅雨のこの頃皆様いかがお過ごしでしょうか。
プログラマブルなガジェットって素敵ですよね。
というわけで本日町田のヨドバシにて予約して参りました。
iPhone 3G S。
モデルはブラックの32GB。
お昼ちょっと前に行ったら自分は20番目の予約者であった。
ブラック32GB希望者としては8番目だったようなので、ブラック32GBは割合的にかなり出ているようだ。
Wホワイトは強制加入だったけどすぐやめてかまわないと言うことだったので気にせず。
端末代金は一括で払うと10%ポイントがつくということだったので一括で払うことにした。
ちなみに町田のヨドバシでは予約順ごとに優先受け渡し時間というのが設けられていて、自分の場合は当日11:30から12:00の間に行くとあんまり待たずに受け渡しが完了するらしい。
そういうわけで当日は時間厳守でさくっとゲットしてこようと思います。
実は町田まで行かずとも自宅から歩いて10分くらいのところにソフトバンクのショップがある。
ので最初はそこに行った。
しかし料金とか契約の説明がたどたどしすぎて面白不安になったので町田まで足を伸ばした次第。
さすがに料金説明に「多分」とかつけるのはないわー。
「多分端末代金の支払いが月々3,300円くらいです。まだよくわかんないんですけど」
とか言われた気がする。それ君多分間違えてないかな。
料金説明の要領がかなり悪かったのでこっちが何かと勘違いしてたかもしれないけど。
「多分端末は値引きがあるんですけど、はっきりとしたことはまだ分からないです」
とかも言われたな。確か。
「パケット定額フルをフルに使うと5,985円になります。多分4,410円になると思うんですけど」
これは確実に言われた。
「多分」という言葉は好きだが使われると怖いときがあるのも事実。
そこで「多分」という言葉は聞きたくなかった。そこは「多分」であってほしくなかった。
いい言葉だが使いどころを間違えないようにしよう。
実はちょっと前にしてました。
今ではすっかりGitしか使わなくなってます。
移行の理由は世間の流行に乗って、という部分もあるのだけど主な理由はクライアントソフトの不在。
MacでいいGUIのSVNクライアントがなくて結局コマンドラインで使っているので、そんだったらGitでいいじゃんといったノリで移行。
WindowsだとTortoiseSVNがかなりいい感じだけど、Macではそれに匹敵する物が見つからなかったのが理由。
svnXはMacでもイマイチなUIなソフトはあるんだなー、と言う残念さ教えてくれたし、SCPluginは後一歩だったけどやや機能的に物足りず使い続けるには至らなかった。
人に何かいい物ないかと聞いてもコマンドライン派が多かったような気がする。
でコマンドラインでも使い始めてみれば実のところそんなに不便はなかったのだが、ただignoreするファイルの設定がいちいちめんどくさくて死にそうだった。
（svn propsetとかコマンドラインでやるもんじゃねえって個人的に思いました）
Gitは以前から実験的に触ったことはあったので移行は割とスムーズに。
ただsvnとrevertの意味が違うのでそこだけちょっと戸惑ったくらい。
リポジトリの移行も簡単で
$ sudo port install git-core +svn
とかでgit-svn込みのGitを入れて
$ git svn clone svn://hoge_repos/hoge_project/trunk hoge_by_git
これをリポジトリサーバ上ににまんまコピーするなり–bareオプションを付けてcloneするなりして完了。
さくっと移行できてしまった。
詳しいところはぐぐればたくさん出てくるので詳細は割愛。
しかし使い始めてみると分散管理の必要がなくてもGitは使いやすい。
ざっと思いつく限りでこんなかんじ。
サーバ上のリポジトリに縛られない軽快さが予想以上に良い。
あとはGUIのクライアントでいいものが出ればSubversionのアドバンテージはなくなってしまう気がするね。
tags:Git subversion | Permalink
2009-06-10
アプリケーションの開発に初めて取り組む人に。 やっといい本がでた。
iPhoneアプリ開発の最初のステップとしては現在最良の入門書だと思う。
分かりやすくていい本。
とにかく自分の作ったアプリがiPhoneやiPod Touch上で動く楽しさを手軽に味わえる点がとても良い。
画像や効果音の素材がサポートページからダウンロードできるので、それらを使うと見栄えの点でもいいかんじのものができあがるのもうれしい。
楽しさ重要。
他の初心者本がまずは座学で理屈から教える先生なら、この本は実技でお手本を見せてくれる先生といったかんじがする。
内容はiPhone SDKのインストールの説明からはじまるので、完全初心者でも安心。
そういった部分が読み飛ばせるくらいの人はすっとばしてサンプルアプリ作成から行くもよし。
アプリの作成はアイデアを形にするまでの制作の流れなども説明されていて、かなり実践的内容。
また作成の手順説明が操作のスクリーンショットを交えて丁寧でかなり分かりやすい内容になっている。
レシピ通りに進めていけばほとんど迷わず読み進めていくことができるだろう。
この本に従って進んで行くと最終的にサンプルアプリを6つ作ることになる。
数作ることで、操作を反復することになり開発の要領を体で覚えることができるのもいいんじゃないだろうか。
一方でサンプルコードに含まれるクラスやメソッドの説明は最小限にとどめられている。
ただそのおかげでサンプルアプリの作成がテンポ良く進められるようになっているような気がするので、それはむしろプラス評価。
足りない点へのフォローとしてはレシピ通りにサンプルアプリを作って終わり、とならないように、そこから先のステップに進む道筋として改良アイデアを提示して促したり、補足資料としてドキュメントやコミュニティへのポインタを設けたりもしている。
ということでこの本を読み終わったら、提示されたアイデアや自分のアイデアを形にする過程で別の本とかAppleの公式リファレンスで調べていけばいいだろう。
そしたら脱初心者。
で、別の本に関しては何冊か本屋でパラパラ立ち読みしてみたけど、入門の部分がすめばあとはリファレンスで足りるような気がした。
とりあえず自分はこの本で入門はすんだので、あとはしばらく公式のリファレンスでがんばってみようかと思っている。
（翻訳が変と評判の『iPhone デベロッパーズ クックブック』だけちょっと気になっているけど）
もうちょい本で基礎を勉強したいよという人は『基礎からのiPhone SDK』あたりが二冊目によさげな気がする。
copyright brass.to | powered by WordPress ME
