【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part16
■ このスレッドは過去ログ倉庫に格納されています
peko作戦について語るスレです。
サーバロケーションPIEに関する話題もこちらで。
＜現在の主要なテーマ＞
・read.cgiのmod_cgidso化によるパフォーマンスアップ
・bbs.cgiのSpeedyCGI化によるパフォーマンスアップ
・FreeBSD 5.3Rへのサーバ更新作業&さらなるチューニング
＜関連板・スレッド＞
また挑戦。＠2ch掲示板
http://dso.2ch.net/myanmar/
また挑戦２。＠2ch掲示板
http://dso.2ch.net/yangon/
bbs.cgi再開発プロジェクト４
http://qb5.2ch.net/test/read.cgi/operate/1101984763/
read.cgi再開発スレ
http://qb5.2ch.net/test/read.cgi/operate/1087199303/
＜関連サイト＞
レンタルサーバー maido3.com ２ちゃんねるの転送量: http://server.maido3.com/pie/
MRTGによる統計情報: http://mumumu.mu/mrtg/
２ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html
＜前スレ＞
【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part15
http://qb5.2ch.net/test/read.cgi/operate/1093068260/ >>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台に反映されるようにすると。
このへんはサザンさんがやってるわけですがｌ、そんなに難しくないはず。 で、ちょっとごそごそしてみた。
緊急にセカンドディスク側で、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が落ちていると、そこも効かなくなるということなのかしら。 ■ このスレッドは過去ログ倉庫に格納されています
