\ay diary

二、三日前から時々oom-killerが出るようになった。なんでかなと見てみたらずいぶんと太ったTypoのプロセスサイズがいくつか。一つあたり500MBとか……。

今までなんともなかったのになと思ったものの、それほど考えてみれば気にしていなかっただけで、実はけっこう前からこういう状態だったのかもしれないということに気付いた。おおむね自分が困るだけとはいえ、ちょっとほったらかしすぎた。動きを見てみると、プロセスが生成されて少しして数秒かけてプロセスサイズが大きくなっていくことがわかった。どうやら何かを読み込んでいるように見える。

実はこのことに気付くほんの少し前のタイミングでPassengerのバージョンを変えたり、他のアプリケーションの配置を変えたり、GEM_HOMEを変えたりということをしている。そのため、まず疑ってしまったのはそのあたりだった。その次に疑ったのは自家製コードのいくつか。といってもTypoのためには数十行のコードを書いた程度で、特別に問題になりそうなものは見付からない。

動いているプロセスにコードをつっこんでオブジェクトの様子を見てみるかとも思い始めていたのだが、ここでscript/consoleでも同じ現象が出ていることに気付いた(遅い!)。そしてconfig/environment.rbを読み込み終えるまでにプロセスサイズが育っていることがわかった。printfデバッグで絞り込みをかけたところ、以下のコードにいたった。

if RAILS_ENV != 'test'
  begin
    ActiveRecord::Base.connection.select_all("select * from sessions")
  rescue
    begin
      ActiveRecord::Base.connection.current_database
      Migrator.migrate
    rescue
      # if there are no database, migrator doesn't no start
      # use case : rake db:create in rails tasks
    end
  end
end

このコードが加えられたのはこのあたり。これなら、とりあえずはlimit 1でも付けておけばよいだろうか。もっとやりようがありそうなものではあるが。

結局、問題が顕在化したのは保存しているセッションの数が多くなってきたからであった。実に602,788レコードもある。セッションデータの掃除は今でも(Typo 5.3ではRails 2.2を使っているが)手作業でやるのかな? (セッションだからdelete_allで十分かしら?)

$ script/runner -e production 'CGI::Session::ActiveRecordStore::Session.destroy_all(["updated_at 

追記

問題として報告しておいたところgithub上のリポジトリでは引用したブロックはコメントアウトされたようだ。5.3.1では直っているのかな。なんだか他のチケットも動き出したので、ちょうどそんなタイミングだったらしい。

開港150周年記念「港都横浜の誕生―新発見資料に見る近代化の原点」というのをやっていて、ちょっとおもしろそうだったので横浜開港資料館に行ってきた。そもそも中に入ったのが初めてだったこともあり、200円でけっこう楽しめた。

ちなみにたねまるの親玉(?)であるタマクスの木は開港資料館の中庭にあって、これは入館しなくても見られる。

一月ほど前に通り掛かったときにお店が変わっていることに気付いた。新しく出来ていたのはChez Akilaというフレンチのお店。

平日ランチメニューは1,400円。ちょっと奮発気分が必要だが、内容はそれに見合うものでおいしかった。+300円でデザートを付けることができる。このときは紅茶プリンにアイスクリームを添えたもので、味もボリュームもお得感がある。

(そのほかの写真)

店内は白と明るい木の色でまとめられている。小さいお店ながら席数をしぼっているのか窮屈な感じはしない。禁煙なのもうれしい。

先日お知らせしたDebian Ruby1.9会議の開催日時と場所が以下に決まりました。

• 日時: 2009-07-05(日) 14:00〜17:00
• 場所: かながわ労働プラザ 第10会議室

参加される方へのお願い

参加される方との連絡・情報交換のためにGoogleグループに場を設けています。ATNDで参加登録された方は、私(akira.yamada gmail.com)まで以下の二点をお知らせください。

• 登録するメールアドレス
• ATNDでのユーザ名

今月のSoftware Design(2009/7号)はDebian特集であった。パラパラとながめていって、ふとパッケージ情報にアクセスするツールを調べ直したくなった。

といっても--helpしてみたり、manページを見たりといった程度。そんな中、grep-dctrlに便利な機能が加わっているのに気付いた(etchのころにはもうあったようだが気付いていなかった、とも言える)。その機能というのは-Sオプション。-Sオプションは-F Source:Packageの短縮形で、パッケージ情報にSourceフィールドがあればそれに対して、なければPackageフィールドに対してパターンマッチを行う。

各バイナリパッケージのパッケージ情報には、そのバイナリパッケージを作るもととなったソースパッケージが何であるかが含まれいることがある。一つのソースパッケージから複数のバイナリパッケージが生成されることがあるためで、ソースパッケージ名とバイナリパッケージ名が異なる場合にSourceフィールドが現れ、その値としてソースパッケージ名が記述される。

あるソースパッケージから生成されるすべてバイナリパッケージを探し出したいとするとき-Sオプションが便利だ。たとえば、ソースパッケージruby1.8から生成される、つまり、パッケージとして提供されるRuby 1.8の全部をインストールしたいとすると、次のようなコマンドラインが考えられる。

$ grep-aptavail -n -X -s Package -S ruby1.8 | xargs sudo aptitude install

(しばし余談)

ここで、-Sオプションではなく、-F Source,Packageでも実現できるのではないかと思える。「:」でなく「,」で区切った場合、そのうちのどれかにマッチしたものが出力されるからだ。だが、実際にやってみるとこれはうまくいかない。なぜかというと、あるソースパッケージの名前と同じ名前のバイナリパッケージを生成する別のソースパッケージというのが存在する可能性があるのだ。

$ grep-aptavail -X -s Package,Source -S libqt4-ruby
Package: libsmokeqt4-1
Source: libqt4-ruby

Package: libsmokeqt4-dev
Source: libqt4-ruby

$ grep-aptavail -X -s Package,Source -F Source,Package libqt4-ruby
Package: libsmokeqt4-1
Source: libqt4-ruby

Package: libsmokeqt4-dev
Source: libqt4-ruby

Package: libqt4-ruby
Source: kdebindings

libqt4-rubyは一例で他にもいくつかある。このような状態はリリース間でパッケージ構成が変わったなど、特別なケースであることが多いと思うが、そういうこともありうるという点には気を付けておいたほうがよいだろう。

(本題に戻る)

sarge以降(あえてsargeという :-)、apt-getではなくaptitudeが用いられていることと思うが、最近のaptitudeの検索パターンは実に充実していることにも気付いた。ソースパッケージruby1.8から生成されたパッケージを選び出してインストールしたければ、次のようにコマンド実行すればよい。

# aptitude install '?source-package(^ruby1\.8$)'