【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part16

**root▲ ★** · 04/12/04 00:28:18

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/

**名無し募集中。。。** · 04/12/05 22:45:45

ex7モ娘（狼）では例年の事ですが保田聖誕祭が6日0時より開催見込みです
特に0時より30分程度及び6時より2分程度一斉投稿による負荷の上昇が予測されます
高負荷でのデータ収集等ありましたらご準備方宜しくお願いいたします

なお、とかげの尻尾規制の変更がありましたら鬼の様な連投もありえますので
必要がありましたらご一報くださいませ

などと書いて負荷が上がんないと結構恥ずかしい

**▲ 某ソレ511** · 04/12/06 00:47:31

昨日の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

**未承諾広告※** ◆TWARamEjuA · 04/12/06 01:47:40

banana238のphpさんが死んでいるようですー（汗）

**root▲ ★** · 04/12/06 11:49:38

oyster243、リブートしたですか。
ううむ。

>>76-77
みてみます。

**root▲ ★** · 04/12/06 11:59:30

243はしばらく観察すね。

**root▲ ★** · 04/12/06 12:04:11

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)

**root▲ ★** · 04/12/06 12:07:57

で、>>76 はソケット用のバッファがいっぱいってことなので、
それっぽいカーネル変数を、様子を見つつ大きくしてみることに。

**root▲ ★** · 04/12/06 12:33:40

banana238の以下の変数を、tigerサーバと同じ値

# increase listen queue
kern.ipc.somaxconn=8192
kern.ipc.maxsockbuf=2097152

にした。

**root▲ ★** · 04/12/06 12:41:38

>>77 関連で、ちと banana238 の Apache と PHP 関連をいじります。
一時的にWeb 止めます。

**root▲ ★** · 04/12/06 13:06:22

banana238のPHP、直ったはず。
(apc.so を extensions.ini で2回呼んでいました)

Perlのsetuid問題は、現在未対応。

**root▲ ★** · 04/12/06 13:22:48

>>82
ちなみに前はそれぞれ、
kern.ipc.somaxconn=2048
kern.ipc.maxsockbuf=524288

だった。

**root▲ ★** · 04/12/06 13:53:19

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

**root▲ ★** · 04/12/06 13:53:51

(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

**root▲ ★** · 04/12/06 13:54:27

oyster243、ディスクだめですね。
DNSキャッシュを緊急に変更する必要がありそう。

**動け動けウゴウゴ２ちゃんねる** · 04/12/06 14:45:21

運営ｶﾞﾝﾊﾞﾚ、超ｶﾞﾝﾊﾞﾚ

**root▲ ★** · 04/12/06 16:21:07

現状:

・oyster243の緊急バックアップは概ね完了
・現地スタッフさんが、HDD手配に奔走中
・HDDが手配でき次第、交換予定

**root▲ ★** · 04/12/06 16:28:09

というわけで、こちらで。

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作戦スレでやるか。

**root▲ ★** · 04/12/06 16:35:15

現状。
まずは、待ちということで。

91 名前：root ★[] 投稿日：04/12/06 16:34:31 ID:???
SCSIすね。

さて、緊急作業は概ね終わりました。
以降は、

1)HDD交換(by 現地スタッフ)
2)OSインストール(by 現地スタッフ)
3)設定(by 私)

という手順になります。
それまでは、待ちの状態かと。

**root▲ ★** · 04/12/06 16:42:43

>>91 は、単独スレかな。
テーマは、dnscache の冗長化で。

**FOX ★** · 04/12/06 17:21:03

目の前の問題は BBQ が止まったことだす。

BBQ がとまっても時間はかかるが書き込めるという仕様になっています。

【お題目】 BBQ を止まらないようにする

これを実現するには?

1) BBQ だけで一台占有し、少しでも楽々動かせるようにする
2) BBQ 内部の処理の効率化、少しでも楽々動かせるようにする

3) 二重化とか　そのへん? (原理的に出来るかどうか・・・)

ちなみに　BBQ はどれくらいの速度で呼ばれているのかな?

**root▲ ★** · 04/12/06 17:26:01

BBQはDNSコンテンツサーバなので、2台にできると思います。
BBSみたいに統計とるのに使ってないので、今のBBQと同じものを
もう1台作成する方針が一番いいんじゃないかと。

そのときは、投入する側にしかけの追加が必要そうですね。
投入したものが、2台に反映されるようにすると。
このへんはサザンさんがやってるわけですがｌ、そんなに難しくないはず。

**root▲ ★** · 04/12/06 17:27:10

で、ちょっとごそごそしてみた。

緊急にセカンドディスク側で、DNSキャッシュだけ動かしてみています。
ちょっと様子見てやばそうなら、すぐ止めるということで。

**FOX ★** · 04/12/06 17:28:22

BBQ って内部では何かDB使っているのですか?

**root▲ ★** · 04/12/06 17:28:53

で、この状態で量産型bananaサーバからの書き込みがブロックされるかどうか、
確認したいわけです。

ブロックされないなら、旧版のbbs.cgiにサザンさんが入れた仕掛けは、
ちゃんと動いていると。

で、同じことをnews18とnews19でもやってほしかったり。

これらはDNSキャッシュを自前で持っているので、
DNSキャッシュダウンの影響を受けないはず。

それでもブロックされるようなら、SpeedyCGI版bbs.cgiの
該当部分が、うまく動いていないことになります。

**root▲ ★** · 04/12/06 17:29:48

>>97
cdbという、DNSサーバに付属のDBを使っていますね。
それ以外には使用していないです。

cdbがあるおかげで、あのでかいデータをうまく扱えている。

**root▲ ★** · 04/12/06 17:31:46

that3 ブロックしない

**FOX ★** · 04/12/06 17:33:06

しかし
私が診断するに、、、

cdb でのデータベース構築が
まったくデータベースの特性をいかしていないように見えるのですが、
(実際の仕様をみないで言っています)

**root▲ ★** · 04/12/06 17:34:03

news19 ブロックする

**root▲ ★** · 04/12/06 17:34:30

>>101
ふむ、具体的にはどういうことでしょう。

**root▲ ★** · 04/12/06 17:34:52

ex7 さっきブロックしていたのを確認(今はしない)。

**FOX ★** · 04/12/06 17:35:29

随時　投入/削除　という仕様じゃない、というとこかな?

**root▲ ★** · 04/12/06 17:36:37

今しないのは、FOXさんが該当部分をスキップしたためですね。

news19とthat3に入っているbbs.cgiは、
SpeedyCGI配下かPerlで動いているかの、違いしかありません。
でもthat3ではブロックしないのに、news19ではブロックした。

ということで、今入っているサザンさんが入れたalarm()の処理は、
SpeedyCGI配下では、正しく動かないと。

**root▲ ★** · 04/12/06 17:37:46

>>105
なるほど、増分投入(1つだけ追加投入するとか)ができない、
ということですね。

それは、cdbの弱点のひとつだったりします。
毎回全部をコンパイルしないといけない。

**FOX ★** · 04/12/06 17:40:57

巨大になってくると
それの再構築にかかる負荷がどんどん増えると予想。
HD に優しくないかと、

どれくらいの大きさあるのかな?
memory DISK に作っちゃうとか、、、

**root▲ ★** · 04/12/06 17:43:01

生データがこれですね。前スレから。

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は、ちょとまってください。確認します。

**root▲ ★** · 04/12/06 17:44:32

これか。
# ls -l data.cdb
-rw-r--r-- 1 ch2bbq ch2 150831091 Dec 5 20:59 data.cdb

で、作っている最中は、2倍になりますね。
できてから mv するので。

**root▲ ★** · 04/12/06 17:45:17

このぐらいなら、メモリ4Gあるoyster243なら、
メモリディスクに置けるかもしれんですね。

**FOX ★** · 04/12/06 17:48:31

私の案としては

1) DNSリクエストのスピードが限界値の半分以下なら
　HD に優しい仕様にする。

2) DNSリクエストの許容量の限界値に値被いているなら
　DNSで行っている仕様を大幅に変更　.cgi 経由にする

でーす

**root▲ ★** · 04/12/06 17:48:36

HDD確保できたもよりです。

**root▲ ★** · 04/12/06 17:50:13

>>112
今の問い合わせ頻度なら、まだ半分もいってないと思います。
DNS的に限界に達するのは、数千query/secのオーダかと。

ということで、前者に賛成です。

# さすがにすぐ、本質を突いてくるすね。

**root▲ ★** · 04/12/06 17:51:00

データがでかくなるとややつらくなってきますが、それでも1000query/secぐらいまでは
ゆとりで耐えるはずかと。

**root▲ ★** · 04/12/06 17:53:30

というわけで、HDDに優しい仕様にする方向で、
検討してみます。

**root▲ ★** · 04/12/06 17:54:04

あとは、SpeedyCGI版だとalerm()でのブロック脱出が
そのままでは使えないらしい、ってのも、いまいちかも、かも。

**FOX ★** · 04/12/06 17:54:25

んじゃ　1) の方針か?

取りうる手段は順次とっていくということで、
まずはmd化に一票
1G あれば当面足りる?

**FOX ★** · 04/12/06 17:55:11

>>117
それは　bbs.cgi スレの方で
研究してミルです

**root▲ ★** · 04/12/06 17:56:45

>>118
1Gだと、微妙かしら。
でも幸運にもメモリ4G仕様なので、
HDDに1.5Gとか2G割り当ててもいいし、なんとかなると思います。

**FOX ★** · 04/12/06 17:57:42

小一時間で再インストール完了すると思うので
今回　md 化できるですか?

**root▲ ★** · 04/12/06 17:59:36

>>121
できると思います。

DNSのログ吐きもばかにならなそうですね。
こっちも、あわせてやってみます。

**FOX ★** · 04/12/06 18:00:20

方針は
全部mdの上がいいですけど、
足りないなら

出来上がり品は HD 上
途中(構築中)は md 上かな、

**root▲ ★** · 04/12/06 18:04:03

再インストール、始まったみたいです。

上記方針、了解。

**FOX ★** · 04/12/06 18:07:29

ちなみに　BBQ は Raid1 が良い気がしたりするのですが・・・

**root▲ ★** · 04/12/06 18:09:13

>>125
そうですね。
そのぐらいの信頼性が必要と。

LSI LogicのMegaRAID(数万円程度高くなる)あたりでRAID1を組めば、
いける気がします。

**FOX ★** · 04/12/06 18:14:06

>>126
早急にいれよう。

**root▲ ★** · 04/12/06 18:16:58

これかしら。

LSI Logic MegaRAID SCSI 320-1
LSI Logic MegaRAID SCSI 320-2

どっちかですね。
-1で十分かな。

**FOX ★** · 04/12/06 18:17:34

あと BBM とかのサーバの配置ですが、

BBM は構想が巨大ですが、この際ちょっと中断して

peko243 = BBQ
peko245 = DNS キャッシュ
BBM は bananaに引越し

ってな感じが良いかと思っているんですが
どですか?

**root▲ ★** · 04/12/06 18:18:28

>>129
今 BBM って、携帯でカキコしようとしたときしか呼ばれてないんでしたっけ。

**FOX ★** · 04/12/06 18:18:45

そうです。

**root▲ ★** · 04/12/06 18:24:05

なら、DBの大きさに依存するですね。
ちょっとみてきます。

で、RAIDですが、
今SCSI 2channel独立なので、
-2の値段が高くないなら、-2のほうがいいかもです。

FreeBSDでは、いずれも問題なく動作するはず。

**▲:/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 04/12/06 18:35:47

bananaにBBMですか。ちょっとつらそうに思うのは私だけ？

また特殊系は全部HDDにやさしくしないといけないと思うのは私だけ？

**root▲ ★** · 04/12/06 18:37:25

ex7 変ですね。
どうしたのかしら。

**動け動けウゴウゴ２ちゃんねる** · 04/12/06 18:41:02

ex7って今落ちてますか？ただ重いだけ？

おお　たいがあ　よ　なにごとだ

**FOX ★** · 04/12/06 18:41:55

>>133
楽勝でしょ

>.134
ちと実験に失敗して。。。　屍

**root▲ ★** · 04/12/06 18:44:43

>>136
実験すか、、、。

game9 game10 news18 news19 hobby7 の bbs.cgi を
Perl起動にしました。これで、とりあえず書き込みはブロックしないはず。

**動け動けウゴウゴ２ちゃんねる** · 04/12/06 18:44:49

>>136
おまえのせいかあぁぁぁぁぁぁ

**root▲ ★** · 04/12/06 18:46:14

で、
ex7 屍
live8 live16 live17 BBQスキップ版bbs.cgi
他のtigerサーバ BBQノンブロック版bbs.cgi

になったと。

他の量産型banana (live14除く) oyster243 復活待ち
かな。

**root▲ ★** · 04/12/06 18:46:44

tiger503 リブートかかった模様。

**root▲ ★** · 04/12/06 18:51:22

news19、やはりブロックしますね。
うーむ。

**root▲ ★** · 04/12/06 18:54:28

BBQのところで詰まってますね。
そこをスキップしたら、ちゃんといけた。

Perl版なのに、どうしてだろう。

**動け動けウゴウゴ２ちゃんねる** · 04/12/06 19:01:50

FOX★たん、プロ野球板のスレが1200ぐらいから70ぐらいになっちまいましたよ。。。
リブートした後

**root▲ ★** · 04/12/06 19:03:00

Perl版のほうも、スキップ版にしないと(FOXさんがした模様)、だめなのか。
うーむ、研究が必要ということで。

**root▲ ★** · 04/12/06 19:04:46

混乱するので、私はoyster243が復活するまでは、
bbs.cgi 方面はいじらないことにします。

現在、ex7 live8 live16 live17 以外は従来のPerl版で動いています。

**root▲ ★** · 04/12/06 19:11:51

ということで、システムインストール作業待ちの状態。

>>129 ですが、BBQとdnscacheをそういう配置にするのは、
メモリ容量の違い、と考えていいのかしら。

で、以降途中は(場合によっては移行後も)、
oyster243でもdnscacheを動かし続けるというかんじか。

**FOX ★** · 04/12/06 19:16:31

BBQ じゃなくて
DNS を引くときにブロックされていると思われ

それらのサーバには 243 しか書かれていないはず、

今 live15 だけ変更してみました

**root▲ ★** · 04/12/06 19:18:04

>>147
そうですね。

でもその部分は、alarm()が効くと思っていたんですが。
それともdnscacheが落ちていると、そこも効かなくなるということなのかしら。

**root▲ ★** · 04/12/06 19:19:28

具体的には、gethostbyname() のところですね。
gethostbyname() から所定の時間内に戻ってこない場合、
次にいってほしいなと。

リモートホストを逆引きしてログにとるところ(gethostbyaddr()のところ)は、
alarm()していないはずなので、そこはブロックしても仕方ないわけですけど。

**FOX ★** · 04/12/06 19:20:01

たんにリモホ引くときは Alarm で引っ掛けていないです

**FOX ★** · 04/12/06 19:20:46

そこの仕様変更は危険と思われ。。。

どんどん　BBQ に焼かれます。

**root▲ ★** · 04/12/06 19:22:16

>>150
うん。そこはブロックされるはずです。

でもそこが大丈夫なはずのtigerサーバ/cobraサーバ(= DNSキャッシュ自分もち)のところも、
BBQのチェック部分でひっかかったのが、なぜなのかなと。

**FOX ★** · 04/12/06 19:22:36

live15,ex8

nameserver 実験で確かめるために変更しました。

1) 345
2) 243
3) maido3 のどれか所定のやつ
4) maido3 のどれか所定のやつ

**動け動けウゴウゴ２ちゃんねる** · 04/12/06 19:22:46

これは面白い祭り会場ですね

生暖かい目で見守っています。
がんがってくださいね！

-=・=-　　　-=・=-

**root▲ ★** · 04/12/06 19:23:14

>>151
BBQは、外からDNSひいても影響ないです。
(外からひくことで登録しているのは、BBX/Rock54)。

**FOX ★** · 04/12/06 19:24:11

Tiger/Cobra のbbs.cgi(SpeedyCGI) のやつは
今のところ何をやっても Alarm をBackEndが受け取ってくれません
たぶん　FrontEnd は受け取っていると思われ
これはこれからの研究に委ねられます。

**root▲ ★** · 04/12/06 19:24:24

>>153
245すね。
今 query きているのを確認しました。

**root▲ ★** · 04/12/06 19:25:16

>>156
了解です。

**FOX ★** · 04/12/06 19:25:22

>>155
リモホ引けないやつはどんどん焼くという仕組みが
Boo80 にあるですよ、

だから BBQにどんどん投入しちゃう

**FOX ★** · 04/12/06 19:26:33

今　ブロックが起ってかけないサーバは BBQ 云々じゃなく
単に普通のリモホ引きが出来ないために起っています。

**root▲ ★** · 04/12/06 19:29:01

>>159
おー、そういうことだったんですか。
逆引きちゃんと設定してないと、どきどきするわけだ。
了解です。

>>160
そうですね。

**root▲ ★** · 04/12/06 19:34:17

oyster243、HDD交換終了。
受け取りました。
セットアップにとりかかります。

**FOX ★** · 04/12/06 19:50:37

当面の方針は

1) 243 (or245)
2) 245 (or243) 半々くらいに、
3) maido3 設置ラックによる所定のやつ
4) maido3 設置ラックによる所定のやつ

ということにして

243 , 245 のDNS ２台体制にする、(BBM はお引越し)
243 で RAID1 を試してうまく行ったら 245 もRAID1化

でいいかな?

**root▲ ★** · 04/12/06 19:54:27

>>163
1)～4)は /etc/resolv.conf の設定順ですね。

で、dnscache/BBQとも、2台体制にするというかんじですか。
それともdnscacheだけ2台体制?

**FOX ★** · 04/12/06 19:59:35

BBQ は別に一台

dnscache/BBQ (二台 143,145)
BBQ 別に一台(ひろゆきが買ってくれるのを期待!!)

ということで
現状では BBQ 専用はないので BBQは 243に同居
BBM は 245 に同居

かな?

**root▲ ★** · 04/12/06 20:06:36

ということは、

oyster243 dnscacheその1 BBQ
cobra2245 dnscacheその2 BBM

でまずは動かしておいて、

別サーバ1 BBQその2

をめざすということかしら。

**FOX ★** · 04/12/06 20:07:44

そうそう
どうでしょ?

**未承諾広告※** ◆TWARamEjuA · 04/12/06 20:10:27

>>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>

だそうですー（汗）

**root▲ ★** · 04/12/06 20:12:03

BBQ死亡時が、どきどきしますが、
BBQその2が来るまでは、bbs.cgiごにょごにょとか、
対症療法でなんとかすると。

であれば、当面これでいける気がします。

次の段階で、oyster243とcobra2245のセカンド側のインタフェース使って、
1つのIPアドレス共有をはかりたいですね。

**root▲ ★** · 04/12/06 20:13:10

>>168
おー、なるほど。

携帯サーバ並みにあれをふやさないと、いかんのか @ banana238。
時間とれたところでやっておくです。

**root▲ ★** · 04/12/06 20:14:16

portsをmake updateし、
make -j8 buildworld buildkernelしています。< oyster243

その間に、banana238をみてきます。

**root▲ ★** · 04/12/06 20:21:24

>>168
banana238に、

# keitai server tuning
kern.ipc.nmbclusters=32768
kern.ipc.maxsockets=32768
vm.pmap.shpgperproc=1024

を足して、rebootしました。
どうでしょう。

**root▲ ★** · 04/12/06 20:58:39

5.3Rへのバージョンアップ完了。
これから、本格的にセットアップ入ります。

**未承諾広告※** ◆TWARamEjuA · 04/12/06 21:11:52

>>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システム自体は正常に稼働しているようです）