やっぱりc.2ch.netもパワーアップしてみよう作戦->画像>4枚

現行のサーバも3年ほど使ってるので、
管理人さんに新しいのを買ってもらえそうです。
と、いう事で、こちらで「わいわいがやがや」やってみましょう。

------------------------

質問・雑談スレ256＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1182209120/783-n

783 名前：ひろゆき＠どうやら管理人 ★ 本日のレス 投稿日：2007/06/27(水) 19:53:56 ???0 ?

788 名前：まみら ★ 本日のレス 投稿日：2007/06/27(水) 21:10:04 ???P
>>783
c.2ch.net用の新しいサーバ買って？

790 名前：ひろゆき＠どうやら管理人 ★ 本日のレス 投稿日：2007/06/27(水) 21:32:23 ???0 ?
>>788
何台ぐらいいりますかね？

794 名前：まみら ★ 本日のレス 投稿日：2007/06/27(水) 21:48:26 ???P
とりあえず調子悪いのはバック２台とフロント１台です。

そのフロント１台は新しいの来てるけど
ネットワークカードの関係でrootさんが調整中です。
何かが足りない様子です。

台数増やす事も考えて、ちょっと相談してまたお話します。

２

死ね

796 名前：ひろゆき＠どうやら管理人 ★ 本日のレス 投稿日：2007/06/27(水) 21:54:26 ???0 ?
わくわくわく。。。

こんなスペックのが何台ぐらい欲しいとか決めて
もらえるとありがたいですー。
>>794

---------------
コピペ抜け…orz

年収億超えてんだからもっとガッツリ用意してもらえよ

クラ強化まだー？(´・ω・｀)

>>1
乙です。

早く買ってｸﾚ。

おつですた。>>1
管理人のおｋが出たですか。

できれば
「大きくなってもスケールする
(= 大きくなる速度にあわせて普通にサーバを増やしていけば対応できる)」
ようにしたいところですね。

今日は激しく体調不良のため、寝るモードで。

あと、フロント側をキャリア別にするのもやめませんか？
特に意味無いような気もするし。。。。

＞「大きくなってもスケールする
＞(= 大きくなる速度にあわせて普通にサーバを増やしていけば対応できる)」
＞ようにしたいところですね。

同じスペックのサーバをフロントとバックに使えば使いまわしも出来るし、
バックが1台こけてもフロントから1台まわすなどの使いまわし出来るようにしたらどうでしょうか？

現状を書いた方がいいのかな？

# tiger511.maido3.com (root権限ありサーバ、Xeon 2.8GHz dual、2GBytes memory、FreeBSD 6.2R)
* blackgoat3.2ch.net
o 携帯電話(c.2ch.net系)用バックエンドサーバ
* 専用ラックスペース(携帯用XO)に存在

# tiger512.maido3.com (root権限ありサーバ、Xeon 2.8GHz dual、2GBytes memory、FreeBSD 6.2R)
* blackgoat4.2ch.net
o 携帯電話(c.2ch.net系)用バックエンドサーバ
* 専用ラックスペース(携帯用XO)に存在

# tiger2507.maido3.com (root権限ありサーバ、Xeon 2.8GHz dual、2GBytes memory、200GBytes IDE HDD x 1、FreeBSD 5.4R)
* c-au4.2ch.net, c-au.2ch.net
o 携帯電話受け口(au用フロントエンド)
* 専用ラックスペース(携帯用XO)に存在

# tiger2508.maido3.com (root権限ありサーバ、Xeon 2.8GHz dual、2GBytes memory、200GBytes IDE HDD x 1、FreeBSD 5.4R)
* c-au5.2ch.net, c-au.2ch.net
o 携帯電話受け口(au用フロントエンド)
* 専用ラックスペース(携帯用XO)に存在

# tiger2509.maido3.com (root権限ありサーバ、Xeon 2.8GHz dual、2GBytes memory、200GBytes IDE HDD x 1、FreeBSD 5.4R)
* c-au6.2ch.net, c-au.2ch.net
o 携帯電話受け口(au用フロントエンド)
* 専用ラックスペース(携帯用XO)に存在

# tiger2510.maido3.com (root権限ありサーバ、Xeon 2.8GHz dual、2GBytes memory、200GBytes IDE HDD x 1、FreeBSD 5.4R)
* c-docomo5.2ch.net, c-docomo.2ch.net
o 携帯電話受け口(NTT DoCoMo用フロントエンド)
* 専用ラックスペース(携帯用XO)に存在

# tiger2511.maido3.com (root権限ありサーバ、Xeon 2.8GHz dual、2GBytes memory、200GBytes IDE HDD x 1、FreeBSD 5.4R)
* c-docomo6.2ch.net, c-docomo.2ch.net
o 携帯電話受け口(NTT DoCoMo用フロントエンド)
* 専用ラックスペース(携帯用XO)に存在

# tiger2512.maido3.com (root権限ありサーバ、Xeon 2.8GHz dual、2GBytes memory、200GBytes IDE HDD x 1、FreeBSD 5.4R)
* c-docomo7.2ch.net, c-docomo.2ch.net
o 携帯電話受け口(NTT DoCoMo用フロントエンド)
* 専用ラックスペース(携帯用XO)に存在

banana405.maido3.com (root権限ありサーバ、Pentium 4 2.8GHz、1GBytes memory、Intel製Ethernetコントローラ搭載(I/F 2つ)、グローバルIPアドレスを4つ使用、FreeBSD 5.3R)
* c1.2ch.net
# c-others1.2ch.net
* 携帯電話受け口(au、NTT DoCoMo以外用フロントエンド1)
# 専用ラックスペース(携帯用XO)に存在

banana406.maido3.com (root権限ありサーバ、Pentium 4 2.8GHz、1GBytes memory、Intel製Ethernetコントローラ搭載(I/F 2つ)、FreeBSD 5.3R)
* c.2ch.net, c2.2ch.net
o クラシックメニュー入り口(2)
* c-others2.2ch.net, c-others.2ch.net
o 携帯電話受け口(au、NTT DoCoMo以外用フロントエンド2)
* c-control.2ch.net
o 携帯電話系サーバ制御用ホスト
* 専用ラックスペース(携帯用XO)に存在

BG3,BG4って落としたままなの？

>>12
いま、復帰させてもすぐにダウンするはず。
暫くはこの状態が続きそうですね。

とりあえず、個人的に気になっているところを。

・BG-squid方式で今後もがんばるのかどうか
・パブリック=プライベート型のネットワーク方式は
トラフィックの点ではいいと思うけど、フレキシビリティというか汎用性があるのかどうか
・今の c って差分取得してないような気がするです
(なってないなら是非差分取得やってほしいかも)

頭ぼーっとしているのでいまいちなこと書いているかもしれないけど、
とりあえずこのぐらいで。

>>14
（１）BG-squid方式で行くか？

おじちゃんがOK出してくれればフロントから直接取りに行きたいですね。
その際は、（３）とセットですね。（＋ローカルsquid？）

（２）パブリック=プライベート型のネットワーク方式はトラフィックの点ではいいと思うけど、フレキシビリティというか汎用性があるのかどうか

（３）今の c って差分取得してないような気がするです

やりたいですね。

差分取得はSquid使う限り無理では
http://qb5.2ch.net/test/read.cgi/operate/1166543133/903

フロントからdatとっても特に問題ないと思うけど(u.laはその方式のはず)、
その場合は差分取得の実装が必須かなと。

ようは、2chの掲示板サーバにやさしければよい
(というかやさしくないと分離の意味がない)わけで。

>>17
> フロントからdatとっても特に問題ないと思うけど(u.laはその方式のはず)、

ちょっと舌足らずでしたね。

・差分取得の実装
・キャッシュをちゃんと持つこと

は、無論必須で。(>>17 の第二段落)

むーさん、早く休んでくださいです…

↓スレスト

>>18
一時期失敗したdatキャッシュ方式に再チャレンジしましょう。

このあたりは週末にでもぼちぼちと始めましょう。
まずは今日はこのあたりで、

あとは他の人も意見頂戴

●対応

まあ、どういう強化をするのか方針決めないと鯖買えないわな

超サクサク

be、ID抽出あたりは対応してほすぃ

残念ながら機能追加は無いですね。

>>26
●に対応もなし？？

まず、強化で使い物になるようにするのが先だろ
追加機能の話どころじゃないし

仕組みを動かすことも大事だと思いますが、（datのキャッシュ）
仕組みを守る動作も入れたほうがいい気がします。（アクセスコントロール）

N分に1度pingを飛ばすなりして、NGなら/etc/hostsにダミーのホスト情報を書くとか。
BGが完全にインターナルならtinydns+dnscache構成でやるのもありかも。
ダミーのHTTPサーバを用意し、全てエラーページを返す
→フロントはエラー表示

Cはいつになったら復旧するのですか…

べっかんこやorzはクッキーがアレだから、やっぱｃじゃないとダメだ

わくわく。。

>>16 でも指摘されていますが，Squid 等の汎用 proxy / cache プログラムが
キャッシュ更新の際に差分取得を行うことはないですね（以前どこかで書いたような
気がしますが，2ch の dat のように末尾に追記する形で更新されるコンテンツは
特殊であり，少なくとも通常の HTML ドキュメントではありえないので）．
なので，差分取得でキャッシュするなら，Squid 等は使わず全部自力で行うことになると．

ｃ使ってる理由が一画面あたりのレス数が変えられる点だけな俺は異端児だろうか

パソコンよりケータイからのほうが2chよく見てるし

いちいち読み込まないcが好き

サーバの設定とかモジュールとかどこで勉強すればいいのだろう。

同じくらいの値段のにリプレースしても
かなりパワーアップ(´∇｀*)って思うけど、
やっぱり楽しくないと駄目ですよね。

今回も構造改革は男性陣にお任せしようかな。
台数増やしすぎても電源問題が心配だし。
最高何台くらい融通してもらえるのだろうか。。

私はスクリプトのスリム化とか考えた方が良いのかしら。
test.phpはまだ全部解読できてませんｗ
負荷の高い処理ってどんなのがあるのだろう。

とりあえず「ここまでの話のまとめ」とか好きなので
そういうのやります。

運営さん頑張って

もうべっかんこ以外愛せないんだ

