【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part14
■ このスレッドは過去ログ倉庫に格納されています
peko作戦について語るスレです。 サーバの新ロケーション、PIEに関する話題もこちらで。 現在の主要なテーマは、 ・新ロケーション、PIEの安定化 ・pekoサーバ突然死の原因究明 となります。 レンタルサーバー maido3.com 2ちゃんねるの転送量: http://server.maido3.com/pie/ MRTGによる統計情報: http://mumumu.mu/mrtg/ 2ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html PINKちゃんねるで現在進行中のama作戦については、こちら。 【Project ama】PINKちゃんねる特化型サーバ構築作戦 Part2 http://qb3.2ch.net/test/read.cgi/operate/1082721809/l50 携帯電話特化型サーバ構築作戦については、こちら。 【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1 http://qb5.2ch.net/test/read.cgi/operate/1075887465/ 前スレ 【Project peko】2ch特化型サーバ構築作戦 Part13 http://qb5.2ch.net/test/read.cgi/operate/1085678587/ 帰宅。 今日は午後からずっとオフラインでした。どうもいろいろとあったようで。 >>113 DNS鯖の設定(鯖-IP部分だけ)どこかにアップしない? >>114 私は、2ch.netのDNSコンテンツサーバの設定してないです。 (maido3.comの中の人が担当) 私が今のところ触れるのは、 サブドメインの分(uma.2ch.netと・peko.2ch.net)のDNSコンテンツサーバと、 DNSキャッシュサーバ(bananaサーバから/etc/resolv.confで参照されている)だけですね。 2ch.netのDNSサーバはns1.maido3.comとns2.maido3.comなので、 私は触れんです。 @ IN SOA 2ch.net. root.localhost ( ごにょごにょ ) pc5 IN A 38.114.144.85 こんなやつの最新版どこかにないかな? と思ったんだけど ns1.maido3.com内で2chのも設定してるなら無理か キャッシュサーバのアドレスが変わると、Rock54への登録とかも必要かな。 しかし、ねそびれた。 >>119 おつですー Rock54 関連は丁稚どんを含めて大丈夫かと思いますです。banana238 -> 206 系なので BBX の oklist の書き換え(or 追記)が必要なのかな? なんか鯖用マザー新発売ってのを見つけたんで貼っておきますね。 PCIexpress16xスロットにPCIexpress4xな高速ストレージカードを繋ぐことが出来るのなら 結構すごそう。(仕様上は繋ぐことが出来るはず) しかも内臓LANがPCIexpress1x接続。 Tyan、Intel 925/915マザーボードを発表 - RAGE XLを搭載した製品など http://pcweb.mycom.co.jp/news/2004/06/24/014.html http://www.tyan.com/products/html/tomcati925x.html ftp://ftp.tyan.com/datasheets/d_s5130_100.pdf 内臓LANチップの解説 http://www.chipcatalog.com/Broadcom/BCM5721.htm 本日の儀式予定: 1)c-docomo, c-others生誕 2)cアドレス変更 1)は今日のごごいちあたりで。 2)は1)へのリダイレクトがうまく動いたら。 ということで、儀式1)をお願いします。 以下の2つの追加登録になります。 +c-docomo.2ch.net:206.223.150.140 +c-others.2ch.net:206.223.150.145 >>124 ?? おぢさんが「done」書き込みをする前に まさか開いちゃったの? c-docomo.2ch.net c-others.2ch.net みえました。 >>126 振り分けをはじめました。 続きはあっちのスレで。 と思いましたが、儀式第2弾があるのを忘れていました。 以下のアドレス変更をお願いします。 これでDNSが浸透した時点で(変更後しばらくかかる)、 oyster246からの携帯系の分離は完了です。 (旧) +c.2ch.net:38.114.144.180 (新) +c.2ch.net:206.223.150.145 >>130 変更を確認しました。 徐々に浸透していくと思うので、週明けあたりには概ね新cにいくようになるとおもわれ。 >>132 おつですー ところで、 c.2ch.net/_service/ は存在するのでしょうか?@現状、c-others に飛ばされるので確認できませんでした。 # 同じ鯖なのであまり意味はないかもしれませんけれども(苦笑) >>133 旧cにはないです。 新cにはあるはず。でもc-othersのやつをln -sしてあるだけ。 >>134 シンボリックの件、承知しました。 同じファイルなので、巡回外したほうが良さそうですね。 ♪そういえば、 VirtualHost ごとに uptime があるのもちょとばかし無駄なような気もしたりして(苦笑) http://qb5.2ch.net/test/read.cgi/operate/1088080432/856 向こうでレスの山に埋もれるのもアレだとおもうので こっちに転載しておきます、 なんか画期的なことだったらたいへんだし >>138 前にもこの案は挙がっていたような気がしますが。 >>139 はあ。探すのに苦労しました。 これの、 http://qb3.2ch.net/test/read.cgi/operate/1073058944/601- この 661 :root ★ :04/02/17 20:14 ID:??? 書き込みのことでしょうか? これだとすると、全体のトラフィックの制御のように読めますから、 実況の対策として、板ごと、あるいは、スレごとにトラフィック制御 してみる、というのとは、ちょっと文脈が違うかも知れませんね。 たまたま思いついて書いてみたのですけれども、なにぶん、 2chのシステムをあまり理解していないもので、はずしていたら ごめんなさい。 でわ。 mod_netniceの2ch特化版ってのはありかもしれないですね。 >>138 netniceは、いまのとこFreeBSD 4.xだけみたいですね。 将来性はきわめて有望(いろいろつかいでがありそう)なので、 かなりおもしろそう。 2ch的には、FreeBSD5.xが必要になりますか? 分かりました。できるだけ頑張ってみます。 もし差支えがなければ、直接コンタクトを頂ければ、 よりご希望に添った形に持っていけるかも知れません。 おぉ。すばらしいです。 ただ、実際に使うかどうかはわかんないです。 あと、i386じゃなくてamd64にも対応してほしいかも。 私のメールアドレスはこちらのリンクにあるやつになりますです。 http://mumumu.mu/ mod_netniceは面白そうではあるんだけれど、サーバからの出力の 帯域を絞る形で動作しそうなので、結果としてリクエストのはけが悪 くなる予感。リクエストのはけが悪いとapacheの仕組みからいって、 MaxClientsいっぱいまでhttpdが起動し、最悪の場合それが全部 read.cgiあるいはbbs.cgiを実行することになるので、サーバ負荷が 心配だったり。 mod_limitipconn2(/usr/ports/mod_limitipconn2にある)あたりだと、 同IPアドレスからの同時接続数を制限できるので、行儀の悪い クライアントによる負荷を軽減できる可能性があるので検討の価値 があるかもしれません。 でも、当面考えるべきはbbs.cgiの改良だと思う。具体的には、 http://qb5.2ch.net/test/read.cgi/operate/1076666901/743-744 を簡略化した感じで、 1. datファイルヘの書き込みおよびsubject.txtや板topの更新を専門 に行うデーモンプロセスを作る。 2. bbs.cgiは書き込み許可のチェックとか書き込みのサニタイジングなど、 個々のPOSTリクエスト単位で閉じている仕事だけを受け持つように し、実際の書き込みはデーモンに丸投げする。 削除関連などdatファイルやsubject.txtに触る仕事の実体を全てデーモン プロセスにまかせられれば、デーモンプロセス自体の実装には特に工夫 しなくても、効果ありそう。 >>149 書き込み時と読込時では性質がかなり違うのと、現時点での携帯の場合は 平均的に遅いのと不安定という苛酷な条件があるので、Love Affairとは 直接の関係はないかと。>>148 で書いたデーモンプロセスは各種ファイルを 持っているサーバで実行するほうが良さそうだし。 別のところで見た「実況」の問題についての素朴な提案なので、こちらの 議論の流れとはずれているのかも知れません。その際にはご容赦を。 帯域の話は、フェアキューイングを使うと、帯域は絞りませんよ。たとえば、 リンクが100Mbpsあるとすると、「実況スレ」だけしかリクエストが無いとき には、100Mbps使いきりますし、そこに同じだけの他のリクエストが来たとき には、50Mbpsづつフェアシェアすることになります。その際、システム全体の スループットは、理屈のうえでは変わりません。 ただ、それは、システムのボトルネックがネットワークI/O側にあるときの理想 的な状況で、かつ、クラス分けのアルゴリズムがうまく実装できたときの話です ね。CPUがボトルネックであれば、いくらネットワークでフェアキューイングし たとしても、あまり意味は無いでしょう。その際には、プロセススケジュー リングの方を、スレ毎にフェアシェアしてやる必要が出てくるのでしょうね。 直感的には、ディスクアクセスが噛むと話が変わってきますけれども、アクセス の多いスレはバッファキャッシュがホットでしょうから、最近のプロセッサで あれば、結構、burstyに出力されているような気はします。チューニングされた コードであれば、なおさらです。そうなると、ネットワークI/Oでのフェアキュー イングが、「実況」問題に効果を発揮する可能性はあります。ただ、実際の ところは、やってみないと分からないというのが正直なところですね。 リクエストが溜まってクライアント数が増えてしまうという問題については、 mod_netnice固有の問題ではなくって、システムの処理能力を上回るリクエストが 生じているときにはいずれにせよ生じる問題だと思います。その際には、選択的 に「実況スレ」のリクエストを処理しているプロセスをアボートさせるしかあり ませんね。もっとも、その処理自体は簡単なはずですよ。案外、そうしたコード を埋めるだけで、問題の殆どは解決してしまうのかも知れませんね。 思いつきで書いているので、間違っていたらごめんなさい。 >>151 フェアキューイングの話はそのとおりだと思います。理解しているつもりです。 で、現状の2ちゃんねるの負荷問題というのは、外野から見ている限りでも いくつかのパターンがあって、書き連ねると次のようなものになります。 1. サーバの契約上の帯域制限に掛かってしまう。 2. ネットワーク的に遅いクライアントが沢山繋がった時に、apacheの性質上 設定したクライアント数分httpdが立ち上がり、その結果物理メモりが破滅 的に不足し、その結果スラッシングが起こり、見かけのCPU負荷が上がる。 3. bbs.cgiの場合(書き込み時)、ファイルの読み書きを行うプロセスが多数起 動される。特に実況時は同じファイルを読み書きするプロセスが上がる。 cgiなのでcgiを呼び出したapacheの子サーバはbbs.cgiが終了するまで リクエストの処理を終えられないため、2の場合と同様の問題が起こる。 1の問題は契約の話なので、技術的には如何ともしがたいわけですが、 この制限でクライアントへの応答が悪くなった時には、LAが上がったりは しないはずなので、現実には2の問題が最も大きいと考えられます。 実況サーバの場合は3に由来して2と同様の問題が起こっていると考えられ ます。 なので、まずは2、3の問題を解決しないと、フェアキューイングをしても、 スラッシングの影響が大き過ぎて効果が出ないのではないかと思います。 2の問題はサーバの能力を越えた設定をしないようにapacheの設定を チューニングすることで解決できます。で、>>148 のは、3の問題を解決 するためのアイデアです。フェアキューイングの効果を求めるためには、 2、3のような状況が起こらないようにしておく必要がありますよね。 >>151 >>153 ども。1レスをもちょっと短めにするといいかもです。 (ここは60秒規制なのでややつらいですが) 中身のコメントは別途。 で、おれさまメモ。Zend Optimizerの効果はかなりある。 【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1 http://qb5.2ch.net/test/read.cgi/operate/1075887465/797- >>154 bbs.cgi関連を最適化しても恩恵を受けるのは実況サーバだけという 気もするので微妙ですが、もし手を付けるのであれば教えてください。 デーモン部分のコードをCで書きますです。 お返事どうも。 フェアキューイングの説明については、余計なことだったようで申し訳 ありませんでした。2chのバックエンドについてまったく理解していない 一般人ですけれども、結論的には、同じところに落ち着いているようで、 少しほっとしました。 さて、上記の書き込みですけれども、直感的な感想です。 1は、簡単ですよね。パケットが契約帯域を越えるとドロップされるなら、 サーバ側で絞れば良いだけのような気がします。 2は、普通は、間にキャッシュサーバを数台噛まして負荷分散、という アプローチになると思いますけれど、キャッシュは置けないという前提の ようですね。そうなると、「遅い」コネクションをいかに落とすか、 あるいは、同じホスト上で、何らかのソフトウェアでキャッシュサーバ の挙動をエミュレートしてやるか、という話になりますか...。 3は、「実況」時のリクエストのプロファイルによると思いますけれども、 「同じファイルを読み書きする」限りは、バッファキャッシュの効率が 高まるので、基本的に個々のプロセスの処理効率は高まると思います。 148は、その問題に対して、読み書きのトラフィックをユーザーランドで write gatheringするというアプローチだと理解しますが、それは、逆に、 コンテクストスイッチ分だけ効率を落とすことになるような気がします。 この手のプロセスまわりの性能問題は、結局はスレッドベースのhttpdに するしかないのでしょうね。逆に言えば、Apacheの利便を取る限りは、 犠牲にするしかない類の話なのかも知れません。 ともあれ、ある程度ネットワークに出力がないと、フェアキューイング的 に美味しくない、というのは正しいでしょうね。ただ、出力のバッファの 挙動って、よく分からない動きをするので、やっぱり、やってみないと 分からないというのが正直なところです。 game6/news11, comic4とも、メモリ節約セッティングに変更後にread.cgiを動かして 数日間安定して動いている模様なので、 tmp3/live12 (cobra2245)も同じセッティングに変更の上、 read.cgiを動かしてみた。 etc2/food5は来週には移転とのことなので、とりあえず今のままで。 pekoサーバのread.cgiはいずれも、munmap()を明示的にするバージョン。 少なくともFreeBSD/amd64では、このほうがかなり安定に動く模様。 そういえば、mod_netniceの作者ってこういう人だったり。 こことは親和性がいいのかも(w。 http://www.netnice.org/2ch.html カイサード アルサード キ・スク・ハンセ・グロス・シルク 灰燼と化せ 冥界の賢者 七つの鍵をもて 開け地獄の門 (´-`).。oO(そんなボケが未承諾広告さんの口から聞けるとはw) >>163 ハーローイーン 七 鍵 守 護 神!!! ですか。懐かし漫画板へ逝ってください。 バスタードはまだ懐かしじゃないぞぉ、と釣られてみよう。 ついこないだようやく単行本新刊出たし、MMORPG化も進んでる?ようだし。 以後は質雑スレで。 そろそろ移転という噂もありますが、 oyster247のhttpdの設定をcomic4と同一に変更して、 etc2とfood5のread.cgiを復活させました。 これで、掲示板があるすべてのpekoサーバでread.cgiが復旧したはず。 pekoサーバのread.cgi問題ですが、 ・munmap()を明示的に実行するようにする ・httpd.confに以下の設定を入れる 1)メモリ使用量に制限を入れる 2)メモリリークによるhttpdの肥大化を防ぐ ことで、ここ数ヶ月苦労した問題は解決したのかもしれません。 <IfModule prefork.c> StartServers 64 MinSpareServers 5 MaxSpareServers 32 ServerLimit 128 MaxClients 128 MaxRequestsPerChild 100 <= MaxMemFree 1024 <= </IfModule> 突然死というぐらいで「突然」起こるので、まだ予断を許しませんが。 根本解決じゃなく、あくまでもすり抜けてるレベルだわな Op鯖導入後からROMってましたが、一つの山を越えたようで、皆さん乙でした! 移動中にtmp3/live12が、、、。 該当時間、負荷は高かったみたいですが、 これが負荷が理由なのか、はたまた例の突然死なのか。 リモートコンソールとかであれこれ状況を見れないんですか?ヾ('-')ノ 線が外れてるんだっけ・・・('-';) root★様いつも乙です。 今回のナルコレプシーが既知の問題点である、メモリリークの不具合ではなく、 偶発的に発生した問題で、極めてレアケースであることを祈ってます。 いえ、それはそれで、勿論問題なのですが。game6やcomic4でroot★さまが 立てた解決への道筋が、間違いでないコトを祈って。 どもです。>>180 愚痴を言わせてもらおうっと。 正直、live12/tmp3というペアリングはちょっとチューニング的に難しいです。 live系のセッティングと一般系の掲示板ではトラフィック傾向がかなり違うため、 本来はセッティングを変えたいところなのです。 例えばlive系だと暇な状態でもhttpdの常駐数が減らないようにして、 突発的なリクエストに耐えるようにするとか、read.cgiが比率的に多くないので、 MaxRequestsPerChildをやや増やせるとか、 いくつかのチューニング手法があります(live8で実施)。 でも、そういうセッティングは、tmp3のようないつもかなり多くのユーザがいて、 かつread.cgiもかなりの比率あるところには、あまり向かないわけです。 で、今は突然死対策もあり、comic4と同じセッティング(= tmp3寄り)になっています。 ということで、live系の負荷増、特に突発的な負荷増には、やや弱いかなと。 でもまぁ、そこをなんとかするのも、腕の見せ所ではあるわけで。 # 安定に動くならperchildかなぁ。それともこれこそnetniceとか使うといいのかも。 ということで、めし。 移動中に落ちるってことは、LANボードかネットワークドライバ周りに異常か? >>181 実況系統とそうでない系統を同居させるのは正直、いかがなものかと・・・ >>184 祭りが良く起きるダウソ板の挙動が不安でbananaに移りたくないのかも?>tmpの中の人 質問でーす game6 , comic4 , tmp3 @peko は 現在 read.cgi 動いているのですか? それと、今後の予想はどうなんですかねぇ? >188 read.cgiは動いてるですよ。>game6 , comic4 , tmp3 gameは夏までに整理できるところは整理したほうがよいかと いいかげん頭打ちになるような気がしないでもないが netniceのBOFってどこなの? BSDなひとときで見てたけど情報がみあたらない。 黒山羊さん生誕の儀式を依頼しておきますです。 今日の構築作業はここまで。続きは明日夜以降。 以下を2ch.netのDNSに追加お願いします。 +blackgoat.2ch.net:206.223.150.190 うーむ。 >>181 を鑑みるに、live9/game7みたいなdat保持数が多い実況板も 再編したほうがいいのかねぇ。。 どうなんでしょ? >>201 ;; ANSWER SECTION: blackgoat.2ch.net. 1D IN A 206.223.150.190 Excellent! あれ、blackgoatってフロントエンドとプライベートIPでつなぐんじゃ なかったけ?外にも公開することにしたのかな? というか、blackgoatが掲示板サーバーからデータを取ってくるわけですし グローバルIPがないと掲示板サーバーと通信できない気が >>206 もちろん、そですね。 ということでこれを作りました。その方面のかた、よろしくです。 http://blackgoat.2ch.net/_service/20040701.txt これ以外はグローバル側からのアクセスは「人大杉」ということで。 これからcの中の人にメール書きます。 comic4 なんですが、、、 FTP で接続はできるのですが public_html へ移動しようとすると listing が出来ないようで、それっきりになってしまいます、、、 public_html から 1035 bytes が来たところでしまってしまう どうしたのかなぁ >>208 なんだか移転が上手くいってないっぽい…? >>210 (((( ;゚Д゚)))ガクガクブルブル ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる