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

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

巨大Live専用サーバの構築

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

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

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

乙

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

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

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

(n‘∀‘)η

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






>>1乙

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

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

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

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

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

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

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

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

こんなかんじ？

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

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

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

>>12
了解。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なので壊れるのです。

>>34

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

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

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

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

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

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

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

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

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

>33
sambaや連投規制は、frontendが今まで通りにやればいいんでないかな？(^_^;)
ラウンドロビンしてるとはいえ、短期的には同じサーバにアクセスするわけだし。

ほかにどういう規制があるんだろう・・・・
まずそのリストアップしないと(^_^;)

>>34
そうですね。読ませるほうは、比較的楽なのですよ。
Apacheのリバースプロキシとか、blackgoatみたいにsquid使うとか、
結構いろいろな手法があります。

問題は、書かせるほうをいかに処理するか。
従来の、bbs.cgiによる簡便なインタフェースをできるだけ残しつつ、
いかに中身をうまく効率化するか、なのかなと。

ラウンドロビン　(←弱そうな名前であまり好きでないのだが)
を使うのであれば、

Samba24 は、うまく行くか、
連投規制は、どうなるかな?
スレ立て規制は元々スレ立てやすい設定だから
あんまり気にする事無いか、トカゲの尻尾もあるし
あと・・・　何あったっけ?

個人的には、NFS経由での書き込みはあまり使いたくないな、
と思っています。トラブルの元。

読むほうでのNFSの利用は、うまくやればありかもですね。

datは、キャッシングかなと思っているです。
フロントにもdatプールみたいなのを作って、キャッシュできないかなと。

で、どっかで話が出ましたが、SolarisだとCacheFSという仕組みがあって、
このへんが結構うまく動くです。
FreeBSDでは、どうするか。フロント側でもsquidみたいなの使ってみるかなぁ。

http://info.2ch.net/wiki/pukiwiki.php?%BD%F1%A4%AD%B9%FE%A4%E1%A4%CA%A4%A4%BB%FE%A4%CE%C1%E1%B8%AB%C9%BD

アクセス規制・プロキシ−規制・Rock54
　BBQなど外部問い合わせ型は問題なし
　内部問い合わせ型も、それぞれがテーブルを持っていれば問題なし
　（つまり従来通り）

samba24・二重書き込み・連続投稿
　フロントエンド単位で規制。
　ラウンドロビンしていても、短期的には同じサーバで書き込みチェックを行うので。
　（つまり従来どおり）

ブラウザ情報規制
　従来通り

スレ立て規制
　これは微妙(^_^;)どうやればいいんだ
　あるいは別な手法を考える？
　バーボンハウスって同じ機能？

お茶飲み規制・落ち着け規制・とかげの尻尾
　仕組みがよーわからん(^_^;)

その他
　従来通り

お茶飲み規制・落ち着け規制 <- 現在これらはないはず
とかげの尻尾 <- BBQ のように外部経由です

最初の段階でのイメージとしては、bbs.cgi(フロント)が、バックにあるbbs-back.cgi(仮称)を叩く、
という、きわめて単純なイメージを考えています。

dat書き込み、リモホ記録といった「書き込み系」をbbs-back.cgiがやると。

で、書いたデータを読みたい時(例えばSambaとか)は、
例えば一番どろくさいやり方するなら、単純にNFSのread onlyで
フロントのbbs.cgiがバックのファイルを直読みするかんじかなと。

かしこいやり方するなら、プロセス間通信でやるとか、
あるいはmysqlみたいなのを使うとか、そういうかんじですかね。
（これらは第2段階以降だと思っています)

live系の即死はほぼ一律じゃしねぃ

>>35
そうかー

スレ立て規制以外の規制は、同じ機能をほとんどいじらずに使えそうですな(^_^;)
＞samba24・二重書き込み・連続投稿
　ラウンドロビンでサーバが切り替わるタイミング（DNSのTTL単位かな？）ごとに
　新しいフロントエンドサーバに割り当て直しが起こるので
　今までより多少甘くなるかも・・・・

