【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part16
■ このスレッドは過去ログ倉庫に格納されています
peko作戦について語るスレです。 サーバロケーションPIEに関する話題もこちらで。 <現在の主要なテーマ> ・read.cgiのmod_cgidso化によるパフォーマンスアップ ・bbs.cgiのSpeedyCGI化によるパフォーマンスアップ ・FreeBSD 5.3Rへのサーバ更新作業&さらなるチューニング <関連板・スレッド> また挑戦。@2ch掲示板 http://dso.2ch.net/myanmar/ また挑戦2。@2ch掲示板 http://dso.2ch.net/yangon/ bbs.cgi再開発プロジェクト4 http://qb5.2ch.net/test/read.cgi/operate/1101984763/ read.cgi再開発スレ http://qb5.2ch.net/test/read.cgi/operate/1087199303/ <関連サイト> レンタルサーバー maido3.com 2ちゃんねるの転送量: http://server.maido3.com/pie/ MRTGによる統計情報: http://mumumu.mu/mrtg/ 2ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html <前スレ> 【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part15 http://qb5.2ch.net/test/read.cgi/operate/1093068260/ ex7モ娘(狼)では例年の事ですが保田聖誕祭が6日0時より開催見込みです 特に0時より30分程度及び6時より2分程度一斉投稿による負荷の上昇が予測されます 高負荷でのデータ収集等ありましたらご準備方宜しくお願いいたします なお、とかげの尻尾規制の変更がありましたら鬼の様な連投もありえますので 必要がありましたらご一報くださいませ などと書いて負荷が上がんないと結構恥ずかしい 昨日のkawasemi-mを見てみたら、01:30ころに 2〜3分データの増加していない時間帯がありました。 ということで、netstatを見てみましたが、その時間帯で下記の値が急増してました。 ちなみに、それ以外の時間帯は、この数字は増えてなくて、 これ以外の値はだいたい全ての時間帯にかけて緩やかに増加している感じですね。 http://stats.2ch.net/_service/netstat-20041205.txt 01:25:00 3207 dropped due to full socket buffers 01:35:00 23922 dropped due to full socket buffers banana238のphpさんが死んでいるようですー(汗) oyster243、リブートしたですか。 ううむ。 >>76-77 みてみます。 12月3日(PST)付けで oyster243 上にいやなメッセージを発見、、、。 システムディスク(da0)の方ですね。これは。 いずれにせよ、しばらく経過観察で。 Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 0 1 4c c1 bf 0 0 80 0 Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): CAM Status: SCSI Status Error Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): SCSI Status: Check Condition Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): HARDWARE FAILURE info:14cc086 asc:3,0 Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): Peripheral device write fault field replaceable unit: 4 actual retry count: 24 Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): Retrying Command (per Sense Data) Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 0 1 4c c3 3f 0 0 80 0 Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): CAM Status: SCSI Status Error Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): SCSI Status: Check Condition Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): Deferred Error: HARDWARE FAILURE info:14cc2bf asc:3,0 Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): Peripheral device write fault field replaceable unit: 4 actual retry count: 24 Dec 3 06:10:22 <0.2> oyster243 kernel: (da0:mpt0:0:0:0): Retrying Command (per Sense Data) で、>>76 はソケット用のバッファがいっぱいってことなので、 それっぽいカーネル変数を、様子を見つつ大きくしてみることに。 banana238の以下の変数を、tigerサーバと同じ値 # increase listen queue kern.ipc.somaxconn=8192 kern.ipc.maxsockbuf=2097152 にした。 >>77 関連で、ちと banana238 の Apache と PHP 関連をいじります。 一時的にWeb 止めます。 banana238のPHP、直ったはず。 (apc.so を extensions.ini で2回呼んでいました) Perlのsetuid問題は、現在未対応。 >>82 ちなみに前はそれぞれ、 kern.ipc.somaxconn=2048 kern.ipc.maxsockbuf=524288 だった。 root権限ありサーバの、FreeBSD 5.3Rへのバージョンアップ作業の残件まとめ 下の方ほど優先度低 BBMとblackgoatが終わったら、あとはぼちぼちってかんじで。 cobra2245 = BBM tiger512 = blackgoat4 cobra2247 = c-docomo2 cobra2246 = c-docomo3 banana403 = c-au1 banana404 = c-au2 banana405 = c/c-au/c-docomo/c-others/c-others1/c-control banana406 = c/c-others2 banana201 = www/www2 (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 0 1 5c 9 9f 0 0 80 0 (da0:mpt0:0:0:0): CAM Status: SCSI Status Error (da0:mpt0:0:0:0): SCSI Status: Check Condition (da0:mpt0:0:0:0): Deferred Error: HARDWARE FAILURE info:15c091f asc:3,0 (da0:mpt0:0:0:0): Peripheral device write fault field replaceable unit: 4 actual retry count: 24 (da0:mpt0:0:0:0): Retrying Command (per Sense Data) (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 0 1 5c a 9f 0 0 80 0 (da0:mpt0:0:0:0): CAM Status: SCSI Status Error (da0:mpt0:0:0:0): SCSI Status: Check Condition (da0:mpt0:0:0:0): Deferred Error: HARDWARE FAILURE info:15c0a1f asc:3,0 (da0:mpt0:0:0:0): Peripheral device write fault field replaceable unit: 4 actual retry count: 24 (da0:mpt0:0:0:0): Retrying Command (per Sense Data) (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 0 1 5c 4 9f 0 0 80 0 (da0:mpt0:0:0:0): CAM Status: SCSI Status Error (da0:mpt0:0:0:0): SCSI Status: Check Condition (da0:mpt0:0:0:0): Deferred Error: HARDWARE FAILURE info:15c039f asc:3,0 (da0:mpt0:0:0:0): Peripheral device write fault field replaceable unit: 4 actual retry count: 24 (da0:mpt0:0:0:0): Retrying Command (per Sense Data) (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 0 1 5c 6 9f 0 0 80 0 (da0:mpt0:0:0:0): CAM Status: SCSI Status Error (da0:mpt0:0:0:0): SCSI Status: Check Condition (da0:mpt0:0:0:0): Deferred Error: HARDWARE FAILURE info:15c059f asc:3,0 (da0:mpt0:0:0:0): Peripheral device write fault field replaceable unit: 4 actual retry count: 24 (da0:mpt0:0:0:0): Retrying Command (per Sense Data) (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 0 1 5c 8 9f 0 0 80 0 (da0:mpt0:0:0:0): CAM Status: SCSI Status Error (da0:mpt0:0:0:0): SCSI Status: Check Condition (da0:mpt0:0:0:0): Deferred Error: HARDWARE FAILURE info:15c079f asc:3,0 (da0:mpt0:0:0:0): Peripheral device write fault field replaceable unit: 4 actual oyster243、ディスクだめですね。 DNSキャッシュを緊急に変更する必要がありそう。 現状: ・oyster243の緊急バックアップは概ね完了 ・現地スタッフさんが、HDD手配に奔走中 ・HDDが手配でき次第、交換予定 というわけで、こちらで。 87 名前:root ★[] 投稿日:04/12/06 16:26:12 ID:??? さて、再発防止対策だなぁ。 1)DNSキャッシュのIPアドレスを共有した、2台以上のサーバでまかなう 2)もう1台DNSキャッシュを用意して、/etc/resolv.confに2行書く 1)がいいですね。 2)だと、今回みたいなトラブルがあると、結局30秒とか1分とか待たされてしまうんで。 で、これを簡単にどう実現できるのか。 peko作戦スレでやるか。 現状。 まずは、待ちということで。 91 名前:root ★[] 投稿日:04/12/06 16:34:31 ID:??? SCSIすね。 さて、緊急作業は概ね終わりました。 以降は、 1)HDD交換(by 現地スタッフ) 2)OSインストール(by 現地スタッフ) 3)設定(by 私) という手順になります。 それまでは、待ちの状態かと。 >>91 は、単独スレかな。 テーマは、dnscache の冗長化で。 目の前の問題は BBQ が止まったことだす。 BBQ がとまっても時間はかかるが書き込めるという仕様になっています。 【お題目】 BBQ を止まらないようにする これを実現するには? 1) BBQ だけで一台占有し、少しでも楽々動かせるようにする 2) BBQ 内部の処理の効率化、少しでも楽々動かせるようにする 3) 二重化とか そのへん? (原理的に出来るかどうか・・・) ちなみに BBQ はどれくらいの速度で呼ばれているのかな? BBQはDNSコンテンツサーバなので、2台にできると思います。 BBSみたいに統計とるのに使ってないので、今のBBQと同じものを もう1台作成する方針が一番いいんじゃないかと。 そのときは、投入する側にしかけの追加が必要そうですね。 投入したものが、2台に反映されるようにすると。 このへんはサザンさんがやってるわけですがl、そんなに難しくないはず。 で、ちょっとごそごそしてみた。 緊急にセカンドディスク側で、DNSキャッシュだけ動かしてみています。 ちょっと様子見てやばそうなら、すぐ止めるということで。 で、この状態で量産型bananaサーバからの書き込みがブロックされるかどうか、 確認したいわけです。 ブロックされないなら、旧版のbbs.cgiにサザンさんが入れた仕掛けは、 ちゃんと動いていると。 で、同じことをnews18とnews19でもやってほしかったり。 これらはDNSキャッシュを自前で持っているので、 DNSキャッシュダウンの影響を受けないはず。 それでもブロックされるようなら、SpeedyCGI版bbs.cgiの 該当部分が、うまく動いていないことになります。 >>97 cdbという、DNSサーバに付属のDBを使っていますね。 それ以外には使用していないです。 cdbがあるおかげで、あのでかいデータをうまく扱えている。 しかし 私が診断するに、、、 cdb でのデータベース構築が まったくデータベースの特性をいかしていないように見えるのですが、 (実際の仕様をみないで言っています) >>101 ふむ、具体的にはどういうことでしょう。 ex7 さっきブロックしていたのを確認(今はしない)。 随時 投入/削除 という仕様じゃない、というとこかな? 今しないのは、FOXさんが該当部分をスキップしたためですね。 news19とthat3に入っているbbs.cgiは、 SpeedyCGI配下かPerlで動いているかの、違いしかありません。 でもthat3ではブロックしないのに、news19ではブロックした。 ということで、今入っているサザンさんが入れたalarm()の処理は、 SpeedyCGI配下では、正しく動かないと。 >>105 なるほど、増分投入(1つだけ追加投入するとか)ができない、 ということですね。 それは、cdbの弱点のひとつだったりします。 毎回全部をコンパイルしないといけない。 巨大になってくると それの再構築にかかる負荷がどんどん増えると予想。 HD に優しくないかと、 どれくらいの大きさあるのかな? memory DISK に作っちゃうとか、、、 生データがこれですね。前スレから。 784 名前:root▲ ★[sage] 投稿日:04/12/02 00:21:17 ID:??? ちなみに今のBBQデータ。でかっ。 %ls -l data -rw-r--r-- 1 ch2bbq ch2 73286705 Dec 1 07:20 data %wc -l data 5158061 data cdbは、ちょとまってください。確認します。 これか。 # ls -l data.cdb -rw-r--r-- 1 ch2bbq ch2 150831091 Dec 5 20:59 data.cdb で、作っている最中は、2倍になりますね。 できてから mv するので。 このぐらいなら、メモリ4Gあるoyster243なら、 メモリディスクに置けるかもしれんですね。 私の案としては 1) DNSリクエストのスピードが限界値の半分以下なら HD に優しい仕様にする。 2) DNSリクエストの許容量の限界値に値被いているなら DNSで行っている仕様を大幅に変更 .cgi 経由にする でーす >>112 今の問い合わせ頻度なら、まだ半分もいってないと思います。 DNS的に限界に達するのは、数千query/secのオーダかと。 ということで、前者に賛成です。 # さすがにすぐ、本質を突いてくるすね。 データがでかくなるとややつらくなってきますが、それでも1000query/secぐらいまでは ゆとりで耐えるはずかと。 というわけで、HDDに優しい仕様にする方向で、 検討してみます。 あとは、SpeedyCGI版だとalerm()でのブロック脱出が そのままでは使えないらしい、ってのも、いまいちかも、かも。 んじゃ 1) の方針か? 取りうる手段は順次とっていくということで、 まずはmd化に一票 1G あれば当面足りる? >>117 それは bbs.cgi スレの方で 研究してミルです >>118 1Gだと、微妙かしら。 でも幸運にもメモリ4G仕様なので、 HDDに1.5Gとか2G割り当ててもいいし、なんとかなると思います。 小一時間で再インストール完了すると思うので 今回 md 化できるですか? >>121 できると思います。 DNSのログ吐きもばかにならなそうですね。 こっちも、あわせてやってみます。 方針は 全部mdの上がいいですけど、 足りないなら 出来上がり品は HD 上 途中(構築中)は md 上かな、 再インストール、始まったみたいです。 上記方針、了解。 ちなみに BBQ は Raid1 が良い気がしたりするのですが・・・ >>125 そうですね。 そのぐらいの信頼性が必要と。 LSI LogicのMegaRAID(数万円程度高くなる)あたりでRAID1を組めば、 いける気がします。 これかしら。 LSI Logic MegaRAID SCSI 320-1 LSI Logic MegaRAID SCSI 320-2 どっちかですね。 -1で十分かな。 あと BBM とかのサーバの配置ですが、 BBM は構想が巨大ですが、この際ちょっと中断して peko243 = BBQ peko245 = DNS キャッシュ BBM は bananaに引越し ってな感じが良いかと思っているんですが どですか? >>129 今 BBM って、携帯でカキコしようとしたときしか呼ばれてないんでしたっけ。 なら、DBの大きさに依存するですね。 ちょっとみてきます。 で、RAIDですが、 今SCSI 2channel独立なので、 -2の値段が高くないなら、-2のほうがいいかもです。 FreeBSDでは、いずれも問題なく動作するはず。 bananaにBBMですか。ちょっとつらそうに思うのは私だけ? また特殊系は全部HDDにやさしくしないといけないと思うのは私だけ? ex7って今落ちてますか?ただ重いだけ? おお たいがあ よ なにごとだ >>133 楽勝でしょ >.134 ちと実験に失敗して。。。 屍 >>136 実験すか、、、。 game9 game10 news18 news19 hobby7 の bbs.cgi を Perl起動にしました。これで、とりあえず書き込みはブロックしないはず。 で、 ex7 屍 live8 live16 live17 BBQスキップ版bbs.cgi 他のtigerサーバ BBQノンブロック版bbs.cgi になったと。 他の量産型banana (live14除く) oyster243 復活待ち かな。 BBQのところで詰まってますね。 そこをスキップしたら、ちゃんといけた。 Perl版なのに、どうしてだろう。 FOX★たん、プロ野球板のスレが1200ぐらいから70ぐらいになっちまいましたよ。。。 リブートした後 Perl版のほうも、スキップ版にしないと(FOXさんがした模様)、だめなのか。 うーむ、研究が必要ということで。 混乱するので、私はoyster243が復活するまでは、 bbs.cgi 方面はいじらないことにします。 現在、ex7 live8 live16 live17 以外は 従来のPerl版で動いています。 ということで、システムインストール作業待ちの状態。 >>129 ですが、BBQとdnscacheをそういう配置にするのは、 メモリ容量の違い、と考えていいのかしら。 で、以降途中は(場合によっては移行後も)、 oyster243でもdnscacheを動かし続けるというかんじか。 BBQ じゃなくて DNS を引くときにブロックされていると思われ それらのサーバには 243 しか書かれていないはず、 今 live15 だけ変更してみました >>147 そうですね。 でもその部分は、alarm()が効くと思っていたんですが。 それともdnscacheが落ちていると、そこも効かなくなるということなのかしら。 具体的には、gethostbyname() のところですね。 gethostbyname() から所定の時間内に戻ってこない場合、 次にいってほしいなと。 リモートホストを逆引きしてログにとるところ(gethostbyaddr()のところ)は、 alarm()していないはずなので、そこはブロックしても仕方ないわけですけど。 たんにリモホ引くときは Alarm で引っ掛けていないです そこの仕様変更は危険と思われ。。。 どんどん BBQ に焼かれます。 >>150 うん。そこはブロックされるはずです。 でもそこが大丈夫なはずのtigerサーバ/cobraサーバ(= DNSキャッシュ自分もち)のところも、 BBQのチェック部分でひっかかったのが、なぜなのかなと。 live15,ex8 nameserver 実験で確かめるために変更しました。 1) 345 2) 243 3) maido3 のどれか所定のやつ 4) maido3 のどれか所定のやつ これは面白い祭り会場ですね 生暖かい目で見守っています。 がんがってくださいね! -=・=- -=・=- >>151 BBQは、外からDNSひいても影響ないです。 (外からひくことで登録しているのは、BBX/Rock54)。 Tiger/Cobra のbbs.cgi(SpeedyCGI) のやつは 今のところ何をやっても Alarm をBackEndが受け取ってくれません たぶん FrontEnd は受け取っていると思われ これはこれからの研究に委ねられます。 >>153 245すね。 今 query きているのを確認しました。 >>155 リモホ引けないやつはどんどん焼くという仕組みが Boo80 にあるですよ、 だから BBQにどんどん投入しちゃう 今 ブロックが起ってかけないサーバは BBQ 云々じゃなく 単に普通のリモホ引きが出来ないために起っています。 >>159 おー、そういうことだったんですか。 逆引きちゃんと設定してないと、どきどきするわけだ。 了解です。 >>160 そうですね。 oyster243、HDD交換終了。 受け取りました。 セットアップにとりかかります。 当面の方針は 1) 243 (or245) 2) 245 (or243) 半々くらいに、 3) maido3 設置ラックによる所定のやつ 4) maido3 設置ラックによる所定のやつ ということにして 243 , 245 のDNS 2台体制にする、(BBM はお引越し) 243 で RAID1 を試してうまく行ったら 245 もRAID1化 でいいかな? >>163 1)〜4)は /etc/resolv.conf の設定順ですね。 で、dnscache/BBQとも、2台体制にするというかんじですか。 それともdnscacheだけ2台体制? BBQ は別に一台 dnscache/BBQ (二台 143,145) BBQ 別に一台(ひろゆきが買ってくれるのを期待!!) ということで 現状では BBQ 専用はないので BBQは 243に同居 BBM は 245 に同居 かな? ということは、 oyster243 dnscacheその1 BBQ cobra2245 dnscacheその2 BBM でまずは動かしておいて、 別サーバ1 BBQその2 をめざすということかしら。 >>84 %php -v [Mon Dec 6 02:46:39 2004] [apc-error] apc_shm_create: shmget(0, 31457280,914) failed: Cannot allocate memory って出ますー(汗) <q cite="http://moonshine.s32.xrea.com/#news "> 04/08/15 ひとりごと。 coreを吐いたり、たまにコンパイルをミスるMMCacheに代わってAPC2の導入を検討中。 まずPHPをconfigureのオプションに --enable-sysvshm を付けてコンパイル。 普通にインストールすると [apc-error] apc_shm_create: shmget(0, 31457280,914) failed: Invalid argument のようなエラーが出て使えない。 FreeBSDではSHMMAXPGSとSHMSEGの値を適当に増やしてカーネルを再構築すれば大丈夫だった。 しかしMacOS Xではカーネルの再構築というわけにもいかない。(Darwinのソースからとかはナシで) </q> だそうですー(汗) BBQ死亡時が、どきどきしますが、 BBQその2が来るまでは、bbs.cgiごにょごにょとか、 対症療法でなんとかすると。 であれば、当面これでいける気がします。 次の段階で、oyster243とcobra2245のセカンド側のインタフェース使って、 1つのIPアドレス共有をはかりたいですね。 >>168 おー、なるほど。 携帯サーバ並みにあれをふやさないと、いかんのか @ banana238。 時間とれたところでやっておくです。 portsをmake updateし、 make -j8 buildworld buildkernelしています。< oyster243 その間に、banana238をみてきます。 >>168 banana238に、 # keitai server tuning kern.ipc.nmbclusters=32768 kern.ipc.maxsockets=32768 vm.pmap.shpgperproc=1024 を足して、rebootしました。 どうでしょう。 5.3Rへのバージョンアップ完了。 これから、本格的にセットアップ入ります。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる