1月 162013
 

 Rails3 に限らずセッション情報の格納先に memcached を使うことは多いと思うが、Passenger + Rails3 でセッションストアに memcached を使うとセッションが切れたり他のユーザのセッションにすりかわったりする。実はPassenger のドキュメントにがっつり書かれている。

Because worker processes are created by forking from an ApplicationSpawner server, it will share all file descriptors that are opened by the ApplicationSpawner server. (This is part of the semantics of the Unix fork() system call. You might want to Google it if you’re not familiar with it.) A file descriptor is a handle which can be an opened file, an opened socket connection, a pipe, etc. If different worker processes write to such a file descriptor at the same time, then their write calls will be interleaved, which may potentially cause problems.

 何が問題かというと、memcached との接続を保持しているデスクリプタも fork() のタイミングで共有されてしまうこと。そのため、例えばほぼ同時に Passenger worker A と B から memcached にリクエストを送った場合、A 側のリクエストが若干早ければ memcached 側から送られた A 向けのレスポンスが A と B 双方で受け取ってしまい、本来は B には B 向けのレスポンスが行くはずが A のレスポンスとなってセッションの取り違いが発生してしまう。これの問題点は、エンドユーザからすると全く覚えのない別のユーザになってしまうことにある。

Continue reading »

7月 102012
 

 前回、初めての検針結果を貼ってみたが、月に1回の検針結果だけで売電量などが分かるのはあまり効率もよくない。電力モニタ JH-RWL3 でも確認はできるが、粒度は 1 時間単位とそんなに細かくはない。

 ただ、JH-RWL3 には lighttpd による Web サーバ機能があり、LAN 越しにもアクセスすることができる。そのため、ZABBIX で 30 秒ごとにデータを取得するようにしてみた。

Continue reading »

5月 062012
 

 まず真っ先に書いておくが、Ruby をディスるつもりは全くない。

 以前、風向は単位ベクトル平均を取ることを書いた。気象庁の「風向」の定義は10分平均、航空管制で用いられる「風向」は2分平均が使われるらしいが、USB Weather Board + Weather Meters を用いた観測では2分、10分、60分の平均を計算している。当初、Ruby で集計していたのだが、データ取得のタイミングである 3 秒ごとに実行されるので、 PhenomII X6 1065T だとこの処理だけで (800MHz のままとはいえ) 1 コアを使う程度の負荷がかかっていた。

 もちろん負荷軽減のために単位ベクトル化処理は演算済みのテーブルで変換するだけだったし、平均処理に必要な ∑ の計算は SQLite 上で行なっていた。それでもそれだけの負荷がかかっていたので若干問題意識を持っていた。実際、ググってみると、Ruby での数値演算は (LL の中でも) 遅い傾向にあることが指摘されていたりする。そこで、軽くベンチマークしてみた。

Continue reading »

5月 172010
 

 ある平日の朝、始業時間前に出社してトイレに行っていた私にメッセで

(09時43分01秒) ○○○@帰東京: ちょっと聞きたいんだが
(09時43分46秒) ○○○@帰東京: ヤフオクの入札履歴をブログで表示するようなのって自作って難しい?

と送ってきたヤツがいた。そう、ヤツだ…… 自分をヤフオクに出したというチャレンジャー、大住有だった。

Continue reading »