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

ということで私がいまやっているのは、

目的1が、httpdの直前にキャッシュを入れて、dat直読みとsubject.txtの処理にかかるhttpdの仕事を軽くする、
目的2が、squidの機能(一人でたくさんの相手を処理できる)を使ってhttpdの空きを確保する、になります。

深夜の実況は、よくのびます。あと、読み手が少ない時も。
でも、とても人気のある番組では、伸びがわるいです。

その原因のひとつとして、大量の読み手がhttpdを占有してしまい、
そのためにhttpdの空きが少なくなってしまい、アクセスそのものが困難になる、というのがあります。
売り切れ状態というやつ。

マツケンサンバとかの時は、ログインするとサーバは反応ある(結構軽い)のに
売り切れ状態となり、アクセスはそのものができなくなってしまいます。
これは、大量の読み手がhttpdをふさいでしまうせいです。

httpdを増やせればいいのですが、httpdは1つのプロセスで1つのリクエストしかさばけないので、
限界があります。

そこでこれを解決するために、目的2をやったと。

目的1については、別レスで。

達成したいこと

live16(tiger) + live8(cobra) + live15(banana) それぞれジンギスカン
を一つの大きなサーバとして運用したい。
出来上がり品は 今の倍のキャパにしたい。

Front1 , Front2 , Front3 ,,, Front10
　↓↑
black goat
　↓↑
live8 , live15 , live16

この構成で　今の倍以上をこなしたい
私の目論見では二倍だったら black goat なし Front 三台で
こなせると思っております


そして Front が逼迫した場合は Front は横並びで増設
back end が逼迫したら black goat 追加、
これで五倍〜10倍いくような予感、なんちゃって

ちなみに back end の読み出しは dat , txt 読み(cgi経由なし)
書き込みは 専用のDSO(written in C)

Front end は単純な　ろびんちゃん

目的1について

これは、主にdat直読みとsubject.txt読み込みの負荷軽減の模索です。
ex7ではヒット率3割ぐらいのようなので、その分httpdの仕事が少なくてすみます。

squidはもちろんその分仕事します。
で、squidの部分を別のマシンに持ってくることで、分散できるんじゃないかと考えていたりしました。


…とここまで書きましたが、私のはは現状のものをあまり変えずに「皮をかぶせる」アイディアですね。

これでも、かなりいけると踏んでいますが、んじゃread.cgiはどうすんのとか、bbs.cgiは結局スルーか、
とか、そういうふうに考えると、ドラスティックには効果を期待できないのかも、しんないですね。
たぶんせいぜい、倍ぐらいにしかならない。

もっとスケールするようにするには、>>156 のほうが、本筋な気がしてきました。
しかしそれには、開発が必要ですね。でもそれは、必要な開発なのかなと。

>私の目論見では二倍だったら black goat なし Front 三台で
>こなせると思っております

うわ、結婚したかも。

今のex7での実験は「現状を延命させる」実験としてかなり面白いので続けようと思いますが、
(ヒット率3割も出ると思わなかった)

改めて >>160 の図面見ると、Front 1〜Front 10に、
squidの部分がそのまま使えそうな気がするですよ(オンメモリモードで)。

開発といっても

front で bbs.cgi も read.cgi も請け負う

front end に置く bbs.cgi の実際にdat に書くという処理の部分を
back end の所定のサーバの cgi(dso) を呼ぶに変えるだけかと、
(そうでもないか? やってみて変なとこちょこちょこ修正ですむような気が)
実況サーバですから timeclose 等はまぁがまんするとか
スレ立て規制はバーボンがあるし、

index.html subject.txt .dat(rea.cgi) を何時どうやって構成するかも問題ですが
最初は back end で構成したものをそのまま呼んできて渡してもよいような
実験の結果 304 が沢山発生したんですからかなり back end は楽になると思う

>>165 ふむふむ。

front endにdat(相当品)を、ディスクI/Oしないでどう持ってくるか、
ってかんじになりそうですね。
>>164 に書いたように、squidとかをオンメモリモードで動かすのがいいかも。

>>160 の単純な形(第一歩)としては

Front1
　↓↑
live16

だと思うんですよね、

>>166

それは front 側は、基本的にすべてメモリ上で処理する
って事ですか?

>>167
ですね、、、下がlive8だったりしますが、
やろうとしているところだったりしました。

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

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

front1 , front2
↓↑
live15

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

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

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

>>171
やりますか。

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

第一弾としては

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

これで天井測定

こんな感じかしら?

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

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

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


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

それでいきますか。

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

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

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

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

そですね、

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

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

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

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

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

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

未使用は、1台のはず。

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

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

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

あっ　そうか・・・　>>184

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

ぐっ　>>183 だった

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

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

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

http://www.mail-archive.com/[email protected]/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.

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

>>188
おー。

やってみるか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>204
すんまそん・・・

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

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

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

こんにちは。

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

基本動作は

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

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

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

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

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