でもべっかんこが落ちたときはよろすく

折角べっかんこから乗り換えたばっかりだったのに

>>31
がっくしはURLに設定を保存する方式（今の所・cのやり方とはちょっと違う）
から関係無い。Cookieオフでも普通に使える。

>>34
がっくしも変えられる。

つうか、それが最低条件だよね。
スレ一覧でのスレ表示数・スレでのレス表示数・1レス内の表示文字数がそれぞれ変更可能なのは
とても嬉しい。

これが出来ないから（べ）っかんこには行けない。

正直よくわからないが…


頑張れ、超頑張れ

今の問題点はどこにあって原因はなんなのだろう

1182953833/l10n
とかにしてたとき、べっかんこで上下しようとすると再読込始めるからべっかんこにはいけない

>>42
普通にハード劣化かもしれないですよね。
携帯アクセスが順調に増えて、結構働き通しだったそうですし。

全角カタカナ
半角ｶﾀｶﾅに

変換されるのが、嫌だ。

まぁ，当面を乗り切る対策と，抜本的に仕組みを作り替えることと，分けて考えてもいいかもですね．

で，この前の雪だるまでの Squid 導入作戦の時に，c-docomo5 で使っているらしき
squid.conf が雪だるまフロントにコピーされていたので，それを見てみると，
今はディスクキャッシュは用いておらず，メモリキャッシュが 128MB ってことになってるっぽいですね．
となると，全 dat が 128MB に収まりきるとも思えないので，あふれた分は BG に取りに逝く，
で BG が忙しく働き，ついには死亡と......

であるなら，RAM をもっとたくさん積んだ鯖を導入してメモりキャッシュ領域をもっと拡大するとか，
あるいはディスク I/O の性能の優れた鯖を導入してディスクキャッシュを使えるようにするとか，
そういうことにより今の仕組みのままでもかなり改善されそうな気はしますね．
逆に言うと，新たに自力での差分取得＋キャッシュの仕組みを作ったとしても，
ものすごい量の dat をディスクに蓄えることになるわけで，
そうなるとディスク I/O がそれに耐えうるだけの性能がないと，
いずれにせよ結局死亡ってことになりかねない，と......

まあ、贅沢な機能を全部盛り込めるほど資源はないわけで
誰かが我慢する前提で補強するしかないわけだ

べっかんこ使えないから早くｃ直して＞＜

おぉ！さすが◆cZfSunOs.Uさん。為になる話だ。
馬鹿な私にも分かり易い。
「当面を乗り切る」しか考えが及ばないので(´･ω･｀) 。
グラフ見ても、BGが死ぬ前はメモリ使用率急上昇みたいだから
RAMを増やすのは良さそうに思える…。

↓ここから馬鹿には分からないダイナミックな提案。

雪だるまシステムは応用できないのでしょうか？

>>38
ゴミに馴れたら負け

>>51
ゴミなんて言うなよ。(べ)も凄いんだぜ？

>>50
もうやってる

べっかんこ使ったことないんだけど
レス表示数クラとか讃岐みたいに自分で設定できるの？

何でも良いから携帯から２ちゃんできるようにして下さい(>_<)

パワーアップとかいらないから早く元に戻せや
重くするだけのくだらない機能なんて誰も求めてないから

パワーアップ＝鯖の能力強化＝見れるようになるってこと
誰が追加機能のパワーアップって言った？ｗ

cの連中って馬鹿多いなｗ

いまに始まったことじゃないけどなぁ

ろくにログも読み返さない連中の民度なんてこんなもんか

自分の好きに設定変えられるほうがいいって奴らは
結局自己中な奴らなんだよｗ

このスレのパワーアップってのは追加機能は二の次で
鯖を強化してみんなが見れるようにしようのパワーアップですんで
勘違いしないように

追加機能を入れようにも見れないんじゃお話にならないし

クラシックなんてお気に入り意外使わない
べっかんこ愛用だがお気に入りだけは使いにくくて

復活ﾏﾀﾞｰ(･∀･ )っ/凵⌒☆ﾁﾝﾁﾝ

機能追加とか言わないでいっそ削除してみるとかどうだろう
書き込みを無くしそれに伴い写も削除初のROM専用に生まれ変わるとか
レス番と検索は読むのに使えるけど思い切って削ってみるとか

ここまで出た話題。

【抜本的に仕組みを作り替えること】
・サーバの追加を単純にしたい。>>9
・キャリア別をやめたい。>>10
・バック/フロント制をやめたい。>>10
・どのサーバも現在のバック/フロント機能を持ちたい。>>10
・BG-squid方式の是非。>>14
・パブリック=プライベート型のネットワーク方式の是非。>>14
.　⇒長所：トラフィックに強い。短所：汎用性が無い。>>14
・差分取得したい>>14,>>15
.　⇒BG-squid方式不可、ディスク I/O強化要。>>16,>>33,>>46
・フロントからdatを取りたい。>>15
.　⇒BG-squid方式不可、差分取得要、キャッシュ要。>>17-18

【当面を乗り切る対策】
・datキャッシュ方式の再チャレンジ。>>21, >>29
・仕組みを守る動作（アクセスコントロール）を入れたい。>>29
・メモリキャッシュorディスクキャッシュの充実。>>46

【その他】
・電源大丈夫？>>36
・管理人の懐具合。>>36
・さらに機能を削減する。>>65

ここまでの必要スペック(笑)。

台数：未定
種類：全部同じの（T-BANANA相当？）
CPU：強いの
メモリ：沢山
HDD容量：沢山
ディスク I/O の性能：強くて安定してて枯れてるの
NIC：1枚でもいいかもしれない
電力：沢山

ごめんなさい。訂正します。

ここまでの必要スペック。

台数：未定
種類：全部同じの（T-BANANA相当？）
OS：最新？
CPU：Xeon 2.8GHz dual以上
メモリ：2GBytes以上
HDD容量：200GBytes IDE HDD x 1以上
ディスク I/O の性能：強くて安定してて枯れてるの
NIC：1枚でもいいかもしれない
電力：沢山

>>68
復旧はいつくらいになりそう？

＞36
がっくしメニューをインストールしたら勉強になりますよ！
パラメータ変えるだけで鯖が軽くなったり重くなったり
http://orz.2ch.io/

Xeonというか今の時代はCore2だろ・・・

>>70
がっくし立てたら森貰えるって本当ですか？

>>71
ひろゆきがモリタポくれるそうですよ

>>69
余裕見て半年後くらいに思ってみたら良いかも。

>>70
返答に困りますねぇ。
まず、自宅だかレンタルだかにサーバを設置しないと…。
WinNT-2000-2003なら触った事あるんだけど、
Win以外はどうやるんだ？？？

>>73
半年…
なんとか１ヶ月位にできない？

>>74
まだシステムの完成形が見えてないしね
長めに見ておいた方が落胆しなくていいかもですよ

>>75
なるほど
なら気長に待ちますわ。

>>72
マジですか。
どうもです

>>74
鯖不足なんで簡単に増強できんのよ
早めにc用鯖の仕様決めて確保しないとドンドン復旧が遅れるよ

ここはそういう話し合いのスレです

携帯→2ch運用情報スレッド45
http://qb5.2ch.net/test/read.cgi/operate/1182908073/

972 名前：マァヴ ◆jxAYUMI09s 投稿日：2007/06/28(木) 23:06:46 ID:XnijJ6Rm0 ?PLT(45055)
そこでT-bananaサーバ更に投入です(^_^;)やっとできた
まじで品薄なのよ・・・・＞T

半年も待てないのだ
(｀´)ﾌﾟﾝﾌﾟﾝﾏｰﾁ

◆mami/ZczII sage 2007/06/28(木) 23:52:53 ID:qkkknU/6P
>>17
ごめんごめん。再来週かもしれない。

携帯→2ch運用情報スレッド46
http://qb5.2ch.net/test/read.cgi/operate/1183041321/21

適当に、バックエンド3台にメーカー別に分けないフロントエンド9台でいいだろ。

メモリ２Ｇ買うんだったら、４Ｇでも対して値段かわらんだろ。
古いＯＳとかマザーボード使うんじゃないんだし。




って無責任に言ってみる。

バックエンドをなくして、全部フロントにして、
キャリアで分けないとか、そんな感じすか？

>>83
実現するには、物量作戦を取らないといけなくなるなぁ
いったい何台必要になるんだろう？？？

>>83
お疲れさん

もしキャリア別にしてきた鯖を統合して1台にするなら
メモリ2GBはちと不安じゃね？
ぶっちゃけVIP(wwwww)と同じ鯖を導入してみて様子見が現実的じゃないかと。

昔は今の物量で足りてたのにな
どんどん増えてるよな

今日中に直さないと自殺します
方法は首吊り
これは本気です

>>88
マルチ脅迫ｗ

脅迫に屈するとは思えないのだがｗ

>>86
> もしキャリア別にしてきた鯖を統合して1台にするなら
別に1台にするわけじゃないし。キャリア分けてたことに大した理由も無いし。
各キャリアの通信速度差による負荷の違い、とか見るためのテストが目的だったわけだよね。確か。

鯖のスペック的には T-banana にすると結構よさげな感じですね．
HDD の I/F も SATA になるし．RAM を 2GB にするか 4GB にするかは思案のしどころですが．

もっとも，T-banana は品薄だそうなので入手までにある程度時間がかかるかもというのと，
たとえすぐに入手できたとしても BIOS を更新するまでは爆弾を抱えることになるし......

.c復旧マダー？
他は見づらい使いづらいよ＞＜

運営の皆さん、連日乙です！
ﾏﾀｰﾘ待とうとは思いますが、復旧の目処がいつ頃になるか知りたいなぁ

もう書いてるだろここに

>>94
>>73嫁チンカス包茎小僧

デフォルト表示じゃなくてもいいからおすすめ2ちゃんつけて下さいー
復旧まで待つお

>>95-96
これは失礼いたしました
教えてくれてありが�d

1G４枚させるAMD系でも面白いかもね
調達がさらに厳しくなるかも知れんけどｗ

AM2ならﾂﾞｱﾙｺｱでも結構電力くわねーし
問題はﾏｻﾞｰにヨサゲなものが無いことか