＞スレたて規制
　BBQみたいな仕組みに置き換え？
　あるいは廃止？
　あるいは全然別の仕組み？

>>48
そうはならないようにしたいなと、思っていたりします。
つまり、別のフロントエンドサーバにあたっても、従来通りそのへんは効くようにしたいなと。

なんにせよ、明日以降まずは土地を整地して、
器の構築をやるです。

I/O屋さんに仕立て上げる方向で。
blackgoatみたいにccdを使ってみるか。

>49
つまり「samba24・二重書き込み・連続投稿」は要改良という方向で(^_^;)
どれも（スレたて規制もふくめて）トカゲの尻尾にまとめちゃうっていう手はあるなぁ・・・・

ん？
規制といえば
SETTING.TXTで定める値が必然的に各板共通になるのけ？

subcakはbackendのお仕事になるのかな？(^_^;)やはり

subbackじゃないや(^_^;)subjectだ

>>53
subject.txt / subback.html は、後ろの仕事になるですね。たぶん。

さすがにねむいす。そろそろまけぐみへと。

おつかれさまです(^_^;)おやすみなさい
おいらもそろそろ寝る〜

ディスクI/Oの分散化じゃないすかね？
dat番号で保存するサーバを切り分けるとか。

>>27
read.cgiのサーバとbbs.cgiのサーバは同一にするという計画だったんだよ！
な、なんだってー＞ΩΩ Ω

>>37>>57
これを読むと、それはありかもしれない。
datの末尾番号で保存サーバを振り分けるようにするとか。

Googleのようにデータを分散化してもつ考えですね。

うーん　逆なんだけどなぁ
フロント複数で datサーバは一台でとうぶん間に合うんだけど、
たぶん　一台で 1,000万post/day くらい処理できそうなんだが、

私も、そう思ってますです。
datのマスターを管理するのは、1台でいけるんではないかと。

フロントエンドがdatファイルをキャッシュするイメージを想定しています。
で、read.cgiは、そのキャッシュを読む。
そのあたりにおいて、携帯サーバとは、ちょっとだけ路線が違うのかなと。

1000万posts/dayという値は例の「おじさんの動物的直感(これが意外とあてになるんだ)」としても、
当面の路線として「必要以上には処理を複雑にしない」で、できるだけいきたいなと。

>>61 のキャッシュは、ライブdatはメモリディスク利用かな。
で、過去ログ(●)はNFS経由か、バックエンドに丸投げ。

Sambaはあのディレクトリをフロントエンドで共有すればいいはずだから、NFSなんじゃないかなぁ。
削除系はバックエンド直叩きすね。

bbs.cgiは最初は単純に後ろに渡すだけのシンプルなもので、いいかも。

>>62
banana227 の情報メールしましたー

bbs-back.cgi は bbs-back.so でやりますんで
dso 化お願いします < banana227

>>63
受け取り&確認しました。
今夜あたりからぼちぼちと。

>>64
Ack.

banana227.maido3.com
liveb1.2ch.net
ch2b1

んで　私が遊ぶとこ作ってくださいー

http://www.sankei.co.jp/news/050107/sha048.htm
「雪まつり」の作業も本格化
運用開始目標は2月7日という感じでしょうか

OS上げて整地してごそごそして、、、。
週末作業ってかんじで。

>>61
そうすると、read.cgiは分散化できていて、datは分散の必要ないと。
あとは、bbs.cgiが分散化できればOKですか？

bbs.cgiの分散化って昔、sp.2ch.netでテストして
出来た気がする。。

>>70-71
ここまでの方針を見る限りは、bbs.cgiの分散化というよりは
ディスクへの書き込みをいかにして均すかということでしょう。
bbs.cgiのコストの最たる部分ですし。

そのうえで受付をふやせればいうことなし。

>>70
read.cgiは比較的分散化しやすいんじゃないかな、ってことです。
bbs.cgiの分散化(たぶん機能を分ける)は、たぶんここでぼちぼちと。

>>71
sp.2ch.net(newsplusの分散化だったかな)って、どうやってやったんでしたっけ。

たんにsquidの透過プロキシーでした。
ネットワーク周りの負荷をとりもって、
本体はbbs.cgiの処理に集中って感じでした。

以前話が出ていたことがあるけど、
bbs.cgiから.dat,subject.txt,subback.htmlにアクセスする部分を別サーバーにして
.datの読み書きをバックエンドにしつつ、subject.txtは
オンメモリで保持するのが良いかと思ってたりします。
で、同じサーバーでread.cgiのバックエンドも動かして、キャッシュを持つと。

フロントではbbs.cgiの処理として
index.htmlや書き込みログやBBxの対処を担当して
実際の書き込みはバックエンドが行うと。
フロント側では、.dat/read.cgi/subject.txt/subback.htmlに対するリクエストは
そのままバックエンド側に回す。

バックエンドでは、bbs.cgiの求める書き込みが妥当かどうかをチェックして
実際に書き込み、フロント側の求めに応じて.datのイメージ等を渡すみたいな。
必要なら、１スレッドでキューに入れながらの非同期書き込みも視野に入れて。

>>74
シンプルすね(私も原案はそれです)
リモホ渡すところとか、そのへんの問題はありますが、
現在でもじゅうぶんに有力な策のひとつかと。

>>75
いいかんじですね。

む、、、この作戦が成功すると
地震板がまともに機能するようになるのかな？

臨時板がまともを期待してはいけません（す

>>78
その予定なんですけどねぇ
壁は高く、幾重にも

>>80
積み重ねていくしかないわけですな。
まさに雪だるま。

あぼーん

地震板、電話の輻輳みたく、「お掛けになった方面の鯖は、ただ今大変込み合ってつながりにくくなっています」
なんてメッセージ画面表示したら、起こられるんだろうな・・・

>>83
そのメッセージに、落ちる寸前のレスをいくつか（あとスレタイ）を
表示させるようにすれば、とりあえず何が原因で落ちたかは、分かる気がします。

それって、一昔前にあった、お茶飲め規制なんすよね。
つまり、掲示板みたいなメディアだと、あんまり効果なかったりするです。

banana227 概ねセットアップ完了。

FreeBSD 5.3R-p4に更新済み。
カーネル的にNFS関連有効に設定。実際の設定はまだ。

ディスクI/O重視セッティング。
・/homeはccdを利用し、ソフトウェアでストライピング(ad0とad1)
・/homeのnewfsパラメータは newfs -U -b 65536 -f 8192 /dev/ccd0
・/homeはnoatime有効(以前から)

ネットワーク周りは、とりあえず携帯フロントエンドサーバ並みのチューニング。

これから >>67 のアカウント情報メールして、
pekoサーバスレでDNSの儀式依頼します。

ということで、
.so という拡張子のファイルは、dso風味で動くようにしてあります。(>>64)

ということで、作業はとりあえずここまで。

ネットワーク帯域どうしましょうか。
現状のMAX10Mbpsだと、
今回の用途からして、キャパ的にどきどきかも。

１Gbps

なお dso を使用するため、httpd そのものを ch2b1 権限で動くようにしてあります。
それに伴い、SuExecもなし。

D言語お勧め

なんか進展ないのかな・・・

もう少し暖かくなってからかも、

暖かくなったら溶けませんか？ > 雪だるま

雪だるまが溶けないうちに雪だるま作戦はあらかた完了しなければならないと思われ、

雪なんて4月になっても残ってるわけだが

冷凍庫に保存してあるから大丈夫

溶けた雪だるまをどうするかって問題じゃなかった？ｗ

　　　　　　　　　　　　→dat(3の倍数)＋レス書き込み
----→delegate-------→dat(3の倍数+1)＋レス書き込み
　　（逆プロキシ）　　　→dat(3の倍数+2)＋レス書き込み
　　　　　　　　　　　　→subject＋スレ立て
　　　　　　　　　　　（振り分け）

下記の2点だけ出来れば動きそう
subjectサーバからdatサーバにスレ立てたら通知
datサーバからsubjectサーバにageの通知

ずれまくりorz

>>99
どれどれ

札幌ではそろそろ雪だるま祭りの始まる頃か

さて、そろそろこれを動かさないとなぁ。
と、とりあえず宣言だけしとこう。

まずは、どうやるかの戦略というか、骨子を

ありゃ。暴発。

骨子をぼちぼちと。

もし>>75な方針で行くなら、
1-2ヶ月の内にどうにか動きそうなものを出せるかもしれません。
仮にフロント側とのインターフェースが決まっても
解決しなければいけない問題が山積みですが。

漏れ的には、特番板とか作ってみたらとか。。。

やっと始動ですか？(･∀･)

>>105
おぉ。

東京に雪が降ったから、そろそろこのスレを動かすか。

まずは、live8にある板をliveb1でも「読める」ようにしようかと。
さて、NFSでやるか、squidとかを使うか。

FreeBSDのNFSがちゃんと動くんなら、NFSのほうがよさげかもと思っていたりするけど、
どうなんだろうか。

あ、あとApacheのmod_proxyというのもあるかな。

始まりますか(･∀･)ﾜｸﾜｸ

>>109
FreeBSDのNFSってLinuxのそれよりいいと聞いてますけど

NFSなんておとろしいので、mod_proxy で reverse proxy設定がよいかと。

sendfile効かないからNFSにはしないなぁ。
まぁベンチ取らないとなんともいえないんだけど。

まあ確かに用途を考えると
あまりすすめられたもんじゃないですね＞NFS

Solaris同士ならいけたかもですが。

いっそ10をいれてじっけんじっけん！てのもありかもw

read.cgiの処理能力について、
昔書いたhttp://2ch-tool.net/mirror/mod_readcgi.zipをベースに(大幅に手を入れて)
「各レスを名前/本文等に分割したものをキャッシュする」から
「各レスを出力するHTMLになおしたものをキャッシュする」に変えたものが
ようやく動くようになったので、
軽くベンチを取ってみました。
(本来ならば現行のCGIDSO版をベースにすべきでしょうが
ソースが手元にないし、一度似たようなものを作っているので)

環境は、Athlon64-3000+ (2.0G, 512K DDR400single) MEM1G @Win2K
対象は、ある時期(１ヶ月程前)の、operate板の全dat
計116ファイル、9,456,984byte、総レス数は39585。

これを、全ての.datに対して
一通りread.cgiの出力イメージを作成するのにかかる時間(ms)です。
最初に空読みして、OSのディスクキャッシュに載せた後、
複数回測定したおよその数字です。

以下、「キャッシュなし」は初回及び保持数が少ない時にかかる時間
「キャッシュあり」は、キャッシュの保持数を充分にして、２回目以降にかかる時間です。
キャッシュなしの数字には、.datをapr_mmapしてそこから内部バッファにコピーする時間と
その.datをparseして各レスのHTMLを作成する時間が含まれます。
また、圧縮は、zlibの標準圧縮率での測定です。

「レスを全部読む」非圧縮
キャッシュ無し　　680
キャッシュあり　　290

「レスを全部読む」圧縮
キャッシュ無し　　1660
キャッシュあり　　1220

「最新50」非圧縮
キャッシュ無し　　138
キャッシュあり　　46

「最新50」圧縮
キャッシュ無し　　282
キャッシュあり　　184

「1-100」非圧縮
キャッシュ無し　　210
キャッシュあり　　85

「1-100」圧縮
キャッシュ無し　　460
キャッシュあり　　313

カーネルのネットワーク/スレッド、.dat読みや書き込みに割かれる分がありますが
Op246Dualの総合的処理能力が約２倍程度だろうと考えると
read.cgi処理に使えるCPU資源はK8単体と同程度以上はあると思われます。

その上で、(「全部読む」「新着」や>>リンククリックを含めた)平均的なread.cgi出力を
l50程度の長さだと仮定すると、read.cgiの処理自体は
ピーク毎秒400リクエスト以上は平気でこなせる、ということになります。
.dat転送も含めれば、(プロセッサ能力だけなら)毎秒1000近く捌けるはずです。

ところで、書き込み処理の方はどの程度まで可能かというと
こちらはHDDの能力に依存するでしょう。
仮に、シーク4ms、15000rpmのディスクに書き込むとします。

平均シークは4msですが、局所性も考えて
シーク+回転待ちで、5ms程度とみると
HDDの能力的には、毎秒200ブロックに対して書き込みが可能なはずです。
(データの書き込みにかかる時間は、64K程度の書き込みでも1ms以下です)

仮に、open,write,closeの３つの合計で
ディスクの10箇所に書き込むとすると
ピークで最大20ファイルに対して書き込みが出来るわけです。
ただし、プラッタもヘッドも１つではないし
ディスク自体も内部キャッシュを持っていることを考えると
ピーク30ファイルは書き込めると思われます。
(ディスクの動作モード等にも依存するかもしれません)
# 実際、体感的にはWin2K+Raptor(遅い方)RAID0でも
# 毎秒100ファイル程度は書き込めているという印象があります。
# まあ、データ本体は非同期書き込みなので、あまり参考にはなりませんが。

以上、読み込みと書き込みの両方の要素から
peko鯖単体の処理能力の限界を求めると
ピーク時に毎秒30書き込みが可能で、
読み出しリクエストがその20-30倍程度と考えると
毎秒600-800程度、内read.cgi呼び出しが300-400程度、
といったところでしょうか。

ピークが１日平均の1/3-1/5程度と考えると、１台のバックエンドで(peko鯖ならば)
毎秒平均6-10書き込み、１日平均50万-80万書き込み程度が
処理できる計算になります。
これは、2chの全書き込みの1/4-1/3程度に相当します。

# 本来、このスレでの話題は「live鯖をどうするか」であって
# 2ch全体の構成を変えることは考えてないでしょうが
# 私自身はlive系には全く縁も興味もないので・・・。


以上、(書き込み能力からの)理論上の目標数値のようなものは出ていますが
実際にここまで実現できるかというと、問題は山ほどあります。

で、とりあえず、バックエンドをどういう形態で動かすのか
(シングルプロセスapacheのモジュールにするのか、さらに別daemonにするのか)
という問題があります。

まず、apacheに載せる場合、(特にFreeBSDなら)workerが動くのか
もしうまく動かないならsolarisやlinuxは視野に入っているのか等や
そもそも1000ものスレッドを作れるのか
(例えばlinux2.4でpthreadをデフォルト使うと、各スレッドでスタックを10M取るため
32bit環境では4Gしかないアドレス空間が全然足りません)
デフォルトで作れないなら、worker.cに手を加えるのか、
仮に作れてもまともに動くのか、等です。

そしてバックエンドを別daemonにするなら
(daemon自体はselect系を使った少数スレッドによる実行形態が望ましい)
それとの通信はどうするのか
(マルチスレッドapacheに交信モジュールを追加して
コネクションプールと各プロセスからの同時接続数制限をしたい)
とかですね。

# 一応今作っているものは、apacheのhttpd依存部とそれ以外(aprには依存しますが)には
# 分離可能なようには努力しています。
# まだ.datの詳細データの読み出しと保存、subject/subbackの作成、及び
# 前述の基本的なread.cgi出力部のみですが。

もちろん、毎秒最大1000ものconnect/close要求(KeepAliveOffの場合)を
こなせるのかというのも大きな問題です。
(少数のコネクションに対してリクエストが合計1000来るというだけなら
DB等で実現しているように、問題なくこなせるはずです)


で、何らかの理由で「毎秒1000」が１台でこなせない場合の対案等は
後ほど(気が向いたら)書き込みます。

まぁ排他処理とかキャッシュみたいなややこしいアクロバチックなことを1台のサーバーとソフトでするよりも。
Keep It Simple & Stupidでバカ端末を複数ぶらさげるほうがスケールするんだけどね。

http://liveb1.2ch.net/livetbs/

とりあえず、単につないでみただけ。
リファラとかいろいろあるからもちろん書き込めないし、
いろんなところにlive8ってハードコーディングされてるということが改めてわかった。

で、いろいろレス。

>>113
やっぱ、Apacheかsquidかなってことで、とりあえずsquidでやってみたです。
設定のフレキシビリティ考えると、Apacheかも。

>>115
それは、すぐにはできにくいすからね。

>>116-119
緻密な調査、ありがとうございます。
非常に参考になります。

100ファイル/secがそのまま「bbs.cgiを秒間100回」にできるわけではないですが、
私の感覚やいろんな統計などとも結構一致しているかんじがします。

cgidsoとspeedycgiにしてから、「読み」と「書き｣を別ホストにできると、
実は相当いけるんじゃないだろうかというのが、これのそもそものきっかけなんで。

で、>>119 にある「２ちゃんねるの全書き込みの1/3-1/4を1台で処理できるパフォーマンスが
出せる可能性があるのかもしれない」というのが、なかなかですね。

>>120
workerで動かせるか、というのは、前からある課題ですね。
mod_proxyでリバースプロキシするなら、フロント側でworker使ってみる意味はあるかもしれないかも、
とか思ったり。

>>121
そですね。
banana大量横並べモデルって、じつはそれに近い気が、しないでもなかったり。

…ということで、もうちょっと微調整するんで、
いったんつなげたやつを落とします。

再度上げた。
今日はこんなとこか。

Apache の mod_cache / mod_proxy 周りは現行の 2.0 より 2.1 / 2.2 の方が
いろいろ手が入って改良されてるようです．まだ alpha バージョンですけど，
実験と割り切るなら使ってみるのも一興かな，と．

live 系鯖のように板当たりのスレ数が少なく，かつ特定のスレに人が集中する
ような状況なら，read.cgi 出力のキャッシュは結構有効だろうと思います．
あとは，それを read.cgi 自前でやるのがいいのか，それとも mod_mem_cache に
お任せするのがいいのか，というところですが．

マルチスレッド MPM の選択肢としては worker 以外にも，バーチャルホスト単位で
別ユーザ権限で httpd を動かせて perchild より安定している Metux MPMとか，
Keep Alive 時の負荷軽減を図った Event MPM とか，もありますね．

【実験】ミニ雪だるま作戦―ex7で3/8 3:10あたりから実験はじめます
http://qb5.2ch.net/test/read.cgi/operate/1110218877/

私もちと基礎実験するかな @live15

その前に知識をむさぼらなければ・・・・・
ということで 質問だらだらでーす

今 live15 は read.cgi が止まっています、つまり俗に言う「人大杉」状態。
この状態で 別サーバで read.cgi をサービスするという事を考えてみようかと、
もしかしたら root★さんがやっているのがそれなのかしら?

live15x.2ch.net で read.cgi を提供するとしたら dat@live15 を取得するのは
どうしたらいいだろう・・・

1) 直接 live15 から持ってくる、 (front end を増やすのが簡単じゃないかも)
2) 専用の black goat 経由で持ってくる、(スケールとの兼ね合いで高コスト?)
3) あと　どうやるの?

もしかして root ★さんは 1) をやろうとしているのかしら?

おぉ、、、。
めしの後で、レスします。

read.cgiを別ホストで動かそうとする場合、何らかの形でdatにアクセスできる必要があります。
その方法ですが、1) 2) 3) だと混乱するんで、a) b) c)で、、、

a) NFSを使う

NFSを使ってlive15のdatディレクトリをlive15xにmountし、まるごと見えるようにします。
これだと、ローカルにあるファイルと同じようにopen()とかread()とかできるので、
read.cgiの改変は基本的に少なくてすみます。

でもmmap()とか使っていると、変えないといけない予感。

あと、FreeBSDのNFSの実装がどのくらい枯れているのかという点で、やや不安です。
私ののおすすめ度: ★

b) read.cgiをいじって、ローカルにdatを持ってくることにする

>>129 の 1) とか 2) の手法です。
で、専用のblackgat入れるのいまいちなので、ローカルにキャッシュ持って、
そこに入れることにするのはどうか、と考えています。

もちろんこのキャッシュで、dat直読みも対応させると。

で、フロントエンドはバックエンドにせいぜい3台、多くても5台ぐらいぶらさげれば
いいところじゃないかと思っているので、1)でいいんじゃないかなぁと(これは、甘く見てるかも)。

私のおすすめ度: ★★

で、キャッシュを持つ実験として、ミニ雪だるまを動かしています。

ex7でディレイなし、read.cgiはノーキャッシュの状況で、
30%ぐらいキャッシュからヒットしています。
つまりその分のアクセスはフロントエンドのsquidがよきにはからってくれていて、
ex7のhttpdはdatの中身をsquid側に運ばないで済んでいます。

この状態でsquidを別マシンで動かすことを考えています。
で、別マシンで動くread.cgiはこのsquidに対して、datをリクエストすると。

混乱しないように ex7 で話しをすすめることにしよう。。。

(b)の場合　その squid というのは ex7 側にあるんですよね?
つまりその負荷はex7に負わせるということですが、
それの占有率ってどれくらいなんだろう・・・

簡単な図にすると、今まではこんなかんじで、

ユーザPC = datリクエスト => httpd at 206.223.150.110

これを、今ex7ではこうやっています。

ユーザPC = datリクエスト => squidローカルキャッシュ[ datキャッシュ ] at 206.223.150.110 = datリクエスト => httpd at 127.0.0.1

で、次の段階では、squidとhttpdを別のマシンで動かすことを考えると。

で、今のsquidの負荷占有率は、それほど高くないです。
topだと、0点台です。
squidの非同期I/O機能が効いている模様。
だた、メモリは食ってますね。ex7のやつが今90Mぐらい。

そもそもsquidには「httpアクセラレーション機能」というのがあって、
それも、ある程度効果を発揮している模様です。

Apacheはpreforkだと1つのhttpdで同時に一人しか相手できないので、スロットいっぱいになってしまうと
身動きがとれなくなりますが、squidだと1つのsquidで同時に何百人を相手できるので、
その部分での効果も、期待できます。

マツケンサンバやバルス攻撃だと読み人が死ぬほど来てスロットをさらっていくので、
それも、ついでになんとかしてしまおうという目論見で。

topだと、0点台です。=> CPU1%以下、という意味です。

補足をひとつ:

リモートホストの情報は、squid => httpdの際に渡るようになっています。
つまり、IPアドレスやリモートホスト名で規制する部分は、従来どおりです。
(mod_rpaf というApacheモジュールを使用)

つまり　squid を独立した別サーバで動かすと
それはまさに black goat であるということですかねぇ

>>137
そうですね。
今のblackgoatでは、squidがせっせと動いています。

BSD Magazineで小飼弾さんがSquidリバースプロクシの記事を書いていたなぁ。
お昼にワイドスクランブルに出演してたのを見て吹いたけど。

>>139
その記事、前にちょっと読んだです。
そんなことも思い出しつつ、設定していたり。

Kogaiさんは、元エッジの役員だからなぁ。

で、subject.txtの304が増えることと、それは果たして負荷軽減なのか、
っていう話を、書いておこうかと。

通常の場合

２ちゃんねるビューワは、ユーザからのsubject.txtの再読み込み要求を受け付けると、
サーバにとりにいきます。

しかし、たいていのビューワはかしこくできていて、サーバ側にリクエストを出すときに、
自分が持っているsubject.txtのタイムスタンプはこれだから、それより更新されていた場合だけ
subject.txtを送ってちょうだい、というリクエストを出します。

サーバはsubject.txtのタイムスタンプを調べて(ここではsubject.txtの本体は読まない = 重要)、
ビューワから送られてきたタイムスタンプと比較して新しかったら、
サーバははじめてsubject.txt本体を読んで、ビューワ側に送ります。
もし更新されてなかったら「304 Not modified」(更新されていませんでした)だけを送って、
subject.txtの本体は読まないし、送りません。

つまりこのように「更新チェックつきりクエスト」を出すことで、もしsubject.txtが更新されていなかった場合、

・subject.txt本体を読むコスト
・subject.txtをビューワに送るコスト
・その分のネットワーク転送量コスト

が、削減できることになります。

それは squid を入れたからなるんですか?
そうじゃないと思うんですが、

で、今回、ビューワとサーバ(httpd)の間に、squidを入れました。
squidはオンメモリとかディスク上とかに、他の人に送ったsubject.txtをたくわえています。
ここでは、現在の設定に従って、オンメモリで考えます。


ビューワからは、squidがリクエストを受け付けます。
squidは自分が持っているsubject.txtが更新されていないか、httpdに聞きます。
聞き方は、ビューワがやるときと同じ手法で、
私の手持ちはこれだから、それより更新されていたら、送ってね、
という聞き方をしているはずです。

ただしこの時、
squid => httpdの問い合わせの際に、何か「うまいこと」が起きているようなのです。
なぜか squid 出すリクエストに対して、httpd は 304 を多く返している。

なぜなのかは、よく調べないとわかりません。
でも、現象として起こっているように思えるので、再度、

実験してなかったときのログ、一昨日の19時台あたり
実験していたときのログ、昨日の19時台あたり

を、確認してみます。

# 謎のままにしたくないなぁ。

>他の人に送ったsubject.txt

これなのかな?

>>144
それしか、考えられないですが。
だとすると、squid => httpdのリクエストがどうして出ているのかが、、、。
しかも、答えは304。

別の話しですが

でも subject.txt って
ex7はジンギスカン仕様だから 元々 on memory のはずなんですが
open close 分だけ節約できるというはなしですか?

open send close ですね。sendはジンギスカンでも節約できないです。

>>145
squid => httpd のリクエストはでるでしょ
それの回答が 403 なだけで

クライアント => aquid の回答は 403 じゃないと思うけど
つまり今までと変わらないのでは?

squid => httpd の回答は send じゃないんですか?

19:00-19:59 JST

3/7 実験なし
3/8 実験あり

のサンプルをとりました。

あぁ、そういう意味ですか。>>148
コストの着眼点が、違うかも。

私は本丸のhttpdのコストが下がるのが、ポイントだと思ったわけです。
squidを別のマシンで動かすことを考えた場合に。

>>149
403 だと、本体のsendは起こらないです。

これは、squidが何をクライアントに返しているかは、別にとらないとだめですね。
304 なのか、本体をずるずる返している(ないと思うけど)のか。

403 だったら、 memory disk でも send が起らないと思うんですが、

>>150
そんなこんなで先日の質問だったわけですが・・・
今さがしていまーす、どこで書いたか忘れちまった
このすれだと思ったんだけど、

で、httpdのログとってみました。>>150 のつづき

3月7日の1時間分 382371 回 クライアント => httpd の数
3月8日の1時間分 353431 回 squid => httpd の数

少し減っているのは、もちろん日付が違う分とか、
squidが隠蔽した分とかが考えられます。
(squidのアクセスログとってなかったので、明確には不明)

>>153
質問・雑談スレだったような。

>>129 >>131
私は black goat 方式が良いのでは?
と思って >>131 の 2) を書いたのです。

理由としては、 正しいデータを格納するサーバは少しでも軽く
余計な仕事をしない方が、将来 fron end を並べたとき有利なのではないかと、
一つの系がこなせる上限というのは back end の上限によって決まるから
(前提条件は「back end は一台だけ」です)

>>129 >>131
私は black goat 方式が良いのでは?
と思って >>129 の 2) を書いたのです。

理由としては、 正しいデータを格納するサーバは少しでも軽く
余計な仕事をしない方が、将来 fron end を並べたとき有利なのではないかと、
一つの系がこなせる上限というのは back end の上限によって決まるから
(前提条件は「back end は一台だけ」です)

再投稿すんません

総数 >>154 のうち、

%grep " 304 " 0307 | wc -l
70960
%grep " 304 " 0308 | wc -l
132584

となっていました。倍ぐらい304が多いかんじ。

うち、subject.txt は、

%grep " 304 " 0307 | grep subject.txt | wc -l
98
%grep " 304 " 0308 | grep subject.txt | wc -l
10687

>>156
ふむ。

後ろには、データのファイルだけを入れるってかんじですか。
bbs.cgiも、データを書くところ以外は前に持ってくると。

そういえば、そんなことをどこかでも言っていたような。

で、今私がやってる実験の話を、別のレスで。

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

目的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 に移って、そのうち消去。

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

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