ラベル OpenSim の投稿を表示しています。 すべての投稿を表示
ラベル OpenSim の投稿を表示しています。 すべての投稿を表示

2013年9月1日日曜日

Mono 3.2.1 のガベージコレクタ

FreeBSD PortsのMono 3.2.1 をインストールしてから、topコマンドでみると、以前は「mono」と表示されていたところが、「mono-sgen」と表示されていました。
ググってみると、MonoのプロジェクトページにGenerational GCというページを見つけました。中身の詳細は理解してませんけどwww、ガベージコレクターが変更になったということらしいです。

このページにRootsという項目があるんで、以前でてた「Too many root sets」ってエラーは、このRootsに関係あるんだろうなぁ...ってことは判ります(理解するのは、しんどいww)。

いずれにしろ、いろいろと改善されているようです。 あとは、ODEがクラッシュしないようになれば言うこと無いんだけど。ODE捨てて、BulletSim に鞍替えしたほうがいいんだろうか...。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2013年8月29日木曜日

Mono 3.2.1で、OpenSimを再構築

FreeBSDのPortsでMono 3.2.1にアップデイトできました。 
% mono --version
Mono JIT compiler version 3.2.1 (tarball Thu Aug 29 14:09:52 JST 2013)
Copyright (C) 2002-2012 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notification:  kqueue
        Architecture:  x86
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen

この新しいMonoでOpenSimを再構築してみることにします。 ビルドする前に、以前作成しているバイナリーをクリーンにしておきます。 
% xbuild /target:clean
...

% xbuild
...
ビルドできたOpenSimを実行してみましたが、特に問題なくうごいているようです。しばらく様子を見ることにします。
投稿者 時刻: 1 件のコメント:
ラベル: ,

2013年8月26日月曜日

Mono 3.2.1 がでてた

FreeBSDの lang/mono のPortsが 3.2.1にバージョンが上がってました。Subversionのログ見たら、わりとこまめにバグフィックスされてたみたいだけど、バージョンアップするのをサボってましたw。

しかし、ちゃんとMonoのPortsがメンテナンスされているのは嬉しいですね。 「Too many root sets」というエラーがでなくなればいいな。FreeBSDも8.4にあげてる事だし、Portsもぼちぼち最新に更新しないとなぁ...。

ちなみに、今は Mono 3.0.3 と opensim-c358d5d で、25日間落ちないで安定して動いています。これだけ長く動かし続けてるのは、過去あまりなかったかもしれません (まあ、連続運転するよりOpenSimのバージョンが上るスピードの方が早いからかもしれませんが w)。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2013年3月13日水曜日

"Too many root sets" というエラーが出た

今日、運用しているOpenSimをみたら、「Too many root sets」というエラーを出して、コア吐いて死んでました。
...
Region (root) # Too many root sets

Stacktrace:

Abort trap (core dumped)
検索してみると、どうやら、Monoのバグのような雰囲気です。
Monoのバージョンと動かしている環境は次の通り。

・ Mono  3.0.3 (FreeBSDのportsによるインストール)。
・ FreeBSD 8.3-RELEASE-p5

Mono 3.0.3になってからなのか、OpenSimのバージョンをあげてからなのかはわかりませんが、最近、たまーに発生します。

なんか、対処法あるのかな?
投稿者 時刻: 0 件のコメント:
ラベル: ,

2013年3月4日月曜日

今度はOSgrid OpenSimulator 0.7.6.dev.e70c71aがでた

昨日、アップデイトしたと思ったら、もう次の新しいバージョンがでてました(X_X;)。

Update – Release changes for OSgrid opensimulator.0.7.6.dev.e70c71a

まあ、開発が停滞するよりはいいことだとは思いますが...。

こんどのバージョンは、OpenSim.ini と GridCommon.ini に変更があります。詳しくは上記URLの記事を見てください。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2013年3月3日日曜日

OSgrid OpenSimulator v0.7.6.2642129 にアップデイト

OSgrid OpenSimulator v0.7.6.2642129 にアップデイトしました。2/6に v0.7.6.3646361 にバージョンが上がったばかりだったのに、2/18には、このバージョンに上がりました。時間がとれなかったので放置してましたが、本日アップデイト掛けました。最近、 頻繁にバージョンが上がります。

バージョンあげる時、データベースにSQLiteを使ってる場合は、以前のバージョンで使っていた OpenSim.db をコピーしてくるだけでOKです。OSGridに(Hyperグリッドとかではなく)リージョンサーバーとして接続しているのならば、OpenSim.dbのみが必要なDBファイルになります。
データベースにMySQL をつかっているのならば、GridCommon.ini の設定を以前と同じようするだけでいいでしょう。
まあ、念のため、「save oar コマンド」 でバックアップを取っていたほうがいいとは思います。

