2ch特化型サーバ・ロケーション構築作戦 Part27
レス数が1000を超えています。これ以上書き込みはできません。
2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
前スレ:
2ch特化型サーバ・ロケーション構築作戦 Part26
http://qb5.2ch.net/test/read.cgi/operate/1183341095/ >>931 はたぶん、
1) フロントのサービスを監視する常駐プロセス
2) そのプロセスからイベントドリブンに起動される切り離し(または復旧)スクリプト
っていう感じになるんだろうなと。
2) はお手製のシェルスクリプトとかPerlスクリプトでいけるんでしょう、きっと。
1) をやってくれるような、いいプログラムはないものか。
きっとあると思うんだけど、あまり調べてないですね。
/usr/ports/sysutils/ の下あたりをあさってみると、何か埋まっているかも。
ということで私はちょっと早めの時間切れ、、、。 >>925 むしろ逆に,罠のある academy6, science6, 2chplus の各鯖の test/.htaccess で
RewriteEngine Off
という設定を入れれば全鯖配布用 .htaccess で mod_rewrite の設定が
可能になると気付いたので,そうしますた. >>933
なるほど、そのほうがよさげですね。
で、7.0Rはとりあえず順調の模様。
◆サーバー(鯖)を増強したいという夢を現実に反映させるスレ◆
http://qb5.2ch.net/test/read.cgi/operate/1207379976/389-
・gccが上がったせいか、オプティマイズするとofflaw.cgiが動かなかった
ぐらいか。これはきっと64bit版でもいろいろあるかも。
あとはこのへんを改めて読む感じか。
http://qb5.2ch.net/test/read.cgi/operate/1207379976/443
> http://www.freebsd.org/releases/7.0R/relnotes.html
> http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf > http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf
を慌てて読んでみましたが、なかなかよさげで。 < 7.0R >>934
> ・gccが上がったせいか、オプティマイズするとofflaw.cgiが動かなかった
ものはためしということで、-O とか -O2 をはずしてみるとか。 > 某所で64bit OSで苦労しているかた 一連の >>933 関連の作業の結果
これまで行ってきた「常連のねらーはせんぶらへ言ってちょ」が出来なくなってしまった。
ということはこれからは負荷は上がる一方でなすすべなしということっすなぁ。
みずから破綻への道を歩み始めたってことだす。 >>939
本当にLAが高くてやばい時は、差分取得以外を人大杉に飛ばせばいいような。 って専ブラも弾いちゃってダメか。
DOM Storage使ってブラウザでもログを保存するようにするとか。
http://developer.mozilla.org/ja/docs/DOM:Storage >>939
今度はその状況で「なすすべ」を考えるのがFOXの仕事だべ FreeBSD-EN-08:01.libpthread
http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc
6.3Rのマルチスレッドは虫入りだったですか。
# 雪だるまは思い切って全部7系にするかな。 あ、でも、
>>943
> On some systems, using libthr instead of libpthread, via the libmap
> configuration file libmap.conf(5), may be an acceptable workaround.
だから、大丈夫なのか。
2ch のマルチスレッドなサーバは基本的に全部 libmap.conf 書いてあるんで。 >>942
だすなぁ
>>943
そんな流れですなぁ。
7.0R 64bitでの実験を見たらGoって感じかな。 >>939 少なくとも,read.cgi 停止時にはサーバサイドでの dat -> html 変換は
行われなくなるわけですが,「破綻への道」というほどのインパクトがあるのでしょうか? うん
2ちゃんねる利用者(正確にはPV)の八割方が専ブラを使っていて
それが今後専ブラに移らないということは・・・
その比率はどんどん下がっていき、ダウン必至かと、
何言っているかわからないかもだけど、そんな感じです。 あっと
「read.cgi は2ちゃんねるの発展のためには動いていないといけない」という
縛りがあります。人が来なくなるというか来る術がなくなるというか、
これを言わなくきゃまったくわけわかんないっすね。 > 2ちゃんねる利用者(正確にはPV)の八割方が専ブラを使っていて
> それが今後専ブラに移らないということは・・・
??? 使っていなくて? 利用者100人として
IE=係数1 専ブラ=係数0.2 として
今は8割が専ブラなら IE 1*20 専ブラ 0.2*80 で合計36の鯖稼動
今後反対になれば IE 1*80 専ブラ 0.2*20 で合計84の鯖稼動
つーことが言いたいわけだな>>947 >>949 「使っていて」なんです。人数比率じゃなくて、PV比率でってことなんだな。
read.html は負荷は劇的に下げる良いものなんだけど、
グーグル等検索エンジンにはいっさい載らなくなるのだ
つまりこのまま行けば人は来なくなる→負荷対策がいらなくなる
というふうに私の目的からは全くはずれてしまうんだなぁ
今までやってきたことは、クローリングにも耐えられる状況を作る
そしてクローリングしてもらう→人口増→はじめに戻る
耐えられる状況を作る方法として
サーバ等の能力を高める
常連さんは read.html を含む専ブラへ行って貰う
だったのだった
>>951
えーとつまり、手段が目的化してて、本当の目的が達成されてしまうとやることがなくなると。 となると、高負荷に耐えられる鯖の導入と、ユーザーが使う専ブラの特典を視野に入れていかないと、
ある意味で無理が来てしまうんじゃないかな、と。 >>951 検索エンジン対策という意味であれば,人大杉時にはロボットが read.cgi に
アクセスしてきても「人大杉」ページにリダイレクトするというのは同じなような.
ちなみに,一連の mod_rewrite 設定は,あくまで人大杉時 (read.cgi 停止時) に
read.html に振るというものであって,read.cgi 稼働時はそのまま read.cgi が動きます. 検索エンジンにはdat内容をRewriteエンジンで返すようにすれば
1-100・l50など関係なくスレ内全部がクロールされるし
read.cgi起動しまくりにもならず、いいんじゃないの つまり人大杉になることがない状態では専ブラ導入のきっかけが無いわけだ 要は,検索エンジンにはちゃんと引っかかるようにして,
なおかつ一般閲覧者による read.cgi 起動はできるだけ抑制できるようにしたい,
って話かな? >>962
かつ設備が破綻しないようにしたい
なんちゃって、
今だいたいサーバ100台でしたっけ、、 検索エンジンへの入り口を用意するという考え方はダメなのかしら。 サーバ台数が増えれば機械のコストも増えるけど
それ以上にお守りが破綻すると思う。
既にという話ですが、 サーバリフレッシュだけを見てもローテーションに要する
時間が1年を超えたらボーンか。 googlebotの一定確率でのキックって、既に実装されていたりしますか。 秘密の花園 500番地
http://qb6.2ch.net/_500/
早速、対抗手段ですか。 対抗ってのは変ですね。対応、対策?
とりあえず、従来と同じことは継続すると。 500よりは503返してしまった方がいい気がしました。 う〜ん,read.html に振るのは一応管理人さんから言われてやったことなので,
どうしましょうかねぇ...... googlebotのみ一定で振るのは無理なんですかね。 >>972
いろんな人がいろんなことを考え、
そして、それぞれの思いを込めてアクションを起こす、
ということなのではないかなと。 某所のqmailが64bitでうまく動かない、は、
たぶんこれな予感。というか既に発見されている模様ですが一応、、、。
ports/118117: mail/qmail broken on amd64 -- fixed
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/118117 live23 で「人大杉」発動なのは、意識的なんですかね。 とりあえず私としては,「一連の作業に問題があったなら,その指示を出した人と話し合って下さい」
ということで対処したいと思います...... 専ブラを使っている身としては、人大杉は専ブラを使う理由では全くないです。
一般のブラウザより便利ってだけ。それはread.jsでも変わらず。
実際、普及しだした頃に人大杉なんてなかったじゃん。
管理人は専ブラに特化するのを嫌っているようだけど、
少なくとも、移行を促したいなら一般ブラでの利便性を低下させるんでなくて
専ブラの存在の周知を図るべきでしょ。 >947
専ブラが便利すぎてアクセスが増える(こともある)ってのが管理人の持論だったかな。
負荷が減る分とのプラマイがどうなるかは知らないけど。 「べき」は前提条件における、もう一方の方策との対比にかかっている。 read.htmlに「表示が遅い人は専ブラ使え!」ってPRしとけばいいとおもうよ >>975
ほかのdjbツールは大丈夫なのかしら?bb*絡み まぁ要は,管理人さんの意図(人大杉をなくす)と FOX さんの意図(検索エンジンに
インデックスされるようにしつつサーバ負荷を軽減)を両立させるような方策を考えれば
丸く収まる,ってことなんでしょうかね.専ブラも read.html も,あくまで手段であって
それを使わせること自体が目的ということでもないんでしょうし. ド素人の戯言ですが
ブラックゴートだかに、クローラを誘導するような仕組みではだめなんでしょうか。 >>狐さん
掲示板に戻る 全部 前100 次100 最新50
の下あたりにでも、
「専用ブラウザを使えば2ちゃんねるがさらに便利に!!」
ってリンクを入れて専ブラの周知を図ればいいんじゃね?
でも人大杉がなければ専ブラを使わせるインセンティブが低いのが問題だな…
例えば
http://janestyle.s11.xrea.com/oosugi.html
の説明みてもまず「人大杉」がありきだもんなあ。
壷の場合はさらにインセンティブが低いよなあ... IE6の場合だけ容赦なく従来の人大杉に飛ばす、とか まあ専ブラ板でも作ったら?
話題が無くて過疎りそうだが。 携帯電話なんかは、GWのIPアドレスが公開されていて、
そこからアクセスは特別扱いしているじゃない?
検索エンジンも同様にIPアドレスを開示させて、そこから
のアクセスだけはread.cgiで処理するようにしておけば
良いんじゃないかな?
google、Yahoo、MSNぐらいを囲めばシェア的に問題無さそう。
2chの影響力を考えると無視は出来ないはず…もし協力しない
所は"切る"という方針で良いでしょう。
それ以外の所もIPアドレスを開示した所は対応で。 >>994
良いアイディアかもですね。< 検索エンジンだけ特別扱い
で、次スレ立てます。 >>994
アイデア的にはいいと思うのよ。
でもgooglebotのおかげで従来で言うところの人大杉に成る程のアクセスがあるのならば
通常の訪問者が全員read.cgi以外で見てて検索エンジン系だけread.cgiていう状態にして
旧来の鯖が対処しきれるのか?という点を考えないと。
>>988が言ってるような他の方法も含めてね。
他社(検索エンジン系)を巻き込む(お願いする)のであればあんまし実験てわけにも。 だったら、各botのクロール頻度とか見たいかも。
それで見えてくる事もあると思うが。 このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。 レス数が1000を超えています。これ以上書き込みはできません。