【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/ 21代目実況鯖か。 というか退役した実況鯖っていくつあるんだ? >>345 少なくともmemtest必須ですかねー rootさん大変みたいですね。がんがってください。出来れば早く復旧しますように(-人-)ナモナモ >>350 (私調べ) liveサーバは14,15,16,19,20が稼動中。 よって退役サーバは15? >>350 live14…ニュース実況++ live15…なんでも実況(ビーナス)、実況せんかいゴルァ!@実況ch、番組ch、BS実況ch(NHK)、BS実況ch(民放)、実況スカパー、ラジオ実況、実況せんかいゴルァ!@スポーツch、お祭り会場 live16…なんでも実況(サターン)、番組ch(NHK)、番組ch(NTV)、番組ch(TV東京)、オリンピック実況(女) live19…市況実況2 live20…なんでも実況(ジュピター)、実況(NHK教育)、番組ch(TBS)、番組ch(フジ)、番組ch(朝日)、実況せんかいゴルァ!@やきうch、実況せんかいゴルァ!@芸能ch live18・・・臨時地震、臨時地震2 もね。 あとlive19には株式、投資一般、ネトゲ速報、ネトゲ質問、ネトゲ実況、2、3 live14にはニュース二軍+、大河ドラマもあります たしかに本当に本人だったら問題でしょうが、偽者の可能性もありえますなw 弁解があれば以下でききましょか 質問・雑談スレ114@運用情報板 http://qb5.2ch.net/test/read.cgi/operate/1111418807/ まずは切り分けのために、Apacheの起動をやめることにしよう。 (Apache起動のとたんに死んだので) ということで、今夜もし私がオンラインでない時にPIEで対応、ということになった場合、 以下のオペレーションをお願いしてもらえると、とても助かります。 (同じ文面をJimさんとSeanさんにメールしておきます) Jim-san, Sean-san, I want to determine the cause of the trouble of tiger503. I suspect that the cause of trouble is my bad apache configuration because when I started apache manually, the system has been down. So, if you can, please do the following operations. It disables Apache server autostarting. 1) Reboot tiger503 as single user mode. 2) Remove Apache startup file, as follows. rm -f /usr/local/etc/rc.d/apache2.sh 3) Then, reboot the system. After the system has been up, I will fix the problem remotely. Regards, >>371 了解 それにしてもクンニしたい・・・・・・ >>372 エッチなのはよくないと思います(><) >>372 我慢は良くないです。忙しくなる前に逝ってきてください。 http://qb5.2ch.net/test/read.cgi/operate/1107376477/372 372 名前:ピロリ[sage] 投稿日:2005/03/24(木) 22:05:35 ID:vNTaqkB+0 >>371 了解 それにしてもクンニしたい・・・・・・ >>372 ,/|_/|⌒`゙ヽ,, cミ、゙゙/と,,,,,と)彡 規制しますよ `´ フィリピンでおかしくなって帰ってキタ━━━━━━(゚∀゚)━━━━━━ !! 軽くなった原因をdeflateを止めたからだと「結論つける」ならば、 すでにCPUの能力が限界であると結論づける事になると思う。 ということはこれ以上の容量(キャパシティー)増加は見込めない。 費用対効果では Tiger の方が上である。 転送量で騒いでた時期もあったけど、 最近は負担のほうが問題ですかあ。 2ちゃんねる君も成長したものです。 http://homepage3.nifty.com/aona/archive/modelnumber_table.html モデルナンバから考えるに、opteron242は2800〜3000相当じゃろうから こんなもんなんじゃろうのぅ セールストークに出てくる電気代云々はこの場合関係なさそうじゃし、 メモリコントローラ直付けはかなり効いておるようじゃが、それならば 安いSempron(32bit)でも効果は同じように(比較対象がPen4になるが) 出てくるはずじゃ 高いopteronを使う必要はないのう 負荷の一種かも知れないけど、 最近ボトルネックというかコストが一番高いのは 「電気代」の事態になりつつあるように思える。 CPU負荷の最大の原因がmod_deflateにあるのならば 圧縮率を下げることで、 mod_deflateによる負荷は1/2-1/3程度まで下げられるはず で、 .datの差分取得をするクライアントは、 Accept-Encoding:gzipを送らないので、mod_deflateは関係ない。 問題は、各種HTMLを取得するクライアント(汎用ブラウザ)、及び subject.txtを取得する時 .datを全取得する時 に、mod_deflate経由の圧縮が有効になること。 まさかc.2chが.datを取得する時に圧縮することはないだろうし とりあえずsubject.txtかな。 あと、確かsquidはVary:Accept-Encodingに対応しているはずなので squidが圧縮後のデータをキャッシュしてくれているのなら効果あるかも。 >>388 AMDのHammar系列はIntelのNetBurst系列よりは 消費電力が低いはずだす …なんか現状は、ディーゼル車がガソリン車より値段が高いようなもんなのかのう、、 >>393 電気代と比べるのは 場所代とか回線代とかです つまり総コストに占める割合のはなし、 >>384 費用対効果ですか。 oyster901は現在メモリ4Gなわけですが、これのメモリを8Gに増やして 真の力(仮)をしぼり出させるより、玉数を増やす(例えばメモリ2Gのtigerを2つ入れるとか)の ほうがいいかもとか、そういう話も含めて、考慮することになりますかね。 あとOpteron242(2004年1月当時としても相当下の方のOpteron)は、 Xeonのいくつぐらいに相当するのか、とか。 最近のOpteronなら、もっといけるのかどうか、とか。 あとは、amd64版のコンパイラの出来とかも、ありえるのか? あるいはamd64は、圧縮・展開が実は不得意だったとか。 >>388 電気代の件 そういえば、4月に出る(遅れているようですが)FreeBSD 5.4Rから、cpufreqという機能が入るみたい。 20050225: The cpufreq framework has been merged. As part of this, the sysctls for acpi(4) throttling have been removed. See cpufreq(4) for the new sysctl interface. The power_profile script has also been updated, so you can use performance/economy_cpu_freq in rc.conf(5) to set AC on/offline cpu frequencies. No new cpufreq drivers have been brought in with this import but drivers from -current can now be built and run on -stable. 電気はCPUが消費しているんじゃなく たきさん着いているFANのような・・・ >>392 で、これ面白いので、やってみるです。 今日寝る前に、subject.txtだけ圧縮しないようにしてみます。< ex10 ex10 は専用ブラウザ率が高いし祭り率も高いから、subject.txt 読まれ率が異常に高いと推測。 >>384 の一行目は皆さん肯定しているんですか? 寒くて地価が安いところに鯖群をおく時代が来るんだろうか ProjectectRussia? >>392 ぶっちゃけた話、IEだけでもdat2htmlアドオンがあるだけで違うと思うけど、 アドオンの開発の仕方をしらんのでつくれませんのでこの話は霧散しますた >>397 えっと、ファンのコントロールとかもあるですね。 きょうびの機械はCPUをゆっくりにすると、それを感知してファンもゆっくりになったりするです。 >>399 個人的には、圧縮かかっている回数が他のサーバに比べて異常に高いんではないかと推測。 で、>>398 というか、温度を見てファンがゆっくりになったりするですね。 CPUがゆっくりになると、温度上昇も少ないわけで。 そういえば以前(去年だったかな)、 低消費電力バージョンのOpteronの搭載を売りにしている1Uサーバのメーカが、 私の知り合いのところに、売り込みに来てたです。 最近はサーバファームも、エコロジーの時代だと言っていました。 つまり 軽くなった原因をdeflateを止めたからだと「結論つける」ならば、 を否定したいだけだったり、 これを肯定するなら本当に結論はでてしまっているよ >>404 私も、それじゃつまんないなと思っています。 で、>>395 の第3パラグラフとか、ex10 は他と比べて圧縮され率が異常に高いんじゃないかとか、 いろいろ考えていたわけです。 確かに deflete はそれなりにコスト高いもののひとつだとわかったわけですが、>>304 に立ち返ると、さてどうなのか。 >>397 6800rpmモノじゃとファン1個当たり0.5Aとか喰うからのぅ >>403 246だすか? アレならメモリも今のより早くなりますのう、 DDR400が使えるだす 「deflate を止めたら軽くなった」は結論の根拠なんかじゃなく 問題解決への糸口だと言ってくれ〜 もしくは勘違いだったと、 で、これまでの実験から考えてみると、 ・HDDはまだ天井を見ていないようだ => まだのぞみがある ・メモリを増やすと、効果は望めるのか => 仮にメモリを8Gとかにしたとして、どのようなチューニングを施すべきなのか つまり、増やしたメモリをどう使うのがいいのか。OSにまかせるのか、あるいはセッティングを変えるのか といったところが、要検討な点、、、なのかしら。 oyster243が今たまたま使われていないので、一時的にメモリをひっぺがして、 数日だけoyster901に入れてみるとか。 >>406 cobra はそんなのが 10個とか20個ついているんじゃなかったかなぁ tiger も結構なもんです >>399 データがCPUに行って圧縮されて戻ってくるなわけで上り下りで2倍の 帯域を使うわけでバスがネックになってるとか思い付きを書いてみる >>407 さて、問題解決の糸口だと言うためには、それなりの裏づけが必要なわけです。 で、どのあたりにその糸口があるのか。 たぶんそれは、次以降の実験フェーズで明らかにしていくべきなんではないかと。 「deflete を止めたら軽くなった」という事実がまずあった。 でもそれだけじゃ、なんかあたりまえなわけです。コストかけなくしたんだから。 というか、別のコスト(= 転送量)に転嫁しただけで。 圧縮をうまくやりつつ、HDDというかI/Oの力を発揮させつつ、 うまく力を発揮させられないか、 というか、>>407 でいうところの解決すべき「問題」とはそもそも何なのか、というところから、 考えてみる必要があるような気がするです。 現 ex10 で実験を行っている目的は 逆に live8 では駄目だった理由ですが、 私は投稿数の積分値に置いています。 つまり 一日の投稿総数。 ある瞬間重くなる(突然のアクセス増)をなくするのではなく 一日の総数での極大地をつぐりたい。 次の瞬間ぱっと立ち直ってさくさく動けばいいのですから、 一時的に、「subject.txtだけno-gzip」にしてみた。 この時間だと、あんまり参考にならないかも。 ex10だったらsubject.txtだけno-gzip、という設定は、.htaccess的にどうやるのかな。 >>412 ふむ。 持続力というか、サーバのキャパシティの問題ですね。 包容力のある、でっかいサーバをめざす、という方向かしら。 300投稿/分 とか 400投稿/分 の状態がずっと続いても、問題なく動くと。 >>415 なぜなら 2ちゃんねるのほとんどの板はそれが重要かと、 例外はlive系だけ liveだけ、とは言わないですが(理由は下記)、圧倒的多数の普通の板は、そうですね。 「どーん」に耐えなきゃいけないのは、live系、eq/eqplusと、あとは私が言うところの「アツい板」達かな。 いわゆる「突沸」するところ。 思いつくままにあげると、anime, shar, keiba, soccer あとどこだろ。 なんにせよ、感情のままに何かが起きるみたいな。 んで ex10 における実験で目指したいところは 1) 一日投稿数の増加 2) 一撃からの回復の早さ です。 1) のためには当然最大速度の向上も必要です 500/min 楽勝とか deflateが重くする原因は何処なのか調べた方が良さそうですね。 まずはメモリ増設で何処まで軽減するかチューニングしながら様子見するとか >>408 oyster243、全く使われておらんと? (BBQはどうなっただすか!?) ほんとうに全く使ってないなら、243にi386版をインスコすて ex10の中身をそっくり移すと面白いのかも知れぬ ソレでOSとcgiの現状がどうなのかがわかるで、 結果として>>395 の下段の検証がある程度出来るかもでよ i386版はかなり練れておるはずじゃからね …あと、量産型Cobraのメモリは512Mモジュール使用でなかったかのう、 高価な1Gモジュール入りはプロトタイプな901、902だけでなかったべか? そのへんどうだったべ? >>413 にして15分ほど。 http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/ex10traf.html 転送量はちゃんと減少。しかし、負荷はいつもの2時台より少ないような。 なんか、subject.txt が異常に多く読まれているが、ビンゴな気がしてきた。 >>420 単純に、増設工事の完了を、待っていたです。 前半は私が忘れていた(たぶんJimさんもメールを見落としていた)だけど。 >>420 > …あと、量産型Cobraのメモリは512Mモジュール使用でなかったかのう、 > 高価な1Gモジュール入りはプロトタイプな901、902だけでなかったべか? だったはず。少なくともcobra2244〜2246は512Mモジュールでした。 901 243がどうだったかは、再確認が必要かと。 >>419 「deflateが重くする原因」の主たるものは、そのCPUの占有率によります。 …そういえばtiger503時代も、転送量の割に負荷が高かった記憶が。 投稿数が多いせいだというのはもちろんあるわけだけど、subject.txt の転送数も 効いているのかも。 >424 と言うことはCPUを4WayにすればCPU占有率下がるのかなぁって思ったんだけど さすがに導入費&維持コストかかり過ぎなので今年登場するデュアルコアに期待 って所ですねぇ (おなじ2Wayでも実質4Way相当) 「面白いスレがたたないかなー」ということで みんなで一生懸命subject.txtをとりまくるわけなんだべか、、 >>422 ああ、そっちの都合だったのけー >>413 をex10のhttpd.confで設定することで、.htaccess から設定をはずした。 で、.htaccess を再配布。 これで、ex10についてだけ、subject.txtのみ圧縮しない、というモードになったはず。 これで明日のラッシュアワー(21:00-24:30あたり)、動かしてみるか。 転送量の比較もしてみよう。 つまり、転送量が大きく増えなくて(全部mod_deflateだと12Mぐらい、全部なしだと20Mぐらいだった)、 負荷が上がらないなら、この設定はサーバのキャパシティ向上には相当意味があることになると。 >>427 というか、専用ブラウザでsubject.txtを超高速でとりまくるのは、 実はサーバにとってはかなり痛かったってことなんじゃないかと。 まさかsubject.txtを毎秒取りに行ってる香具師とかいるんじゃないかと言ってみるテスト 下手するとコンマ何秒の世界だったりして 一時期「ミニ雪だるま」の実験をした時、subject.txt のヒット率が 異常に高かったのを覚えています。 たぶん、一部の2ちゃんねるビューワで、 相当な勢いでsubject.txtをとっているものがあるんじゃないかと、推測していたり。 調べてみますか、、、 < subject.txt/UA >>432 ex10で例のfox.cgiをごにょごにょするのが、一番手軽でよさげかも。 あと、気が向いたら DeflateCompressionLevel 1 も試してみてくださいな。 圧縮後のサイズは平均15%程度大きくなるけど CPU負荷はかなり低くなると思いますよ。 ex10.2ch.net サーバ .txt 呼び出し回数 = 32646 deny from 206.223.152.95 #(289) 0.89% deny from 206.223.152.90 #(267) 0.82% deny from 210.135.98.230 #(238) 0.73% deny from 219.113.242.218 #(223) 0.68% deny from 222.15.3.135 #(195) 0.6% >>435 上2つはblackgoatの予感、、、だけど、blackgoat並みにとってるやつ、 結構いるのね。 上位五個 206.223 は blackGoat かな? 1h で約300回は全然キャシュが効いていないような、 全体としては誰かが極端に多く取得じゃなく みんなで激しく取得という印象 今ディレイ1分だから、60回…ってのを期待しているのかしら。 ちょっと、設定見直してみるか。 1) blackgoat が二台とも来ているのは仕様? 2) blackgoat は60秒delayなんだから一時間で 60回 (6板あるから 300回かな?) >>435 deny from 210.135.98.230 #(238) 0.73% Network Information: [ネットワーク情報] a. [IPネットワークアドレス] 210.135.98.0/24 b. [ネットワーク名] BARTOK-NET f. [組織名] 株式会社ジェンマエンジニアリング g. [Organization] Gemma Engineering m. [管理者連絡窓口] AS116JP n. [技術連絡担当者] AS116JP p. [ネームサーバ] ns0.bartok.ad.jp p. [ネームサーバ] ns1.bartok.ad.jp [割当年月日] 2004/03/13 [返却年月日] [最終更新] 2004/03/13 17:52:02(JST) >>441 1) 振り分けは、c.2ch の中の人たちがやっているです。 ex10の板をどう分けるかに依存しているですね。 確か今は、ある板についてどっちかのblackgoatしか使わないはずだから、 例えば3つの板をBG3、別の3つの板をBG4とか、やっているはず。 6板で300回が理論値だとすると、倍近い、、、。のかな。 .txt で抽出しているから 別の .txt の可能性もあるかも? って他に .txt あったっけ? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる