■　新しいサーバで read.cgi が正しく動かない問題。

>>283
ちなみに
bbs.cgi@live5 は gzip 圧縮(index.html subback.html)の部分を
コメントアウトした特別製です。
ということは、新しいの上書きしたらちょっと挙動不審になるです。

いたって好調だから他のapache2(music2以降)のサーバにもいれようかな。。。

>>278　いまんとこ僕と愉快な仲間たちの間でも不具合聞いてないっす。

と思って、etc サーバを見てみたら・・・

CPU0 states: 13.0% user, 5.1% system, 0.0% nice, 81.2% idle
CPU1 states: 7.4% user, 2.0% system, 0.0% nice, 89.4% idle
CPU2 states: 11.4% user, 3.4% system, 0.0% nice, 84.0% idle
CPU3 states: 9.2% user, 1.3% system, 0.0% nice, 88.3% idle

なんか四つ付いているんですけど・・・

>>289
xeonってハイパースレッディング対応だったかな？
AMD使いなんで推測ですが…

って,ここで終わっちゃわけわかめぢゃないか…
ハイパースレッディングに対応だと1個のCPUを2個認識するはず。
ﾄﾞｿﾞｰ
ttp://www.intel.co.jp/jp/developer/technology/itj/2002/volume06issue01/art06_computeintensive/p01_abstract.htm

cpuinfoでも４つみえました。
processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.00GHz
stepping : 7
cpu MHz : 1993.606
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 3984.58

>>292
(恐らく2次)キャッシュサイズのxeonなら,そういう
仕様で間違いないと思いますー。

>>289 >>292
4つｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

>>293
ウホッ 抜けてますた。
キャッシュサイズ512kでつね…

うほっ

>>283
うん。そのノリに近いかも。
実際昔はディスクドライブの調子とか負荷の状況とか、HDDに耳当てて聞いてた。
モデムの通信音やLEDの光り方で通信のパフォーマンスが出てるかどうかも
ある程度はわかったし。

>>284
6 zombie ってそんなもんなんでしょか。
CPU status 的には特に問題なく、わりと健康に見えますねぇ。< その値
で、いたって好調すか。bbs.cgiも軽くなるし、一石二鳥か。

あとは iostat や vmstat (とかのコマンドってLinuxにあるんだっけ、
じつはLinuxはきちんと管理したことなかったりして)、あるいはtopコマンドあたりで
システムの様子を見てみるとよさげか。

etcもmod_deflateになりました？
大きなサイズのスレが開けるようになりましたが。

ttp://www.yakin.cc/
昨日よりは薄皮一枚落ちた感じですが,
ディスクアクセスの状態がポイントですかね。
んじゃおやすみなさーい…

ん?
ほんとに四つ付いているのかなぁ・・・

music2 以降のoysterサーバを top コマンドで覗いてみたら
live5(oyster19) 以外四つ見えるです。

かといって問い合わせたら、二本抜かれそうだし・・・
はてはて、

>>297
CPU負荷は最大で両CPUとも40%を超えることはないようです。
おおむね最大で38%くらい、
enoughって感じかな、
いたって快調に動いています。

>>298
なりましたー

>>301
おー、ありがとうございます。
これで作業が楽になるですー。

HT対応Xeonじゃないすか？
これ。
ttp://www.intel.co.jp/jp/eBusiness/products/server/benefits/ht/

>>287
if (apacheが1)
　　gzip圧縮処理
endif
みたいにすればよさそうすね。

Apacheのバージョンは、/usr/sbin/httpd -v とかやるととれるから、
Perl から呼べばよいかな。

1.x と 2.x で httpd -v の出力は微妙に違うみたいなので、例えば、
/usr/sbin/httpd -v | head -1 | sed -e 's/.*Apache\///' -e 's/\..*//'

に相当するようなことをPerlで組んで、結果が1か2かで判別すればいいのかな。

>>303
おお、そういえば。

>>300
> CPU負荷は最大で両CPUとも40%を超えることはないようです。
> おおむね最大で38%くらい、
> enoughって感じかな、
> いたって快調に動いています。

いい感じすね。mod_deflate有効化前はどんなふうだったのでしょう。
gz作成のための処理とI/O待ちとが多かったとすると、かなり改善されるはず。
特にカキコの多い板は顕著かと。

# まさかとは思うけど、
# system("gzip subback.html"); みたいなことはしてないですよねぇ、、、。< bbs.cgi

# まさかとは思うけど、
# system("gzip subback.html"); みたいなことはしてないですよねぇ、、、。< bbs.cgi

コメントを差し控えようかと・・・
管理人に聞いてくださいー

>>307
Mmm, No comment is sometimes more fluent...

Anyway, if mod_deflate is deployed, this gzip'ing process becomes unneeded.
So, I don't care this.

>>308
あ、careの後ろにaboutかも。やっぱ、現場英語はだめだこりゃ。

こんな行がありましたよ＞bbs.cgi

do{
system("gzip -c $SUBFILE > $SUBGZFILE");
}while(-z $SUBGZFILE);

>>304
書き込みのたびにhttpd -v呼ぶんですか?
それよりSERVER_SOFTWAREで判定しては?
if ($ENV{SERVER_SOFTWARE} =~ m{Apache/1}) {
do{
system("gzip -c $SUBFILE > $SUBGZFILE");
}while(-z $SUBGZFILE);
}

>>310
ぎょぎょぎょ。Perl module使った方がコマンド呼ぶ負荷が(以下略。

>>311
あ、そのほうがいいすね。

ここは一つ、実験室を再開してbbs.cgiの改造を本格的に・・・。

ハアー！さっぱりさっぱり

んじゃ案を

案 ver0.001

main()
{
SETTING.TXT 読み込み();
規制関連();
datに追記();
subject.txt更新();
/*subback.html更新();*/
}

/html
/i
の処理は無くなりますか？

それらを、かんかんがくがくと

おけです。別ｽﾚ立てたほうが良いですね。
実験室やrdtのような特別板でもつくりますか？
それともこの板に立ててしまいましょうか…？

まずは基本思想からだから
この板に別スレッドでのんびり話し合って行くっていうところでしょうか、

1) 基本思想
2) 基本設計
3) 詳細な設計　→　モジュール別にコード書き
　　(ここでさまざまな方法が試される、連投規制とか)
4) 組み上げ
5) テストー

ってな流れになるのでしょうか。