チケット #17254

shellサーバーの利用制限に関する質問

登録: 2009-06-10 17:15 最終更新: 2009-11-09 18:25

報告者:
担当者:
チケットの種類:
状況:
オープン [担当者決定済み]
コンポーネント:
マイルストーン:
(未割り当て)
優先度:
5 - 中
重要度:
5 - 中
解決法:
なし
ファイル:
なし

詳細

TOMOYOプロジェクトの原田です。お世話になります。

shellサーバ上で、TOMOYO Linuxパッチを当てたLinuxカーネルコードのクロスリファレンスサービスを提供しています。perlで書かれたライブラリが該当するファイルのコンテンツをHTML形式で表示するというものですが、しばらく(数ヶ月)前より、長いファイルについて表示が途切れてしまうようになりました。

http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/net/r8169.c

海外からの利用者も多く、是非サービスを継続したいので、原因がわかればご教示いただけませんでしょうか。よろしくお願い致します。

チケットの履歴 (12 件中 3 件表示)

2009-06-10 17:15 更新者: haradats
  • 新しいチケット "shellサーバーの利用制限に関する質問" が作成されました
2009-06-11 11:58 更新者: tach
  • 担当者(未割り当て) から tach に更新されました
コメント

そのプロセスは CPU パワーをたくさん利用していないでしょうか。 シェルサーバは全ユーザで共用しており、スペックも高くないことから、 CPU Time を 10分以上利用しているプロセスを強制終了しています。

もし、全ソースコードを一つのプロセスで処理しているのであれば、 たとえばファイル毎・ディレクトリ毎のように処理を分けられないでしょうか。

すみませんが、よろしくお願いします。

2009-06-11 12:06 更新者: ishikawa
コメント

tach への返信

そのプロセスは CPU パワーをたくさん利用していないでしょうか。 シェルサーバは全ユーザで共用しており、スペックも高くないことから、 CPU Time を 10分以上利用しているプロセスを強制終了しています。

いや、その事実はないようです。

動作を確認するとわかりますが、同一のページであれば 必ず同一箇所(同じバイト数)できっちりきられて同じように かえってきます。

ブラウザをかえても同じ(たとえばwgetとかでとっても同じ)なので、 CGI or 扱ってるデータそのものに問題があるように思います。

コードを少し追いかけた範囲だと、おそらくSimpleParse.pmの nextfrag()が途中で終わってしまっている or ここで扱っている $INFILE に途中までしかデータがないように思います。

(少なくとも、システム側のなんらかの制限にひっかかっているとか いう状況ではないように思います)

2009-06-11 12:45 更新者: kumaneko
コメント

ishikawa への返信

tach への返信

そのプロセスは CPU パワーをたくさん利用していないでしょうか。 シェルサーバは全ユーザで共用しており、スペックも高くないことから、 CPU Time を 10分以上利用しているプロセスを強制終了しています。

はい。インデックスの作成操作には CPU Time を 10 分以上消費してしまうため、 現在はシェルサーバ上で作成するのではなく、ローカルで作成したものを scp で アップロードするという運用を行っています。(インデックスファイルの互換性が 無いという可能性もありますが、それを確認するためには、シェルサーバ上で インデックスの作成をしてみる必要があります。)

いや、その事実はないようです。

はい。インデックスからの検索処理は短時間で終わるので、 CPU Time の使いすぎで切れているとは考えられません。

動作を確認するとわかりますが、同一のページであれば 必ず同一箇所(同じバイト数)できっちりきられて同じように かえってきます。

こちらで何度かリロードしてみたところ、 2716, 3235, 3144, 3205, 3114, 2716, 3114, 3114 行目で切れてしまいました。 3114 行目で切れることが多いですが、 常に同一箇所ではないようです。ファイルからの読み込みが途中でエラーを 起こしているか、プロセスが SEGV のようなエラーを起こしているような気もします。 お手数ですが dmesg などに変なエラーが出ていないか ご確認いただけませんでしょうか?

2009-06-11 13:15 更新者: ishikawa
コメント

kumaneko への返信

動作を確認するとわかりますが、同一のページであれば 必ず同一箇所(同じバイト数)できっちりきられて同じように かえってきます。

こちらで何度かリロードしてみたところ、 2716, 3235, 3144, 3205, 3114, 2716, 3114, 3114 行目で切れてしまいました。 3114 行目で切れることが多いですが、 常に同一箇所ではないようです。

そのようですね。apache のアクセスログを見ましたが必ずしも返している バイト数が同じだとは限らないように見えます。同一のサーバにおいても、 異なった値になるときがあるようで、サーバごとの差異でもないですね。

ファイルからの読み込みが途中でエラーを 起こしているか、プロセスが SEGV のようなエラーを起こしているような気もします。 お手数ですが dmesg などに変なエラーが出ていないか ご確認いただけませんでしょうか?

確認しましたが、apacheのエラーログにもdmesgにもとくになにか関連しそうな メッセージはありません。

2009-06-12 00:27 更新者: 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がエラい時間を食っている状況に なっています。

なにか心当たりはございませんでしょうか?

2009-06-15 11:48 更新者: 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 さん

ローカルで作成するときに使用している Perl のバージョンについて確認ください。> haradats さん

あと、念のため i386 か x86_64 かも確認した方が良いかも?

2009-06-15 12:02 更新者: 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)

2009-06-15 12:07 更新者: 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)

のようですね。

2009-06-15 15:45 更新者: 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)

2009-06-15 15:53 更新者: 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サーバ側でリストアできるかは、まだ試していません)。

2009-11-09 18:25 更新者: sado
  • 担当者tach から sugi に更新されました

添付ファイルリスト

添付ファイルはありません

編集

ログインしていません。ログインしていない状態では、コメントに記載者の記録が残りません。 » ログインする