haradats 
tach そのプロセスは CPU パワーをたくさん利用していないでしょうか。 シェルサーバは全ユーザで共用しており、スペックも高くないことから、 CPU Time を 10分以上利用しているプロセスを強制終了しています。
もし、全ソースコードを一つのプロセスで処理しているのであれば、 たとえばファイル毎・ディレクトリ毎のように処理を分けられないでしょうか。
すみませんが、よろしくお願いします。
ishikawa tach への返信
そのプロセスは CPU パワーをたくさん利用していないでしょうか。 シェルサーバは全ユーザで共用しており、スペックも高くないことから、 CPU Time を 10分以上利用しているプロセスを強制終了しています。
いや、その事実はないようです。
動作を確認するとわかりますが、同一のページであれば 必ず同一箇所(同じバイト数)できっちりきられて同じように かえってきます。
ブラウザをかえても同じ(たとえばwgetとかでとっても同じ)なので、 CGI or 扱ってるデータそのものに問題があるように思います。
コードを少し追いかけた範囲だと、おそらくSimpleParse.pmの nextfrag()が途中で終わってしまっている or ここで扱っている $INFILE に途中までしかデータがないように思います。
(少なくとも、システム側のなんらかの制限にひっかかっているとか いう状況ではないように思います)
ishikawa への返信
tach への返信
そのプロセスは CPU パワーをたくさん利用していないでしょうか。 シェルサーバは全ユーザで共用しており、スペックも高くないことから、 CPU Time を 10分以上利用しているプロセスを強制終了しています。
はい。インデックスの作成操作には CPU Time を 10 分以上消費してしまうため、 現在はシェルサーバ上で作成するのではなく、ローカルで作成したものを scp で アップロードするという運用を行っています。（インデックスファイルの互換性が 無いという可能性もありますが、それを確認するためには、シェルサーバ上で インデックスの作成をしてみる必要があります。）
いや、その事実はないようです。
はい。インデックスからの検索処理は短時間で終わるので、 CPU Time の使いすぎで切れているとは考えられません。
動作を確認するとわかりますが、同一のページであれば 必ず同一箇所(同じバイト数)できっちりきられて同じように かえってきます。
こちらで何度かリロードしてみたところ、 2716, 3235, 3144, 3205, 3114, 2716, 3114, 3114 行目で切れてしまいました。 3114 行目で切れることが多いですが、 常に同一箇所ではないようです。ファイルからの読み込みが途中でエラーを 起こしているか、プロセスが SEGV のようなエラーを起こしているような気もします。 お手数ですが dmesg などに変なエラーが出ていないか ご確認いただけませんでしょうか？
ishikawa kumaneko への返信
動作を確認するとわかりますが、同一のページであれば 必ず同一箇所(同じバイト数)できっちりきられて同じように かえってきます。
こちらで何度かリロードしてみたところ、 2716, 3235, 3144, 3205, 3114, 2716, 3114, 3114 行目で切れてしまいました。 3114 行目で切れることが多いですが、 常に同一箇所ではないようです。
そのようですね。apache のアクセスログを見ましたが必ずしも返している バイト数が同じだとは限らないように見えます。同一のサーバにおいても、 異なった値になるときがあるようで、サーバごとの差異でもないですね。
ファイルからの読み込みが途中でエラーを 起こしているか、プロセスが SEGV のようなエラーを起こしているような気もします。 お手数ですが dmesg などに変なエラーが出ていないか ご確認いただけませんでしょうか？
確認しましたが、apacheのエラーログにもdmesgにもとくになにか関連しそうな メッセージはありません。
ishikawa ishikawa への返信
そのようですね。apache のアクセスログを見ましたが必ずしも返している バイト数が同じだとは限らないように見えます。同一のサーバにおいても、 異なった値になるときがあるようで、サーバごとの差異でもないですね。
ファイルからの読み込みが途中でエラーを 起こしているか、プロセスが SEGV のようなエラーを起こしているような気もします。 お手数ですが dmesg などに変なエラーが出ていないか ご確認いただけませんでしょうか？
確認しましたが、apacheのエラーログにもdmesgにもとくになにか関連しそうな メッセージはありません。
状況がわかりました。apacheに設定されているCPU RLIMIT(3秒に設定されています) にひっかかってるようです。
この3秒が妥当なのかというのは一つあることはあるんですが、 どうも、現状そこで動いている lxr の動作が異常に遅い様子で、 profileすると
sf-usr-shell:~$ cd /home/groups/t/to/tomoyo/cgi-bin/lxr sf-usr-shell:/home/groups/t/to/tomoyo/cgi-bin/lxr$ PERL_DPROF_OUT_FILE_NAME=~/tmon.out PATH_INFO=/drivers/net/r8169.c perl -d:DProf /home/groups/t/to/tomoyo/cgi-bin/lxr/source > /dev/null sf-usr-shell:/home/groups/t/to/tomoyo/cgi-bin/lxr$ dprofpp ~/tmon.out | head -6 Total Elapsed Time = 5.558558 Seconds User+System Time = 5.448558 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 62.8 3.425 3.425 7352 0.0005 0.0005 DB_File::FETCH 25.2 1.374 5.610 1 1.3736 5.6100 LXR::Common::markupfile
といった感じで、なぜかDB_FILE::FETCHがエラい時間を食っている状況に なっています。
なにか心当たりはございませんでしょうか?
といった感じで、なぜかDB_FILE::FETCHがエラい時間を食っている状況になっています。
解析ありがとうございます。
「DB_File::FETCH slow」で検索してみたところ、 Perl のバージョンによって Berkeley DB のフォーマットが違うようです。
http://www.mail-archive.com/perl-win32-users@listserv.activestate.com/msg26256.html
同じバージョンの Perl で作成すれば解決する可能性があります。
tomoyo.sourceforge.jp で使われている Perl のバージョンについて教えてください。＞ ishikawa さん
ローカルで作成するときに使用している Perl のバージョンについて確認ください。＞ haradats さん
あと、念のため i386 か x86_64 かも確認した方が良いかも？
ishikawa kumaneko への返信
といった感じで、なぜかDB_FILE::FETCHがエラい時間を食っている状況になっています。
解析ありがとうございます。 「DB_File::FETCH slow」で検索してみたところ、 Perl のバージョンによって Berkeley DB のフォーマットが違うようです。 http://www.mail-archive.com/perl-win32-users@listserv.activestate.com/msg26256.html 同じバージョンの Perl で作成すれば解決する可能性があります。 tomoyo.sourceforge.jp で使われている Perl のバージョンについて教えてください。＞ ishikawa さん
5.8.8 です。 (debian 的にいうと、5.8.8-7etch6 です)
ローカルで作成するときに使用している Perl のバージョンについて確認ください。＞ haradats さん あと、念のため i386 か x86_64 かも確認した方が良いかも？
i386 です(32bit kernel/32bit userland)
ishikawa ishikawa への返信
kumaneko への返信
といった感じで、なぜかDB_FILE::FETCHがエラい時間を食っている状況になっています。
解析ありがとうございます。 「DB_File::FETCH slow」で検索してみたところ、 Perl のバージョンによって Berkeley DB のフォーマットが違うようです。
>
http://www.mail-archive.com/perl-win32-users@listserv.activestate.com/msg26256.html 同じバージョンの Perl で作成すれば解決する可能性があります。
うーん、いま確認してみたところ BDB のファイル自体は fileコマンドでみた範囲だと
Berkeley DB (Hash, version 8, native byte-order)
のようですね。
haradats Reply To ishikawa
kumaneko への返信
といった感じで、なぜかDB_FILE::FETCHがエラい時間を食っている状況になっています。
解析ありがとうございます。 「DB_File::FETCH slow」で検索してみたところ、 Perl のバージョンによって Berkeley DB のフォーマットが違うようです。 http://www.mail-archive.com/perl-win32-users@listserv.activestate.com/msg26256.html 同じバージョンの Perl で作成すれば解決する可能性があります。 tomoyo.sourceforge.jp で使われている Perl のバージョンについて教えてください。＞ ishikawa さん
5.8.8 です。 (debian 的にいうと、5.8.8-7etch6 です)
ローカルで作成するときに使用している Perl のバージョンについて確認ください。＞ haradats さん
ご対応ありがとうございます。 ローカルでの環境ですが、Windows VISTA上のcygwinで、v5.10.0のperlを使っています。
あと、念のため i386 か x86_64 かも確認した方が良いかも？
i386 です(32bit kernel/32bit userland)
haradats Reply To ishikawa
ishikawa への返信
kumaneko への返信
といった感じで、なぜかDB_FILE::FETCHがエラい時間を食っている状況になっています。
解析ありがとうございます。 「DB_File::FETCH slow」で検索してみたところ、 Perl のバージョンによって Berkeley DB のフォーマットが違うようです。
>
http://www.mail-archive.com/perl-win32-users@listserv.activestate.com/msg26256.html 同じバージョンの Perl で作成すれば解決する可能性があります。
うーん、いま確認してみたところ BDB のファイル自体は fileコマンドでみた範囲だと {{{ Berkeley DB (Hash, version 8, native byte-order) }}} のようですね。
当初は、インデックスの生成についてシェルサーバ上で行っていましたが、2.6カーネルの肥大化によりたまに処理が中止されるようになりました（cpu時間の制限です）。そこで、最初は、個人持ちのDebian (lenny)上でローカルにクロスリファレンスを生成し、shellサーバにアップロードしていたのですが、動作せず、調べてみるとBerkley DBのバージョンが違うことが判明（確かDebianの環境では、version 7でした）。Debianの環境を更新することも考えたのですが、面倒だったので、Cygwin上でリファレンスを生成、shellサーバに転送するという運用を採用しています。
「DB_FILE::FETCHがエラい時間を食っている」理由は、単純にクロスリファレンスのサイズが巨大なことが原因ではないかと思われます。サーバ側の制限を変更する（ゆるめる）ことができなければ、インデックスファイルの生成と参照を分割するか、あるいは、MySQLを使う新しいlxrに移行すれば「参照時間」の制限はクリアできるでしょう（ただ、ローカルの環境でダンプしたMySQLのデータをshellサーバ側でリストアできるかは、まだ試していません）。
sado 
OSDN Admin
sugi
TOMOYOプロジェクトの原田です。お世話になります。
shellサーバ上で、TOMOYO Linuxパッチを当てたLinuxカーネルコードのクロスリファレンスサービスを提供しています。perlで書かれたライブラリが該当するファイルのコンテンツをHTML形式で表示するというものですが、しばらく（数ヶ月）前より、長いファイルについて表示が途切れてしまうようになりました。
例 http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/net/r8169.c
海外からの利用者も多く、是非サービスを継続したいので、原因がわかればご教示いただけませんでしょうか。よろしくお願い致します。