BG-squidしないなら、既存のサーバで試して見るのがいいのでは？
生きているc-docomoやc-auを放置しているのは勿体無い気がする。

こうすけさんが試してみるといってるのは
それかもしれない

BG-squidしない版をつくって、生きてるサーバで試してみると
いいかもですね。

少しずつ体調回復をはかり中、、、。
しかし今夜まではほとんどアクセスできない予定。

>>102
差分取得を先に実装してほしいかもです。
そうじゃないと(毎回全量転送だと)、各サーバへのインパクトが大きすぎるかなと。

あと、以前やってみたときは、IDEのディスクが音を上げた記憶がありますが、
これも全量転送だったからなのかも。

今の鯖体制での効率化が先だろうね

がっくしも差分取得に対応しようそうしよう
差分取得できたら20秒間隔で取得してもいいですか？（今は40秒）

全体に転送量が増えている & 負荷が増えているのは、
やっぱり c が落ちているからかなと。

hobby9 が今日から人大杉設定みたいですが、
それもこの関連ですかね。occult とか携帯多いです。

>>105
現状のままがいいかなと。

…すまない皆様、伺ってもよろしいですか。
もしかして、差分取得ってスクリプト側の仕事？

そうだろうな
スクリプトの仕事だろうな

>>107
もちろん。

今私が知っている差分取得対応しているやつ:

・u.la
・AAS
・s2ch(讃岐メニュー)

携帯がこれからハイスピード化することも考えてパワーアップを考えてるのかどうかが問題

もうこうなったら一週間閉鎖してサーバ変えた方が早い

u.la は「対応しているはず」と思ってますが、
転送量グラフとか、この目で確認したわけではないです。

AASとs2chは、以前転送量グラフで確認したです。

ディスクアクセスが悲鳴を上げるなら、最初は全板対象じゃなくてもいいと思うんですよ。
wwwww鯖のみ・live鯖のみ・news鯖のみ・ex鯖のみ・・・な感じで利用板を絞れば、
キャッシュに持つdatの量減ってキャッシュのヒット率上がるのではないかと？

＞106
了解ですー

ルータンの考え方はどうなの？

s2ch の下がり方は劇的だった

じゃあ、落ちてる今の内に作っておかないと。。

まず、自分の所(c系)のdat置き場のファイルを開きますよね。
多分、//c.2ch.net/dat/hogehoge/fugafuga.datとかにしておけば、
今のDNSの仕組みで適当なサーバに接続できますよね？
これは現行の仕組みと同じかな。？。見た感じそんな気がする。
それで既にキャッシュ済みのレスが表示できます。

新着レスがある場合、新しい部分は2chサ＝[バから取ってｂｱなければいけｂﾈい。
なｂｯれば、キャッャVュをぞのまま封\示。
あｂ黷ﾎ、2chサーバから取ってきたdatを表示。

判定はファイルサイズで行うのかな？
それとも凄い方法があるのかな？

新着レスがあった場合は、>>1から最後まで全部持ってきて良いのかな？
それともキャッシュに追記できるような仕組みがあるのかな？

ご存知の方がいらっしゃいましたら教えてくださるか、何かヒントを…！
考え方がおかしかったら指摘して下さい。

どこかに差分取得のスクリプトはあるはず
docomo7あたりだったかな？

既に差分取得を成功させている中の人たち(>>109)に、
アルゴリズムを解説いただくのがいいんではないかと。

>>119
おぉ。

で、これから会議→たぶんそのまま外勤 の予感。

つーか実況カテゴリだけ外して復帰させろよ。
本来実況なんて無くてもいい板だろ。
それでもヤバイならVIPも切ってみよう。

monazilla Part 5
http://pc11.2ch.net/test/read.cgi/tech/1057329161/

>>119
探してきます。

>>120
よし。讃岐君にアクセスしてみよう(ﾟ∀ﾟ)。

>>123
読んでくれば良いの？ 不動楽さんがいてなごんだ(´∇｀)。

>>124
今の感想をひとことおねがいします

>>126
なぜ韓国に謝罪しないんですか？

>>127
どうして靖国に参拝されるのですか？

韓国？それて食い物か？

靖国参拝？全く記憶に御座いません！

正確には差分取得じゃなくてキャッシュ処理？
差分だったら新しいところだけ取得できる感じだよね。

>>128
うん。私もその漢字に惑わされた。

それっぽいファイルを見つけたけど、@fopenとか今まで目を逸らしてたから
ムツカシー

差分取得するには元のデータがないといけないので、差分取得はキャッシュとセットです。

今北重工業

>>130
ですね。

というか、BGをやめて各フロントにdatキャッシュを持たせるなら
(前にも書きましたがそのこと自体は悪くないと思う)
動かす＊前に＊差分取得を実装してからにしてほしい、
というのが、長年見てきた私からのお願い、かなと。

そうじゃないと、フロントが増えるごとに、
どんどん転送量が増えていってしまうことになってしまうです。
(もちろんサーバがデータを提供する負荷も増える)
差分取得入れてももちろん増えていくわけですが、増え方が全然違うので。

ここで讃岐をみんなｽﾙｰしたら面白いんだが・・・

>>131
ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!

差分取得のやり方について、cの中の人たちに協力してもらえるとうれしいです。

で、私はまたしてもオフラインに。

讃岐行きていたのか

携帯から全く繋がらんﾋﾞｸｯ

banana405.maido3.com
c-others1.2ch.net [206.223.150.145] 90.001 sec.Time out
0.02 0.12 0.08failed 板数：0　詳細：c-others1.2ch.net
携帯 au,docomo 以外のフロントエンド

banana406.maido3.com
c1.2ch.net [206.223.150.145] 90.001 sec.Time out
0.02 0.12 0.08failed 板数：0　詳細：c1.2ch.net
classic メニュ。

tiger511.maido3.com
blackgoat3.2ch.net [206.223.151.55] 90.003 sec.Time out
1.44 1.35 1.33failed 板数：0　詳細：blackgoat3.2ch.net
携帯アクセス用バックエンド鯖（黒やぎさん１）

tiger512.maido3.com
blackgoat4.2ch.net [206.223.151.57] 90.004 sec.Time out
0.35 0.41 0.56failed 板数：0　詳細：blackgoat4.2ch.net
携帯アクセス用バックエンド鯖（黒やぎさん２）

復活マダー？

今のうちにハイスピードに対応しておかないとドコモ905iシリーズが出る頃には大変なことになる

>>131
差分取得って何？ あたりから成功してる大先生に日本語で教えて欲しいのです。
こうすけさんか不動楽さんが作ったみたいなモジュールは既にあるみたいです。
まずは連絡先を教えて？

スクリプトの本文どこまでココに書いていいのか分からないので。

sanuki at s2ch.net

>>141
ありがとうございます。

差分取得を自作した事あるけれど、、、、、
はまった所は、透明あぼーんでDATが大幅に短くなった場合の考慮漏れがあった事かな。
短くなった状態で差分取得しようとするとサーバが 416 を返してくるんだよね…。

http://info.2ch.net/wiki/pukiwiki.php?monazilla%2Fdevelop%2Faccess#Range

あとズレ判定用として私は2スレ分は溯るようにしました。
（あぼーんが連続した時のご認識回避のためです。）

s2chのスクリプトを正式採用しちゃえばいいんじゃね？

s2chってPHPだっけ？

まず普通にdatをキャッシュする
↓
GET /bbs/dat/key.dat HTTP/1.0
Host: server
User-Agent: UA
Range: bytes=ファイルサイズ-1
Connection: close
↓
206なら更新があるので返ってきたデータの先頭が改行コードなら書き足す
もし改行コードじゃなかったらあぼーん判定してdatを再取得

304なら更新がなかったので更新時間のみを変更

416ならあぼーん判定してdatを再取得する

こんな感じ

ごめん。全然わからないや。
docomo7に置いてあったものと随分やり方が違う模様。。。。
しくしく。

讃岐たんとことまったく同じにしてくれたら使いやすい

>>146
If-Modified-Since: も付けないと304は帰ってこないと思われ。

＞206なら
まず、ここが分からない。誰がコレを返すの？

＞まず普通にdatをキャッシュする
これを最初にやったら、全転送と同じじゃない？

>>150
RFC 2616を読みたまへ

HTTPステータスコード
http://www.asahi-net.or.jp/~AX2S-KMTN/ref/status.html

＞＞まず普通にdatをキャッシュする
＞これを最初にやったら、全転送と同じじゃない？

一回目は全部取得して、二回目以降は差分を取得するんですよ。

If-Modified-Sinceはお勧めしない
http://pc11.2ch.net/test/read.cgi/tech/1057329161/424

けど、問題は特に起こってないのかな
Janeだと流れの速いスレだとたまに発生してうざいけど

>>149
よくわからないけど返ってきてるはず
それ入れると微妙に挙動不審になったりするし
あと、s2ch.netのスレの下の方にある(･∀･)新着ﾅｲﾖってやつが304が返ってきたときに出るやつ

>>150
上
ステータスコード

下
1回にいくつまでとか決まってるの？

>>153
なるほど、秒単位問題ですか、知らなかった。
でも、-1秒して取得をかければ問題なさそうだけどね。
それで>>146みたいに304の場合は更新日時だけ変更すればいいかも。


>>154
そうなのか…。
でも何に対して「更新は無かった」って判定しているのだろうか？
If-None-Match？

206とか304は2chサーバが返すんですよね？携帯用じゃなくて。

＞改行コードなら書き足す
キャッシュしたデータにキャッシュしたデータを書き足す？？
2chサーバが増分だけ送ってきてくれるですか？

>>152
304だったら、ファイルは開くけど保存しないで捨てるって事ですね？！
なんとなく分かってきた気がします。

あっ、改行コードなら先頭の改行コードを切り取って書き足すの間違いね

例
50レスあるスレを取得
↓
1分待つ
↓
通信
↓
60レスになっていたので、先頭に改行コード+10レスが返ってくる
↓
先頭の改行コードを切り取って50レス+10レスで60レスになったよﾔﾀｰ

>>157
304だとデータ部分が空で「変更はなかったよ」って応答が帰ってくる。
中身が殻なので余計なトラフィックが発生しません。

やっと、見てる行が違うのが分かりました！
function createcacheていうのを見てたら、
なんとなく分かってきた。
でも、コレ、206の時、何もしないになってる。なんでだろ。

まみら★さんに萌えフラグが立ちました。

>>158-159
増分だけなんですね。
よく見てみたら増分と全部では貰うステートメントが違うのかな。
よく見てみよう。

case文の部分だよね。
206は416と同じ動きになりますよ。何もしていないのではないですよ

えええー>>163
そういや、break;してない！ そっかーなるほど。見落としてました。
すいませんVBA厨で。。

ちょっと知恵熱が出てきたので離脱します。

200で全取得
206,416で差分取得
304で時間のみ更新
って処理をしているはずですよ

まみらかわいいよまみら

おまいら頭いいな！


何言ってるかさっぱり分かんねーけど

>>168
|ω・`）最後の一文リアルでワロタｗ

いやー慣れの問題だけですから（　´_ゝ`）ｴﾍﾝ

なんかしらんけどプラウザ側の資料ですが置いておきますね
http://age.s22.xrea.com/talk2ch/#get

よくわからんが、差分取得時のロジック改善を計画しているのか？
おまえら大変だな

期待してます＞＜

キャッシュがあるか無いかは、多分DB使った方が良さそうな♪

大坊？

皆さん乙です
正座して待ってますよ(･∀･)

まみらって誰だよ！

まみらだよ

さっぱりだけど、システムを改良しようとしてるのくらいはわかるよ
がんばってください

べっかんこで採用されてるgooとか言う画像変換使える様にして欲しい
結構見れない画像があるので

>>180
新機能は、まだまだ後の話だな。

今は本機能の復旧が先だしな

それもそうだねf^_^;

>>181
urlクッションごときに、『新機能』という表現はおかしいぞｗ

べっかんこは変な昨日付きすぎで使いずらい
早く復帰をお願いします

スレ内検索ができたらいいな。

一応、キャッシュする仕組みは作りました。（c-docomo7）
（ただしdatのみ、subjectはもうすこししてから）

今日は後で少し時間とれるかも。

とりあえず、BG3/BG4 を落としっぱなしにしておくのもいまいちなので、
負荷で落ちているのかそうでもないのかも含めて、
一度立ち上げなおしてもらいます。

フロントの squid は落としておき、
そのうえで1.0で要請入れて、
立ち上がったら、BG の squid を落とします。

ということで、これからたんたんと。

# 個人的にはBG3/BG4のsquidは、もうBG目的では上げない気でいます。

ちと私の都合で予定ずらして、>>188 は13:00からやります。

>>123のスレ読んできた！ 頭に入ったかどうかは謎。

>>180
cに入れるとdeny対象に入るかも。

>>187
乙です。見てこようっ。

落ちてる奴の復旧だから他に影響はないわな
頑張ってくだされ

>>187
思ってた所と違うみたいだった。

BG上げてもBGとしては動かさないので、
差分転送サポート & datをキャッシュするしくみをフロントで、
になるまでは、現状のままかと。

# サーバが健康なら再整備してフロントに入れることはありうるかもですが。

＞こうすけさん
if($use_cache){}の中身とcreatecacheをコピペすれば良いのかしら？
それだけで動くと思うのは素人でしょうか。

global $fh;
global $unlimited;
global $time_now;
global $use_cache;
これらがどこで定義されてるか探したほうが良いですか？

ここまで出た話題。

【抜本的に仕組みを作り替えること】
・サーバの追加を単純にしたい。>>9
・キャリア別をやめたい。バック/フロント制をやめたい。>>10
・どのサーバも現在のバック/フロント機能を持ちたい。>>10
・BG-squid方式の是非。>>14
・パブリック=プライベート型のネットワーク方式の是非。>>14
.　⇒長所：トラフィックに強い。短所：汎用性が無い。>>14
・差分取得したい>>14,15
.　⇒BG-squid方式不可、ディスク I/O強化要。>>16,33,46
・フロントからdatを取りたい。>>15
.　⇒BG-squid方式不可、差分取得要、キャッシュ要。>>17-18
.　⇒全量転送ダメ、絶対。>>103
.　⇒取得間隔は何秒？>>105-106
・最初は差分取得する対象のサーバを限定する。>>113

【当面を乗り切る対策】
・datキャッシュ方式の再チャレンジ。>>21,29
・仕組みを守る動作（アクセスコントロール）を入れたい。>>29
・メモリキャッシュorディスクキャッシュの充実。>>46
・今生きてるサーバで非BG-squidをやろう！>>100-103

【その他】
・電源大丈夫？>>36
・管理人の懐具合。>>36
・さらに機能を削減する。>>65

ここまでのスペック。

台数：未定。BG×3＆FEnd×9説浮上。
種類：全部同じの（T-BANANA相当？）
OS：最新？
CPU：Xeon 2.8GHz dual以上。Core2？。AM2dualはマザボに注意。
メモリ：2GBytes以上。4GBにします？
HDD容量：200GBytes IDE HDD x 1以上
ディスク I/O の性能：強くて安定してて枯れてるの
NIC：1枚でもいいかもしれない。現状は2枚。
電力：沢山

＜＜宿題＞＞
T-BANANA相当のスペックを調べてくる。I/F：SATA

>>190
denyって何ですか？

アク禁

というか、コピペでだけで完璧に動くコードを見てみたい・・・ｗ

>>194
基本的にはそのはずです。
global　は　test.php　で定義しています。
$fh　はゴミですね。

denyとはこの手の用語で制限のこと
アクセス規制の意味がある

>>200
て事は採用は難しいって事ですかね？

>>199
わーい。そしたら何とか出来そう！

今はrootさんが見てると思うので触らないです。

>>201
採用するのは全然かまわないけど、すぐに見れなくなるかもね？って話です。

>>202
フロントのsquid切ってある => 外にとりに行かない
ので、フロントのプログラム部分は触ってもかまいません。

で、BGが何らかの結論を見たら、
当面の方針とか、そのへんを。

>>202-203 補足

要請は 1.0 でしているので、「1.0 の対応」になります。
なので、フロントの改変とかは、すすめていただければokかと。

ただし、現状どのフロントもT-bananaよりパワー弱いので(特にHDD)、
その範囲内でということで。

>>202
ソフトバンクには有り難いので是非採用して頂きたい、他のだと画像が小さいので

tiger512は遠隔リブートで上がりました。(squid上がらないようにしました)

tiger511は遠隔リブートでは上がらなかった模様。
その旨を伝え、チェック・対応を依頼しました。

＞その範囲内
またムツカシイ事を言われてしまった。

docomo7のtest.php見てきます。
getres.phpに該当部分はもう貼ってもいいのかな？

携帯からの接続は、通信が遅いせいでApacheのスロットがなかなか解放
されないのが問題なんだよね？　スロットが開放されないと裏方も解放
されないから、メモリも余計に使うと。

そうならば、80番ポートで一時受付させる"リレープロセス"を走らせて、
裏で走っているApache(別ポートに変更）にリレーするようにしたら
どうかな？
リレープロセス〜Apache間はデータの受け渡し時のみ接続して"さっさ
と切断"させる。あとはリレープロセスがﾏﾀｰﾘ携帯にデータを送ると。

リレー側はなるべく軽くして大量に掃けるようにする必要はあるけど、
こうすればApache側の負荷は軽減すると思うよ。その気になればリレー
側で流入量の制御も出来るだろうし。

おい、早くパワーアップさせろや

>>210
帰れ、作業の邪魔だ

>>209
> 携帯からの接続は、通信が遅いせいでApacheのスロットがなかなか解放
> されないのが問題なんだよね？　スロットが開放されないと裏方も解放
> されないから、メモリも余計に使うと。

これはまさによく言われていることですね。
KeepAlive とかは当然offだったりします。
httpd が売り切れないようにいろんなチューニングするのは、
結構もう実施していたりするです。

ただ、今回のcはそれが問題というより、
別のところ(そもそもの処理の重さ)の問題の方が大きいかなと。

> そうならば、80番ポートで一時受付させる"リレープロセス"を走らせて、
> 裏で走っているApache(別ポートに変更）にリレーするようにしたら
> どうかな？

これ、一時期試してみようと思ったことあるです。
squid あたりを HTTP アクセラレータにするとか、そんなかんじですかね。

で、うまくsquidにボリュームがつけられれば、
死ぬまで受け入れることにはならないと。

で、一時期 >>209 >>212 を試してみようと思ったけどやめたのは、
eAccelerator 入れて、BG方式にしてフロントでのディスクI/Oをやめた結果、
httpd の売り切れの症状が出なくなったことからですね。

でも今後差分取得が実装でき次第、
各フロントでdatキャッシュ持たせる方向だと思うので、
再度試してみる価値はあるかも。

パワーアップするのはいいが
まさかべっかんこ並みに派手にするつもりとか？
1ページ当たりの容量が増えたら携帯に保存されたキャッシュも
すぐ消えてなくなるし困る

>>214
当面は機能追加よりも「安定志向」だと思っているです。
高機能なものが使いたければ、そういうメニューは既にあるわけで。

>>212

> これ、一時期試してみようと思ったことあるです。
> squid あたりを HTTP アクセラレータにするとか、そんなかんじですかね。

普通のリバースプロキシだと、携帯側との接続が切れないと内部側とも
切断しないんじゃないかな？とか思ってます。
なるべく早くApacheを切断してあげるのが肝かと思ってます。

> ただ、今回のcはそれが問題というより、
> 別のところ(そもそもの処理の重さ)の問題の方が大きいかなと。

orzもそれで悩んでいるみたいですね。（キャッシュ検索あたり）
まだまだアクセスが伸びるだろうし、輻輳時に落とさない仕組みが必要に
なりそうですね。

>>216
> 普通のリバースプロキシだと、携帯側との接続が切れないと内部側とも
> 切断しないんじゃないかな？とか思ってます。

うーむ、そうかも。

Apache status で w になっているやつが多くなると、危険ですね。
携帯も網が早くなったせいか以前ほどには
「てめー早く受け取りやがれゴルァ」みたいなのは多くないですが、
本質は変わらないですからね。

一番いやんなのは昔どっかにも書いたけど、
リンク押した直後に圏外のところに逃げちゃうことかなと。
(地下鉄とか?)

> 一番いやんなのは昔どっかにも書いたけど、
> リンク押した直後に圏外のところに逃げちゃうことかなと。
> (地下鉄とか?)

地下鉄で通勤しているのでよくやってるｗ
あれはやっぱりサーバには良くなかったのか orz

>>217
JMだとW状態のまま10000秒以上のこっちゃってるやつがあるんですが、
強制的に切断させるのってどう設定すればいいんですかねぇ。

Timeout 5

とか httpd.conf に書くんではだめなんだっけ。>>219

>>220
やってますけど、意味が無いみたいな・・・

今日も携帯スレは賑やかだわ

各板から、「携帯で書けねーぞｺﾞﾙｧ！」　な人たちを誘導してるからなぁ

tiger511 も上がりました。(squid上がらないようにしました)
フロントのsquidを上げました(誘導かかるようになったかと)。

ちと、しばらくオフライン。

で、

>>208
混乱させてしまってごめんなさい。
私のほうの作業はいったん終わりなので、
フロントのほう、みていただいてOKです。

global $unlimited;
global $fh;
の処理がまだよく分かんないけど、やっちゃいますね。（管理人式）

>>226
global $unlimited;
保持するキャッシュの数です。

global $fh;
ゴミなので消しちゃって良いです

>>227
docomo7のtest.phpにはunlimitedの文字が無かったんですけど、
そのままだったらマズかったかしら？

>>228んじゃ、100くらいにしときましょう
test.phpの先頭に書き込んでください。
そのうち、板ごとに設定しましょう

subjectはとりあえずproxyなしに変えますね。

>>229
100にしましたー。

getsubjectの方が差分に対応してないみたいなので、
まだエラー出てるみたい？

わかったー。docomo7のコピーしますね

subject.txtって毎回全更新だから差分取りする必要ない気が。
最終更新時間の判定だけでいいのでは？

>>231-232
んじゃ、キャッシュ格納ディレクトリを作ります

>>219
RLimitcpuは設定した？httod.confに。

>>233
面倒だから単にproxy通そうかなと思ってたりして、、、

>>232
終わったー

>>237
おつです。

>>235
してなかったですー。
ということでしてみた

乙です！＞こうすけさん、まみらさん

>>236
なるほど

なんで>>1が常に出るようになったのかしら？
getres.phpの比較してみたんだけど、
思い当たるフシがありません。
# ちなみにNoEditorというのを使ってみる事にしました。

>>241
今はこうすけさんが対応されて直ってます。

とりあえずしばらくオンライン。

現状、どうなんでしたっけ。

>>242
じゃない。どこ直したのか教えてください。

>>243
現状は機能削減版i2chが7台あるみたいな感じです。

>>245
フロントで動き出したと。

差分取得は動いているですか?

>>242
$content .= readdat($no,$r[$no]);
ここで1が強制的に書き込まれていた。
1の内容はキャッシュに埋め込まれていて、同じ変数$contentで読み込んでいたので、
1の内容の次に従来の表示が追記されてしまっていました。
$content1 .= readdat($no,$r[$no]);
と言うように別の変数にして対応したよ、

あと、フロントでdatキャッシュするようにしたということは、
きっと定時クリーンナップが必要だと思います。

cronの設定とかしこむかんじで(できないようなら言ってください)。
早朝に-mtime +2ぐらいでfindして古いのを消せばおｋかなと。

>>246
差分取得は動いています。（i2chそのままぱくりですから）
今はキャッシュゼロの状態なのでがりがり溜め込んでいる状態です。
暫くすれば落ち着くと思われます。

>>248
特に必要ないですよ。
今は各板で100個のキャッシュを持っていて101個目をキャッシュするときに
一番古い（アクセスしていない）キャッシュを捨てる仕組みが入っています。

>>247
なるほど。だから1が付いてたんですね。
勝手に消してごめんなさい。

>>251
前やった時もそれで散々悩んだｗ
すっかり忘れてましたｗｗ

>>249-250
了解です。

トラフィック等を見て掲示板サーバに負担が行かないようなら、
今日のところはこれで動かすかんじで。

で、100個というのはきっと、tuning必要そうですね。
個人的にはもうちょっと多いほうがいいような気もしますが、
このあたりを見ながらチューニングしていくかんじで。

http://mumumu.mu/mrtgc/mrtg-rrd.cgi/traffic/

で、これがうまくいくようなら、
今だめぽなbanana405の代替品も、
通常の(メモリ増やした)bananaでいけるのかなと。

>>254
そうですね。
板ごとに設定してもいいかなとも思っています。

各位乙です．

キャッシュの掃除は，個数での判定や find -mtime でやる以外に，
dat 落ちを検出したら (302 や 404 が返って来たら)
消すっていう方法もありますね．

>>257
> dat 落ちを検出したら (302 や 404 が返って来たら)
> 消すっていう方法もありますね．

これは賢いですね。
特に、実況(携帯からみんな見ているんだこれが)系には効果大かなと。

Apacheのリスタートテスト at 各フロントしながら、負荷観測中。

[Sat Jun 30 02:08:26 2007] [notice] child pid 24126 exit signal Segmentation fault (11)
[Sat Jun 30 02:08:26 2007] [notice] child pid 24124 exit signal Segmentation fault (11)
[Sat Jun 30 02:08:26 2007] [notice] child pid 24123 exit signal Segmentation fault (11)
[Sat Jun 30 02:08:26 2007] [notice] child pid 24114 exit signal Segmentation fault (11)
[Sat Jun 30 02:08:26 2007] [notice] child pid 24104 exit signal Segmentation fault (11)

となりはじめると、httpd のリスタートが必要な状況か、、、。

ということで、c-docomo6 と c-docomo7 の httpd を一度リスタート。>>259

フロントの squid はもう要らないはずなので、これから落とします。

>>260
あ、グラフ見てそうかなーと思ってさっきリスタートしてしまいました。

>>260
フロントのsquid落としました。

>>261
了解です。そのへんは適宜。

で、OSとApacheは機を見てバージョン上げます。

>>260
ついでにキャリア別はどうしましょうか？
全部c.2ch.netにして7台に振り分けしませんか？

>>263
PHPも上げてください

いい機会だし雪だるまでおなじみのmatdも考えてみては

>>264
そのへんの設定変更はきっと動作をみつつこれから、
というかんじですね。

必要に応じた新戦力の投入は管理人のOK出ているわけで、
どういうのがいいかもここで考えるのがいいかなと。

個人的にはキャリア別はそろそろやめる方向かなと思っていたりします。
ただ、全部フラットにするのがいいかどうかもあるかな。

matdとかが使える環境にするのがきっと一番いいんですが、
それだと、ネットワーク環境も含めて統合的に考える必要があるし。

>>265
OS上げるとなると5.x→6.xへのジャンプアップになるので、
基本的にports関係は全部入れ替えになるかと。

で、形を「差分取得ありフロントキャッシュ型」に変更したわけで、
この状態でどのくらいの戦力なのかがわからないと、
今後の戦略も立てにくいですね。

ということで、今日は少なくともこの状況でしっかり観察して、
次の手を考えるのがいいんではないのかなと。

あれ？c復活した？
ちと重いが一応繋がるﾜｰｲ!!
運営の皆さん乙華麗！

ふむ、PHPのWarningが出続けているですね。
これ重いんで、ログには出さないようにしよう。

[Sat Jun 30 02:41:49 2007] [error] [client むにゃ] PHP Warning: feof(): supplied argument is not a valid stream resource in /home/ch2c-docomo/public_html/getres.php on line 805

; - Show all errors, except for notices
;
error_reporting = E_ALL & ~E_NOTICE & ~E_WARNING

になっているし。ううむ。

http://ch2.ath.cx/load/i/

携帯ねらー恐るべしだな…

もうすぐ、落ちそう。

キャッシュ保有数を300に変更します。
>>270
なおします。
proxy設定になっていた。

うーん、これどうやって消せばいいのか。>>271
今日入ったところだと思うんだけど。

HDDがあっという間に消費されてしまうし、
そもそもこれを書くために資源使っているし。

>>275
お願いします。

c-others2 とか、このためだけで陥落しそう。

直すにあたり httpd の停止が必要な場合、言ってください。

test.phpの先頭に
error_reporting(E_ALL ^ E_NOTICE);
があるのがいけないのかな？

>>279
E_WARNING の時もレポートしない、
という設定にしてもらえると。

error_reporting(0)にしてエラー出力しないようにしよう
PHP.iniあたりにデフォルト値が書かれているとかいないとか

>>281
php.ini はかなり昔に >>271 に変更済みです。
# 以前はまったので。

>>281
(0)だと、デバッグが困るかもですね。
そのへんは中身をやっている方におまかせします。

で、設定変更したら言ってください。

私のほうで一度膨れ上がったエラーログクリアして、
httpd を再起動します。

>>284
一応、終了しました。


>>283
必要な時には付けると言うことで

>>284 をやりました。
エラーログの爆発は止まったようです。

とりあえず落ち着いたのかな。

折りも折り、羽賀研二氏が逮捕とかなんとか。

復活ｷﾀ━━(ﾟ∀ﾟ)━━!!

>>141
スパム宛先

Jane mobleマンセー

>>287
どんな折りも折りなんだｗ

エロい方々、本当に本当に言葉では言い尽せない程、お疲れさまでした。
c.2chから記念カキコ.･ﾟ(ﾉД`)ﾟ･ﾟ･.
嗚呼、クラかわいいよクラ

祭発生中につき news21/mnewsplus で様子見ていますが、
各cフロントからの差分転送は概ねうまくいっている感じですね。
掲示板サーバへの負担はほぼ最小限に保てている感じ。

思った以上に上手くいっている感じがする。。。

ちなみにディレイは90秒に設定しています。

会話の邪魔になるが
がんばれまじがんばれ

>>293
いまのところは、というかんじですかね。
他のメニューに移行された方もいるかも。

>>294
了解です。
様子を見ながらチューニングで。

他のメニューを使用中で復活に気付いてないだけかも。
でも、orzの転送量は減ってるから、徐々にcに戻っていくと思う。

で、うまくいっているとすると、
差分取得機能が非常にでかい気がします。

掲示板サーバの負担にならないなら、
他のメニューを使われても、いいんではないですかね。

PCでいうと、
・c.2ch.net … 2ch が標準で提供している read.cgi とか read.html
・他のメニュー … 各専用ブラウザ

のような位置づけなんではないかなと。

ディレイを90秒も取れば、負荷は下がるだろうね。
特に実況関係では。

>300
あまいのだ。リロードに制限はかけられないのだ。
実況厨は新レスが取得できるまでリロードしまくるのだ。

運営の皆さん乙です。
やっぱりcは使いやすい。

>>301
そういう時に携帯に304を返せたら楽そうだね。

liveの負荷を気にするような実況で304なんてほとんどなさそうだが

勉強になります。

エラーログなんて見た事ないや。。

あちゃー、出て来ない時に必死にリロってたのも負荷の一端かあorz
中の人ごめんなさい、今度から出て来ない所だけread.cgiで読みます

>>304
いやいやディレイ待ちの間に携帯からリロードが来たらの話ね。
携帯に対して 304 Not Modified だけ返しておけば、お互いに
楽が出来るよね。

携帯がIf-Modified-Sinceなんか付けてくるか？って話はあるけど。

＞rootさん
http://mumumu.mu/mrtgc/mrtg-rrd.cgi/io/
ここにdocomo系のグラフが無いみたいです。

c-others2のLAの高さが心配。１台だから、こんなものなのかな…？

c系は >>309 も含めて、「正しく」重いみたいですね。

>>308
みてみます。

今週末の経過を見てみないとなんともですが、
これなら、フロントのサーバを負荷に応じて追加していけばいい気がします。

というか、とりあえずその状態にしないと話にならなかったわけで、
まずは最初の応急処置はできたのかなと。

>>308
追加したはず。

>>311
ありがとうございます。

dat落ちしたスレを読むと、「プロキシにつながらない」になるような気がするです。

現状:

c-au/c-docomo系: それぞれtiny tiger3台
・IDE1台でまかなっているディスクI/Oが飽和、処理できない状態 → httpd スロットあふれ中
・CPUパワーはぎりぎり〜やや残っているか(I/Oが先にめいっぱいで使い切れない)

c-others系: ※現在banana1台離脱中
・いずれもあふれ中

概ね想定どおりか、と。

現状で /md でdatキャッシュさせられる自信はないです。
(前にもやってみたけど、OSの虫を踏んだりしてだめだった)

>>313
横槍ごめんなさい、さっき同じ症状が出ました
見れるタイミングだったのにまた一瞬で落ちたかと思った…

>>315
明らかな(特にプログラム上の)動作障害と思われるものは、
報告いただけるとありがたいかなと。

>>314
ディスクI/Oが飽和ですか？　それは厳しいですね。

orzのアクセスログを見てると 各板のsubjectへのアクセスの割合が結構
多いんですよね。subjectだけでもRAMディスクにでも逃がせばディスクの
負荷が結構軽減するんじゃないかな？

とはいえ全板のsubjectを集めると合計で60MByteぐらいになったはずなの
で、、、最新の200板分とかに制限する必要はあるかもしれないけど。

subjectも90秒ディレイなら、90秒より古くなったsubjectのキャッシュは
もはや不必要な物なわけだから、保持するのはもっと少なくてもいいかも。

>>317
> ディスクI/Oが飽和ですか？　それは厳しいですね。

私としては想定の範囲内でした。

上のほうで未承諾さんが「DB入れる」というのも書いていましたが、
結局IDEディスクだと、なんとかになんとかなのかなと。

しばらく見ていてこんな傾向なら、BG(こっちはSCSI U320+ccd)2台を
フロントに投入、というかんじかなと。

で、いちばんいけるかもと思ったのは、差分取得が効いているようで、
最大でも転送量が10Mbps出ない、というところですね。
これなら、某10Mbps接続のサーバ群を投入可能なのかも。

で、subject.txt を /md にするのは、確かにありかもですね。
このへんは明日以降に少しずつで。

>>313
どうしましょうか。
見た感じ、ファイルを入れる関数が空だったら
全部そのメッセージになっているような。
ほんとかな。
また明日以降に。。

関数じゃない。変数でした。

>>319
subjectはまだ毎回読み込みです、、、
前にも書いたけど、これはproxy経由（ローカル？）でもいいかなと考えていたり、、、
結局squidが行うかtest.phpが行うかの違いだと思うので、、、

>>313
なおした

>>320
あと、ログ再取得も仕込んでおいた。

ここまで全部FOX ★の自作自演

というのはガセ

パワーアップしたのかな

なんだかんだ言って順調？

普通に見れるよありがたう

誰だ。

c-others2が辛そうです＞＜

クラシックがやたら重い

おやなつかしい

c.の中の人乙ですた！

おれはcを諦めた
べっかんこに移行する

DoCoMoだけど
最近2NNから飛ぶと混雑していますって出るから
orzﾒﾆｭｰに行くとｱﾊﾟｯﾁｴﾗｰとかﾍﾟｰｼﾞが見つかりませんになる

ORZはだいぶ改善されてきた

そうなんだ
じゃあ、俺が村八分にされてるのか

ワロタ ｗｗｗ

＞337
http://orz.2ch.io/p
ここから行ってもだめ？
規制はしていないんだけどなぁ、、

>>339
おお、すごい、ありがとう
どこの板でも受け入れてもらえる予感

あれ、やっぱなんか3回に1度くらいｱﾊﾟｯﾁｴﾗｰでる
英語でｽﾞﾗｽﾞﾗｰって
P251iSだからかな、古くてごめん

ｲﾝﾀｰﾇｯﾄｴﾗｰだった
idからして呪われてるだけかもしれない
ありがとう

＞341
ふむ、、板メニューのあたりですかね？
改善しますー

うん、検索かけるときと、url踏んだとき、たまにｴﾗｰでる
ごめんなさい

＞344
いやぁ、悪いのは344さんじゃなくて、へっぽこな仕組みを作った俺なんで。
板の方は直ったはず。検索は徐々に直るはず。。。

順調ｷﾀ━(ﾟ∀ﾟ)━!!ﾄﾝﾄﾝｯ

>>259
c-docomo5 PHP 5.1.2 eAccelerator v0.9.5-beta2
c-docomo6 PHP 5.1.2 eAccelerator v0.9.4-rc1
c-docomo7 PHP 5.1.2 eAccelerator v0.9.4-rc1
c-au4 PHP 4.4.1 eAccelerator v0.9.3
c-au5 PHP 4.4.1 eAccelerator v0.9.3
c-au6 PHP 4.4.1 eAccelerator v0.9.3
c-other21 ?
c-ohters2 4.4.1 eAccelerator v0.9.3

messageを見る限り、c-docomo5では出ていないので、
eAcceleratorをバージョンアップすれば解決かもしれませんね。

PHP5+eAcceleratorの組み合わせはバグあるから早くアップデートした方がいいよ

2chサーバが重かったり落ちてたりすると、そことの接続待ち
の間はhttpdのスロットを塞いでしまうよね？

それを回避するために定期的にサーバステータスをチェックして
LAが異常に高い場合はディレイを増やしたり、死んでる場合は
最初からつなぎに行かないといいんじゃない？

>>347-348
なるほど、後でごにょごにょしてみます。

>>349
そのへんは、さじ加減が必要と。

ローカルルールの閲覧機能はなしですか？
公式で確認できないのに
「LR守れー！」と言っても、説得力ないっすよぉ

c.2chでorzを動かせば完璧じゃね？

>>352
orzというかdatCont（ry

c-xxは、単なるラウンドロビンでしょうか？
ロードバランサーとか入っていますか？

Name: c-au.2ch.net
Addresses: 206.223.150.22, 206.223.150.12, 206.223.150.17

Name: c-docomo.2ch.net
Addresses: 206.223.150.27, 206.223.150.32, 206.223.150.37

DNSラウンドロビンです

>>356
ありがとです。

au系は落ち着いた感じがする。（キャッシュ100個/板）
docomo系、othersはまだだめな（キャッシュ100個/板）

subjectもキャッシュさせようかな。。。

倉重いなぁ
てか先週のせいでべっかんこに慣れすぎた

やっぱ100だと、キャッシュの効きがいまいちですね。
http://mumumu.mu/mrtgc/mrtg-rrd.cgi/traffic/

今は仕方ないかもですが、資源増やした時は200ぐらいにはしたいかなと。

>>360
ちょっと前に200に戻しました。
少なくともdocomoとothersはいっぱいいっぱいですね。

T-banana1台でどれくらい捌けるか試したいですね。。。

>>359
べっかも糞重いぞ

まぁ，(旧)BG や T-banana ならディスク I/O がもっと楽になりそうですが，
そうなるとロードバランスでは能力差を加味して傾斜配分するとかした方が良さそうですね．

現状ってBG外したんでしたっけ？

>>365
BG外して、差分取得ありのフロントdatキャッシュにした状態ですね。
予想通り、フロントのHDDのキャパがあふれたと。

システムとしては(ちゃんとあふれて)安定していると思うので、
BG3/BG4をフロントサーバ化して投入、
あと今あいているstigerを入れるあたりが、次のステップなのかなと。

で、stigerって書きましたが、
これは管理人が直接寄付を受けたものなので、
実際に投入するかどうかは管理人の胸先三寸ってかんじで。

個人的にはネットワークが10Mbps設定なので、
携帯のフロントだとそのまま使えるかんじ(というか他に使おうとすると設定変更が…)
だったりして、好都合なのかなと。

ちなみにstigerを入れるとすると、
stiger100, 103, 104, 105 が投入可能です。
OSはいちおう、こっそり6.2Rに更新してあります。

それで、SunOSさんが >>364 でも書いていましたが、
ロードバランスの傾斜配分あたりを考えるかんじなのかなと。

老婆心ながら

それ縁起悪いっすよ

stigerって、関連キーワードとかで使ってませんでしたっけ？

keyの下1桁で保存するフロントのサーバを決めるとかにしちゃえば、
HDDフルは避けられる予感です。

>>371
c-0.2ch.net・c-1.2ch.net……c-9.2ch.netとサブドメイン割り当てて
2ch内リンクはスクリプトがスレッドキーの末尾を見て
サブドメインを替えるって感じ？

cobra5台にそのサブドメイン2つづつ割り当てて
残りのcobra1台はsubject.txt専門とか？

cobra・tiger・stiger・banana・tbanana混在環境なら
スレッドキーの下2桁を使って100分割して
サーバの強さで受け持ちバーチャルホスト数を変える感じ？

>>369
縁起ですか、、、。stigerは縁起が悪いと。
そんでは、まずBG2台のフロント化からいきますか。

>>370
6台中2台関連キーワードに使ってますね。(stiger101とstiger102)

>>371
あ、ごめんなさい。私の言い方が悪かったです。
「HDDのキャパがあふれた」というのは、
HDDの容量じゃなくてHDDの＊処理能力＊です。

systat -vとかで100%とか出る状況ですね。
IDEのディスクだと、予想通りというか、やはりつらいかんじで。

傾斜配分って出来るんですねー。（前にも聞いた気が）
記憶が不確かだったので少し心配してました。
BG機を投入するのはとりあえず、othersとdocomo？

傾斜配分はいろいろ方法考えられますが、
そのへんは時と場合によりで。>>374

で、すぐに投入可能戦力を整理しておくと:

a) tiger511/tiger512 Xeon2.8G 2Gmem U320SCSI
b) banana405の代替品(*1) Pentium4 1Gmem IDE
c) 縁起の悪いstiger(*2)

(*1)は別途こちらからメールする必要ありかも。
(プライベート側ネットワークがいらなそうになったなので、その旨)

(*2)入れるかどうかは、寄付を受けた人(管理人)の胸先三寸

>>374
で、個人的には、

(1)BG2つをDoCoMoとauに入れて、
banana405の代替品をothersに入れて試してみる

(2)(1)の結果を見て、次の手を考える

キャリアごとをどうするかとか
新戦力を投入するならどんな戦力がいいかとか
傾斜配分をどうするか等

というかんじがいいかなと思っているです。

>>376
さんせー

無神論者なので、縁起を気にしないフリとかで
行きたいと思います。
c)
>>375

気にしないんじゃなくて
気にしないフリかい

管理人のおすすめはc.2chだけあってcですか

>>378
了解です。

今OSだけしか入ってないので、
今日帰宅後あたりからBG3/4もあわせて、
土地作りとかすすめはじめるということで。

>>375
> b) banana405の代替品(*1)

について、増設ネットワークカード以外を同仕様にしたものを
出していただけるかどうかについて、中の人にメールで確認しました。

これから夜までほぼオフライン。

http://mumumu.mu/mrtgc/mrtg-rrd.cgi/traffic/

２ちゃんねるから引っ張っている転送量を観察しているのですが、
なぜ22:30頃を境にいきなり２倍近くに跳ね上がるのかしらん?

>>383
昨日の話？

んだんだ

(；･`д･´)てっ、テレホーダ(ry

>>358
>>360-361
このへんあたり

キャッシュの設定を変えたから？

テレホだったら23時過ぎだろ・・・常識的に考えて

ダイハード３は、、、関係無いか、
つまらんかったし。

あぁ　なるほど、キャッシュの変更なのか、
どもでした。

subject.txt のキャッシュも当然必要ですし(スレよりも長く設定120secとか)
板にもよりますがスレのキャッシュは200や300じ足りなかったりします。
vipなんぞは1,000くらい必要です。
よろしくお願いしま〜す

ニュー速＋の重さは異常

携帯に限った話じゃないけど、tmp6鯖とかsociety6鯖の重さもｱﾚ

>>390
はーい
今週末までには

ちなみに、べっかんこはキャッシュはどれくらいしてるんでしょうか？

ここでがっくし鯔鯖の方々がキャッシュの内訳について解説
↓

あー

全く以て解らん所存にございます。。。

subjectもキャッシュした。

subject.txt は 120sec delayでもみんななんとも言わないくらい
スレも60secでも何事もおこらない

これが最近の実験結果です

>>397
がっくしのやつdenyされてるよ

>>382
先日出していただいたbanana2882を
再度出していただけることになりました。
今、ログイン情報受け取りました。ぼちぼちと。

>>399
T-banana？

subjectをキャッシュにした変更の際に広告が消えた。
帰ったら直さないと

>>400
2800番台なので、通常のbanana(の年齢が新しいやつ)ですね。
T-bananaは3100番台のようです。

banana405(std. banana)の代替機なので、std. bananaと。

で、戦略としては、
・まずは現有戦力でどこまでいけるか

をやって、
・追加の戦力が必要ならその時に動く

というストラテジでいくということですね。

# とは言うものの、ヘビーなディスクI/Oについて
# T-bananaの実力がどうなのかは、興味深いところで。

むさん、
(;´Д`)Д`)Д`)Дﾟ)
　ﾊｧﾊｧ ﾊｧﾊｧ ﾊｧﾊｧ ﾊｧ?

c-others2のLAが下がらないのでVIPのキャッシュを500にしました。

キャッシュをなくす(減らす)のはこの作戦の意味をなくすことかと
またrootさんにdenyされちゃうのでは?

この作戦 = Love Affair 作戦

（ーωー;）

掲示板システムを守ることが第一義ですね。

既出のMRTGとかでトラフィック(*1)を監視しつつ、
うまく調整していくのがよいと思います。

(*1)第一の優先度は、
掲示板サーバに大きな負担をかけていないか

BG2台、banaan405の代替品、縁起の悪いやつとかもですが、
まずはたんたんとできるものを投入していくかんじですすめます。
本業多忙でなかなかあれですが、できる範囲でいろいろと。

>>405
それでは、キャリア別を止めてシームレスにするまでは、
DoCoMoとau以外はdenyしましょうか。
denyというか
落ちるまで稼動→気が付いたらリブート。コースになりますか。

（　´_ゝ`）

今、緊急に200にしましたが、結構空きが出来たみたいですので
グラフ観察の為、少ししたら300に上げてみます。

(´･ω･`)

>>410
携帯スレでも書きましたけど、様子見は大事ですよ。。
c-others2の現状把握は今後の為に生きてくるのですから。

>>412
はい。
それでは、次の変更は1時間後くらいが適当でしょうか？

>>413
短すぎｗ
キャッシュが効いてきて、差分取得している状態で観察しないと駄目。
そして、利用者が最大数になるまで気長に観察。
１日くらい？

>>414
１日ですか。
200〜300は>>349の時点でも試みてるので、
もう少し上でも良いかな？って気はしてます。
今回、500(vip1000)→500(vip500)にしてもidle減らなかったので
個人的に300〜400を観察してみたいかも。。

rootさんの空きとどっちが早いかって話にもなってきますね。

わたしたちは何をやっているのか
これはこんな作戦です

【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/operate/kako/1075/10758/1075887465.html
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
http://qb5.2ch.net/test/read.cgi/operate/1088657713/
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part3
http://qb5.2ch.net/test/read.cgi/operate/1095146311/
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part4
http://qb5.2ch.net/test/read.cgi/operate/1116860379/

というか，リクエストの量に対して HDD のパフォーマンスが追いつかないのが
苦しんでる原因なんじゃないかと．今後鯖を増やして1台あたりのリクエスト数が減れば，
キャッシュをもうちょっと増やしても追いつくようになるんじゃないかなぁ，とか．

日本語表記に事実と異なる誤りがありました。訂正してお詫びいたしまつ

誤：わたしたちは何をやっているのか

正：わたしは何をやっているのか？

>>417
そう踏んでいます。

かつ、スケールするように(>>9)、
かつ掲示板システムに大きな影響を及ぼさないように (>>407)したいなと。

全板×1000スレがサーバ負荷的に無理なら
全板×500スレという選択肢の他に
半分の板×1000スレというのもあると思うので>>113と

ユーliveとexとwwwwwを切っちゃいなヨ！

FOXさんがこれだけ真面目に話すという事は
状況はかなり逼迫しているという事ですね。
1日を観察に費やすのも駄目だし、
転送量の増加は1MBも認められない、と。

あとは、キャッシュ数を増やして、かつ
インターバル(現在90秒)を伸ばすという案もあると思いますが
諸兄のご意見伺いたく。

>>421
> 1日を観察に費やすのも駄目だし、
> 転送量の増加は1MBも認められない、と。

そんなこと言ってないと思うなぁ。

転送量そのものが問題なんじゃなくて(転送量はあくまで結果の一部に過ぎない)、
掲示板システム全体への負担だと思います。

結果として転送量が増えたとしても、
掲示板システム全体としての負担が減るなら、それでいいと思うわけで。

# うわ、会議の時間だ。

まぁ，試行錯誤する中で一時的に転送量が増えるのは仕方ないにしても，
転送量が増える（ことにより各掲示板鯖の負荷も高くなる）状態が固定化されるのがマズい，
ということなのではないかと．最終的には各掲示板鯖の負荷を低く抑えられるようにすべき，と．

>>422
了解です。
いつもと雰囲気が違ったのでビビってしまいました。
では明日まで観察します。

まぁ、試行錯誤しないと前には進めないかと。

（　´_ゝ`）ＰＣユーザ減少を携帯ユーザ増加が支えている（　´_ゝ`）
（　´_ゝ`）時として集中すると人大杉になるのは昔からの事（　´_ゝ`）
（　´_ゝ`）携帯搭載ブラウザはＰＣ並のブラウザに進化しつつ有る（　´_ゝ`）

専ブラ標準搭載携帯の登場はまだか

(´･ω･`)全体板が人大杉になるなら・それは喜ばしい事(´･ω･`)ノ

だいたい時間によって負荷だって違うわけだし

ひろゆきはやっぱり永遠の17歳だな

まず何を目的に何をしているのかを見失わないことが大切だと思う。
データが　a)２ちゃんねる　-> u)ユーザへ直接流れていた太古代。
それでは溢れる(※１)ということがおき、次の段階へ、
a)２ちゃんねる -> b)黒山羊さん -> c)c.2ch.net -> u)ユーザ
このとき b)は c)以降がどうなっても a)に何も影響を及ぼさなくするという防波堤の
任を負わされたんだな。そして今回それが正しく動いているということが初めて
検証されたんだな。あくまでも c) を動かすためのシステムではなく
「b)以降がどうなっても a)に影響を及ぼさない」というシステムを作るのが目的なんだな

※１ = サーバというのは最後の一滴で溢れるもので、溢れたあとは全てが動かなくなるんだな
容量100で 99,100 までは動いているけど 101になったとたん今まで動いていた100すらも失うのだ。

そしてこの状況は２ちゃんねるには何度も訪れているいつものことなんだな
その時々いろいろな方法でクリアしてきたんだけど、
一番みんなの記憶にあるのがたぶん2001年八月だとおもう。
そのときに取った方法は、ご存知の通り名誉ある撤退。
一度規模を縮小して(外部に負荷を押し付けて)勘定の合うモデルにしてから
再度スケール拡大という方法を取ったんだな。

勘定の合う形にしてからでないとスケール大きくしたら
傷は深まるだけだと思う、破綻するともいう。

んで　a) -> b) -> c) -> u)　の場合はどうするかというのが今回のテーマになるかと、
試行錯誤をするにしても目的をあやまったら管理人も本(※２)の中で言っているように
「局所最適化」をやってしまっちゃったりするのではないかと危惧しておりまして
私は本筋論を展開して行こうと思うのだ。

本(※２)　= ２ちゃんねるはどうして潰れないのか?

>>432
> 勘定の合う形にしてからでないとスケール大きくしたら
> 傷は深まるだけだと思う、破綻するともいう。

さて、それをどうするのがいいのか。

●の時は「二度とやるもんですか」(本人談)っていう人が
どこかから現れたわけですが、
今度はチラシの裏あたりから何かが現れたりするんだろうか。

っていうかこの議論ってようは、その昔にaccuseでやっていた、
(当時私はaccuseにはほとんどいなかった)、
「明日はどうなる？働け！ひろゆき」シリーズの再来ってことですか。

>>416 のLove Affair作戦は2004年(今から三年前)にはじめたんですが、
part1の冒頭で「何をするか?」を決めています
それは「キャッシュで解決を計る」です。
当時のアクセス数と現在を比べると、たぶん10倍(?)になっていると思うのですが
つまり現在はいくらa)２ちゃんねるのサーバ能力が向上したとはいえ
いままでのキャッシュの能力(bの能力)よりも劣っているものの開発は
なんの解決にもならないでしょう。つまり劣っているものを作るならBG黒山羊さん(b)を
増やすほうがとってもいいと思います。なぜならキャッシュの性能とは
転送量の抑制もさることながら転送回数も重要なファクターだからです。
今、現在で言えば断然後者のアクセス数の抑制が２ちゃんねるのサーバを救う効果があります。

キャッシュで解決を計る。
キャッシュの性能をよくする。
が目的を達成するための道筋ですなぁ

では、BGを使っていない現在の方式は
BGを使っていたころと比較してキャッシュ効率はどうなの？
無視できないほど効率区悪くなっているの？

ということで、現在やらなきゃいけないのは
高性能なキャッシュの製造＆実装＆性能試験かと、
100,200,300なんて話じゃ駄目なのよ。
ライブなスレッドは全てキャッシュできなきゃさ

時間になっちゃった。
続きはまた。

<チラシの裏>
>>438 の話って、新宿のデ○ーズで管理人とSunOSさんとで
熱く話した内容だよなぁ、、、。
</チラシの裏>

たぶん、既存の戦力を緊急投入したら
(たぶんばんそうこうを貼るぐらいの効果しかないでしょう)、
きっとそこから始めるんだろうなと。

まぁ，今の c-* の能力だけだと，ライブスレッド全部キャッシュするとディスク I/O が追いつかないでしょう．

>>46
>RAM をもっとたくさん積んだ鯖を導入してメモりキャッシュ領域をもっと拡大するとか，
>あるいはディスク I/O の性能の優れた鯖を導入してディスクキャッシュを使えるようにするとか，

というのが前提じゃないかなぁ＜ライブスレッド全部キャッシュ
あるいは，今の鯖でも台数を増やせば，1台あたりのリクエスト数が抑えられ
ディスク I/O が追いつくかもですが．

質問です
>>371って可能ですか？みんなで同じキャッシュを溜め込むのは無駄ですよね。

携帯を隔離するという考え方はもう時代に合わないのでは？
携帯が少ない中でその数が増えてたから隔離したけど
もうPCと携帯を差別するような時代じゃないでしょう。

携帯のアクセス増加で掲示板サーバーが苦しくなるのは仕方がない

ヽ(^o^)丿

>>371 をやるとすると，

1. ロードバランスの段階で URL に応じて振り分ける．
2. キャッシュファイルをリモートから参照可能にする．

のいずれかの手段が必要ですね．1. をやるとすると，ロードバランスの手段として
DNS ラウンドロビンや MAT(DSR) は使えないということになりますね．
HTTP レベルでロードバランスすることになりますが，
そうなるとロードバランサがボトルネックになりそうな悪寒......

2. については，Squid なら ICP のような仕組みがありますが，
自力キャッシュならそういう仕組みも自分で作ることになりますね．
NFS が使えれば比較的簡単かも知れませんが，事実上使えないので
独自にいろいろ工夫して実装しなければならない，と......

>>442 携帯が，通信速度の面でも（CSS や JavaScriptなどの）処理能力の面でも
PC とほぼ同等になれば，それもありだとは思いますね．

鯖の数が増えていくと2chへのアクセスも増えていくんですかねぇ？
内部でキャッシュするものと、全体の為にキャッシュする鯖があると
いい感じなんでないかなぁと思うです。

＞442
隔離というか専用ブラのように
Read/Writeの分離じゃないですかねぇ？

>>446
昔話に出ていた外部鯖向けキャッシュ鯖白山羊さん？

＞447
ではなくて、鯖内部と、システム内部でってことです。
がっくしは、中央鯖がdatのありかを持っているです。
このシステムであれば、黒山羊さんがしっかりキャッシュするという感じで。

差分取得に成功した時は、HDDへの書き込みも
差分だけを追記(アペンド)するように出来ないの？

そうすればディスクI/Oは減りそうだが。

│今のc-*はフロント兼BGなのだ
│
│フロントは他のフロントが持っているキャッシュ内容を認識でいていないから
│重複キャッシュが発生してキャッシュ効率が悪いのだ
│
│キャッシュ効率を高めるために重複しないようにするのだ
│どうやって？　←＊今ここ＊
│
│キャッシュの重複を無くすとキャリア別は止めることになるのだ
↓それは問題ない？　←＊こっちが先でも可＊

1)全部にc-foo、個別にc-foo1. c-foo2. c-foo3. …とでも名前付けてキャリア別を止める

2-1)板とc-foo*の対応表を各フロントが持つ（例　operate<>1）
他の板へのリンクは対応表を参照してc-foo*の部分を決める

2-2)他のスレへのリンクはスレキーの末尾を参照してc-foo*の部分を決める
スレ一覧が全部http://c-foo*から書くことになるから地獄か？

>>450
フロントはsubject.txtのみを保持し、スレッドを一覧まで出す。
バックエンドはdat表示のみ行う。
フロントのスレッドへのリンクはkeyに応じたバックエンドのurlとする。
バックエンドに担当外のkeyのurlが来たら有無も言わさず担当者にリダイレクトする。

ってのはどうかな？

>>445-446
ちょっと言葉足らずだったですね

キャッシュするサーバー(現在はcのフロント)を増やせば
掲示板のサーバーに負荷が増える、それは仕方がないこと。
キャッシュ効率の点で、BGのようなものがあるのがいいのは分かるけど、
そうするとBGの処理能力が問題となる。(←まさにこの前までのc.2ch.net)

携帯ユーザーが2倍になったとして、キャッシュしてる鯖を2倍にすれば
掲示板サーバーにかかる"携帯分の負荷"は2倍になるけど
c.2ch.netのおかげで"携帯分の負荷"がそもそも大幅に圧縮されてるから
それが2倍になったところで、そこまで重大な問題にはならないはず。

>>383の指摘のとき、掲示板サーバーのLA、アクセス、トラフィックのグラフをチェックしたけど
はっきりわかるような差はなかったし、今のままでフロントを増やしてもそんなに問題はないのでは。

でも、>>451の案がなかなかよさげ。

私の頭は単純なので
>>36 に書いたように

> 同じくらいの値段のにリプレースしても
> かなりパワーアップ(´∇｀*)って思うけど、

て事で、管理人さんに現状の倍くらいのスペックの
サーバーを買ってもらって、10台総入れ替え〜しか
思い浮かばないです。それでまた3年持てば良い方かな…とか。
これって面倒なのかな？

しばらく皆さんの素敵そうなご意見ROMってます。

寺務さんの耳がおかしくなっちゃうよ＞＜

＞452
いやぁ、単に鯖を増やすだけならしかたない、
じゃなくて無駄ですよってことです。
BGがBGである必要もないし。

フロントもバックもいらなくて、
何かしらの方法（KEYの下1桁？）で担当を割り当てて、
自分が担当じゃなかったら担当にLocationするのではないかなぁと。
ただ、この方法だと、特定スレに集中する場合に耐えられないので、
フロント＋BGが1鯖に入っていて、
連動した方ががいいんじゃないかなぁと思うです。

あと、担当があぼーんしたときのことも考えないといけないですね。
まぁ、リブートするまで我慢というのもありですが。
どうせなら冗長構成目指して、アサインテーブルを再構築できた方がいいじゃない？

>>455
無駄なのは分かりますけど、
キャッシュの効率を優先するためにキャッシュサーバーの負荷が高くなりすぎて
携帯ユーザーの利用に支障をきたしては意味ないと思うんですよ。

Love affair 作戦は、掲示板サーバーが守られればいいという
考えのようですけど、それはもう違うんじゃないかなと思う。
携帯ユーザーに立っていろいろ考えるほうにも少しは移していいと思う。

もちろん、キャッシュの効率を落とさずにキャッシュを持つサーバーを
うまく分散できるならそれは素晴らしいこと。
datキーで担当を決めるのは良い案だと思います。

＞457
while(1)

ローカルキャッシュして重くなることより、
2chにアクセスが増えることの方が意味がないと思う。
それなら、べっかんこやがっくしで十分機能しているんだから、
c2chは撤退すればいいんじゃない。
と、これは極論ね。

あれこれ言ってもしゃーないので、
ここを直したら直るとかじゃなくて、
理想の仕組みを作る方法でも考えましょうや。

って考えるとやっぱりがっくしだなぁと考えてしまうｗ