bbs.cgi再開発プロジェクト 3
■ このスレッドは過去ログ倉庫に格納されています
>>641
例えばbubbleサーバのnatsumeloj板なら、
find ./public_html/natsumeloj -user nobody -name \*.dat -print
なんてのを流せば、すぐわかるかと。
これをサーバの数分、板の数分やればいいかな。
ひまをみて、_service/を見て板名とってきてfindかけて、
オーナーをfixするためのshell scriptでも書いてみましょ。
できたら、各マシンで手分けして流していただくということで。 止まらなかった原因は単にchmodが効いてなかったってだけなのかー。 >>644
引っ越しのときにdatをchownするだけではダメですか？ 移転の時は普通にファイルを移動してるだけなので、chownしなくてもいいはずです。>>647
というか、普通はこんなこと起きない気がしますね。< オーナが違う
途中でsuexec環境に変わった場合にのみ、起こるはず。
あるいはsuexecがバグっていて、「httpdのオーナーが抜けてきちゃった」場合とか。
# 経験したことあります。 移転しても移転しても書き込めるもよう。
>>645
これは「調子の悪い」とは違うと思うが。 >>648 補足。
> 移転の時は普通にファイルを移動してるだけなので、chownしなくてもいいはずです。>>647
理由: マシンをまたいだファイル移動の時に、オーナーが変わるから。 >649>651
ここで同じような報告を繰り返されてもご迷惑になるだけかと
>>639
drwxr-xr-x 2 (･∀･)ﾆﾔﾆﾔ users 4096 Mar 5 21:13 ./
drwxrwxrwx 15 root root 4096 Mar 5 21:11 ../
-rw-r--r-- 1 root root 0 Mar 5 21:12 A
-rw-r--r-- 1 (･∀･)ﾆﾔﾆﾔ users 0 Mar 5 21:12 A.tmp
[(･∀･)ﾆﾔﾆﾔ test]$ mv -f A.tmp A
[(･∀･)ﾆﾔﾆﾔ test]$ ls -la
合計 8
drwxr-xr-x 2 (･∀･)ﾆﾔﾆﾔ users 4096 Mar 5 21:14 ./
drwxrwxrwx 15 root root 4096 Mar 5 21:11 ../
-rw-r--r-- 1 (･∀･)ﾆﾔﾆﾔ users 0 Mar 5 21:12 A
[(･∀･)ﾆﾔﾆﾔ test]$
>>644
色々と考えられる事はあるのですが順番にやっていかないと
どれが原因か分からなくなりそうなので、まずこれから。。
見つかったスレに1000番目を書き込んだ時にこれ↓が表示されるかどうかが知りたかったんですよ。
>"ＥＲＲＯＲ！", "ＥＲＲＯＲ：このスレッドには書き込めません。最後の手段!!"
で、おそらく表示されるだろうとは思うのですが
1000 over を判定しているのはこれ↓を書き込む為にしているような、、
>"１００１<><>Over 1000 Thread<>このスレッドは１０００を超えました。 <br> もう書けないので、新しいスレッドを立ててくださいです。。。 <>\n"
cgiの最初の方でこれ↓しか見ていないのは負荷軽減の為だと思うのですが
1000を越えているかどうかを最初に見ればパーミッションがどうなっていようと
1000を越えているスレには書き込めないと思うのですけど、既出の問題なのかしら、、
>#.datが存在してないか書けないならばいばい >>653
drwxr-x--- 24 root root 4096 Mar 5 21:09 ./
drwxrwxrwx 21 root root 4096 Feb 25 12:56 ../
[(･∀･)ﾆﾔﾆﾔ root]$ mkdir test
mkdir: ディレクトリ `test' を作れません: 許可がありません
[(･∀･)ﾆﾔﾆﾔ root]$
>>653
さんくす。Linuxでも問題なさそうですね。
んじゃ、shell script作ってみます。
今日はJimさんデーの2日目なんで、明日以降になるかもしれませんが。 ここまで読んだ
引越し屋バンバンが地方営業なのがわかった 902のカーネルだけ、5.2.1-RELEASE-p1に上げてみた(i386モード)
しかし、状況は変わらず。 options AAC_DEBUG=3
とか入れてみるか。 うひょ。>>659-660 は派手な2連続誤爆だ。 1000越えて書き込まれてたスレ発見。
真・スレッドストッパーのガイドライン
http://that.2ch.net/test/read.cgi/gline/1022203584/l50
試しに書き込もうとしたら
ＥＲＲＯＲ：このスレッドには書き込めません。緊急緊急緊急!!
と出ました。
このスレが建ったのは2002年、>>636で書かれている去年以前に建ったスレ。
手を加えるならXXX 名前：書けませんよ。。。 投稿日：停止
真・スレッドストッパー。。。(￣ー￣)ﾆﾔﾘｯ と本当にスレッドストッパーかけてくださいと冗談言ってみる。 ギコナビで書き込もうとしたら
ＥＲＲＯＲ：このスレッドには書き込めません。緊急緊急緊急!!
と表示されているが実際には書き込まれてます。
こっちに誘導されて来ました
yournet.ne.jpの規制が先ほど解除されたのですがlive10の規制が解除されていないようです。
解除の方よろしくお願いします。
規制絡みの設定のひとつF22が入ってないんじゃない？＞live10
【Project peko】2ch特化型サーバ構築作戦 Part8
http://qb3.2ch.net/test/read.cgi/operate/1078972549/
19 名前：root ★ 投稿日：04/03/11 13:36 ID:???
live10, f22への登録おながいします。＞サザンさんかな。
【実況板】 live5/7/8/9 鯖 【専用スレッド】その４
http://qb3.2ch.net/test/read.cgi/operate/1078921755/359
まとめると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プロセスが行うので
排他処理は不要。
ていうか俺が作れってか ■ このスレッドは過去ログ倉庫に格納されています