あと、今回、bin/assetcache にあるアセットキャッシュデータ も以前のバージョンの物からコピーするようにしました。
% cp -Rp 以前のバージョン/bin/assetcache .
私ところだと、4つのリージョンで256MBのサイズになってましたので、ここが空っぽだと、OSGridのアセットサーバーにアクセスが集中するので、立ち上がりも遅いし、決して潤沢とはいえないOSGridのサーバー郡に無用な負荷を掛けてしまうことにもなるんではないかと思います。


正常にアップデイトし、OpenSim.exeが立ち上がったら、OpenSimのコンソールコマンドで、「fcache assets」 を実行しとくと、リージョン上にあるオブジェクトがキャッシュ存在するか確認が行われるんじゃないかと思います。効果あるのかどうかはわからないけど、まあ、気休め(^_^;)。


投稿者 時刻: 0 件のコメント:
ラベル: ,

2013年2月3日日曜日

monoのバージョンを 3.0.3に上げました。

FreeBSDを8.2 --> 8.3へあげたついでに、monoのバージョンを3.0.3にあげてみました。Portsで正式に、3.0.3がサポートされています。これで少しはLinuxと同じレベルに近づけたかな?

リリースノート
http://www.mono-project.com/Release_Notes_Mono_3.0.3
 
OSGridのOpenSimのバージョンもあげちゃったし、 メモリリークの量が減ったかどうかは、よくわかりません。まあ、特に問題なく、それなりに安定して動いてるようにも見えます。

nantのPortsは、BROKENなままなんで、OpenSimのコンパイルには、xbuildを使いました。

FreeBSDの方も、CVSが廃止されてSubVersionに移行するとか、いろいろと状況がかわってるので、いろいろとまとめをしたほうがいいかもしれないなぁ...。

投稿者 時刻: 0 件のコメント:
ラベル: ,

2012年12月4日火曜日

CTRL-CでOpenSimが落ちないようにする

OpenSimを端末ウィンドウでうごかしてる場合、CTRL-Cを押すと中断されて落ちてしまいます。これはWindowsでもUNIXでも同じです。UNIXの場合は、端末でCTRL-Cを押すとSIGINTというシグナルが発生し、その端末上で動いているプログラムを中断させます(デフォルトの動作の場合)。

私は、WindowsマシンでViewerを動かしながら、OpenSimが動いているサーバーにTeraTermで接続してOpenSimのコンソールを操作しています。CTRL-CはWindowsでは、Copy&PasteのCopyのショートカットキーになってますので、Windowsのノリで、sshの端末画面の上で間違えてCTRL-Cを押してしまうことがよくあります。また、UNIXのShellのコマンドラインでは入力途中のコマンドをCTRL-Cを押して中断・破棄するということもよくやります。

そういう手クセがついていると、OpenSimのコンソールでついついCTRL-Cを押して、誤ってOpenSimを落としてしまうことがあります。こないだも、OSGridの私のリージョンに人が来ていたにもかかわらず、CTRL-Cを押してしまったようです(手クセなんで、あんまり自覚がない。ごめんなさいwww)。

これを防ぐために、次のような「opensim_start.sh」というスクリプトでOpenSimを起動するようにすると、CTRL-Cを押しても大丈夫になります。
#!/bin/sh
stty intr undef
mono --debug OpenSim.exe
stty intr ^C
キモは、「stty intr undef」 というコマンドで、intr (SIGINT)を発生させる文字コードを未定義にしてからOpenSimを起動してます。これで、OpenSim起動中はCTRL-Cを押してもなにも起こりません。そして終了前にCTRL-Cに戻しています。sttyの詳細についてはオンラインマニュアルを見てください。

まあ、これで不用意にOpenSimを落としてしまうことが少なくなると思います(^_^;)。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2012年11月15日木曜日

OSGridで動画を撮ってみた

BlogにYouTube動画を張ったことがなかったので、試しにやってみました。撮影場所は、OSGridのMARTYS ART GALALERY II というリージョンです。アバターは、「hop://login.osgrid.org/Tryloria%202/192/48/22」でもらったHexeというVampireアバです。


録画は、BB FlashBack Express 2 というソフトでしました。 今見たら、BB FlashBack Express 3がでてました。

動画の撮りかたや編集は、まだ良くわかってないので、適当にやってます。まあ、いちどちゃんとマニュアルや、解説本を読まないと....(^_^;)。


投稿者 時刻: 0 件のコメント:
ラベル: ,

2012年11月12日月曜日

解決: ビュアーが原因だったかも...(変な現象が発生)

「変な現象が発生」という記事で、リージョンにある木々が隣のリージョンにずれて表示されるという Cool VL Viewer v1.26.5.16 のバグですが、v1.26.5.18 で直ったようです。


Cool VL Viewer v1.26.5.18で隣のリージョンを見たところ。正常に見えている。
ChageLogにも説明がありました。
Cool VL Viewer v1.26.5.18 (experimental branch with v3.4 renderer):

Same changes as in v1.26.4.38, plus:
  • Fixed tree rendering (phantom trees sometimes appearing on the horizon when hovering over a parcel with trees) and tree shadows issues (bad shadows).
作者は、このBlogを見たのかしらwww。
投稿者 時刻: 0 件のコメント:
ラベル:

2012年11月7日水曜日

monoのバージョンを2.10.8にあげてみた

monoのバージョンを 2.10.6 --> 2.10.8に上げてみました。

リリースノート
http://www.mono-project.com/Release_Notes_Mono_2.10.8

FreeBSDのportsのmono (lang/mono)は、2.10.6 の次は、2.11.1 にいきなりバージョンが上がってるようですが、ここは、portsのMakefileに小細工して、2.10.8をインストールしてみました。正式にPortsになっているバージョンではないけど、細かいバグ修正が修正されているようなんで、ためしに使ってみます。

投稿者 時刻: 0 件のコメント:
ラベル:

2012年11月3日土曜日

ビュアーが原因だったかも...(変な現象が発生)

ついさっき公開した「変な現象が発生」という記事ですが、どうやらビュアーのバグのようです(>_<)。

「変な現象が発生」の記事を書いた時に使っていたのは、Cool VL Viewer v1.26.5.16 でした。このv1.26.5は、「Cool VL Viewer v1.26.5 (new, EXPERIMENTAL branch with the new v3.4 renderer)」という、テスト版です。

Firestorm 4.2.2 (29837)で、INしてみたところ、問題なく表示されました。また、 CoolVLViewer-1.26.4.36 (安定版)、Imprudence 1.3.2、Imprudence 1.4.0 beta 2でも、問題ありませんでした。

Cool VL Viewerの1.2.5.x (テスト版)を使ってたのは、アバターを表示するときに、アバタのスキンなどのテクスチャーが変になりにくいからです。

というわけで、ビュアー側の問題のようでした。お騒がせして申し訳ありませんでした。

投稿者 時刻: 0 件のコメント:
ラベル:

変な現象が発生

!!! 注意 !!!
この記事の変な現象は使っていたビュアー(Cool VL Viewer v1.26.5.16)が原因だったようです。 詳しくはこちら「ビュアーが原因だったかも...(変な現象が発生)」をごらんください。


OSGridの私のリージョン(New Galapagos 2)で、変な現象が発生しました。
このリージョンは、OpenSim Creationsにあった、OAR(OpenSimulator Archive)ファイルのThe Path V0.7をリージョンに読み込んだものです。

本来リージョンの上にあるハズの木々が、 隣のリージョンにずれて表示されています。


不思議なことに、そのリージョンに降りると、アバターの周辺には隣にあった(2)の位置から、本来あるべき(1)の場所に木が戻ります。


また、隣のリージョン((2)の位置)に移動して自分のリージョン((1)の位置)の方をみると、一瞬(2)の位置に木々が見えるんですが、次の瞬間にアバターから2つ遠い先のリージョンに木々が移動してしまいます。


うーん....。

この現象は、opensim-36bfd36 (OSgrid OpenSimulator 0.7.5.dev.36bfd36) にあげた後、しばらくしてから気づきました。
OpenSimのバージョンをあげたことが原因なんだろうかと思って、一つ前の opensim-4e9509d に戻しましたが、同じ現象になりました。もっとも、OpenSimのバージョンを上げても同じMySQLのデーターベースを継続して使ってるので、データベースのリージョンに関するデータがおかしかったら戻しても変わらないのかもしれません。

木のオブジェクトがロックされてなくて、それを全選択してしまってて、操作ミスで移動させてしまったんだろうか? リージョンのデータベースが変になった???

いったん、リージョンを削除し、もう一度OARを読み込ませればいいのかなぁ.... (>_<)。
投稿者 時刻: 0 件のコメント:
ラベル:

2012年10月15日月曜日

ODE 0.12をGIMPACTで再コンパイル

先月、「ODE 0.12にアップデイト」というBlogエントリを書いたのですが、OpenSim ODEで検索してたら、次のような記事を見つけました。これは、opensim-devのメーリングリスト(ML)に投稿されたもののアーカイブのようです。
Prospective ODE physics changes (将来のODE物理に関する変更)
http://opensim-dev.2196679.n2.nabble.com/Prospective-ODE-physics-changes-td7144808.html
このMLのスレッドは、18個ほど投稿がされています(Threadedのリンクをクリックするとスレッド一覧が見れます)。

議論の中身はあんまり理解できない(^_^;)のですが、collider(コライダー? 衝突検出器?)に従来のOPCODEではなく、GIMPACTを使ったほうがクラッシュしにくいとか、[ODEPhysicsSettings]の中の contacts_per_collision というパラメータを80からもっと小さい値にしてもいいんじゃないか、とかが議論されています。まあ、詳しくは、上記MLのスレッドをご覧ください。

ODE 0.12の再構築

前回のODE 0.12のコンパイルでは、「http://opensimulator.org/wiki/PhysicsEngines」の内容に従って、configureのオプションを決めたのですが、今回は「--with-trimesh=gimpact」のオプションをつけることにします。

まずは、前回の 「ODE 0.12にアップデイト」の手順に従い、ソースコードを取得し、FreeBSD用パッチをあてます。その後、「sh autogen.sh」でconfiguareスクリプトを作成して、次の引数をつけてconfigureを実行します。
# ./configure --disable-asserts --enable-shared --disable-demos --with-drawstuff=none --with-trimesh=gimpact CFLAGS="-O2 -msse -mar
ch=i686" CXXFLAGS="-O2 -msse -march=i686"
ちょっと見ずらいので、複数行で表記すると次のようになります(UNIXのShellは行末に「\」がある場合、次の行と連結して1つの行として扱います)。
# ./configure --disable-asserts --enable-shared --disable-demos \
              --with-drawstuff=none --with-trimesh=gimpact \
              CFLAGS="-O2 -msse -march=i686" \
              CXXFLAGS="-O2 -msse -march=i686"
後は、make & install します。
# make
...
... 
# make install
...
...
この新しいODEのライブラリだと、クラッシュしにくくなったような気がします。

contacts_per_collision パラメーターの調整

OpenSim.iniの [ODEPhysicsSettings] セクションに contacts_per_collisionのパラメータを追加します(ODEに関するパラメータの大部分は、OpenSimDefaults.ini にあります。OpenSim.iniはそれに追加・上書きしています)。
[ODEPhysicsSettings]
    contacts_per_collision = 10
このcontacts_per_collisionの値を小さくすると、物理オブジェクトを使ったときのCPUの負荷が劇的に減ります。10 の値が妥当なのかどうかは判りませんし、なんか乗物等で不都合がでるかもしれません。でも、物理な0.5m角のCUBEを400個くらい積み上げて崩してみても、前よりはアバターが動けるように感じますし、崩れ方・転がり方も、以前よりすこし自然な感じがします。
それと、いまのところクラッシュしていません。まあ、私の主目的は、クラッシュしないことですんで、これでとりあえず良しとします。

物理オブジェクトの掃除のTips

物理オブジェクト を積み上げて崩すという遊びをしていると、コンソールに「 [PHYSICS]: Physical Object went out of bounds.」という警告メッセージがどんどんでたり、あっちこっちに散らばった物理オブジェクトを探し回って消さなくてはいけなくなることがあります。
こんな場合、OpenSimの次のようなコンソールコマンドを使うと便利です。
delete object outside - Delete all scene objects outside region boundaries
delete object name [--regex]  - Delete a scene object by name.
show object name [--regex]  - Show details of scene objects with the given name.

範囲外にでたオブジェクトは、「delete object outside」コマンドで削除します。
物理オブジェクトに、あらかじめ特徴的な名前をつけておいて、「delete object name --regex オブジェクト名の正規表現」とすれば、探し回わって消さなくてもすみます。間違って他のオブジェクトを消してしまわないように、あらかじめ、「show object name --regex ...」で消すオブジェクトを確認しといたほうがいいかもしれません。


a
投稿者 時刻: 0 件のコメント:
ラベル:

2012年10月10日水曜日

メモリリークの原因

OpenSim Version 0.7.5 (Dev)Build 4e9509d にアップデイトしてみましたが、相変わらずメモリ使用量は時間とともに増加するようです。
Kimiko Dover さんの「OSgridのメモリー消費増加の原因」って記事を前にみてたので、試しに OpenSim.iniの[Startup]セクションの次の3つの設定をコメントアウトにしてみました。 
[Startup]
    ...
    ;WorldMapModule = "WorldMap"
    ;MapImageModule = "Warp3DImageModule"
    ;GenerateMaptiles = true
コメントアウトし、しばらく動かしてみてますが、メモリ使用量の増加はおこらないようです。psコマンドを定期的に動かしてメモリ使用量を記録するスクリプトをcronで動かしてみてますが、増えたり減ったりしてます(減ることもある)。
vsizeが仮想記憶メモリサイズ(KB)で、rssが常駐メモリサイズ(KB)です。 
タイムスタンプ       vsize  rss    コマンドライン
2012-10-09 23:00:00  316780 224232 mono OpenSim.exe
2012-10-09 23:30:00  316780 224232 mono OpenSim.exe
2012-10-10 00:00:00  316780 224232 mono OpenSim.exe
2012-10-10 00:30:00  316780 224232 mono OpenSim.exe
2012-10-10 01:00:00  316780 224256 mono OpenSim.exe
2012-10-10 01:30:00  316848 224304 mono OpenSim.exe
2012-10-10 02:00:00  316848 224332 mono OpenSim.exe
2012-10-10 02:30:00  316848 224340 mono OpenSim.exe
2012-10-10 03:00:00  316848 226112 mono OpenSim.exe
2012-10-10 03:30:01  316848 214680 mono OpenSim.exe
2012-10-10 04:00:00  316848 213312 mono OpenSim.exe
2012-10-10 04:30:00  316848 210284 mono OpenSim.exe
2012-10-10 05:00:01  316848 210284 mono OpenSim.exe
2012-10-10 05:30:00  316848 210296 mono OpenSim.exe
2012-10-10 06:00:00  316848 208484 mono OpenSim.exe
2012-10-10 06:30:00  316848 208484 mono OpenSim.exe
2012-10-10 07:00:00  316848 209968 mono OpenSim.exe
2012-10-10 07:30:00  316848 209968 mono OpenSim.exe
2012-10-10 08:00:00  316848 209968 mono OpenSim.exe
2012-10-10 08:30:00  316848 209968 mono OpenSim.exe
2012-10-10 09:00:00  316848 209972 mono OpenSim.exe
2012-10-10 09:30:00  316848 209972 mono OpenSim.exe
2012-10-10 10:00:00  316848 209972 mono OpenSim.exe
2012-10-10 10:30:00  316848 209972 mono OpenSim.exe
2012-10-10 11:00:00  316848 212752 mono OpenSim.exe
2012-10-10 11:30:00  316848 212756 mono OpenSim.exe
2012-10-10 12:00:00  316848 212756 mono OpenSim.exe
2012-10-10 12:30:00  316848 212756 mono OpenSim.exe
2012-10-10 13:00:00  316848 212760 mono OpenSim.exe
2012-10-10 13:30:00  316848 212760 mono OpenSim.exe
2012-10-10 14:00:00  316848 212760 mono OpenSim.exe
2012-10-10 14:30:00  316848 212760 mono OpenSim.exe
2012-10-10 15:00:00  316848 213096 mono OpenSim.exe
2012-10-10 15:30:00  316848 213096 mono OpenSim.exe
2012-10-10 16:00:00  316848 213096 mono OpenSim.exe
Warp3DImageModuleについては、「http://opensimulator.org/wiki/Warp3DImageModule 」に記述があります。

Warp3DImageModuleを使わないと、マップに表示される画像がしょぼくなりますが、メモリリークしなくなります。なので、使わない方向でしばらく動かそうと思います。

ちなみにOSG48のメンバーの方によると、WindowsでOpenSimを動かしている場合は、このようなメモリリークは起こらないそうです。

Warp3DImageModule、もしくはmono特有の問題なのかもしれません。libgdiplusとかX11とかのライブラリとかが関係しているのかも...。

投稿者 時刻: 0 件のコメント:
ラベル:

2012年10月7日日曜日

OpenSim Version 0.7.5 (Dev)Build 4e9509d にアップデイト

OSGridのOpenSimの新しいバージョンがリリースされていましたので、アップデイト掛けてみました。
OpenSim Version 0.7.5 (Dev)Build 4e9509d[r/20546]
 正常に起動されているようです。まあしばらく様子をみてみます。

投稿者 時刻: 0 件のコメント:
ラベル:

2012年9月27日木曜日

メモリリークしてる?

topコマンドで、OpenSimを動かしているmonoのメモリ使用量モニタしてるんですが、時間の経過とともに徐々に大きくなってきます。ちなみに、OpenSimのバージョンは、OSgrid OpenSimulator 0.7.5.dev.224efe7です。

起動直後は次のような感じ(COMMANDがmonoのところのSIZEとRESに注目)。 
last pid: 20123;  load averages:  0.47,  0.27,  0.15        
81 processes:  1 running, 80 sleeping
CPU:  4.7% user,  0.0% nice,  2.2% system,  0.1% interrupt, 93.1% idle
Mem: 457M Active, 1969M Inact, 218M Wired, 2676K Cache, 112M Buf, 349M Free
Swap: 2048M Total, 3360K Used, 2045M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
20105 opensim    51  46    0   336M   255M ucond   3   1:10 15.23% mono
 1673 mysql      17  44    0   192M 45720K sbwait  1  17:33  0.00% mysqld
...
... 以下省略
...

だいたい51時間後は、次のような感じ。メモリ使用量がほぼ倍になってます。
last pid: 20086;  load averages:  0.20,  0.15,  0.10
83 processes:  1 running, 82 sleeping
CPU:  1.3% user,  0.0% nice,  3.0% system,  0.0% interrupt, 95.7% idle
Mem: 734M Active, 1947M Inact, 212M Wired, 2740K Cache, 112M Buf, 99M Free
Swap: 2048M Total, 3368K Used, 2045M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
78208 opensim    54  44    0   619M   515M ucond   3 563:00  8.30% mono
 1673 mysql      16  50    0   192M 45708K sigwai  2  17:32  0.00% mysqld
...
... 以下省略
...
「opensim メモリリーク」で検索してみたら 、Kimiko Dover さんの「Opensimで、メモリーリークが起きているのかな？ 」って記事がヒットしました。メモリ使用量増加の割合もだいたい同じぐらいです。

このペースでメモリ使用量が増えたら、ほかにもサービス動いてるし、ちょっとこのマシンでは苦しいなぁ...。問題が根本的に解決されるまで、定期的に再起動かけるようにするかな。ハードウェア共用のVPSとかをレンタルされている方は苦しいかもしれませんね。

投稿者 時刻: 0 件のコメント:
ラベル:

2012年9月23日日曜日

OSG48に参加しました

OSG48とは、OSGridに接続している日本人オーナーのリージョン郡です。私も、このリージョン郡へお誘いをうけて、参加させていただきました。当初1つのリージョンだけのつもりだったんですが、「何事も経験だからまとめて引越ししたら?」との事で、それじゃあ、ということで4つまとめて移動してきました。

周りにたくさんのリージョンがあります。お隣さん、よろしく!


 お隣の高い山のリージョンから自分のリージョンを眺めるの図。


いまのところ、安定してるとは思うけど、昨日物理オブジェクト400個だしたら、core dumpしてOpenSimが死んでしまった。ODEには、まだなんか潜在的な問題があるのかなぁ? それともOpenSimの側の使い方の問題?

OpenSimが死んだとき、自動的にリカバリーする仕組み、そろそろつくらないと...。


投稿者 時刻: 0 件のコメント:
ラベル:

2012年9月21日金曜日

ODE 0.12にアップデイト

いままで、ODE(Open Dynamics Engine)は、FreeBSDのPorts(devel/ode)のものを使ってました。このバージョンは 0.11.1です。いま、ODEプロジェクトのホームページを確認したら、0.12がでていました。0.11.1が出たのが 2009-10-17で、0.12が2012-05-28 ですので、いろいろとバグが修正されていることが期待できます。まだ、Portsは0.11.1のまんまなんで、ここは手動でソースコードからライブラリをインストールすることにします。

automakeをインストール

ODEのコンパイルには、automakeが必要ですので、Portsからインストールします。
# cd /usr/ports/devel/automake && make install clean
依存関係のあるPortsもあわせてインストールされますが、まあ、気にしない。
automakeはODEをコンパイルする為だけに必要で、実行時には必要ありません。

ソースコード取得とパッチあて

ODEのサイトの download のリンクをたどると、sourceforgeのサイトにいきます。そこから、「ode-0.12.tar.bz2」をダウンロードし、展開します。ダメなら、ブラウザ等でいったんダウンロードしてから、FreeBSDに転送します。
# fetch http://sourceforge.net/projects/opende/files/ODE/0.12/ode-0.12.tar.bz2
# tar xvzf ode-0.12.tar.bz2
...
... ファイルが展開される
...

展開したソースコードのMakefile.amに次のパッチを当てます。こちらからダウンロードするか、コピペして、「ode-0.12_freebsd.patch」というファイル名で保存してください。 
--- Makefile.am.orig    2012-02-12 07:03:27.000000000 +0900
+++ Makefile.am 2012-09-19 21:24:49.000000000 +0900
@@ -40,5 +40,5 @@
         CHANGELOG.txt INSTALL.txt README.txt LICENSE.TXT \
         bindings

-pkgconfigdir = $(libdir)/pkgconfig
+pkgconfigdir = $(libdir)data/pkgconfig
 pkgconfig_DATA = ode.pc
このパッチを当てないと、monoがlibode.soを見つけられなくてエラーになります。odeのソースコードがFreeBSDの devel/pkgconf の仕様に適合してない為みたいです。

# cd ode-0.12
# patch -p1 < /some/where/ode-0.12_freebsd.patch

configure & make

パッチがあたったら、sh autogen.shを実行して、configureスクリプトを作成します。
# sh autogen.sh
次にconfigureスクリプトに、次の引数をつけて実行します。 
# ./configure --disable-asserts --enable-shared --disable-demos --with-drawstuff=none CFLAGS="-O2 -msse -march=i686" CXXFLAGS="-O2 -msse -march=i686"
CFLAGSとCXXFLAGSに「-O2 -msse -march=i686」をつけているのは、IntelCPUのSSE命令などをつかって、ちょっとでも最適化し、性能を上げようとしてます。サーバーのCPUのアーキテクチャにあわせて、適切なものに変えるといいかもしれません(どのくらいパフォーマンスが稼げるのかは不明)。

では、ソースコードをmakeし、エラーがなければインストールします。
# make
...
... 
# make install
...
...
インストールが完了したら、OpenSim.exeを再起動します。エラーなく起動されればOK。

動作確認

さて、うまくうごいているか動作を確認してみます。
まずは、CUBE を500個だし、物理属性をつけます。

 

 だんだん崩れていきます。


 ぺっちゃんこになりました。


さすがに、500個も物理オブジェクトを出すと、身動きがとれません。ちなみにOpenSimを動かしているコンピュータは、Intel ATOM D525、メモリ4GBです。


 CUBEの中を歩き回ります。まともに動けませんけど、OpenSimは落ちないみたいです。


この時の、topコマンドによるプログラムの状態は、次の通りです。
last pid: 86961;  load averages:  1.13,  0.77,  0.48                                           up 5+10:20:55  01:07:55
93 processes:  2 running, 88 sleeping, 3 stopped
CPU: 25.5% user,  0.0% nice,  2.3% system,  0.0% interrupt, 72.1% idle
Mem: 503M Active, 2020M Inact, 224M Wired, 61M Cache, 112M Buf, 188M Free
Swap: 2048M Total, 2528K Used, 2045M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
86679 opensim    53  44    0   413M   322M ucond   3  10:17 104.98% mono
 1673 mysql      16  50    0   192M 45656K sigwai  2   7:24  0.00% mysqld
 2242 opensim     1  44    0 11900K  8732K select  0   0:54  0.00% screen
68091 opensim     1  44    0  3688K  1688K CPU2    1   0:04  0.00% top
 1685 root        1  44    0  3384K  1120K nanslp  1   0:04  0.00% cron
 1460 root        1  44    0  3352K  1096K select  1   0:03  0.00% syslogd
.....
.....
.....
重いのは重いけど、sshで接続しているセッションは普通に操作できます。
また、私のリージョンサーバーは、現在4つのリージョンがあるのですが、CUBEをぶちまけた隣のリージョンにテレポートしたら、そこでは普通にうごけました。

また、500個も物理オブジェクトをぶちまけると、次のような警告がOpenSimのコンソールに沢山でます。
01:04:41 - [PHYSICS]: Physical Object went out of bounds.
01:04:41 - [PHYSICS]: Physical Object went out of bounds.
...
... 途中省略 ...
...
01:05:01 - [PHYSICS]: Physical Object went out of bounds.
01:05:03 - [PHYSICS]: Physical Object went out of bounds.
01:05:03 - [PHYSICS]: Physical Object went out of bounds.
Region (root) #

これらのオブジェクトは、地面の下にもぐっていたり、リージョン境界でぐるぐるまわってたり、隣のリージョンまでいってしまってたりします。ビュアーのArea Search等で、オブジェクトを探して、一つ一つ削除していかないといけなくなります(>_<)。作業を簡単にするため、あらかじめ物理オブジェクトには、検索しやすいような名前をつけておくことをお勧めします。

まとめ


まだ、もっと様子をみないといけないけど、ODEがいきなり落ちてしまうということはなくなったかもしれません。

投稿者 時刻: 0 件のコメント:
ラベル:

2012年9月16日日曜日

プロセスのメモリ上限を増加させた(ODEがエラーで落ちた)

ODEがエラーで落ちるという件ですが、プロセスが使えるメモリ上限が少ないためにでていたのかもしれません。OpenSimのサイトの次のページを見てみると、Linuxの場合プロセスが使うスタックの最大サイズを262144KBにしろとあります。
http://opensimulator.org/wiki/PhysicsEngines
In Linux you should consider using included shell script, opensim-ode.sh or type ulimit -s 262144 before running mono OpenSim.exe if you plan on having a large number of physics objects (each avatar is a physics object, as well as those which have the physics flag set on the simulator). The ulimit -s 262144 in Linux protects you against stack collisions and corrupted memory when there are a large amount of physical objects roaming around.
(個々のアバターは、物理オブジェクトと同じ扱い)
 
 FreeBSDの場合、カーネルパラメーターでプロセスが確保できる、データサイズ、スタックサイズ等の上限が設定されています(これ以上は指定しても増えない)。
# sysctl kern.maxdsiz kern.maxssiz
kern.maxdsiz: 536870912
kern.maxssiz: 67108864
このサイズはすべてのプロセスの最大値なので、すべてのプロセスはこの上限を超えてメモリを確保することはできません。プロセス毎に小さく設定することはできます。また、子プロセスは親プロセスのリソース制限を(ファイルディスクリプタや、環境変数などと同じように)継承します。

現在のプロセス(というか対話しているshell)のリソース制限値は次のようにして調べられます(limit, ulimit という csh, sh の内蔵コマンドでも表示できる)。
# /usr/bin/limits
Resource limits (current):
  cputime              infinity secs
  filesize             infinity kB
  datasize               524288 kB
  stacksize               65536 kB
  coredumpsize         infinity kB
  memoryuse            infinity kB
  memorylocked         infinity kB
  maxprocesses             5547
  openfiles               11095
  sbsize               infinity bytes
  vmemoryuse           infinity kB
  pseudo-terminals     infinity
  swapuse              infinity kB
これをみると、データーサイズ 524288KB、スタックサイズ 65536KBで、OpenSimのサイトの注意書きにあるスタックサイズ262144 KBにくらべて小さすぎることがわかります。

大きくするには、/boot/loader.conf に次のように設定します。
#
# for OpenSim ODE(Open Dynamic Engine).
# ODE require  262144KB or more Stack Size.
# 
kern.maxdsiz="1024M"
kern.maxssiz="512M"
(#はコメントなのでいらないけど、後でなぜそうしたのかわかるように書いておくほうが吉。)
まあ、これだけ大きければOKかも。でも大きいということは、メモリリークするプログラムとかがあった場合、検出するまでに時間がかかったり、検出した時点では、システムのメモリ使い尽くしてしまっててOSごと落ちるということもないとは言えないので、ある意味慎重に設定したほうがいいとは思います。

こうしておいて、OpenSimを立ち上げると、140個ぐらいの物理属性つけたCUBE をぶちまけても落ちなくなりました。ただし、そのリージョンではすべての動作が遅くなり、すごく重くなります。まあ、すべてのフレームにおいて、物理オブジェクトの位置と回転を計算し、その変化した位置情報をビュアーにUDPパケットで送らないといけないので、CPUも使うし通信するデータ量もかなり増えてしまうからなんだろうとは思いますが....。OpenSim.iniのパラメータをいじったら、すこし緩和できたりするのかしら?






 ただ、落ちなくなるといっても限界があり、260個ぐらいだして、ぶちまけたCUBEのなかをアバターで歩き回るとやはり前のようなエラーがでました。
ODE INTERNAL ERROR: disabled body tagged
Stacktrace:

  at (wrapper managed-to-native) Ode.NET.d.WorldQuickStep (intptr,single) <0xffffffff>
  at OpenSim.Region.Physics.OdePlugin.OdeScene.Simulate (single) <0x01383>
  at OpenSim.Region.Framework.Scenes.SceneGraph.UpdatePhysics (double) <0x00029>
  at OpenSim.Region.Framework.Scenes.Scene.Update (int) <0x004af>
  at OpenSim.Region.Framework.Scenes.Scene.Heartbeat () <0x000bf>
  at System.Threading.Thread.StartUnsafe () <0x00059>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0xffffffff>
Abort (core dumped)
この、「ODE INTERNAL ERROR: disabled body tagged」ってのが出る条件が良くわからない。中身を理解するのは、私のレベルでは無理だけど、エラーがでて、システムがとまってしまうのは困るなぁ...。
投稿者 時刻: 0 件のコメント:
ラベル:
登録: 投稿 (Atom)