【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/ 最近毒男板の観光客、ってよく聞くけど そのわりにはたいしてちゃっかりカウンターの値(=index.html読まれた数)が 大して増えていないのは一体。 たしかに11月上旬くらいには一割増し(+2500)程度はあったけど。。 おとうさん、おかあさん、毒男は2chのために行ってまいります。 ('A`)ゞ 現在 ex7 280投稿/min くらい メモリは十分なような、 CPU States は 40%前後 (たまに85%なんてのも) とくに問題なさげです いいかんじですね。書き込みも重くないです。 これでピーク時(今日はもうピーク越えた予感)にも問題なければ、すごいかも。 日曜日の11:30〜12:30は、安倍なつみが司会を務めるハロモニの日 その後、ハロプロのスポーツフェスティバルinさいたま こんなふうですね。 常駐型バックエンドがうまいぐあいに常駐して、とてもいい感じに動いているように見えます。 read.cgiは起動しないし(あたりまえ)。 PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 6389 ch2ex7 102 0 9372K 8432K CPU2 0 0:53 22.90% 22.90% speedy_backend 5887 ch2ex7 101 0 9436K 8412K select 2 1:03 21.19% 21.19% speedy_backend 7921 ch2ex7 100 0 8844K 7872K select 0 0:13 16.58% 16.46% speedy_backend 6391 ch2ex7 99 0 9072K 8008K select 0 0:19 13.18% 13.18% speedy_backend 1061 ch2ex7 99 0 9160K 8148K select 0 1:57 10.30% 10.30% speedy_backend 5890 ch2ex7 99 0 9172K 8112K select 1 1:16 8.74% 8.74% speedy_backend 6386 ch2ex7 101 0 8040K 7280K select 3 0:04 8.74% 8.74% speedy_backend 7923 ch2ex7 99 0 8456K 7500K select 0 0:07 8.07% 8.01% speedy_backend 6382 ch2ex7 98 0 9284K 8260K select 2 0:46 3.56% 3.56% speedy_backend 6384 ch2ex7 97 0 9080K 8084K select 3 0:37 2.64% 2.64% speedy_backend 631 dnscache 96 0 32868K 32172K select 3 128:43 1.90% 1.90% dnscache 99798 ch2ex7 96 0 9284K 8296K select 0 1:18 0.98% 0.98% speedy_backend >>28 そのまま放送するんですかね。 テロップ入りかな。 >>29 STATE のところに CPU1 , CPU2 , CPU3 とかって出るのは どういう意味なんですか? 実は今、新潟じゃハロモニ。をやってたりする なっちが出てるやんw Tigerサーバは、Xeon x 2(2CPU)です。 で、こいつはHTTをサポートしています。 HTTは乱暴に言ってしまうと、CPUへの仕事の入力路を1CPUあたり1つから2つにして、 よりスムーズに仕事の投入ができるようにするための技術です。 これをやると、システムからは2つのCPUに見えます。 というわけで、FreeBSDからは4CPUのマシンに見えることになります。 で、topでの表示は、 それぞれのCPU(CPU0〜CPU3)に、該当プロセスがアサインされているっていう意味かなと。 そろそろ実験止めて設定元に戻してよ 今日午後からずっと書き込めなくなってる >>33 CPU1 - 4 のStatesが別々に出るようにはならないんですかねぇ % で表示されているのは 全体の平均? top -S とやってシステムプロセスも表示すると、それぞれのCPUの忙しさがわかるです。 んで、こういう表示になるわけです。 PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 14 root 111 0 0K 12K RUN 0 205.5H 81.05% 81.05% idle: cpu0 11 root 108 0 0K 12K RUN 3 175.4H 65.92% 65.92% idle: cpu3 12 root 106 0 0K 12K RUN 2 163.9H 57.81% 57.81% idle: cpu2 13 root 105 0 0K 12K RUN 1 153.6H 53.76% 53.76% idle: cpu1 14241 ch2ex7 101 0 9128K 8120K RUN 0 0:12 24.02% 24.02% speedy_back 13925 ch2ex7 100 0 9520K 8476K RUN 3 1:01 19.82% 19.82% speedy_back 12779 ch2ex7 99 0 9556K 8572K CPU2 2 1:37 14.26% 14.26% speedy_back 11890 ch2ex7 96 0 9864K 8844K select 0 1:30 13.23% 13.23% speedy_back 12600 ch2ex7 97 0 9424K 8452K select 0 1:46 6.10% 6.10% speedy_back 13544 ch2ex7 97 0 9308K 8292K select 1 1:09 3.81% 3.81% speedy_back 上記の通り、資源は全部で400%(CPU数だけ倍になる)ということになり、 idle: cpu? というプロセスが「動いている」ように見える時間は、CPUはアイドル状態というわけです。 質問・雑談スレ81@運用情報板 http://qb5.2ch.net/test/read.cgi/operate/1101642955/949 というわけで、今ex7はかなり遊んでるすね。 で、こいつらを平均した値が概ね上の「idle」のところの数値ということで。 こっちか。 995 名前:root▲ ★[sage] 投稿日:04/12/04 02:06:41 ID:??? systat -pとかsystat -vとかすると、いろいろとわかるです。 >>41 いろいろ実験するのは結構だが せめて書き込めるようにして >>43 どういう状況で書き込めないかしっかり書いたら? >47 (・∀・)ナンカエラーダッテ HTTP/1.1 302 Found (・∀・)カンリョウ!! というわけで見れませんです >>48 read.cgiからなら読める・・・ なぜだ? Cookie無い状態で文中に "を入れて書き込むと "以降の文章が消える件について OS も更新されたのでマルチスレッド MPM の再挑戦もいいのでは,と思いつつも, mod_speedycgi2.c を見ると ---------------------------------------------------------------------- #if APR_HAS_THREADS /* Two problems with threaded mpms: * * Speedy routines are not thread safe. We can workaround that with a big * lock, though that may cause excessive waiting when Maxbackends * is used. * * Frontends are sent SIGALRM to wake them up, and signals don't get * delivered to the waiting thread. */ ap_mpm_query(AP_MPMQ_IS_THREADED, &is_threaded); if (is_threaded) return log_scripterror(r, HTTP_FORBIDDEN, 0, "cannot use mod_speedycgi with a threaded mpm"); #endif ---------------------------------------------------------------------- ということで,残念...... mod_perl ならばいいのでしょうけど, それでも bbs.cgi の方を MT-Safe に手直しする必要があります. まぁ,今は prefork MPM で SpeedyCGI に対応させる方が先決でしょうね. なお,mod_cgidso 及び当方で DSO 対応化した read.so は MT-Safe です. live16 , live17 を SpeedyCGI 化するー are you ready ? >>58 おぉ。 既にSpeedyCGIは入れてあるので、問題ないです。 おつでした。>>60 live8も今はSpeedyCGIなので、できるはず。 live8/16/17のApacheの RLimitCPUを30から120にした。 banana238にてゾンビさんがちょろちょろ。。。 駆除していただけるとありがたいですm(_ _)m http://ch2.ath.cx/load/live8.html なんか突き抜けてるよママン(((( ;゜Д゜)))ガクガクブルブル で、最後のほうだけ実況板にいたけど、さすがに反応遅くなってたなぁ ふむ 逆にグローバルを使って処理を軽く出来るということか、、 こんど挑戦してみよう。 って、ex7のほうが密かに 380.35 res/minまで達しとる http://ch2.ath.cx/load/ex7.html 733 :名無し募集中。。。 :04/12/05 01:26:40 ここは金田一春彦を祖父に持つ俺の出番だな 1102177546 734 :名無し募集中。。。 :04/12/05 01:26:41 IDみたいなもんかな 1102177530 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()でのブロック脱出が そのままでは使えないらしい、ってのも、いまいちかも、かも。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる