Xrea serverへRails install

1. Gem install
$ ruby setup.rb config --prefix=~/local

2. Rails install
$ gem install rails -i ~/local/lib/gems --no-rdoc --no-ri

3. Add environment into .bashrc
$ echo 'export GEM_HOME=~/local/lib/gems' >> ~/.bashrc

4. link
$ ln -s ~/local/lib/gems/bin/rails ~/local/bin
$ ln -s ~/local/lib/gems/bin/rake ~/local/bin

## Create test project ##
$ cd tmp
$ rails test
$ ln -s ~/tmp/test/public ~/public_html/rails

Now we can access to http://xxx/rails

しかし、、、Rails 2.3.2のCGIハンドラが動かない。バグっぽい。
同じことがpostされている
http://www.ruby-forum.com/topic/182327

rails 2.3.2対応

Rails 2.3.2へのUpgrade

Debian experimentalのRuby1.9.1を使用する

1. ruby1.9.1をインストールにする。
URI::ParserというクラスがRuby1.9.1 (1.9.0はダメ)から入っているようで
Rails 2.3.2もそれを想定してあるためまずUpgradeする。

2. gemのインストール
ソースからインストール (/usr/bin/gem1.9というのができる)

3. rails for ruby1.9.1のインストール
$ sudo gem1.9 install -v=2.3.2 rails

4. narrayのインストール
$ sudo gem1.9 install narray

5. hpricotのインストール
$ sudo gem1.9 install hpricot
コンパイルにしくじるので、hpricot_scan.cの
RHASH(hash)->tblをRHASH_HASH(hash)に変更して
xxx.soをlib以下へコピー
あと、fast_xsは、hpricot_scanのエラーのせいでとまっているので
ruby extconf.rb; make
でコンパイルしてコピー

6. mysql.so
2.8.1のソースをもってきてmake install

7. libopenssl-rubyのインストール
$ apt-get install libopenssl-ruby1.9

8. rackのインストール
webrickを起動するのに必要
(今は1.8で動作させているので1.9ではいらないけど一応入れとく)

ruby1.9.1だと、./script/consoleとか動かないので
sumida-systemで起動するものは、ruby1.8で稼動させる。
そのために、ruby1.8でもrails/hpricotなどを入れる。

追記:
state_machineをgemで導入

mysql index

backtestをしていると、ある一定時間経つと急激に遅くなっていたので
調査をしてみた。
最初は、Buffer poolが足りないのかなと思って増やしていたのだけど
それでも、遅くなるまでの時間が長くなるだけでまた遅くなる。
backtestを行うtick tableのスタートポイントを変えてみたのだけど
必ず遅くなっていた近辺でやっぱり遅くなることが判明。
ということで、SQLをexplainしてみてみると、
where: file: sortといった感じで、見たくない文字が、、、。
そこで、MySQLのIndexが使用されない場合を検索してみると
order byで指定しているカラム以外をwhereに使ってると
使われないといった記述があった。
実はそれ以外にも結構使用されない場合があるみたい。
named_scope: barsの中のSQLで、datetimeをorder byで使っていて
whereの中は、
datetime >= xxx and open is not NULL, close is not NULL
としていたので、sortがfileになっていたみたい。
とりあえず、NULLかどうかはアプリ側で判断することにして条件を外す。
1テーブルあたりのselectが0.43msから、0.01msへ。
ということで、体感的にもかなり速くなった。SQLは重要。

SVM

Ruby/SVMをruby1.9を使用してコンパイル。
extconf.rbでMakefileが作成されるみたいなので
/usr/bin/rubyを/usr/bin/ruby1.9の
symbolic linkにしただけ。

deadlock解消

Decisionをつねにdupして、ThreadPoolに投げこんで処理をすすめていたが
毎回@sessionを利用してDBに書くのもSVMを利用するとなるとコストが高いのでdupしないでいけるようにデザイン変更。
その際、deadlockが発生していたが、原因は以下だった。

1. Decisionのstatusが1度実行するとdoneになる。
2. statusをreadyにしなかったため、2度目の実行がすぐに終わってしまう。
3. Agentは、Decisionの終了を待つため、condition_waitするがその前に
Decisionがready statusじゃないので、Decision::start/finalizeを
実行せずに終了してしまう。つまり、spin_lockして待つわけではないので、Agentのcond_waitを待たない。 したがってdeadlockしてしまう。

とりあえずstatusをちゃんと変更するようにして解消

仮想環境のネットワーク

kvm で仮想ネットワークを使用するときは、-net nic -net tapとして
ifconfig tap0 0.0.0.0 up
brctr add br0 tap0
で tap0をbridgeインターフェースに入れる。

udhcpdのconfigは
start 192.168.5.30
end 192.168.5.254
interface xenbr0
max_leases 225
option subnet 255.255.255.0 <- 必要
option router 192.168.5.1
option dns 192.168.5.1
で設定しておいてあげるとd-iがいい感じに設定してくれる

Design change

すべてのサービスをThread化して
- MarketAgent
- CandleMaker
- DealAgent
と3つのうち、CandleMakerは1つだけ起動するようにやっていたが
例えば、Forex, Commodity, Stockと3つのマーケットを監視するように
していたとき、処理が重くなってしまい、その後に稼動するDealAgentが
遅れてしまうため、マーケットごとに起動するようにした。
つまり、各マーケットごとに3つのタスクが1セットになる。
コンテナは1つで、いくつでもスレッドをたてられるようにしてあるので
まぁ、9個のタスクをあげてもいい。

Todo:
- クラスアンロードの実装
- スレッドを制御するためのインターフェースの実装
今は、とりあえず、feedsテーブルから登録を削除すれば
トリガーとなるupdateメッセージは送信されなくなるので
その後は、タスクは何もしなくなる。あるタスクだけ変更して
リロードしたい時のための口が必要
- 上記Serviceをまとめた設定ファイルの実装
例えば、services.ymlというファイルに

forex:
- fetch
- candle_maker
- deal

commodity:
- fetch_commodity
- candle_maker_commodity
- deal_commodity
みたいな感じにして、起動時にロードして起動する

RubyのException

今さらながら、rescueでExceptionを捕捉してraiseする場合でも
ちゃんと、ensureは実行される。
raise以降のやつはもちろん走らない

begin
begin
raise Exception
rescue Exception
p 'Hello'
raise Exception
p 'Hello2'
ensure
p 'Yahoo'
end
rescue Exception
p 'Finish'
end

-- Result --
"Hello"
"Yahoo"
"Finish"

Gnome Applet改良

Gnomeのアプレットを
indust product別にし
またずっと表示してても
気にならないように
30%の透過Windowにした。
ままいい感じ。
Gtk::Window::set_opacity(0.3)
一発。

2.6.28での注意点

Kernelを2.6.28にしたのだけど、MAQUARADEを入れていると
listenしていないポートへのTCPのconnectでblockしてしまう。
正確には、RSTをサーバ側は返しているのだけど、なんらかにより
Timeoutまでまっているっぽい。
2.6.26までは、そんなことなかったのだけども、、、。
Mac miniのサーバにはMASQUARADEはしないので、まぁ、問題はないけど
ThinkPadでの開発のときは外しとかないと、、、