フロントは10台~20台
最低でも10台を考えているけど
それでも?
おいちゃん若いんか…
けっこう
直接フロントに過去ログ移すのは
・ 過去ログが膨張するとフロントの HDD 容量が逼迫する.
・ フロントを増やすと過去ログ転送もその数だけ必要になる.
なんで,ぼっとん(過去ログ専用バックエンド)はムダでもないような.
>>926 していた、ですね。
で、それはあまりにもコストが高かったので、ちょっと前に既にやめているです。
雪だるまサーバが日増しに弱くなっていく様子が、手に取るようにわかった。
理由は、offlaw.cgi とかモリタポとか公式p2とか、いずれにせよ過去ログ関連と。
過去ログサーバを別に作って、
そちらに過去ログを置くのは、
意味があると思うですね。
んで 落とす方法は
普通に http経由にして dso でゴリゴリ書いたほうが良い予感。
専用ブラウザのdat参照のシーケンスわすれちまったなぁ
offlaw.cgiやread.cgiの過去ログ参照については、ローカルなのが(=雪だるま以前と同じ)
一番安定してるだろうということで
>>925を書いたんですが
そんな将来をにらんだ話だとは思わなかった。
>>927 将来を見据えた話なら、ぼっとんの必要性は賛成です。
>>935 とてもざっくりだと、
dat 参照 => 302 が返る => offlaw.cgi を起動する
ではないかと。
dat 落ちの時は scp か何かでも使えばいいんですかね.
read.cgi は,HTTP で取ってくるライブ dat のやり方を過去ログにも流用すると.
offlaw.cgi も,同様に改造できればそれでいいんでしょうけど,さて......
>>936 そろそろ「安定」がキーワードなので
とんがった設定よりは台数投入してこなす段階化と、
フロント四台のそれぞれを 75%稼動にする = 一台追加する
と、
>>938 なるほど、mv の替わりに単に別サーバに scp すると。
エラー処理とか考えないといけないと思いますが、
筋は悪くないかも。
scp って何?
cp のsuperなやつ?
昔、rcp (remote copy) と言っていたやつです。
今は ssh のプロトコル使って、scp (secure (remote) copy)になったと。
おおっ
scp ../../dat/news/aaa/bbb/ccc/9999999999.dat botton.2ch.net/なんたら
とかやれば良いんですか?
もし offlaw.cgi のソースがないとすると......open(), close(), read() あたりを
横取りして HTTP でファイル取ってくるようにするライブラリ作って LD_PRELOAD かますとか.
>>940 まぁリモート転送となるとどの方法でもエラーは要考慮でしょうけど,
エラーならいったん転送留保して,あとで再挑戦とかですかね.
>>943 scp localfile [user@]remotehost:remotedir
とかですね.
>>944 私が書いたやつだから。。。
どっかにあるはずー
というか、 AMD とかで再度コンパイルしているんだから
絶対にあるよ、きっと(←絶対といいながら、、、)
>>943 で、通常だとパスワード聞かれますが、
あらかじめ秘密の鍵を作っておいて、それで認証するようにすれば、
それをパスワードの替わりにすることで、パスワードなしで転送できます。
秘密の鍵を作ってあらかじめセットしておくのは、
スロー同期のところで、同じしくみ使っているです。
なるほど、
scp をdat一個一個に発行するのは負荷どうなんでしょか?
多いときで 100スレ/minくらいかしら?
>>950 localfile のところで複数ファイル指定も可能ですし,あるいは -r オプションで
指定したディレクトリ以下を recursive に転送ってのもできますんで.
なるほど、なるほど、
りょうかいですー
いろいろ工夫できるということか、
んじゃ
>>907 は案1ということで、
他に案ありますかねぇ
そろそろ次スレの季節
次スレも待ち続けるのかな?
>>952 read.cgi/offlaw.cgiなどの過去ログの取得部分を
httpベースに変えれば、過去ログサーバを分けなくても
よいのかなと。
あんまり複雑にするのも障害時の対応が大変そう。
現在の率速というかネックはスケールできないバックなんですよね、
つまりどこの負荷を下げたいかというと、
バックなんです。
お、乙
>>956 過去ログのアクセスがどの程度なのですかね。
負荷を上げるほどあるのかどうか。
絶対的な負荷を下げるためという意味では
分けるというのはそうなのだと思います。
(というか、そういったものの積み重ねですかね。)
>>960 既に一台→三台にわけてるわけで、
たぶん秋には倍とは言わないけどさらに追加が必要だと重いますー
さらに安定化を目標としたいから
若干性能下げても台数追加で望みたいという希望も先ほど書きましたが、
「さらに」を二回書いてくどい文になっちまった シクシク
おっちゃん、フランシスコ・ザビエル化したんか?
あと,ストレージに要求されるものも違いますね.
ライブな dat -> 速度 > 容量
過去ログ -> 速度 < 容量
んで,過去ログを分離できれば,将来的にジンギスカンとかやらなくても,
容量は小さくとも高速なストレージを使うとかいう選択肢も出てくる,とか.
>>964 バッテリバックアップされたメモリディスクとか、そのへんを使うとか。< ジンギスカン用に
速度的にはどうなんでしょか?
>>968 i-RAM ですか。SATA HDD の16倍と。
前に特化型スレでも、話題になったですね。
それは MD よりははるかに遅いような、、、
>>970 メインメモリのほうが、速さではかなり上ですね。
しっかり、誤爆しました。
996 名前:root▲ ★[] 投稿日:2006/06/12(月) 04:04:46 ID:???0 ?#
個人的には、i-RAM とかは
ジンギスカンII にするのの代替(dat 部分だけ)というかんじに思うですね。
通常の動的なファイルは、通常ジンギスカンで特に問題ないので、
ライブな dat を置く場所、ぐらいですか。
HDD よりは高速だけど、メインメモリには劣ると。
というか SunOS さんも書いていますが、たぶんこれは「高速な HDD」ぐらいのしろものかなと。
まぁ,外部デバイスとして使う限りは I/F の転送速度が限界となりますからね.
その点で通常の RAM より劣るのは致し方ないと.
>>972 のように dat の置き場所
として考えればメリットはあるかな,ということで.
I/F の転送速度といえば LAN の速度もあるんで,ネットワークサーバとして考えれば
LAN の速度と比較して爆速である必要もそんなにないかな,ということも.
´・ω・`)つ旦~旦~旦~旦~
976 :
名無し草:
ここまで読んだ
adhocに過去ログをフロントのHDDに入れてたけど
そのへんちゃんとやろうよ、という話だと理解しました。
memoriesがだいぶ前からいっぱいいっぱいのようなので、
bottonもかなり負荷がかかるんじゃないかなあと。
実況の過去ログにクロウラーが来るかどうかはわかりませんが
news20になら来そう。
C:をsystem、D:をdataにしてあるのにD:がいっぱいになったので
C:に一部の動画とか移してなにがどこにあるかわからなくなった
うちのマシンと同じようなことですか? ぜんぜん違いますねすみません。