【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/ 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が落ちていると、そこも効かなくなるということなのかしら。 具体的には、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 ２台体制にする、(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へのバージョンアップ完了。
これから、本格的にセットアップ入ります。 >>172
%php -v
[Mon Dec 6 04:04:02 2004] [apc-error] apc_shm_create: shmget(0, 31457280,914) failed: Cannot allocate memory
変わらないようですー（汗）
<q cite="http://moonshine.s32.xrea.com/#news">
04/08/28
APCの件は解決。/private/etc/rcでSystem V共有メモリの量を大きくすれば良かった。
8/15に書いた方法はBSDサブシステムが立ち上がってから実行されるため、変更できなかったと考察した。
</q>
と言う記述もありましたー
kernel のオプションについては疎くて適切なアドバイスが出来なくてごめんなさいですm(_ _)m
あと、
%ps auxUch2rck54
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
ch2rck54 1001 0.0 0.0 0 0 ?? Z 3:30AM 0:00.00 <defunct>
と云うのも出ていますので、こちらも調査してみるです。。。
（こちらはRock54自動起動で何かが起こっているみたいですので。／Rock54システム自体は正常に稼働しているようです） >>174
了解です。
oyster243復旧後にでも。 あと、こゆのも出てるみたいですー＠svc関連
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 494 0.0 0.1 1180 488 con- I 3:20AM 0:00.00 [readproctitle] ■ このスレッドは過去ログ倉庫に格納されています
