■新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!? Part1

**FOX ★** · 05/01/07 03:19:00

■　新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!?

巨大Live専用サーバの構築

live系のサーバは台数投入したところで、ほとんど遊んでいる
サーバ + 一台の負荷が高くてアクセスできないサーバという
悲惨な状況になっちゃうので、複数のサーバを巨大な一台と見立てて
なんとかならんものなのかを模索するー。

【Step1】四台のbananaサーバで現 live8/live16/live18 を全部収容する。

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:19:16

　　　　　　 |三|
　　　　　／■ ＼
　　　　　 |´∀｀　 |　ｵﾆｷﾞﾘｭｷﾀﾞﾙﾏｶﾞ2ｹﾞﾄ
　　 ★ 　ヽ＿＿ノ　 ★
　　　＼ミ≡≡彡／
　　　　/　　　巛　ヽ
　　　 |　　　　　　 |
　　　丶　　　　ﾉ
　　　　　＼＿＿_／
⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒

**その他 ★** · 05/01/07 03:19:27

乙

**南アルプス** ◆98YENoslbU · 05/01/07 03:20:14

今ここに醜い自演を見た。

**ひろゆき＠どうやら管理人 ★** · 05/01/07 03:20:37

mysqlがクラスタリングのモデルだしましたけど、
あれはどうなんでしょう？

**その他 ★** · 05/01/07 03:22:19

汎用は所詮汎用だと思うなぁ、、、

**動け動けウゴウゴ２ちゃんねる** · NG

(n‘∀‘)η

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:26:35

誰も言ってあげないみたいだから言ってあげよう。

>>1乙

**じじぃ その４** ◆HETAREzfq. · 05/01/07 03:28:06

とりあえずbbs.cgiのsubject関係とdat関係の処理を明示的に分離しるんけ？
ようﾜｶﾗﾝけんども

**root▲ ★** · 05/01/07 03:28:46

いきなり第一ステップから「全部収容」すかぁ。
さて、どの持ち駒をどう使っていこうかなと。

>>3
さすが、流行に敏感。

**マァヴ ★** · 05/01/07 03:31:43

あー、３年くらい前に構造を色々考えたことがあった気がする(^_^;)
あの頃とはかなり様相が変わったんだよね・・・・
能力を分割するとしたら
・bbs.cgi
・disk I/O
・read.cgi
の３つかな？

**その他 ★** · 05/01/07 03:34:35

banana227 を bqckend にして
live14/live18 あたりを front にしてbasicなものを組んで
試行錯誤してみようかな、、

banana227 の root pw を明日になったら送りまーす >>10
banana386 と
banana613 は最初は単に virtualhost 作ってラウンドロビンしてみよう

**マァヴ ★** · 05/01/07 03:37:07

bサーバ、dサーバ、rサーバと仮に名前をつけると味気ないので
弘法・聖徳・空海と名づけるとしよう(^_^;)

まず聖徳の仕事
　弘法から投げられた書き込みをひたすらメモリーに書き込む
　空海から呼びだしを受けたら、どんどんdatを投げる
　1000に達したスレッドはガンガンディスクに書き込んで、メモリ上から消す

こんなかんじ？

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:39:27

cgiはそれぞれのサーバーに
datは4台のサーバーにRAID5(6?)の様な感じで格納ってなるの?
>>1を見るだけでは良く分からないけど

って書いていたら>>11-13が書き込まれたけど....俺の脳みそではヨクワカラン

**root▲ ★** · 05/01/07 03:40:58

基本コンセプトは
「読み手担当と書き手担当を完全に分離することにより、効率をアップする」です。
すべては、ここから。

>>12
了解。

**マァヴ ★** · 05/01/07 03:43:38

弘法の仕事(^_^;)
　ラウンドロビンでたくさんたてて、どこに書き込みが来ても適切な聖徳に渡す
　やってきた書き込みが正当かどうかのチェックをする（聖徳は書き込む以外やらないですむように）

空海の仕事
　ラウンドロビンでたくさん立てて、どこに読み出しが来ても適切な聖徳からdatを取得する
　読み出しの要求に対して、聖徳からdatを引っ張ってきて、htmlに変換して吐き出す
　一定時間（10秒程度？）はキャッシュして、聖徳への呼びだし回数を減らす

こんな感じ？(^_^;)

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:44:11

root ★ﾀﾝの説明は分かりやすいなぁ

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:45:18

>>17
ありゃ▲抜けてた。

**マァヴ ★** · 05/01/07 03:45:29

>15
bbs.cgiとread.cgiの分割だけでも充分かもしれないですね(^_^;)
弘法と聖徳は一体化・・・・
ただ、そうするとbbs.cgiにスケールメリットが取れなくなるけど

**root▲ ★** · 05/01/07 03:47:09

で、読み手担当は、read.cgiサービスと、datファイル直読みサービスを提供します。
bbs.cgiのフロントエンド(と仮に名づけよう)も、担当するかな。
つまり、お客さんの相手に専念する。

で、bbs.cgiフロントエンドは、いろんなチェックしたら、
datファイルやらリモホ情報やらを、書き手担当に何らかの方法で通信して伝えます。

書き手担当は、ひたすらI/Oする。
datちょうだい、と読み手担当に言われれば渡すし、
これ処理しといて、と読み手担当に言われたら、たんたんと処理する。
でも、お客さんの相手は基本的にしない。

削除とか芋堀とか、いわゆる保守系は、書き手担当が受け付けるのかな。
あくまで、保守系だけね。お客さんは受付へどうぞ。

**マァヴ ★** · 05/01/07 03:50:45

>20
read.cgiとbbs.cgiだと、負荷総量ではreadのほうが圧倒的にでかいんじゃなかったっけ？(^_^;)
readを分離したほうがいいと思うんだけど。

**▲ 某ソレ511** · 05/01/07 03:53:56

live系だとbbs.cgiのほうの負荷で重い場合が多いんですよね、、たしか。
ラピュタの時は読み込みが多くてだったけど。

**じじぃ その４** ◆HETAREzfq. · 05/01/07 03:55:48

負荷がたかくなるとsubject.txtがまず壊れる場合が多いんじゃが
read.cgiサービスとbbs.cgiサービスを分けることでコレは改善しるのけ？

ようﾜｶﾗﾝなりにおらが理解してたのでは
agesageの処理もかなりきつかったような気がしるんじゃが

**マァヴ ★** · 05/01/07 03:56:49

>23
改善はしないと思う(^_^;)

**マァヴ ★** · 05/01/07 03:57:39

http://kobodaishi.xrea.jp/
ふはははは(^_^;)

**root▲ ★** · 05/01/07 03:57:46

>>21
bbs.cgiの方が圧倒的にでかいですね。
特にread.cgiはdso化して起動コストがなくなったので。

bbs.cgi(のフロントエンド)ができるだけブロックしないようにしたいですね。
重い処理(ディスクI/O関連)を、後ろに回すのが、たぶん第一段階の最初かと。

で、後ろに回した処理がボトルネックになるようなら、最初は成功。
あとは、後ろ側の処理の効率を上げる方向で、チューニングしていくと。

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:58:50

>>13
弘法と空海は同一人物では・・・

**root▲ ★** · 05/01/07 03:59:41

もちろん、前と後ろの通信をうまくやってできるだけブロックしないようにするとか、
そういう方向でのプログラミング的手法も、必要になりそうかな。

いずれにせよ、またお風呂にでも入りながら、
ちょっと脳内で絵を描いてみようかと。

**マァヴ ★** · 05/01/07 04:00:19

>26
なるほど(^_^;)
まずはbbs.cgiの分離ですね

**通行人** · 05/01/07 04:06:28

実況系はagesageの処理を無くしてもいいんじゃないかと思ったり・・・

**その他 ★** · 05/01/07 04:07:54

1) 机上の空論
2) それに基づいた絵
3) 絵を描く
4) 実験する
5) 1)が合っていたかどうかの検証

これをひたすら繰り返すと、

**じじぃ その４** ◆HETAREzfq. · 05/01/07 04:11:11

コレを機会に負荷が高くなった時に起きる不可視やら板とびやらの
主だった仕組み（原因）をご教授願いたいものじゃ

datを更新しました⇒（伝達）⇒subjectを書き換えます
のどっちかが溢れてしまうからこういうことになるんじゃとおもうんじゃが
どっちが溢れることが多いんじゃ？

subject生成の工程に伝わった時点でそこが溢れておるのか、
dat更新の段階で溢れてしまってsubjec生成tの工程に伝わってないのか、

**その他 ★** · 05/01/07 04:11:44

んで
現状は bbs.cgi が律速であると解かっている

bbs.cgi を動かすサーバを二台にしてみる
ただしdatは一箇所に書かなきゃ意味が無いので
backendにdat処理用一台と、

これでやって、　subject.txt や規制系やその他もろもろが
使い物になるのかどうか、、、
特に規制系はsambaにしても連投規制にしても、かなり手ごわいかと、
あきらめるのも一手ですが、

**ひろゆき＠どうやら管理人 ★** · 05/01/07 04:12:49

readがいくらでも分散できるのは
blackgoatで証明済みなような。

**その他 ★** · 05/01/07 04:13:02

>>32
「壊れてもいいや直せば」という前提で
ファルロックを一切行っていない、つまり排他制御していない

なので壊れるのです。

**FOX ★** · 05/01/07 04:15:04

>>34

そですねぇ
delay値をどれくらいにすれば体感上違和感がなくなるか、
それとトラフィックのボリューム(頻度?)との兼ね合い、せめぎあい
なのかなぁと

**root▲ ★** · 05/01/07 04:15:29

で、最近のことをちょっと書いておくと、、、。

特にlive16とかはread.cgiやdat直読みの人が待たないようにするために、
ほんとはもっとhttpdの数を増やしたいわけです。

しかし昔は、起動数をむげに増やすと、「どーん」とbbs.cgiが同時に100個以上
起動された時に(例: 西部警察で導火線爆弾が出る等)、もう即死するしかなかった。

で、昨年bbs.cgiをSpeedyCGIにすることで、
最大並列処理数(バックエンドの最大起動数)を制限することができるようになり、
即死のリスクをとても減少させることができました。

でもこの場合、bbs.cgiの実際の処理をしている人がおなかいっぱいになると、
こんどはフロントエンドがバックエンドの処理終了を待ってしまって、
結局httpdを埋めていってしまうことになります。
つまり、流入は制限されるのですが、「終了に時間がかかって、窓口人員が不足がちになる」
ことに変わりはないわけです。

また、バルスとかマツケンサンバとか、超人気番組の場合、
おそろしい勢いで読み手が攻めてきて、httpdが売り切れになってしまい、
サーバは負荷が低いのに、誰も書き込みができないし、
読むのも難しい、という状態になったりします。
これも、窓口の人手が足りない状態。

ということで、
・窓口の人手を増やして
・お客をできるだけ待たせないようにしながら
・でも、サーバにはやさしい方法で処理する

ような手法はないだろうか、というのが、今回の試みなのではないかなと。