bbs.cgi再開発プロジェクト 3
■ このスレッドは過去ログ倉庫に格納されています
まとめると1001突破するけどそのうち止まるってこと? >>625 ソース
>if($lognum > 1020)#最後の手段
↑
これを超えたら
>DispError("ＥＲＲＯＲ！", "ＥＲＲＯＲ：このスレッドには書き込めません。最後の手段!!");
それ以降は↓になるわけです。
>DispError("ＥＲＲＯＲ！", "ＥＲＲＯＲ：このスレッドには書き込めません。緊急緊急緊急!!"); 最後の手段が効いてるけど緊急緊急緊急は効いてないってことか
最初から$lognum > 1000で判定しない理由は何だっけ? 効いてないのは古いファイルが chmod(0555, $dattemp); 出来ていないから。
そこで 1020を超えた時点で条件に引っ掛けて、datファイルを新しいファイルにコピーして
そのファイルを chmod(0555, $dattemp); している。
その後今までの古い datファイルは消去。
新しいファイルはパーミッションが 0555 になっているので今度は｢緊急緊急緊急｣で分岐するというわけ。 http://qb3.2ch.net/test/read.cgi/operate/1069525567/528-
最近スレ移動の後のストッパーが聞いてなくて
書き込めてしまうのが続出してるみたいなんですが、
これもここに報告でいいんでしょうか？ >>685
たぶん移転するためのcgiはbbs.cgiじゃないから
ここじゃないほうがいいかなぁ、、
まあ、もう書いちゃってるんで言ってもしょうがないですが。 う～ん、ここで1000ストッパーの改造がはじまってから、
>>685の現象が多発するようになったので、
関係あるのかな？って思ったんですが、、、
ﾊﾃｻﾃ >>685 >>687さんに同意で。。。
格段に多いですよ 移転痕ストッパー外れ。 スレスト、ゴミ箱移転跡が移転すると書き込めるようになるのは仕様です 1000ストップの判断をしたあとで書き込んだ方がいいと思うんだけど
そうしない理由って何かあるの？ Perlで書けよな。
高速だし、柔軟性あるし、大抵のサーバーで動くし、機能的にも問題ない。
PHPでは絶対書くな。 >>691
2chのスクリプトはCじゃありませんでしたか？
俺の勘違いなのかのぅ。 実況鯖だけかもしれないけど、bbs.cgi は perlcc で C にしてたような。 ひぇ～ごめんなさい。C というよりはバイナリ実行形式でした < perlcc
ちなみにオプションをつければ C のコードも出せるようで。半可通でスミマソン >>695
(巨大な).cファイルに変換されて、Cコンパイラでコンパイルされますです。
.cファイルも取り出せますが、読めたもんじゃありません。 停止済みのスレッドの移転の場合は再停止（もってなければお願い）
停止前のスレッドの停止＋移転の場合は移転してから停止。
が正しい措置と思われ。
>>697
そーなるとperlccで吐くコードではまだまだ無駄がありそうでつね。
やはりC(++)で最適コードを書いたほうがいいのかな・・・？ >>699
ひ（ry がさわれなくなるからCで書くのはダメ、なんじゃなかったかな。
ただ、トラックバック機能のためにread.cgiをちょっと改造してたところを見ると
もしかしたらCもさわれるのかもしれないけど。 >>689 >>698
>>687-688の意味がちゃんと伝わってない希ガス
＞スレスト、ゴミ箱移転跡が移転すると書き込めるようになるのは仕様です
「移転すると」ってのは鯖移転だと言いたいようだけど、
>>687-688の指摘はそうじゃなくて
削除人が移転やスレスト呪文唱えた直後のスレッドなのに、スレストが効いてない
＝パーミッションが書き換わってない ってことです。
>>686に同意しつつも一応念押し。
>>702
触らせないようにすれば、その人に全面的にお任せ になるだけかと。 >>700
なるほど。
>>702の意見も正解かもしれませんな。
C言語版のしっかりしたメンテナがいればひ(ryは触る必要はないと思われ。 >>703マジで多いです
スレ移動した後、移転後をさらに停止させなきゃならないので
２回スクリプトを走らせなきゃならないし、ログも２倍溜まってるような・・・・・
ソースは無くて感覚だけど、ここで１０００ストッパーいじりがはじまってから
増えたのは確かだと思う
>>686だとしても、どこに書きゃいいんだか
管理人に連絡か？ >>707
安定性に問題があるだろ、氏ね。ｳｻﾞｲ。
ここまで斜め読みでカキコ。
dat書き込み時にレス数を数えて1000達成したら、
その場でストッパーかけないと本来はダメでしょうね。
理由は、数える→1001スレストの間に
他のプロセスがdatに書き込む可能性がありますから。 >>712
flock処理周りの実装バグったんじゃねーの?
過去のバグを前提にシステムのポリシー決めてたら
ろくな方向に向かわんぞ。
「OSによって問題がある」とかなら
symlinkで代替してもいいしさ。
そもそも書き込みは排他を前提にしないと
単純に設計がおかしいってことになる罠
排他無しは
ときどきリセットされるアクセスカウンターと同じ設計で
それは直すべきもの
そもそもサーバー構成がまともじゃねぇよ。
表側に位置するCGIサーバー群は全て同じ仕様と内部構造にして
DNSラウンドロビンにて負荷分散。
データ管理は裏方のDBサーバー。
DBはMySQLみたいな汎用RDBMS使ってもいいし、
NFS使ってUnix FSだけで管理してもいいし(その扱いは今とほとんど同じ)
裏と表の間でやりとりする専用プロトコルと専用メソッドを開発してもいいし。
でもって、クライアント側からのリクエストが閲覧だけのとき(書き込みではないとき)
の処理を徹底的に減らす必要があるな。
閲覧処理で行われる「いつもやってる計算」の中の「いつも結果が変わらない処理」
は書き込みのときに全て終らせてキャッシュさせておく。
主にHTMLに対する整形があるだろう。
書くレス番ごとのHTML整形されたファイルを作ったり
1-100を選ばれた場合の整形済HTMLを用意したり。
あと最も激しい負荷の矢面に立たされる読込処理のCGIは
C/C++で書いておく。そしてstatic link。
もしくはC/C++で書かれたプログラムをapache module化する手もある。
ここ数年仕様がほとんど変わってないんだから
これからも仕様は変わらないだろう。
「変更容易だが速度は遅い」という特性のスクリプティング言語を使っても
あまりメリットないよ。
「えー。Cわかんないよ。Perlならわかるけど」
とかいうなら、おまえんちのApacheはPerlで書かれてるのかと問いたい。 CGIとしてのperlを高速化したいなら
mod_perlにするかprelinkを使うのをおすすめ。
prelinkツールにてperl本体を前処理しておけば
perlの起動が高速化される。 鳥インフルエンザキャリアの人？（ｗ
だったら焼却漏れがありますよと伝えなきゃ（嬉）＠Ｔ波町 最近過去ログ周りに注力しているせいか放置されている最寄ですが、
bbs.cgiのmod_perl化は検討されています。
ただ今はperlccによるバイナリ化で
それなりに効果を挙げているようなので現状でとまっているようです。
しかし吐くCコードとバイナリが巨大なので
メモリを圧迫しているということはあります。
理想はC化なのですが、そうするとひ(ryが扱えないということらしいです。
read.cgiは既にCです。
I/Oのはげしいスレはdatは常時オンメモリです。
NFSマウントはセキュリティ上あまり好ましいものではありません。
余計なポートを空けることになるからです。
# NFS over HTTPはできそうですが、結局負荷増につながりそう。 >>719
続き。
2chにおける一番の負荷はディスクI/Oです。
そして一プロセスあたりで一番使うのがbbs.cgiです。
root師の言葉を借りるならば、「1にI/O、2にI/O・・・」だとか。 ＞理想はC化なのですが、そうするとひ(ryが扱えないということらしいです。
こうゆうところがひろゆ子らしいとゆーかなんとゆーか。。。 後このスレで議論されまくっていますが、
bbs.cgiは仕様変更が多いのでチューンがめちゃくちゃ甘いですね。
コードの整理とC化で倍速になりそうな悪寒。 >>722
1,000倍になると思われ、
で、現在不具合はあるのかな? < bbs.cgi >>723
個人的には、サーバ落ちによるものを除いても、復帰依頼の回数がやや増えた気がしますね。
ただ、復帰屋さんにまめに動いていただけているので、運用でカバーできているような気もします。 現行のbbs.cgiのソース公開は無理でも、Cで一から作り直すのは駄目なんですか？
それこそ、オープンソースで遣れば荒らし対策とかもちゃんと出来そうな気もするし。
ひろゆきの気持ちとしては、弄れなくなるのは「嫌」なのかも知れないけど、運用とし
ては別に良いんじゃないかぁ。現行だって随分人任せみたいだし(w >>725
そこは管理人から何回も名言されているので
私はその言葉を聴いて私として行動していくだけです。
あなたはあなたの道を行けばいいだけかと、
誰も邪魔しないと思います。
前進あるのみ。 ひ（ｒｙ はPerlしか使えないんだっけ？
でも最近「弄った」とか言っているの見たことないし、
ひそかにC化しちゃってもいいんじゃないの？ばれないって (w
で、flockが使えないから 排他処理全くしていないって本当なの？
本当ならすごいね。 1ディレクトリーの中にファイルは多くて何個ある?
数千個越えてくるとディスクI/Oの負荷が高くなりやすい。
それを防ぐために1階層か2階層はサブディレクトリーによる分類が必要。
squidのキャッシュディレクトリーを参考にな。
メモリ搭載を増やしてディスクキャッシュに頼るという逃げもあるが
根本的には「必要とされないデータをディスクから読む」という
動作を減らす設計が必要。
URLの末尾"l50"でアクセスするユーザーが大半なのに
毎回読まれるたびに1番レスから全部読んでいたら無駄が大きい。
その場合l50専用のファイルを「書き込み時」に生成するとか
逃げ方はいろいろある。
インデックスファイルと本文ファイルを分けて
インデックスファイルを読むことによってレス番からオフセットを求めて
本文ファイルを読むときはオフセット使って一気にfseekする手もある。
mysqlでも使っておけとと言いたいところだが、
ファイル使うにしてもおかしな設計だと
その負荷の大半は「無駄な負荷」になるんだよ。
ていうかflockはしておかなきゃ。 flockを使わない実装のほうが負荷が低いですよ。
$ /usr/bin/time perl -e 'open(F,">>/tmp/xxx");for($i=0;$i<100000;$i++){flock(F,LOCK_EX);flock(F,LOCK_UN)}'
0.16user 0.07system 0:00.22elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
flockはたいした負荷じゃないべ >>719
> NFSマウントはセキュリティ上あまり好ましいものではありません。
> 余計なポートを空けることになるからです。
NFS通信するホストは物理的に近隣に配置して
それぞれLANカードを1枚余計に搭載してプライベートアドレスを割り当てて
HUB経由直結でプライベートネットワークを構築して
そちら側からだけ通信許可すれば外向きにポートが開かないので
セキュリティー上の問題は無いと考えて良い。
それが困難ならipchains等によるフィルターも有り。 ていうかbbs.cgiとread.cgiのソースはどこよ? bbs.cgiはひどいスパゲティソースで、見た人が次々に消えてしまう
らしいから、一から作ったほうが早いかもよ。
ということで、がんばれ。>>736 >>736
いわゆるNASなどを使ったソリューションではよくある形ですね。
10.0.0.0/8とかつけとけばいいと。
でも、NFSとflockって大抵の場合、きわめて仲が悪かったり。
(私は何度も痛い目にあいました)
いずれにせよ、細かなI/Oが多数発生するような系では、
flockはともかくNFSを使う気は全くないですね。
NFSだと、Apache的にEnableMMAPやEnableSendfileとかがうまくないので、
パフォーマンス的に激しくつらいです。
例えばhome directoryの共有みたいな用途には便利だし、
うまくやれば管理も楽なので、NFSという技術そのものを否定するものではありませんです。
単純にライブな掲示板システムには、ちょっとなぁというだけで。
で、flockは >>735 みたいなやり方の負荷は、確かに高くなりません。
でも、他の人を「待たせる」ことが、そもそも負荷というか、重荷というか、コスト高になります。
掲示板システムって、もう、待たせちゃいけない。システムも、ユーザも。
待たせるぐらいなら、他の手段(rename()をうまく使うとか)を使うですね。
某氏じゃないけどNFSはこういう用途に使う場合には、
Network Failure Systemだぐらいに思っていたりして。 >>740
またせちゃいけないからflockはつらいってか。
じゃあ手段1。書き込む先のファイルを分けることだな。
$thread_num = スレ番号;
$pid = $$;
open(WRITE,">$base_directory/$thread_num/$pid");
でもって、これらをマージするのは別のデーモンが行う。
もしくは手段2。デーモンがunixソケットの口を開けて待っていて
bbs.cgiはそのデーモンに向かって次々と書き込みリクエストを投げつける。
実際のファイルへの書き込みはデーモン1プロセスが行うので
排他処理は不要。
ていうか俺が作れってか >>741
> ていうか俺が作れってか
期待してますです。
私は「作られたものの性能をできるだけ発揮させる」とか
「既にある仕組みを用途に合わせて適用する」とかいうのは
なんとかやれますけど、スクラッチから作るのは正直苦手なんで。 NFSとflockの両方を提案したがこれは両方の組み合わせを提案したわけじゃないのであしからず。
NFSは「読込負荷の分散のためラウンドロビン化された表向きCGIサーバー群」が
データを抱える裏方のサーバーに読みに行く場合のみ。
flockは書き込みに関してだけで、これは単一のホストがローカルドライブに対して行う。
俺が考えている構成は以下のような感じ。
まず表向きのCGIサーバー群を用意してラウンドロビン化。
裏方サーバーはデータの管理専用で板ごとに分散。
表と裏の通信はTCP上の独自プロトコル。
表サーバーについて: read.cgiは直接裏のサーバーに問い合わせるのではなく
表サーバー内で動作するキャッシュ機能提供のデーモンを経由する。
キャッシュ能力を持つデーモンは逆proxyの効果を上げる。
裏サーバーについて: 読込と書込の2つのデーモンを走らせてTCP listen。
書込デーモンはTCP口のところである程度バッファ能力を持たせておけば
過去flockを使ったとき発生した「待ちのための負荷増加」を減らせるはず。
読込デーモンの処理を極限まで減らすため、
HTML化やl50分の切り出し等、読込時によくある動作は書込デーモンが
あらかじめ行ってファイルへ書き出す。
本当は読込デーモンと書込デーモンを一体化させて
できるだけファイルを経由しないオンメモリ動作にした方がさらに効率的なのだが
開発に時間がかかるしバグ取りが大変だしメンテできる人が減ってしまうことになる。 743続き
書込時の流れ:
[表鯖]bbs.cgi
↓
[表鯖]書込デーモン
(チェックやフィルタなどはこことbbs.cgiだけで行い裏の負荷を下げる)
↓
[裏鯖]書込デーモン
読込時の流れ:
[表鯖]read.cgi
↓
[表鯖]読込デーモン
(キャッシュ能力を持たせて逆proxy状態に)
↓
[裏鯖]読込デーモン
表鯖はデータを抱えない同一構成のマシンを大量に並べてラウンドロビン化。
そうすりゃ表鯖にいくら負荷をかけても数の力でごまかせる。
ていうかこれだとNFSは不要か。 そうそう、書きこむ人 (bbs.cgi) がｲﾊﾟｰｲいるから 3000 超えちゃったり。
dat 直読みも表面的には「直読み」だけど本当は DB アクセスにしちゃうとかね。
AddTypeapplication/x-httpd-cgi.dat
AddHandlercgi-script .dat
とかとか。 そして次の世代の２ちゃんねるが生まれて来るんですね、
みんながんがれ 途中で書き込みしてしまいました。１時間ほど前からhuman3㌧でます、対策よろしく 見習い▲ ＝ 仕事人 ＝ 夜勤 ＝ Z社員 でしたっけ？
ﾗｳﾝｼﾞとかの人の多いところには排他入れたいけど、
入れると負荷が高まるというトレードオフをどう克服するか
楽しみに待っていますよ 書き込みデーモンの話題とか見ると、去年の暮れから話がループしているな。
実際のコードを書くためには、bbs.cgiをサブルーチン単位で公開できるところだけでも提示してくれないと書けないと思う。
どうなんですか? root★氏やひろゆき氏的にそのあたりの書き込みサブルーチン公開は? >>751
んー、だから鶏と卵問題で前進していないから、いいかげん最初の一歩を踏み出しましょうということで。
wikiに公開できる部分を張ってもらうのがいいと思う。
まあ予想されるひろゆき氏の答えは「どの部分を非公開にしなくちゃいけないかも分からない」だったりして。 >>753
その程度もわからないのだったら、いっその事c化しても問題なさそうだな(w >>755
みたいですよ。
もっとも、公式見解が聞きたいところだけどw >>757
一応連携しているはず、と信じたい。
見習い師いわく、「bbs.cgiは完全な挙動をしている」。
しかしながら、
・perlccの吐くCソースとバイナリが大きいのでシェイプアップの余地がある。
・スパゲティソースであることが過去の議論から明白なので、
処理過程も見直せば大幅な負荷軽減が期待できる。
・ディスクI/Oまわりの見直しでディスク負荷が軽減可能。
今のソースはコストのかかるfopen()コールが不必要に多い模様。
などの理由から、私はCでやれるんならそうしたほうがいいんじゃない？という意見。 結局1から作り直すことも出来ず
ソースを全部公開することも出来ず
一部分を公開して→直すの繰り返しで
スパゲティ状態を直すことも出来ず
これじゃとても再開発とは呼べない気がします
と禿外な事言ってみる 運営が欲しいのは
沢山のプログラマーではなく一人の天才プログラマー とりあえず
use warnings;
use strict;
つけて動くようになったら
mod_perl化… じゃあ、オブジェクト指向で書き直してみるとかｗ
以後、部分公開も楽になるかな サザン★さん お呼び出しです
F22 で proxy999 を取っていると思いますが
全く同じルートで proxy998 も取ってください。
各サーバが BBQ の proxy998 も取りに行きます。 >>765
かんりょうでーす
999 と同じ場所に 998 がおいてありますー >>766
どもども
中身はなにもしなくていいですー
たぶんなにもしていないとおもうけど 某ぶぇらさんみたいな喋り口の人が来て、改造案で気を吐いていますね
ここじゃ押してばっかりだと、ｵｼﾓﾄﾞｻﾚﾏｽﾖｰヾ('-')ﾉ for some reason
bbs.cgi を更新したので peko サーバよろしくー > root★さん >>771
live8/9/10/news11 done. >>768
あうーん
やっぱりあちこち欠けて(編集されて)配られるので
F22(各サーバ)が直接 qb4 の 998 を見るようにしました。
ということで、 bbq 側(f22本体)からは 998 はずしてくださいー >>772
どもです
これで ほとんど bbs.cgi を更新しなくても済むようになりました。
＞729
そんなしょぼいコードを参考にしたら２ちゃんねるは壊滅しますよ、と。 ■ このスレッドは過去ログ倉庫に格納されています
