bbs.cgi再開発プロジェクト 3
■ このスレッドは過去ログ倉庫に格納されています
読み出す側で1001以上出力しないようにして、 レス数1000超えてたら自動的に1001のレスを付加してやったらええんでないの? 見た目1001超えなければ、書き込みも減る=妙な鯖負荷も減るだろうし。 で、状況見て書き込み側を改良していけばいいような。 >>94 それだと書き込みが「吸い込まれ」たことにならない? 「絶対に上がらないスレ」ってできませんかね? bbs.cgiで>>1 のメール欄を見て「sagesage」だったら 書き込みのメール欄の先頭に「sage」を追加する、とか。 重くなるだけで利用価値ないかな。 ていうか、そんなことを2ちゃんねるでやる必要性が感じられないな。 sageだかageだか知らないけど、2ちゃんねるはスレッドフロート式なんだから、 sage進行信仰に対する一つの答えを出すことに意味があるのですか? さあ?意味なんて考えてもみませんでした。 やったら、できたら、そうなったら面白さの幅が広がるかな、と思っただけですよ。 それがおもしろそうな機能には見えなかったんでね。 わざわざcgiを改造してまで追加する価値があるような おもしろい機能とは思えないですよ。ageらないスレなんて。 うーん、やっぱダメかなぁ。 2ちゃんねるの根幹をゆるがす面白さだと思ったんですが。 (´・ω・`)ショボーン ただ、おもしろいかどうかは個人の主観なので、 おれは全然おもしろくない機能だと思うのですが、 ひろゆきがおもしろいと思えばありだとは思うんですけどね。 あと、sageっぱなしだと他の人が入ってこないのでどうしても馴れ合いが 進んでしまう、と考えられる点もマイナスポイントかも。 ああ、馴れ合いの問題はありますね。 適用してみたいと思ったのは次のようなスレです。 ・+系板の雑談スレ ・AA系の板のスレ ・自己紹介板のスレ ・bbspinkの一部スレ ・ネタスレ ひ(ryは面白がらないっぽいなあ。 なんかそんな気がしてきますた。 実況鯖だけインビジチューニングとか?(そりゃダメだろ 1.スレッド立てる人はスレが荒れてほしくないと思い強制sage進行スレに指定 2.70%のスレが強制sage進行スレとなる 3.スレはだいたい立てた順番にならぶ 4.sageの価値そのものが低くなる こうなっちゃうんじゃない? むかしむかし、スレタイに「(10000)」と入れると上げられないスレにできたけど 「バグ」として修正されたことを考えると望み薄では 一応こちらで。 2chの動作報告はここで。 パート10 http://qb3.2ch.net/test/read.cgi/operate/1076174286/528 528 :FOX ★:04/02/25 21:44 ID:??? 問題は処理の順番というか・・・ 1) bbs.cgi の中盤で dat に追記 2) bbs.cgi の後半で subject.txt を書き換え 3) この時 dat 内のレス数カウント 4) ついでに 1,000 超え判定 → 1,001 書き込んでパーミッション変更 5) しかし既にこのときには次のbbs.cgiが目前までせまっているらしい。 1)の前に3)4)を入れられないのかと。 それだけでover 1000の書き込みははねられ、 それだけDisk I/Oの負荷が減ると思われ。 何でこんな処理になっていたんでしょ。 理由が知りたい。 >>112 最初は1000超え判定ルーチンがなかったんだよね? あとからとりあえず後ろにくっつけてみた、って感じじゃないかな。 >>112 529 :FOX ★:04/02/25 21:47 ID:??? dat のopen , close で行くと、 1) 512 超え判定、超えていたらDispError(); 2) 追記のために open -> write -> close 3) subject.txt 書き換えのために res数取得 open -> read -> close 4) 超えていたら 1,001 書き込み open -> write -> close ->chmod これなら、 open(+<);# 読み書き(追記用)両用フラグを与える write; read; if(over 1000){ white; close; chmod}; else close; endif; とすればopenの手間は一発(=1/3)ですむ。 >>114 あ、まちがいた・・・ ○| ̄|_ ×if(over 1000){ white; close; chmod}; ○if(over 1000){ write; close; chmod}; 4) のところで、 A) 999以上で書き込めるの? B) んじゃdatに1000ストッパー追記しよう C) んでもって、パーミッション切っちゃおう D) おしまい となってます。 B) に詰まっちゃって、A) をすり抜けてきちゃうのがたくさんできる予感。 >>114 まさしく dat 追記する瞬間だけど open(OUT, ">>$DATAFILE"); print OUT "$outdat\n"; close(OUT); ここで dat 数を数えて DispError() するってこと? そのあとで subject.txt を書き換えるときに また dat数数えるってこと ? >>116 あ、A) は A) 1000以上で書き込めるの? だ。 でも、実際の1000大幅超えスレでは、1000ストッパーが何回も書き込まれているのに その後から書き込みしたレスも書き込めちゃってるんだよね。 だから、Bに詰まっちゃってるのはないんじゃないかな。。 >>119 datへの書き込み後に1000越え判定するんで、有り得ないこともないですね、 512kB 超えの判定は bbs.cgi のかなり序盤 ここだとうまく行くから ここで dat数も数える? んで数を保持しておいて、、、 後半の subject.txt 書き換え部分でその数使う? すでにずれている予感もするのだが、、 ピーク時 bbs.cgi は 20回/sec くらい呼ばれているぞ それも同じ subject.txt に対して >>117 こういうことでは? open(OUT, $DATAFILE, "a+"); print OUT "$outdat\n"; @logdat = <OUT>; if (scalar @logdat > 999) { print OVER "1001<><>Over 1000 Thread<>このスレッドは1000を超えました。 <br> もう書けないので、新しいスレッドを立ててくださいです。。。 <>\n"; close(OUT); chmod(0555, $DATAFILE); } else { close(OUT); } そう、だから1000越え判定をdat追記前にもってこようと。 >>121 50ms以下ですか・・・かなりきついですね。 >>121 openのコストよりstatのほうがちいさいのであればそれてもいいかと。 そういえばbbs.cgiのcputimeってどのくらいです? それ如何によってはある程度のdat(レス)数(の意でいいのだろうか)で filelockかけるっていうことも視野に入れてもいいかなと。 まちがいなく1000近くになれば重たくなりますが、 over 1000の膨大なdisk I/Oでリソースを食うよりはましかと。 # peko級でcputimeが50ms程度でおさまっていればいいのですが・・・。 前にも書いたけど、1000レス制限は本当に必要なんだろうか……。 サイズ制限だけでも間に合うんじゃないだろうか……。 >>127 いつ書き込みできなるのか分からないし、 次スレを作るタイミングも分からないし、 とにかくユーザにとって使いづらいというかイライラすることは間違いない。 >>128 いつ書き込みできなくなるかについては、レス数のかわりにスレサイズを見るようになり、それがあたりまえになるんでは? AA系なんかだと「450K超えたからそろそろ次スレ」なんてのはあたりまえだし。 レス番号は左に確実に表示されているからどんなバカでも一目瞭然だけど。 datサイズは分からない人がたくさんいる。 はて。「サイズがxxxKBを超えています。512KBを超えると表示できなくなるよ。 」というメッセージは大きく表示されるけど。 専用ブラウザじゃ気づきにくいねぇ。 番号の変わりに番号+その時のDatサイズにしたら面白そうだけど。 だから1レスごとに「133 : xxxkb/512kb:動け動けウゴウゴ2ちゃんねる 」 とか表示されていればアホでも理解できるだろうけど。 そうでなければ不親切極まりない。 というかユーザー無視のプログラマ親切なダメ設計だと思う。 >>133 そういう文句は専用ブラウザの作者に言うべきでは? read.cgiは 「1000を超えると書き込めないよ」と同じように 「512Kを超えると書き込めないよ」と警告が出るし 「レス番号が表示される」のと同じように 「サイズが表示される」もんね。 ただ、その事(>>133 が知らない)と1000レス制限は撤廃してよいか、ってのは 別の話だとは思うけどね。 1000とり合戦はなくなるだろうけどな。 liveだけ250kにすれば? さて、やっとここに書く時間がとれた。 chmod()を使うからいけないんだと思うですよ。 fchmod()を使って、アトミックにすべきかと。 6.10. 競合状態を避ける http://www.linux.or.jp/JF/JFdocs/Secure-Programs-HOWTO/avoid-race.html より引用。 他の例として、ファイルのメタ情報をいろいろ操作する作業を行う場合(オーナーの変更、 ファイルの状態確認、パーミッションビットの変更等)、まずファイルを開いて、開いたファイルに 対して操作してください。つまりこれは、chown()や chgrp()、chmod()のようなファイル名を 受けとる関数ではなく、fchown()や fstat()、fchmod()システムコールを使うことを意味して います。こうすることで、プログラムが動作している間にファイルの置き換わりを防げます (おそらく競合状態も)。たとえば、あるファイルを閉じてから、chmod()を使ってパーミッションを 変更すると、攻撃者はその 2 ステップ間にそのファイルを移動もしくは削除し、別のファイルに 対してシンボリックリンクを張ってしまえるかもしれません(たとえば、 /etc/passwd に対して)。 つまり、ロックじゃなくてrename()を使うというのと、意味合いは同じです。 (rename()はアトミックだから) というわけで今の処理、 http://qb3.2ch.net/test/read.cgi/operate/1076174286/490 の、 490 名前:FOX ★[] 投稿日:04/02/24 22:13 ID:??? bbs.cgi のもっとも後半部分にこんなのがあるですよ。 open(RDAT,"<$dattemp"); @logdat=<RDAT>;#ログを配列に読み込む close(RDAT); #ログのカキコ数を取得 $lognum = @logdat; if(-w $dattemp && $lognum > 999){ open(OVER, ">>$dattemp"); print OVER "1001<><>Over 1000 Thread<>このスレッドは1000を超えました。 <br> もう書けないので、新しいスレッドを立ててくださいです。。。 <>\n"; close(OVER); chmod(0555, $dattemp); $lognum++; を、 print OVER "1001<><>Over 1000 Thread<>このスレッドは1000を超えました。 <br> もう書けないので、新しいスレッドを立ててくださいです。。。 <>\n"; fchmod(0555, OVER); close(OVER); $lognum++; にすればいいんではないかなと。 # Perlよくしらないから、0555とOVERの順番は逆かも。 つかCのchmod()と引数の順番反対な気が。< Perl うん。それも一理ある。>>141 visudoとかcrontab -eとか、いろんなところに使われているですね。 こういう新機軸のかずかずを最初に実装した4BSDは、 いろんな意味で偉大だったと再認識するわけで。 ただ、こういうのって、負荷が超高くなるとか、きびしー条件じゃないと、 なかなか不具合が露見しにくいとこだから、いい実験なのかもしれんですね。< live8 open(RDAT,"<$dattemp"); seek(RDAT, 0, 2); $lognum = $.; close(RDAT); ちゅーか、Perl4の書き方は止めようよ。 ほれ http://www.pure.ne.jp/ ~learner/program/Perl_oo.html flock って、ここだけでも使っちゃダメ? #ログのカキコ数を取得 $lognum = @logdat; if(-w $dattemp && $lognum > 999){ open(OVER, ">>$dattemp"); flock(OVER,2); seek(OVER,0,2); print OVER "1001<><>Over 1000 Thread<>このスレッドは1000を超えました。 <br> もう書けないので、新しいスレッドを立ててくださいです。。。 <>\n"; chmod(0555, $dattemp); close(OVER); $lognum++; fchmod()って、ひょっとして標準のPerlにはついてないのかしら。 とりあえず、状況を管理人に通報しておきましたです。 原因も明確なので、あとは様子見しか正直やることがないかと。 おぉ、>>150 はごばーく。無視してくださいです。 以下のプログラムで、ちょっとテスト。いちおう動いた。 でも、ちょっと強引。 で、h2phしてsyscall.phを作っておく必要ありの模様。 これ入れれば、ほぼ間違いなく3000とか4000いくのはなくなると思われ。 うまく動くようなら、麻原判決の前に、live8でテストしてみるか。 #! /usr/local/bin/perl # # fchmod test via syscall # # may be needed 'h2ph' require 'syscall.ph'; open(TTT,"A"); syscall(&SYS_fchmod, fileno(TTT), 0555); close(TTT); exit; あとは、rename()の助けを借りて、コピーして元datの複製を作っといて、 複製をchmod()してrename()するぐらいかなぁ。 でも、こんなことすると効率悪い気がするなぁ。 if (まだ書き込める) { 元ファイルの複製を作る; chmod(555,複製); rename(複製, 元ファイル); } >>154 はいかにも筋悪だなぁ。 複製を作っている間に、どんどん書き込まれる予感。 やっぱ、>>152 しかない気がする。 で、いちおう、make(perlcc)は通った模様。 ひ(りゃ的にOKなら、ちょっとやってみっか。 # なんだか、びんぼーくじを引いてるような気もする、する。 そしてずるずる引き込まれていくというのは内緒です。 sysopen はダメなのかな? sysopen FH, $filename, O_RDONLY, 0555 or die; みたいな。。。 ♪open Systemcall がよく判ってなかったりして(汗) 私としては、こーゆーのはぜひとも次世代を担う若者にやってほしいわけですよ、よ、よ。やっぱ。 わたしがperlの文法を覚えたのは 旧実験室のやつがきっかけだというのは、ないしょです。 >>158 sysopen使うなら、syscall使うのと50歩100歩かも。 つか、プログラマじゃない人にPerlをいじらしたらいけません(素)。 おじさんはダメだよ、おじさんは。 あれですね、一回 bbs.cgi を整理しないといけないのかも。 継ぎ足し継ぎ足しでやってますからねー、 処理を変えずにうまいこと順番を変えていく。 色々試してみる。 いつかは Best Choice が見つかるかも。 (見つからないかも) >>162 には、激しく同意。同意だが、、、。 どなたか、柱になってすすめていただける人がいれば、 ちょっぴり支えるぐらいはできるかも。 細い杖だけどね。 わたしゃ、お守り関係で正直もうお腹いっぱい、PIEおっぱい。 >>163 ( ´д)ヒソ(´д`)ヒソ(д` ) >>163 (;´Д`) ちょっとやってみよう。 とりあえず、現在の大まかな処理を書いてみよう。 今なんとなくぼーと観察してたけど、 なんだか、何らかのシステム資源が足りなくなった瞬間にこの現象が始まる気がする。 つまり、fchmodにしても解決しない問題なのかも。かも。 で、ある速度を超えると、どうも資源が足りなくなってるような。 今回のだと、なんだか「セックルキター」ってのがどばどばっと書かれて、 該当datの読み込み数が50回/secを超えたあたりか。 で、いったんこの状態になると、軽くなるまではずっとこの状態が続くように思えるんで、 やっぱ、資源が足りない系な気がするなぁ。 でも、syslogにはそれっぽいの、出てないんだよなぁ。 うぅ、様子見ようと思ったら1869でとまっちゃった。 1) お茶でも飲みましょう 2) 串なホストを弾く 3) ブラ変 4) Cookieなかったら食え 5) 広告開いておく 6) 入力変数成型 7) ホスト取得(携帯は端末ID) 8) 512KB越え or datが書き込めないならエラー 9) Cookie設定 10) ●とかトリップとかキャップとか 11) ブラウザ変ですよん 12) 入力変数のCheck 13) PROXY制限(BBX Rock54 Samba24) 14) スレ立て制限 15) もうちょっと落ち着いて書きこみしてください 16) ID生成 and dat書き込み 17) subject.txt更新 and 1000越え判定 18) HTML出力 19) ふう、疲れた 7でホストを取得する前に2で串なホストを弾いてますね。どんなからくりなんだろう。 >>173 13)のSamba24は連投規制ですよね? timecount/timecloseもないので、この2つで一体化すると良いと思います。 あ、現在の処理か、、 512KB処理と1000超え判定がかなり場所的に離れてますね、、 ホスト取得というのは、書き込んだ時用の記録だと思います 串を弾くのは単純にREMOTE_ADDRだったり、REMOTE_HOSTを使えばいい話ですし をーなんだか愉しそうな香りが(嬉嬉嬉)@bbs.cgi 大改竄計画 173 を検証してみて不要なものとか重複しているところとか 80kg 超えているところとかを検討するとよさそうですね。 でもゆっくりとした時間が取れないので鬱(泪) で、16 以降は単一プロセスでやらせたいなぁ。。。 bbs.cgi が受け持つのは 15 までにする。 あと、 bbs.cgi の起動数の制限を設けたいなぁ。1 鯖につき 50 プロセスまでとか。 書き込まれた内容を処理する前に、 書き込めるかどうかのチェックを、できる限り 済ませておく方向に、できないだろうか… 書き込めなかったら成型処理しても無駄な訳だし… 8)は15)の後に移動するとともに処理直前でsubject.txtをロックしてから 判定と書き込みを行いオーバーしたか18)が終わったらロック解除。 ほとんどオンメモリ状態なはずなので実際の処理は1msかかってないと思うんですよ。 ならばsubject.txtやdatの書き込みとHTML生成はシーケンシャルでもよいかななんてね。 OSのファイルキャッシュがまともに働いていれば、という前提付きですが。 >181 16以降の ファイル書き込みは(TCP経由で)常駐プログラムだけがやるとか? >>185 そんな感じです。 整形された line の先頭に、"bbs<>key<>" を付けて、tai64 形式のファイル名を付けて、特定のディレクトリに投げるの。 でもって、書き込みやさんはその特定のディレクトリだけを監視して(1秒おきにとか)、 何かしらファイルが放り込まれたら書き込みの操作を 1 人でやるの。 svc にさせてもよいかなぁ。 >>186 書き込み屋さんは非同期で動くんですか? bbs.cgiがレスポンスを返すのはHTMLの生成が終わった後でなければマズい気がするんですが……。 >186 ファイルに書き出すのはやめた方がいいと思う 極端な話SQL鯖のような感じにリアルタイムで返って来るようにする リアルタイムで返って来ないと・・・ 書き込んだ内容が反映されてない -> なんらかの規制になってると判断する可能性有 2chブラウザのかちゅ〜しゃに至っては書き込み後自動的にdat読み込む >>188 まずいっけ? もし生成が溜まっていても、bbs.cgiがチェックしていればよさそうだけど。 >>189 書き出しはDBIにしておけば、MySQLでもDBI::Fileでも任意のドライバに変えるのは簡単。 今まではfileオープンしてそこに追記していたんだから。 tai64で1つごとにファイル書き込みしたとしても次元が違うぐらい速度が上がると思うけど。 案1 「bby -- スレッド情報一元管理システム」と同じDNS使用 dnsに板とキーを投げる dnsは板・キー・レスカウントを保持 通常は127.0.0.1を返し レス数1000になったら127.0.0.2を返す 案2 レス数管理にSQL鯖使用 >190 >書き出しはDBIにしておけば、MySQLでもDBI::Fileでも任意のドライバに変えるのは簡単。 2つのプログラム(2重起動含む)から1つのファイルを使って大丈夫なのか? DNSはキャッシュされるのでそういう用途には向いていないと思います。 >2つのプログラム(2重起動含む)から1つのファイルを使って大丈夫なのか? そういう泥臭いことを引き受けてくれるのがDBIです。 パフォーマンスを考えるとSQLデータベースになりますが、それはまぁ後々の話として。 インターフェースさえDBIにしておけば後でいくらでも入れ替えられます。 http://module.jp/works.html のPerlによるハイパフォーマンスWebアプリケーションの開発を参考に ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる