read.cgi再開発スレ Part2
■ このスレッドは過去ログ倉庫に格納されています
◆cZfSunOs.Uさん作成のmod_cgidsoにより、大きな負荷軽減が図られたread.cgi。
このスレでは、そんなread.cgiの(再)開発・実装すべき機能について取り扱います。
前スレより:
574 名前：FOX ★[sage] 投稿日：05/01/05 15:54:28 ID:???
全てのサーバ cobra/toger/banana で read.cgi の dso化が完了。
これから href の置き換え ime.nu 対応を行い
それが終了したら第一ステップは完。
第２ステップは
2-1) bug つぶし
2-2) 仕様の変なところは変更
2-3) 時代背景にあわせたデコレーション
こんなとこかと、
前スレ:
read.cgi再開発スレ
http://qb5.2ch.net/test/read.cgi/operate/1087199303/ >>423
> proxy 関連の設定はどうなってますか？
# livejupiter
ProxyPass /livejupiter/SETTING.TXT !
ProxyPass /livejupiter/ http://live22x.2ch.net/livejupiter/
ProxyPassReverse /livejupiter/ http://live22x.2ch.net/livejupiter/
です。 >>425 了解です．zz_filesize の型は良かったのですが，
>*p = '\0' ;
があるので apr_brigade_pflatten() のところはこうした方がよさそうです．
- apr_brigade_pflatten(f.ctx, &ch2->BigBuffer, &ch2->zz_filesize, r->pool);
+ apr_off_t blen;
+ apr_brigade_length(f.ctx, 1, &blen);
+ ch2->zz_filesize = blen;
+ ch2->BigBuffer = apr_palloc(r->pool, ch2->zz_filesize + 1);
+ apr_brigade_flatten(f.ctx, ch2->BigBuffer, &ch2->zz_filesize);
>>426 了解です．特に問題はなさそうですね．何が起こってるのかトレースできればいいんですが...... ううむ、>>422 のようです。>>427
で、ch2->BigBuffer は、dso_main で最初に、
CH2READ ch2 ;
と言っていて、CH2READ は、構造体になっているです。
で、その中でこんなかんじでとっているです。
つまり、apr_pallocで取っているわけではないみたい。
char BigBuffer[SZ_BIGBUF] ; で、入れてみましたが、
・バーチャルホスト毎の access.log error.log は出ない
・一番親のログは >>422
のようです。 >>428 なるほど．とするとこんな感じですか......
apr_off_t blen;
apr_brigade_length(f.ctx, 1, &blen);
if ((ch2->zz_filesize = blen) >= SZ_BIGBUF)
return 何かのエラー番号;
apr_brigade_flatten(f.ctx, ch2->BigBuffer, &ch2->zz_filesize);
# デカい構造体をスタックに確保するってのはちょっと不安があるわけですが，
# 今までそれで動いてたのなら今回の問題とは無関係だろうということで......
で......死んだ時の core のバックトレースを取るとか，truss でトレースするとか
できますでしょうか......？ 現在のもの:
+#ifdef SNOWMAN
+static apr_status_t rdat_filter(ap_filter_t *f, apr_bucket_brigade *b)
+{
+ return ap_save_brigade(f, (apr_bucket_brigade **)&f->ctx, &b, f->r->pool);
+}
+#endif
+#ifdef SNOWMAN
+ int rv;
+#if defined(AP_SERVER_MINORVERSION_NUMBER) && AP_SERVER_MINORVERSION_NUMBER >= 2
+ ap_filter_rec_t frec = {"READDAT", {rdat_filter}, NULL, AP_FTYPE_RESOURCE, NULL, NULL, 0, 0};
+#else
+ ap_filter_rec_t frec = {"READDAT", {rdat_filter}, NULL, AP_FTYPE_RESOURCE, NULL};
+#endif
+ ap_filter_t f = {&frec, NULL, NULL, r, r->connection};
+ char *uri = apr_pstrcat(r->pool, "/", ch2->zz_ita, "/dat/", ch2->zz_key, ".dat", NULL);
+ request_rec *rdat = ap_sub_req_lookup_uri(uri, r, &f);
+
+ if (!(rv = rdat->status == HTTP_OK ? ap_run_sub_req(rdat) : rdat->status)) {
+ apr_off_t blen;
+ apr_brigade_length(f.ctx, 1, &blen);
+ ch2->zz_filesize = blen;
+ apr_brigade_flatten(f.ctx, ch2->BigBuffer, &ch2->zz_filesize);
+ apr_brigade_destroy(f.ctx);
+ ch2->zz_mtime = rdat->mtime ? rdat->mtime
+ : apr_date_parse_http(apr_table_get(rdat->headers_out, "Last-Modified"));
+ }
+ ap_destroy_sub_req(rdat);
+
+ if (!rv) {
+ ch2->where = W_LIVE;
+ return 1;
+ }
+#else
(続く) >>430
何かのエラー番号: datが大き杉
ってことですかね。
で、Apacheのcoreをとるには、、、。 if(ch2->zz_filesize > SZ_BIGMAX) return 3002 ;
だから、3002でいいのかな。 ということで、今こうです。
結果は同じか。
で、core dumpとってみるです。
+#ifdef SNOWMAN
+ int rv;
+#if defined(AP_SERVER_MINORVERSION_NUMBER) && AP_SERVER_MINORVERSION_NUMBER >= 2
+ ap_filter_rec_t frec = {"READDAT", {rdat_filter}, NULL, AP_FTYPE_RESOURCE, NULL, NULL, 0, 0};
+#else
+ ap_filter_rec_t frec = {"READDAT", {rdat_filter}, NULL, AP_FTYPE_RESOURCE, NULL};
+#endif
+ ap_filter_t f = {&frec, NULL, NULL, r, r->connection};
+ char *uri = apr_pstrcat(r->pool, "/", ch2->zz_ita, "/dat/", ch2->zz_key, ".dat", NULL);
+ request_rec *rdat = ap_sub_req_lookup_uri(uri, r, &f);
+
+ if (!(rv = rdat->status == HTTP_OK ? ap_run_sub_req(rdat) : rdat->status)) {
+ apr_off_t blen;
+ apr_brigade_length(f.ctx, 1, &blen);
+ if ((ch2->zz_filesize = blen) >= SZ_BIGBUF)
+ return 3002;
+ apr_brigade_flatten(f.ctx, ch2->BigBuffer, &ch2->zz_filesize);
+ apr_brigade_destroy(f.ctx);
+ ch2->zz_mtime = rdat->mtime ? rdat->mtime
+ : apr_date_parse_http(apr_table_get(rdat->headers_out, "Last-Modified"));
+ }
+ ap_destroy_sub_req(rdat);
+
+ if (!rv) {
+ ch2->where = W_LIVE;
+ return 1;
+ }
+#else >>432
CoreDumpDirectory /tmp
とかで（httpd プロセスが書き込み可能なディレクトリを指定）．
>>433 というか，lookfor() はエラー時 0 を返すので，とりあえずその部分では
- return 何かのエラー番号;
+ return 0;
にしないとしょうがないですか...... >>435
設定してみた。
で、
if(!lookfor(ch2,r)) return 3001 ;
なので、return 0ですか。 ううむ、core dumpしないみたいです。
[Mon Dec 05 10:25:09 2005] [notice] child pid 74701 exit signal Segmentation fault (11)
# XXX
CoreDumpDirectory /tmp
を、httpd.conf に書いたのですが。 そうか.....httpd が最初に root で立ち上がってると OS のデフォルトでは
core 吐かないようになってるのかな......とすると，とりあえず直接 User
ディレクティブで指定してるユーザで立ち上げてみるとか...... 302 みたいです。<= rdat->status core dumpしてるの、ここじゃないですね。
もっとあとみたい。 ap_rprintf(r, "%s\n", ch2->BigBuffer);
ってやっても、なんかちゃんと出ないみたい。 >>441-445 乙です．こちらのローカル環境ではOkなんですが，う〜む...... -funsigned-char しているせいかなぁ、、、。 strlen(ch2->BigBuffer) が、3らしい。ううむ。 う〜む......原因もつかめないとすると......サブリクエスト方式をやめて
ソケットで localhost に取りに行く方式にした方がいいんですかねぇ．
read.cgi 1呼び出しごとに2プロセス消費することになっちゃいますが...... 同じだった。
BigBufferの最初の4バイトが、どのdatを読んでも 1f 8b 8 0 になるです。
>>449
それも、なんかしゃくですね。ううむ。 バッファを大域変数でとってみたけど、同じだった。
apr_brigade_flatten のところが、ちゃんと動いていない?? ch2->zz_filesize はどうですか......？ http://live22x1.2ch.net/test/read.cgi/livejupiter/9240000003/
を読んで、
ap_rprintf(r, "%d\n", ch2->zz_filesize);
ってやったら、832 って出たです。
実際には、1428バイトあるですね。 ってことは、、、。
ここは1Gbps内部接続だし、圧縮はなくてもいいような気もするです。 どうすんのがいいのかな。
live22のhttpdでgzipしないようにする? のも、いまいちだなぁ。
サブリクエスト(って言うんでしたっけ)の時に、no gzip にできないのかしら。 ううむ、
こりゃ、live22側のhttpdをごにょごにょするほうがよさげですね。
SetEnvIfか何か使うか。 ってことは、
・フロントエンドからのリクエストだったら、gzipかからないようにする
で、いけるのか。
やろう、やろう。 うーむ、、、。諸事情によりmod_rpaf使っているからなぁ。
REMOTE_ADDRではできないのか。
どうすべ。 とりあえず、後で考えることにして、
mod_deflateはずしておこう。 @ live22
で、read.cgiを入れてみるか。 355 ▲ ◆cZfSunOs.U sage 2005/12/06(火) 05:04:33
なぜか read.cgi スレで「連続投稿ですか？10回」とか出てしまうんで一時避難でこちらへ......
>>455-458 むむ......ってことは......
apr_table_set(r->subprocess_env, "no-gzip", "");
を ap_run_sub_req() の前に実行かな......
356 ▲ ◆cZfSunOs.U sage 2005/12/06(火) 05:13:01
apr_table_unset(r->headers_in, "Accept-Encoding");
も入れた方がいいかな......
# 相変わらずあっちに書けないんでどなたか転載して頂けると助かります......
357 ▲ ◆cZfSunOs.U sage 2005/12/06(火) 05:14:25
間違えた...... r じゃなくて rdat じゃないとダメです．
apr_table_set(rdat->subprocess_env, "no-gzip", "");
apr_table_unset(rdat->headers_in, "Accept-Encoding"); >>464
これの 357 のやつで、live22の設定をgzipありにしても動いたー。
すばらしいです。これでread.cgiもフロントにできる。 まだ #ifdef しているけど、フロント動作版 read.cgi を live22x[123] に入れた。
これで、大会前の準備はほぼすべて整いました。
深夜までつきあっていただいた SunOS さん、
それから神様 >>455 さん、ありがとう、ありがとう。 rdat(rnew)のヘッダいじるとrにも反映される予感。
2.0と2.2でちょっと違うけど、
rnew->headers_in = r->headers_in;
こんな風になってる。
envはコピーのようだけど。
rnew->subprocess_env = apr_table_copy(rnew->pool, r->subprocess_env); >>467 おぉ......となると，こうすべきですね．
# "no-gzip" は多分なしで平気ですね．
rdat->headers_in = apr_table_copy(rdat->pool, rdat->headers_in);
apr_table_unset(rdat->headers_in, "Accept-Encoding"); >>468
組み込みます。
で、昨日の会話でわかったのは、
Apache 2.2系と2.0系のread.cgiでは、バイナリレベルでの互換性がなくなるってことすね。
いずれ2.2化する時には、注意しないと。 live22x[123] に、read.cgi の広告を配布するようにした。 緊急の問題ではないですが，ここ（スタックにデカい配列・構造体を確保）が
やはりちょっと気がかりではあります．
>>428
>CH2READ ch2 ;
>char BigBuffer[SZ_BIGBUF] ;
現状では一応問題なしのようですが，もし今後マルチスレッド MPM を使用するとなると......
メイン以外のスレッドに割り当てられるデフォルトのスタックサイズはメインのより小さいです．
ulimit での指定もメイン以外のスレッドには効きません．FreeBSD での具体的数値は
わかりませんが，Solaris では 1MB(32-bit) / 2MB(64-bit) がデフォルトです．
そして，dat の最大サイズが 512kB となると......
もちろん global / static 変数はマルチスレッドではマズいんで，apr_palloc() で
ヒープ領域に確保するようにした方がよさそうです．Apache 2.2 では ThreadStackSize で
スタックサイズを指定可能なんで，それで乗り切るって手もなくはないですが...... >>471
気になりますか。
ぼちぼち、apr_palloc にしてみますか。
ちなみにそれで確保したやつって、なんか解放とかしなくていいのかしら。 >>472 malloc() だと明示的な解放が必要ですが，apr_palloc() ではプールの寿命が尽きた時点で自動解放されます．
例えばリクエストプール (r->pool) で確保すれば，リクエスト処理が完了した時点で自動解放されます． >>473
了解です。安心していいってことですね。 【きりたんぽ】雪だるま作戦に思いを馳せながら雑談するスレッド Part28
http://aa5.2ch.net/test/read.cgi/nanmin/1133468879/739-740
739 名前： ◆MUMUMUhnYI [sage] 投稿日：2005/12/07(水) 12:05:52 ?###
過去ログにいったやつが、うまく出ないみたい。< フロント版read.cgi
だめな例: 基本的にdat落ちしたやつ全部
http://live22x.2ch.net/test/read.cgi/dancesite/1115133136/
あとで、みてみるということで。
740 名前： ◆MUMUMUhnYI [sage] 投稿日：2005/12/07(水) 12:24:56 ?###
>>739
なおした。
read.cgi ver 05.0.2.1 2005/12/07
ライブなdatじゃない場合は、通常と同じ方法でディスクを参照。 >>475 乙です．
----------------------------------------------------------------------
以前 worker MPM を試してみたら SIGBUS になってしまったことがありましたが，
http://aa5.2ch.net/test/read.cgi/nanmin/1118138260/278-279n
これは >>471 の要因でスタック領域からはみ出てしまってたのかも知れませんね． >>476
なるほど、ありえますね。
# worker MPMはSpeedyCGIがそのままでは動かないかもという話も。 >>477 そのあたりはこういうことで．
# これを受けての worker MPM 挑戦だったわけで......
http://aa5.2ch.net/test/read.cgi/nanmin/1118138260/147
>そういえば...... 今 SpeedyCGI は speedy プロセス呼び出しの形で使ってますか？
>mod_speedycgi だとマルチスレッド非対応ですが，speedy プロセス呼び出しなら無関係なんで
>マルチスレッド化も可能ではあるんですが...... >>478
そっか、そうでしたね。
ってことは、再チャレンジすることもありうるのか。 でも、再チャレンジする場合、read.cgi で使用している外部関数が、
全部MT-safeじゃないと、いまいちなわけか。 >>480 APR 関数は基本的に，内部では Unsafe な関数の使用を避け (MT-)Safe になるよう
配慮されているため，APR 関数を使っているのならおおかた大丈夫かと思います．
ただ，呼び出す関数が (MT-)Safe であっても，処理の流れなどに起因して
マルチスレッド環境で問題が起こることもあり得るので（今回出てきた
スタック上の巨大変数もしかり），その点が要注意ではありますが． #include <pthread.h>
#include <stdio.h>
int main()
{
size_t size;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_getstacksize(&attr, &size);
printf("%lu\n", (unsigned long)size);
return 0;
}
----------------------------------------------------------------------
ってのを tiger (FreeBSD 5.3R) 上でやってみたら，libpthread / libthr ともに
65536 (64kB) だそうです．そりゃはみ出しますね...... /* datを読むバッファ領域を、apr_pallocで動的に確保する */
ch2->BigBuffer = apr_palloc(r->pool, SZ_BIGBUF);
にしたバージョンを、live22x2で試しました。
問題なさげ。
dso.2ch.netでも問題なければ、これで。 >>484
read.cgi ver 05.0.2.2 2005/12/10 ということで配布して20分ほど経ちましたが、
read.cgi が多い news19 / life7 / hobby あたりでも、問題なさげすね。 read.cの
#defineLINK_URL_MAXLEN256
これ。なんか大きすぎない？
普通200以上超えるURLは無いと思うんだが。 ミスorz
#define LINK_URL_MAXLEN 256
タブは無視されるのを忘れてたよﾏﾏﾝ で、今のソースもちと見てみましたが、
もっと大きな値になっているようです。 >>490そうだな・・・CGIがあったよな・・・ぬるぽ
>>491手元にあるソースは狐の人が書き換える以前のものだからね・・・bbs.cgiスレも見たけどソースは非公開っぽいし。
公開すればもっと質の高い物になると思うよひろゆきﾀﾝ >>488
まれにAAでも使う
それより15個規制はテンプレ作るとき結構きついので可能な範囲で緩和して欲しい ■>>410みたいに鯖移転前のスレは鯖移転だってことがわかるように書いたほうがいいんじゃないの
移転先で生きてるわけだし
これだと普通の過去スレと見分けがつかない ■>>2-のようにアンカーにハイフンがつきそのあとに数字がないと
アンカーそのものが無効になる不具合 何と２ちゃんねるのbbs.cgiで公式にサポートされているのは、
つまり、書き込み時に dat 内にリンクとして埋め込まれるのは、
>>mmm
と、
>>mmm-nnn
の2パターンだけなのです。
bbs.cgi は、わざわざそのように書かれています。
つまり右側に数字がないのは、アンカーではないことになります。
昨年 bbs.cgi をきっちり読むまで、
実は私もこのことは知りませんでした。はい。 read.cgi っていつまで test フォルダに入ってるの？ >>500
たぶん、ずーーーっと。
あらゆるプログラムがtestだと思い込んでいるです。
datのフォーマット同様、もう変えるのは（りゃ。 >>489
前は>>2-は>>2のアンカーとして機能してなかったっけ（ハイフンが黒になる） >>501
今日も実験、明日も、そしてあさっても（りゃ。むぎゅ。
一応書くと、アンカーは bbs.cgi だから。。 >>502
んーむ。
いずれにせよこれは、bbs.cgi の問題ですね(>>503 のとおり)。
そっちにリンク入れておくです。 >>501
逆に言えば、新スキームを導入することができたら
配置を変えられるって考えていいかな?
板名.2ch.net/read.cgi/スレ/ とか ＞逆に言えば、新スキームを導入することができたら
めんどくさがって実行しない、に一票。 >>506
現に困ってる人は(あまり)いないし、うrlがｶｺﾜﾙｲ程度だからねー
個人的には、板移転時のキレイさを鑑みて、板毎virtual host化
してほしいな〜と。DNS更新もメンドくさくなくなったようですし
そこんところどうなんでしょう? 理想は、
板トップ
http://2ch.net/board/
スレは
http://2ch.net/board/key/
雪だるまサーバ＋read.cgiにPATH_INFOを使えばいいんだ！
（かなり面倒くさいでしょうが ＞雪だるまサーバ＋read.cgiにPATH_INFOを使えばいいんだ！
＞（かなり面倒くさいでしょうが
めんどｋ(ry 見た目はともかくＵＲＬ短くすればかなり資源の節約になるんでは ソースorファイル自体を公開。
まずはそれからだ。 そうそう、gz圧縮されてない9桁keyの過去ログを、read.cgiが
探せなくなってるんだよね。
全体的に。 read.cgi ver 05.0.2.6
live22x 系(雪だるま)で、read.cgi 動作ホストを部分的にするための準備工事。
具体的にはリンクに使用するホスト名を、live22xN.2ch.net のどれで指定しても、
live22x.2ch.net になるようにするコードを追加。
これで、mod_proxy で read.cgi 動作ホストを限定させることが可能になるはず。
こうすれば、全フロントに dat を rsync する必要がなくなるはず。
というもくろみで。
# offlaw.cgi も、mod_proxy で同じ設定をする必要あり。 で、なぜ >>518 の工事が必要になるかというと、
ProxyPass /test/read.cgi/ http://live22x2.2ch.net/test/read.cgi/
ProxyPassReverse /test/read.cgi/ http://live22x2.2ch.net/test/read.cgi/
といった指定をして、live22x2 に read.cgi を集めようとした場合、
read.cgi に渡されるホスト名が live22x2.2ch.net になってしまい、
上のほうの
■掲示板に戻る■ 全部 1- 最新50
のリンクに入るホスト名も、そのままだと live22x2 になってしまうため。 …というか、ここにホスト名って、ほんとは要らない、、、のかな。
ま、いっか。
今は考えないでおこうっと。
おふろ入ってきます。 あとは、rsync の仕組みを変える(多段化)とかかなぁ。
過去ログをみつけるところが問題なわけだから。 ということで >>518 はあまり意味がないので、
追加したところを #if 0 〜 #endif で囲んでおこう。 http://qb5.2ch.net/test/read.cgi/operate/1145615267/443-453n
get.cgi の処理を 2ch 各鯖でやる部分（フロントエンド）と
p.2ch.io でやる部分（バックエンド）に分けるのも一案かな．
あるいは，もっと単純に mod_proxy + mod_cache などで
get.cgi の出力をキャッシュさせるって手も． ■ このスレッドは過去ログ倉庫に格納されています
