【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part14
■ このスレッドは過去ログ倉庫に格納されています
peko作戦について語るスレです。 サーバの新ロケーション、PIEに関する話題もこちらで。 現在の主要なテーマは、 ・新ロケーション、PIEの安定化 ・pekoサーバ突然死の原因究明 となります。 レンタルサーバー maido3.com 2ちゃんねるの転送量: http://server.maido3.com/pie/ MRTGによる統計情報: http://mumumu.mu/mrtg/ 2ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html PINKちゃんねるで現在進行中のama作戦については、こちら。 【Project ama】PINKちゃんねる特化型サーバ構築作戦 Part2 http://qb3.2ch.net/test/read.cgi/operate/1082721809/l50 携帯電話特化型サーバ構築作戦については、こちら。 【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1 http://qb5.2ch.net/test/read.cgi/operate/1075887465/ 前スレ 【Project peko】2ch特化型サーバ構築作戦 Part13 http://qb5.2ch.net/test/read.cgi/operate/1085678587/ >>414 うん、このスレで言うことじゃないけど。 >>415 これにて退散します。失礼しました。 >>416 そこで言っても説明さえしてくれないんだよな・・。 退散はします、失礼。 >>404 おいおい、おっさん。 他人にケツをふいてもらうのかよ。 >>389 鯖争奪戦時の約定を違えましたね(・∀・)ニヤニヤ >>389 ヤダヤダヤダヤダヤダヤダヤダヤダヤダヤダ!!!!!!!!!!!!!!! 負荷が軽い状態で突然死んだ、、、。< tiger503 いやな予感。 >>426 pekoと同じ突然死ですかねぇ。 だとすると、 1) メモリ 2GBクラス 2) DualCPU 3) SCSIシステム あたり+2ch+FreeBSD5で顕在化する地雷があるのかなぁ? pekoサーバはi386じゃなくてamd64だけど、 SMPとapicをコメントアウトしてから今のところ一度も死んでないからなぁ。< game6/news11 ちと調べてみる。 ひょっとして、また、read.cgiを止めると、 tigerも問題がなくなるとか・・・! reboot して read.cgi とめてみます SMP + read.cgiの状況で落ちたとすると、 つまりこの問題がもしFreeBSD-5.2.1R/i386にもあるとすると、かなりやっかいだ、、、。 しかし、topで見ているとここはbbs.cgiがよく暴走するですね。< tiger503 で、RLimitCPU (=120)にひっかかるまでCPUを食い続ける。 >434 FreeBSD-5.2.1R/i386が原因か切り分ける為にどれか1台に前のバージョンで 試してみてはどうでしょうか? >>437 4.10Rを入れるですか。(HE時代のumaサーバはFreeBSD4系だった) 今のTigerのアーキテクチャなら、技術的には可能ですが。 安定を望むのであれば、FreeBSD 4.xxと言う選択肢もありかもですね。 >>437 は可能なら、やってみる価値はあると思いますね。 とりあえず5-CURRENTを持ってきて、関連しそうなソースを眺めてみるか。 まずはめし。 >>441 今のgame6/news11の状態ですね。 SMPなし状態。(i386ではないのでapicはもともとなし) やってみる価値はあるけど、 read.cgiなしでしばらく(すくなくとも1日は)動かしてみてからか。 gdb /usr/bin/perl [暴走しているプロセスID] ってやったら、 (gdb) where #0 0x2818648f in stat () from /lib/libc.so.5 #1 0x080d8925 in Perl_my_stat () #2 0x080cec5b in Perl_pp_ftis () #3 0x0809d028 in Perl_runops_standard () #4 0x0805bb46 in perl_run () #5 0x0805b82b in perl_run () #6 0x08058f59 in main () #7 0x08058e02 in _start () だそうで。 すくなくともこのPerlは、stat()の中で暴走していた模様。 ううむ。 live13がだいじょうぶなら そこにex7を突っ込んで(ryするとか・・・ ぢすく周りの気瓦斯・・・ 頼むから誰か 「bbs.cgi再開発プロジェクト 4」 を立ててくれ >>447 透明削除で回復できますからいらないです。 うーん、立てるとしても必要になってからでいいんじゃないかなあ 寝ていた(倒れていた)間に、なんだかいろんなことがあったようで。 で、とりあえずbbs.cgiが更新されていたようなので、 pekoサーバのものをコンパイルして更新しておいた。 落ち着いているようなので、 ・MaxRequestsPerChild 10000 => 100 ・StartServers 128 => 64 ・MaxSpareServers 128 => 64 にして、ex7のread.cgiを元に戻してみた。 で、あまりにしっちゅうbbs.cgi(Perl)の暴走を目撃するので、 RLimitCPU 120 => 60 に変更した。< ex7 これでしばらく実験かと。 read.cgiがまた喧嘩しちゃってるのかな? 書き込み時にだいぶ時間かかりますた ex7重いっすね 選挙でVIPに人が集まってるのかな 重いすね。 bbs.cgi(perl)がたくさん暴走してました。 今は少しましかな。 >>455 のやつ、ex7だけ30(秒)にしてもいいかもしんないなぁ。 ex7だけ30secにした。 しかしlive系でもたまにしか起こらないのに、どうしてこうもbbs.cgiが暴走するんだろう。< ex7 >>463 perl(perlcc) のバージョンが 5.8 系だとか? >>464 5.6.1ですねぇ。すくなくとも私がおもりしてるやつは全部そうです。 ex7は実験のため、あえてperlccはしてませぬ。 >>463 が効果出してるですね。 でも、しょっちゅう暴走する状況にかわりはない模様。 軽い状態でいきなり反応がなくなった、、、。 やはり同じ病をかかえているのか。 リブート要請しました。 リブート要請しました。 上がったら、read.cgiを止めます。 >>466 http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5/ 5.6 系は 1 なのですかー。。。 5.8 系にするのはちょと怖いような。。。 でも 5.8 系の鯖では何事もなかったかのように動いていたりもするし。@非 root な banana 鯖 >>472 非rootなbananaも5.6.1のはず。 >>474 確認してみましたが、退役した鯖の httpd レスポンス Server: にだけ、Perl/v5.8.0 の文字列が入っていました。 ということで現状すべて 5.6 系かと思われるですm(_ _)m read.cgiを動かすとダメになるとは・・・ 前途多難ですねぇ・・・ >>476 ・1CPUにした(SMP, apicをコメントアウト)game6がその後5日間落ちていない(amd64だけど) ・1CPUなbananaサーバは問題が起こっていない ところをみると、FreeBSD 5.2.1のSMP/apicまわりに何か問題があるのかも。 qb5.2ch.netサーバのuptime情報(?)みたいなのが今日の0:30で止っているようです http://qb5.2ch.net/_service/20040711.txt 2004/07/11 00:30:00 LA=12:30AM up 31 days, 11:53, 0 users, load averages: 5.58, 10.41, 16.00 で止ってます qb6.2ch.netは動いているみたいです >>477 1CPUでは問題が発生せず、2CPU(機能)にのみ問題が発生している、 ということを考慮すると、 現行のFreeBSDと2CPUの問題としか、考え難いですねぇ・・・ FreeBSDの4.xのほうがいいのかなぁ・・・ >>478 たぶん昨日の騒ぎで、F22を切ったままなんではないかなと。 携帯からのアクセスが20:00から上昇中。 ロードアベレージはかなりあるけど、何とか動いている模様。 http://mumumu.mu/mrtg/mrtg-rrd.cgi/load/ >>482 選挙開票で上がったのかなと思いました。 >>482 ホントだ 36access/sec = 10.8kaccess/5minだから、昨日に比べても極端に アクセスが増えてると言う訳ではなさそう。 http://mumumu.mu/mrtglog/2004/07/10/access/c-docomo2access.html ドキッとして調べてみたけど、そうではなさそうですね。 本当にLAが上がっている模様。 このグラフはApacheのserver-statusからとるようにしました。 (今まではアクセスログを正直にカウントしていた) で、見ているとrunnable processが多いです。< c-docomo2 選挙 < 新庄 らしい。(もちろん選挙も無視できないけど) I updated bbs.cgi on all peko servers. 問題切り分けのため、近々シングルCPU設定を試してみる予定。< ex7 それでうまく動くようなら、やむを得ないけどしばらくシングルCPU設定で。< tigerサーバ 携帯サーバへのアクセスも峠越えたみたいなので、今日はこれで。 acpiを止めてみたらどう?という天の声を聞いた。 /boot/device.hintsに hint.acpi.0.disabled="1" か。 あーacpiが悪さするってのは結構ありえますね。 Linux系でもたまに聞くので。 ぐぐったらこんな話もありました。 ttp://pc5.2ch.net/test/read.cgi/unix/1039789225/485 >>495 すいません、またコテハン入れ忘れた・・・ orz これを読む限り、(OS問わず)SMPとACPIは相性がよろしくありませんな。 たぶんhaltさせるときは同時でないといけないから 何かの理由でそのタイミングが狂うと(その段階で)出してはいけない命令が かちあってそのままお亡くなりになるという・・・・ 設定変更・リブート完了。 read.cgiを復活させました。< ex7 これで明日まで無事だったら、デュアルCPUを復活させてgame6とかにも入れてみよう。 で、順次他のサーバにも。 突然死がとうとう解決されるのか!気になる結果はCMのあとで!! まっ実験しなきゃ先には進めん。 いい結果を期待したいが・・・ これでもダメなら・・・ どうなるんでそ?>root ★ さん やっぱりシングルCPUでしばらくの間は置いとくのかな。 >>502 まずはex7でのテスト結果をマターリと見ようかと。 これまでの様子から、1日動けば効果ありとしてよいと思われ。 【BBQ 2本目】炭まだぁ〜? 【公開串リストメンテ】 http://qb3.2ch.net/test/read.cgi/operate/1077190185/681- ここらで話題が出たのが最後かな?>BBM BBQスレでやってるから話が流れる流れる・・・ まあ、いろいろ他に優先事項がいろいろあったんですけどねー peko姐の新しいお仕事・・・ 【oyster争奪戦】新サーバ情報スレッド 14 http://qb5.2ch.net/test/read.cgi/operate/1086435290/552 552 名前:留守番 ★ 投稿日:04/07/03 05:51 ID:??? BBQ シリーズの携帯版でーす(mobile) 固有番号を溜め込みます 1) 初めて書き込もうとした人に、お知らせ出すとか、 2) 書き込みお断りを制御したり 3) 携帯関係の統計取ったり いろいろ出来る予感です 基本的な動きとしては 1) key は携帯固有番号 2) 問い合わせ、登録、削除、更新はすべて getなんたら 八個くらい用意すればいいかな? dat8.dat7.dat6.dat5,dat4.dat3.dat2.dat1key.bbm.2ch.net dat1 = action(登録、問い合わせ、更新・・・ の作業番号or文字列) dat2 = ....... そのまえに、 comic4 の F22 を止める → comic4.peko 作成 → 過去ログ移転 かな ★? 38 → 206 もやっちゃいたいような(苦笑) ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる