組んだばかりのP8BにQueueManagerをインストールしてクライアント(Nodeというらしい)として実行すると、しばらくは問題なく動いているが、突然Node側のメモリの使用量が増えはじめて、99%になってシステムがフリーズする。
OSはWindows 7 Pro 64BIT、メモリーは4GB x 2の8GBだ。
別のPCでQueueManagerをサーバー(Hostというらしい)として実行してあって、P8B(Node側)でQueueManagerを起動してからしばらく経つと、今のところ確実にこの現象が再現する。
QueueManagerはPOSER Pro 2012のインストーラーでインストール時にQueueManagerだけをインストールするオプションでインストールした後、QueueManager2012-SR2_winを実行してアップデートしたものだ。
現時点では原因も対策も不明だ。
追記(2012/08/18)
その後、SmithMicroのサポートとのやりとりで、どうやらネットワークを介したデータのやり取りに不具合があり、それが原因ではないかということになっていた(現地時間 08/08/2012 04:54 AM)が、しばらくしてSR3が出て、QueueManagerに関する修正ポイントとして
Queue Manager
· Fixed problems with texture reference resolution when sending to Queue Manager
· Fixed case where network disruption would cause instability in remote nodes
のような２点がリストアップされていた。
このうちの後者の方がSmithMicroのサポートが伝えて来た原因に該当するものだと思われた。
事実、SR3へのアップデート後、360フレームの動画のレンダリングを以前と同じ環境でやってみたが、不具合は一切出ずに完了した(これは早とちりで、実際は別の問題が発生。下記追記を参照のこと)。
追記(2012/08/25)
18日には「不具合は一切出ずに」と書いたが、実は大間違いで、メモリーのリークっぽい現象でフリーズ状態になる現象は出なくなったが、その代わりにフレームをすっ飛ばしてくれるようになってしまった。
360フレームくらいの動画をQueueManagerにレンダリングさせると、正常なら指定したフォルダに360枚の連続した画像が作成されるのだが、QueueManagerのステータスで完了を示しているのに、ファイルを数えると336枚しかないとかいう状態になった。24枚のレンダリング結果がどこかへ無くなってしまったのだ。
１枚２枚なら今までもよくあったことだが、今回は360枚あたり10～30のファイルがランダムに、無くなるのか、そもそもレンダリングしてないのか知らないが、とにかく、フォルダに全ファイルが揃うことが一切なくなってしまった。
ランダムにぽつぽつと何十枚も歯抜けするというのは最悪の不便さだ。
再びSmithMicroのサポートに相談したら、「無くなるのはいつも同じか？」とか「無くなったのはNode側で受け持ったものかHost側で受け持ったものか？」とか言ってきて、「んなの覚えてねえよ。」「どうやったら受け持ちが分かるんだよ。」と言ったら、「QueueManagerにログが表示されているはずです。」と言うので、合わせて4MB近くになるログのファイルを「はい、ログです。」とだけ書いて送ってやった(現地時間 08/23/2012 10:39 AM)。
送ってから、少し冷静になって考えると、ふと思うところがあったので、いろいろ検索して調べた結果を参考にして、ネットワーク関連の設定をいろいろ変更した。
なんと症状がすっかり改善してしまった。
実は、SNPを無効にしたら、症状が出なくなったのだ。Windows 7でSNPを無効にする方法は別の記事に書いた。
今度こそ、一件落着となって欲しいものだ。
追記(2012/08/28)
サポートからやっと返事が来た(現地時間 08/27/2012 01:34 PM)。
「Queue Managerを再起動すればミスったファイルを再度レンダリングするはずだ。」と言ってきた。
「Queue Managerは自分じゃ完了したつもりになってて再起動しても何にもやらねえよ。まさか、ずっとチェックしてて、ロストしたら再起動しろってか？それは無理。」と返信しておいた。Queue Managerが表向きは正常終了を装っていることがちゃんと伝わっていなかったようだ。
さらに「『再起動ボタン』とか『再レンダリングボタン』とかをつけるように提案しておく。」とか書いてあった。
ログを参照してミスったものをもう一度レンダリングするというようなことも書いてあったが、その機能は確かに有用だが、なんか根本が違う。
なんで「途中でロストしてもそのまま放置」という仕様なのか理解できない。
素人なんでよく分からないが、PC間のLANでの接続が常に完璧で、ネットワーク関連のあれこれが全て完璧に動作し続けることが前提のネットワーク・レンダリングなんて、ちょっと手抜きのし過ぎじゃね？
双方向の通信が可能なはずなのに、エラー無く通信が完了したかの確認をやらずに、一方的なデータのやり取りで済ませているのは、プログラマの怠慢だと思う。
あまりに的を外れてるので、直ったことは書かずに、「このままじゃQueueManagerの意味が無いし、Proの意味も無いね。」とも書いてやった。
現状でSNP無効後のQueue Managerの調子はどうかというと、それぞれ360、180、90、360、360、360フレームの６つのレンダリングを行って、フレームをロストしたのは90フレームの動画のときに１フレームだけという成績だ。この程度なら許容範囲だし、SNP関連が不具合の原因だったと考えて間違いないだろう。サポートには伝えてないが。
追記(2012/08/29)
サポートからの最後の連絡があった。
というかもう返事する必要もないのだが、お決まりの「プロジェクトチームに連絡しておいた。」ってヤツ。
これは、経験上、SmithMicroのサポートでは「あんたには付き合ってられないから、もう何も聞かないでね。」という意味と同じ。
どうせ次のSR版が出るまでは指をくわえて待つか、自分で解決策をひねり出すしかないからだ。
ま、でも、イーフロンティアさんの頃に比べれば、一応出来る範囲の対応はするし、SR版も比較的よく出す方だよね。
