【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part17
■ このスレッドは過去ログ倉庫に格納されています
peko作戦について語るスレです。 サーバロケーションPIEに関する話題もこちらで。 <現在の主要なテーマ> ・oyster243(BBQ/dnscache)の突然死対策&cobra2245セットアップによる2台体制化 ・oytser902(memories)のFreeBSD 5.3化 ・「雪だるま作戦」による、スケーラブルなサーバ群構築 ・read.cgi/bbs.cgiの細かな調整・詰め ・携帯サーバのプライベート側スイッチのグレードアップ検討 ・各種作戦・プロジェクトとの連携 ・FreeBSDのさらなるチューニング詰め <関連スレッド> ■新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!? Part1 http://qb5.2ch.net/test/read.cgi/operate/1105035540/ ■ 自動地震速報@2ch をつくろう http://qb5.2ch.net/test/read.cgi/operate/1106583619/ ■ テレビ番組欄@2ch をつくろう 第2話 http://qb5.2ch.net/test/read.cgi/operate/1107366393/ <関連サイト> レンタルサーバー maido3.com 2ちゃんねるの転送量: http://server.maido3.com/pie/ MRTGによる統計情報: http://mumumu.mu/mrtg/ 2ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html <前スレ> 【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part16 http://qb5.2ch.net/test/read.cgi/operate/1102087698/ たぶん設置場所の関係からラックマウント機器でないとつらいという制約もあるでしょうし、 そのうえ圧縮つきで1TB以上を確保しておく必要があります。 さらに>>610 でrootさんが言っているけどオートチェンジャーつきとなると sumaの数倍は●がとびまくりそうです・・・ >>621 の条件を満たすとなるとこれくらいですかねー 金銭的に極めてつらいでしょうね。。。。 ttp://www-6.ibm.com/jp/storage/products/tape/lto/3581.html ttp://h50146.www5.hp.com/products/storage/tape/ssl1016_sdlt/index.html >>622 どっちも200まんえんぐらいじゃのう hpのはFC変換ハブがいるから、もっと高くつくかの? >>624 ねだんはPolywell次第じゃないかのう 正規代理店として持ってこれるブツがあるなら値引きも期待出来るで、 でも、少なくともsuma並のねだんはするとおもうんじゃが ただたんに鯖を組むだけなら100まんえん以下で済むとおもうでよ ↓の2Uのケースに、てきとうなRAIDカードでも組み込んでミラーさせて (http://www.polywell.com/us/rackservers/poly2012ai.asp ) 大きいS-ATAHDD(今は400GBが最大)を何発か入れればそんなもんで済むべ でも、テープを持ち出すからには 何か鯖をたてるだけでは実現できないメリットがあるとおもうんじゃが、、 それはどんなんだべか? NetVault を使うとハードディスク上にバーチャルテープライブラリを構築できますが、 そんな事するくらいなら普通に pfsdump でも使った方がましですな memoriesもう一個立てて、半手動で同期とっとけばいいんじゃない もう、RAID-5でも0+1でもいいから、HDDで堅牢性を求めた方が安上がりで、楽な気がする。 もしくは、>627みたいに、鯖間でミラーリングするとか。 テープドライブまで使う必要があるのかどうか・・・。 各鯖の空きHDDをひとつのHDDとして見立ててバックアップに使うシステムとか。 あ、一個でもクラッシュしたらパーか つかえねーww >>628 すでにmemoriesはRAID5です 思いつきですがGoogle Inc.の中の人に相談したらいいかもね あそこは超優秀な技術者の巣窟ですから テープの利点というんは、メディアを持ち運び出来る点かのう、 データを管理人の手元においたり、ブラジルで使ったりとかも 可能になってくるんでなかべか、 利用法によっては鯖代の足しになったり鯖負荷低減になったりしるかものう あとは、巻き戻しポイントを複数用意出来るという点かのう 1ヶ月前のデータじゃとダメだという場合、2ヶ月前、3ヶ月前と さらに前のデータを用意出来るのは状況によっては有意義かも試練 …ほかに利点はあるべか、 memoriesの場合は導入直後にフルバックアップをとって、 その後は各種プログラムなどの仕様変更や新規収容があったときに 差分をとるやり方をすれば問題ないかと。 そういった理由でオートチェンジャーは必要性は薄いと思います。 で、メディアはJimさんが地理的に離れたところに設置した耐火金庫へ放り込んでおく、と。 root★さんいますか? bbs.cgi@ex10 を更新しても反映されないような仕様ですか? >>633 そんなはずはないですが、、、。 なんか、一時的に該当時間、何か様子が変だったみたい。 で、テープですが、入れ替えしないでとれると 手間がないかな、ってかんじで、チェンジャーつきがいいのかなと。 でも高いなら、チェンジャーはあきらめて、とる時はPIEに人がいて、 テープを差し替える、というのでも、十分な気がします。 上記を想定すると、オペレーションは、概ねこんなかんじかなと。 フルダンプ用のテープを2セット用意しておき(例えばAとBとする)、 1)最初にAにフルダンプをとる 2)次にmemoriesに収納があった時にBにフルダンプをとる 3)その次の収納の際にはAにとる、以下2)と3)を繰り返す これにより、一世代前のテープが常に存在するので、 万一テープにとっている間にSumaがクラッシュしたり、 間違ってテープを上書きしてしまっても、被害を最小限にとどめられる。 で、増分とってもいいんですが、今の更新頻度と手間を考えると、 毎回フルダンプをとっても、十分(たぶん、収納のタイミングでとるだけでいいから) なのではないかなと。 >>634 りょうかいですー < 前半 テープは見積もりとって見ます 携帯からスレ立てる事は出来ますか? 教えてください >>634 チェンジャーというよりもFC機のほうがねだんがたかいようじゃよ FC機の場合、小容量のは種類もすくないようで、 FC-SCSIブリッジとかいうんも、とてもたかいようじゃ。。。 >>635 工工エエエエエ(´Д`)エエエエエ工工 バックアップは日本全国で分散されて保存さえれてるってのはだめなの?w memoriesに収容されているのは.dat.gz, .html, .html.gzの3つで 他のもの全て(index.html, subject.txt)を含めても .dat.gzさえあれば復元できるはず。 で、全てテキストな.datの圧縮率を1/3程度と仮定すると 最大1.5Tあるmemoriesのデータでも 全体の1/5、つまり300GのHDD一台でバックアップできるはず と、暴論を述べてみる。 圧縮しての保持形態や復元作業の手間(時間ではなく手間)などを考えると そのまま保存できるテープ等のデバイスの方が良いことは間違いないんだけど。 >644 出来ないこともないですけどDVDの枚数と焼き時間がトンでもないことに(滝汗 DVD−R 1枚あたり約4G 1枚焼く時間 最速クラスで約6分 仮に1Tだとしたら250枚なので 6x250=1500分 約25時間(滝汗 しかもそこまで連続焼きにドライブが耐えられないと思われ テープにバックアップしたものを、リストアすることなんか 永久にないと考えたほうがいいですよ ただ、保存したという自己満足だけ 国内価格だけどこのクラスなら比較的に安くてテープコストも安いみたいです。 ttp://www.plathome.co.jp/detail.html?scd=11850316 >649 アメリカだとここまで下がってます。 ttp://www.costcentral.com/proddetail/HP_StorageWorks_Ultrium_215/C7492B/D33101/ >>642 分散コンピューティングか!! UDのHDD版。手間暇掛かりすぎな悪寒。 >>653 みんなのHDDをおらに少しだけ分けてくれ! こんにちは。 似たようなスレに投稿してみたけど、そこよりもこっちの方が活発なので再投稿。 2ch 第二投稿なので、いまいち投稿の仕方などの雰囲気がつかみ切れていないが。 提案としては、HTML 生成圧縮済のページを URL でハッシュして、メモリ上に保存。 以下、ほぼコピペ。 基本動作は if(URL を元に HTML ページのハッシュを生成と検索) { ハッシュテーブルからキャッシュを送信} else // 見付からない { HTML 生成、送信して、ハッシュに保存 } HTML 済の保存場所としては、 1. 一つのプロセスが常駐できるなら on-memory 2. mfs または tmpfs 3. local fs ハッシュテーブルは多段式にして優先順位を元に高速アクセスできる所に生成済ページを保存 アクセス数と最終リクエストによる優先順を保持して、1 または 2 と 3 を併用できたらいいとは思うけど。 新しくアクセスされたところは 1(2) に残り古いページは 3 に移って、そのうち消去。 記事の数やメモリの量にもよるけど読者が多いところに有効。 とっても大雑把だけど雰囲気ぐらいはつかめまつか? memoriesを2機にしてバックアップ兼負荷分散がいいのでは? >>639 お、そうなんですか。 それなら、SCSIカードを追加とかでいけるような。 今夜あたりに、適当に調達案をここにでも。 >655 DHT(分散ハッシュ)でググレ。P2P研究関係とか。 あと実績がある硬い仮想ファイルシステムじゃないと2chに導入するのはムズイような。 >>658 道楽には硬いものはいらないかとw で、できればSolaris ZFSを投入してほしいなあと妄想してみる >>650 おおっ 安いのう おらが>>617 で出したソニーのFCなブツもこうなっておる ソニーのブツは互換性が全くなさそうじゃからそもそもアレなんじゃが、 http://www.getplus.co.jp/product.asp?product=652039 \1,666,717(税込) http://www.costcentral.com/proddetail/Sony_SAITe1300FS/SAITE1300FS/C92636/ $7,683.60 >>657 Reffiさんがだしたサイトをみるに、FCモノ限定じゃと 少なくとも6000ドルはみたほうがよいようじゃのう おらには出せない金額ではない(虎の倍)ように思えるけんども、 そのへんはサンダルをこよなく愛するえらい人的にはどうなんだべなぁ? ところで、メディアの種類には拘らないのけ? 国内の関係者が使っておるブツと互換性があるブツを選べば 今後いろいろと(新しい)使いかたがあるとおもうんじゃが、、 >>659 とりあえず過去ログ読んで来い 偽FOXもな >>658 ふ〜ん、そんなのもあるんだね。 後でゆっくり読んでみるよ。 いいたかったのとはちょっと違う。 今は「 read.cgi がリクエストが来たら、各リクエストごとに dat から HTMLを生成している。」がいまの実装であっているかい? 違っていたら、この提案は意味なし。 read.cgi がファイルにアクセスして、HTML 生成をするのはかなりの作業だと思う。それを、一回毎に HTML を生成、破棄しいないでプロセスにキャシュしておくのはどうかというのが提案。 squid などで、試しているキャシュに似ている。 Apache が read.cgi を含むプロセスと、何らかの通信をするなどして、一つのプロセスが常駐する必要がある。 一段目のキャッシュとして malloc 等で割り当てたメモリに HTML を保存する。 そこに、URL が存在したら、それをそのまま socket に流す。 一段目のキャシュに無かったら、二段目だ。 こっちもハッシュの鍵はURL。 こっちでは、HTML ではなくて、生成圧縮済の HTML へのパス。 例えば、/var/tmp/read.cgi_cache_file。 これは、一段目のキャッシュが大きくなった時にファイルに書き込む。 IO が発生するが dat を読んで、HTML を作って、圧縮するよりは、速いはず。 二段目にも無かったら、dat を読むしか無いね。 HTML を作ったら今度は送信するだけでなく、一段目のキャッシュに保存。 しばらく経つと、キャッシュも大きくなるから、何らかの優先順位を決めて、一段目のは二段目に移動。 二段目のは削除。 キャッシュにハッシュ関数を使うってだけ。P2P のとは全くの別物。 仮定としては、メモリと /var/tmp (一時保存のHD)等は余裕があって、ユーザは書き込みよりも、読者の方が多い。 アクセスの多い板はある程度限られている。 >>662 メモリキャッシュ→ファイルのキャッシュ→従来の方法 っていうことですか。 こないだ、ミニ雪だるま作戦でちょっと試したやつですね。 こないだはread.cgiの出力はノーキャッシュでやったのでsubject.txtだけでしたが、 それでも2〜3割はメモリキャッシュからヒットしました。(旧ex7の場合) ということで、read.cgiでも同じことができるなら、 news系とかpc系とかのようにROMの多い板では、相当の節約になる気がしていたりします。 >>663 実況だとメモリキャッシュ、通常だとファイルキャッシュ重視の構成にするといいのでしょうかね。 そういう意味で膨大なキャッシュシステムを構築している、 それもクラスタリングはあくまでその補完でしかないGoogleってすごすぎですね。 できるならGoogleのエンジニアのお知恵を拝借したいぐらいでしょう>雪だるま作戦 >>663 そんな感じです。 既に実験済でしたか。 どこをたどれば、関連記事を読めますか? SpeedyCGI は別物ですよね? mod_cgidso による実装ですか? >>666 ありがとです。 スレと squid の FAQ を読んでみました。 基本的に考え方は同じですね。 ただ、いまいちわからなかったのが read.cgi で生成される記事です。 こちらの方も squid がしっかり効いているのでしょうか? CGI を通したページは最終更新日を調べられないので、キャッシュできないような気がするのですが。 >>667 read.cgiのキャッシュは、datのLast-Modified: を返すようにする、、、ってかんじにすればいいのかな。 セキュリティホール情報 ttp://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1286 >675 この修正後にリビルド推奨なのでかなり深刻なバグのようです。 655 です。 >>668 似たような試みは既にいろいろとされているんですね。 もしかして、邪魔なだけ? >> 669 655 です。 たぶん今のままでは無理かも知れないです。 設定を見直せばうまくいくかも。 こぴぺ ttp://squid.robata.org/ReverseProxy_top.html CGIスクリプトやアクティブサーバページズなどの動的なコンテンツはキャッシュする事ができません。 プロキシは静的なページのコンテンツのみをキャッシュできます。 4つの尤も重要なヘッダーのタグは: * Last-Modified: プロキシにページの最終更新日を知らせます。 * Expires: キャッシュからいつ削除するかをプロキシに知らせます。 * Cache-Control: いつプロキシにキャッシュされるべきかを指示します。 * Pragma: プロキシにページをキャッシュすべきかどうかを指示します。 http://squid.robata.org/squid2.0-conf.html TAG: hierarchy_stoplist このリストに記述されたワードがURLの中に見つかると、隣接キャッシュではなく直接サーバにリクエストを行います。隣接キャッシュを使いたくないオブジェクトのために使ってください。 このオプションは複数回指定できます。デフォルトは、'cgi-bin'と'?'を含むURLの場合に直接オブジェクトを持ってきます。 # hierarchy_stoplist cgi-bin ? >676 英語FreeBSD MLのnectarの投稿もよまずにあいまいなこと書くなよー。 スラッシュドットにもストーリーあるよ。 telnet使ってなければ言うほど深刻でもない。 >>675 ユーザランド(telnet)のみですね。 ぼちぼちやればいいかなと。 >>677 いや、意見・コメント歓迎です。 次の手はそのへんかなと思っているので、とても助かるです。 ざっと読んできた。 怪しいところにtelnet なんちゃら 25とかtelnet なんちゃら 80とかいうのは意外とやってるから、 気をつけるに越したことはないってかんじかなと。 ジンギスカン仕様のサーバが止まったり移転したり飛んだりする度に 設定が飛んでしまうのは何とかならないものでしょうか。 名無しやローカルルールは再依頼してもらえば済みますが、 スレ立て規制のホストリストまでリセットされていつもクソスレが大量に乱立します。 (スレ立て規制値はかなり厳しいのですが、これじゃ意味がない) 書き込みはサーバが飛んでも消えないように、ホストリストも同様にしていただけるとありがたいのですが。 >>682 もう、おじさんが直したんじゃないかな。 >スレ立て規制のホストリスト これはやってないような・・・ こんどやろう /etc/make.conf はいじってるのかな? 超簡単なベンチマーク・・・ dd if=/dev/zero of=/dev/null bs=1024 count=2000000 とりあえず、雪だるまなしの状態のcobraでは -M64あたりが中庸を得ているみたい。 tigerものびを見ていると、-M48あたりが中庸な値かも。 たぶん雪だるま化した時は、今の-M128とかでもいける可能性も、あるかも。 read.cgi にリミッターつけて 128の方が良いに一票 live16/live20 を -M64 => -M48 ex10 を -M128 => -M64 にそれぞれ変えた。 ex10が重い重い重い重い重い重い重いoyster902 http://qb5.2ch.net/test/read.cgi/operate/1111933915/176-180 >>687 やっぱ、それでいきますかねぇ。 個人的にread.cgiにはリミッター、入れたくないんですよね。 んじゃ、今日の様子見て、ex10はLA=30、live16/20はLA=20ぐらいでリミッター入れることにしますか。 ex10 >>689 にしてきた。 live16 と live20 は、これから変更予定。 で、-M128と-M64に戻してきます。 で、ひとつ提案なのですが、今回の負荷試験が終わるまでは、 わたしにめんじて、狼のTYPE2と一連のSamba/timeclose/timecountも一時的に解除しませんか。>>687 どうも、人が多いんじゃなくて、単なる連投板みたいですが、 それでもセッティング出しには、やはりご協力いただきたいのです。 live16 / live20 を、LA=20 で人大杉がかかるようにした。 これは他のtigerと同じ値。 >>692 他ですか。 やはり、例によって1ピースを少なくする路線なのかなぁ。 というか、ほんとは人が少ないってわかっちゃった以上、 もう「ブレーメン」という単位が出来た頃の、あなたじゃないってことなのかもね。 >>694 >>691 ほんとは人が少ないんだとすると、解除は、、、ないかな。 ちょっと、さみしい気もするけどね。 >>695 単なる連投板じゃないかもしれません 474 名前:動け動けウゴウゴ2ちゃんねる[] 投稿日:2005/03/31(木) 22:16:29 ID:cbsbJk4L0 狼は連投が激しいとかいうけど120秒規制になった時 VIPも狼並みに書き込み数減少した Apache2はIntel Compilerだとかなり高速化されるそうだ。 でも商用Webサーバーで使っているとライセンス的にはどうなんだろね。 >>696 どうも。例のpoundでURL見て振り分けるってやつですか。 考えてみる価値は、あるのかも。 あの頃よりも、だいぶいろいろなことがわかったので、 いろいろ研究してみる価値は、ありそうですね。 >>698 iccですか。 FreeBSDは、サポートされてるのかしら。 ところで、>>687 は、次のステップも見ているのかなと。 ああ http://qb3.2ch.net/test/read.cgi/operate/1068017802/816 これ書いたの俺か。 >700 いちおうportsがlang/iccにあります。 ライセンス周りを手動で手続きしてdistfilesにもってくる感じで。 新米のでいまいちつかめていないところが多いです。 どのスレを見ればいいのかわからなかったり、古くて信じればいいのかわからなっかったり。 指摘して頂いたり、ポインタなどを示してくれると助かります。 >> 696 ちょいと返事がおかしいですけど、Linux の noatime は *BSD よりもはずです。 Linux は非同期書き込みしかできないから。 今でも、サーバは全て noatime で運用しているのでしょうか? softupdate だと noatime よりも遅くなるが、/root を小さくしておくと、 FreeBSD 5 系は fsck を後ろで動かしつつ、システムが動きます。 そのため、起動がとても早い。 noatime では無理じゃないかな。 をを、いかなきゃ! マルコフ連鎖で自動生成された文章かな? /rootってのは/のことか? background fsckとnoatimeの関係性について何を言いたいのか良く理解できん。 >>703 noatimeは実施済みです。 ttp://qb5.2ch.net/test/read.cgi/operate/1105035540/86n いちおうマジ解釈すると、703はasyncとnoatimeを混同しているってことなのかもね。 ext3よりもUFS2(+softupdate)は全然良いFSだと思う。 >>706 softupdateといえばcobra導入当初disableだったにもかかわらず実況に耐えたという伝説がありますな。 >>706 の指摘通り async と noatime を間違っていました。 ご指摘ありがとう。 KeepAliveTimeout 10 => 5 を、live20とex10で実験開始。 一時期入れようと思った、mod_dosevasiveあるいは相当品を、 また考えるべきなのかしら。 PHPに脆弱性によるバージョンアップがあったようです。 p2.2ch.net不具合報告スレ http://qb5.2ch.net/test/read.cgi/operate/1108723551/908 ソース ttp://headlines.yahoo.co.jp/hl?a=20050403-00000007-zdn_ep-sci 公式アナウンス ttp://www.php.net/release_4_3_11.php >rootさん、じじい その4さん 今きがついたのですけど、 server select http://www.mediaselect.co.jp/ss/ 来月号でバックアップソリューションの特集組むそうです バックアップの件はこれのトレンドをみて判断するのも一興かな、と >>719 ちょっと面白そうな雑誌ですね。 さて、RELENG_5_4が出て5.4-RC1になったので、 ぼちぼち、5.4Rへのバージョンアップの準備をすすめようかと。 で、今回一番めんどいのは上の方でもちょっと出たけど、これかなぁ。 5.4Rになったこととは直接には関係しないけど、影響でかいし。 20050201: AFFECTS: users of lang/perl5 and lang/perl5.8 AUTHOR: tobez@FreeBSD.org lang/perl5 has been updated to 5.6.2, and lang/perl5.8 has been updated to 5.8.6. you should update everything depending on perl, that is: * first, upgrade your perl installation (use either lang/perl5 or lang/perl5.8, the latter being recommended); * for FreeBSD 4.X, run "use.perl port", so that the system knows you have 5.8.6 or 5.6.2; this step is not needed on FreeBSD 5.X and FreeBSD -CURRENT; * run some magic incantations to upgrade all ports depending on perl, that is run something like : portupgrade -f `(pkg_info -R perl-5\* |tail +4; \ find /usr/local/lib/perl5/site_perl/5.[68].[1245] -type f -print0 \ | xargs -0 pkg_which -fv | sed -e '/: ?/d' -e 's/.*: //')|sort -u` This is likely to fail for a few ports, you'll have to upgrade them afterwards by hand. ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる