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

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

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

巨大Live専用サーバの構築

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

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

**root▲ ★** · 05/03/09 04:05:50

>>168
できれば、そうしたいと思っていました。
cのフロントとおなじ乗りで。

**FOX ★** · 05/03/09 04:08:00

んで　live15 で実験しませんか?
なぜならあいている banana があるわけで、

front1 , front2
↓↑
live15

がすぐ組めるような、
これで live15 系として banana 一台の何倍のキャパになるかが知りたかったり、、

**root▲ ★** · 05/03/09 04:09:43

最初は、squidの非同期I/Oならかなりはやいはずだから、I/Oさせてもいいかなぁとか
思っていたんですが、今日の結果を見て(まだdiskd試してないからあれだけど)、
やっぱりフロントエンドでI/Oさせるのはかなりつらいのかなと、改めて思いました。

まだ独立で動かしてないから、言い切れない部分がありますけど。

**root▲ ★** · 05/03/09 04:11:15

>>171
やりますか。

ex7でのデータとりは、このままやるとして、
今liveb1を名乗っているやつを front1 に改造すると。

**FOX ★** · 05/03/09 04:14:00

第一弾としては

1) front1 をつくる
2) back はいまのまま　(bbsx.soは作るけど)
3) front2 を追加

これで天井測定

こんな感じかしら?

**動け動けウゴウゴ２ちゃんねる** · 05/03/09 04:18:31

私は基本的に>>156案に同意ですが
バックエンドは、基本的にCPUはスカスカになり
(ネットワーク処理もCPUはIDLEでしょうから)
read.cgi処理も出来るだろうと考えています。
.datも含めて、オンメモリのキャッシュを有効に活用すれば
sendfileには劣るかもしれませんが、ネットワーク負荷も
静的コンテンツ転送以下に抑えられるでしょうし。
同居すれば、「.datをどうやって取ってくるか」「.dat転送のコスト」
等は無視できるようになりますから。

ただ、(特に開発中は)CGIDSOは非常に有効ですが
これ自体は、(fork/execはしないものの)毎回ロードとリロケーションを行っていると思います。
この点も考慮すると、スカスカって程ではないかもしれません。

それと、index.htmlの作成もbackend側で出来れば、
(連投規制等考えなければいけない点もあるものの)
フロント(.dat書き込み以外のbbs.cgi処理全般に専念)は
ほぼ完全にラウンドロビンで台数増減が自由になると思います。

とはいえ、実験した数字を見てみるのが一番ですね。
backendのCPUに余力がありそうならread.cgiを後ろに回すことも考える、という事で。

**root▲ ★** · 05/03/09 04:21:18

それでいきますか。

これで、read.cgi、dat直読み、bbs.cgiをfront1で担当できるようにいろいろ整えるということですね。

書き込みはfront1のbbs.cgi => live15のbbsx.so で、
読むほう(read.cgiとdat直読み)をどうするか、、、が、質問の趣旨であると。

**root▲ ★** · 05/03/09 04:22:53

>>175
どもです。
> 毎回ロードとリロケーションを行っていると思います。

タイムスタンプぐらいは、見てるんじゃなかったけか。

**FOX ★** · 05/03/09 04:24:42

そですね、

私も　どれとどれを fontにして
どれを back にするかという点では
本当に迷います

ここは実験しかないでしょうなぁ

**root▲ ★** · 05/03/09 04:30:06

>>178
さて、今liveb1って名前ですが、、、。
そのまま、使いますかね。

**FOX ★** · 05/03/09 04:35:00

いいんじゃないですか、
作る cgi 等も、ぐちゃぐちゃぺたぺたで最初は作りますし、
本番はlive16,live8のときですから、

**FOX ★** · 05/03/09 04:36:57

おっと　二台ありませんでしたっけ?
使っていないbanana

その２台を両方とも front にしたいから
livebq , liveb2 としておいて
実際にユーサがアクセスするラウンドロビンのやつは別名がいいかな?

**root▲ ★** · 05/03/09 04:41:01

未使用は、1台のはず。

もう1台、私が他サーバのメンテナンス用として使っているのがあります。
バージョンアップ作業の際の作業用マシンとか、ソースツリー置いてあったり、
CVSupやftp.freebsd.orgの部分ミラーをしてしたりしています。
くずして転用することはできますが、あまりくずしたくないかも。

**▲ 某ソレ511** · 05/03/09 04:42:07

eq.2ch.netでつかっちゃったからね。

**FOX ★** · 05/03/09 04:42:24

んじゃ　pie工事後にbananaを一台投入するということで、

**FOX ★** · 05/03/09 04:43:36

あっ　そうか・・・　>>184

あのサーバは暇そうだなぁ
もっとアイデア出して忙しくさせてくださいー

**FOX ★** · 05/03/09 04:43:57

ぐっ　>>183 だった

◆cZfSunOs.U · 05/03/09 08:34:19

read.cgi をフロントエンド側で走らせる場合，squid で dat をキャッシュさせるとなると，
dat を直接 open() はできないでしょうから，squid に対し HTTP リクエストを発して
取ってくるということになるんですかね．>>175 さんのおっしゃるようにバックエンドで
read.cgi を走らせてフロント側でキャッシュというのとどちらがいいのか......
まぁ実験しないとわかりませんね．

>>177
>> 毎回ロードとリロケーションを行っていると思います。
>
>タイムスタンプぐらいは、見てるんじゃなかったけか。

これは利用形態や状況に依存しますね．prefork MPM の場合，
あるいはマルチスレッド MPM でも read.cgi 呼び出しが間欠的であれば
ロード・リロケーションが毎回発生すると思います．一方，
マルチスレッド MPM で read.cgi が常時呼ばれている状況なら
毎回発生とはならず，ほぼ常駐したままになると思います．

◆cZfSunOs.U · 05/03/10 20:55:04

http://www.mail-archive.com/dev@httpd.apache.org/msg24903.html
* FreeBSD, threads, and worker MPM. All seems to work fine
if you only have one worker process with many threads. Add
a second worker process and the accept lock seems to be
lost. This might be an APR issue with how it deals with
the child_init hook (i.e. the fcntl lock needs to be resynced).
More examination and analysis is required.
Status: Works with FreeBSD 5.3. Does not work in previous versions.
This has also been reported on Cygwin.

**動け動けウゴウゴ２ちゃんねる** · 05/03/10 21:13:47

ほう。
つまり、1プロセスならば問題なさそう、という事ですね。
むしろ願ったりな状況なのかも。

**root▲ ★** · 05/03/10 22:54:35

>>188
おー。

やってみるか。

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 02:09:43

杉花粉で雪だるま・・・orz

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 03:44:18

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

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 11:49:44

DISKDは速いディスクなら圧倒的にパフォーマンスいいよ。
ただ、failしたときどうすんのか。

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 12:10:47

よー分からんけどスレを全てメモリで保持、バックアップ(ハードディスク書き込み)を外部で行えばいいんじゃないの?

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 14:14:34

>>194
すでにメモリディスク＝通称ジンギスカンは導入され絶大な成果を挙げていますが何か

**▲ 某ソレ511** · 2005/03/22(火) 18:31:57

datフォルダは今のところジンギスカンの対象外じゃなかったっけ、、

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 18:43:45

>>196
やっぱりジンギスカンは高いから？

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 19:11:42

>>196
そーでしたかしら
だったらスマソ

**じじぃ その４** ◆HETAREzfq. · 2005/03/22(火) 20:20:59

aliveなスレ（掲示板上にあるやつ）と過去ログ倉庫を
明確に分けたらうまく逝くのかのう？

aliveなほうは全ての作業をオンメモリで
dat落ちや削除・芋掘りがあった時点で倉庫に送る（HDDに送る）とか
云い換えれば、メモリマシンとHDDマシンを完全分割

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 20:39:39

>>199
マシン感転送に時間かかりそうだしなんだか遊んでる資源が増えそうなようかん

**じじぃ その４** ◆HETAREzfq. · 2005/03/22(火) 20:55:31

>>200
ああ、云われてみればそうかものう。。。

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 22:22:25

とりあえずHDD送りはLAが一定以下でbbs.cgiがコールされたとき限定でいいんじゃないかしらと言ってみる

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 22:57:30

>>202
電源落ちるかメモリが逝くとデータが全部消えるんですが
サーバ室侵入で電源「プチっ」とかやられたら

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 22:59:14

だんだん雪だるまの趣旨から外れてる希ガス…
ま、外野だからいいかｗ

◆Reffi/bQ.c · 2005/03/22(火) 23:01:40

>203
ＰＩＥのセキュリティ体制を知らないのかと小一時間（ry

**動け動けウゴウゴ２ちゃんねる** · 2005/03/22(火) 23:09:33

>>204
すんまそん・・・

>>205
万全って感じですか

ってゆうか1見てこないとな
書き込みながらこのスレがなんなのかわかってない悪寒

**動け動けウゴウゴ２ちゃんねる** · 2005/03/23(水) 01:35:07

そういえばDB Magazineのはてなの記事は読んだ？
MySQLのレプリケーションを使って、参照系のサーバーを更新系DBにたくさんぶら下げて。
多数のreadを参照系でさばいて、少ない書き込みは更新系だけで処理するんだって。
んで参照系はメモリを2G積んだサーバーでtmpfsにDBを置くと。

**動け動けウゴウゴ２ちゃんねる** · 2005/03/25(金) 16:35:17

こんにちは。

ちょいとこのスレを目を通しただけなので、いまいち掴み切れてないのですが、一提案。
整形済のものをハッシュテーブルを利用して生成済 HTML を cache してみるのは。

基本動作は

if(URL または、リクエストでハッシュを生成と検索)
{ ハッシュテーブルからキャッシュを送信}
else // 見付からない
{ HTML 生成して、ハッシュに保存 }

HTML 済の保存場所としては、
1. 一つのプロセスが常駐できるなら on-memory
2. mfs または tmpfs
3. local fs

理想としては、アクセス数と最終リクエストによる優先順を保持して、1 または 2 と 3 を併用できたらいいとは思うけど。
新しくアクセスされたところは 1(2) に残り古いページは 3 に移って、そのうち消去。

記事の数やメモリの量にもよるけど読者が多いところに有効。

とっても大雑把だけど雰囲気ぐらいはつかめまつか?