【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/ >>74 >>78 でfusiaasanになってたw Yahoo!BB 3つとも見れました >>77 ようわからんけど、excelで等高線グラフを作ってみたら bananaのピーク地点がcobraだと台形になった。 >>81 えー 範囲指定してボタン押すだけだから誰でもつくれるお? それにexcelのオマケだからグラフきちゃないしー excel持ってない人も多いし excelファイル開きたくない人も多いし 歓迎する人は結構いると思うよ game6の件。ここにも一応。 867 名前:root ★[sage] 投稿日:04/06/23 23:13 ID:??? 2日動いたというのは正直画期的なので、 read.cgiのmunmap()をやめるのは効果ありか。 次上がったら、comic4/c並みにMaxRequestsPerChildを小さくしてみる予定。 サーバダウン(鯖落ち)情報 Part39 http://qb5.2ch.net/test/read.cgi/operate/1087762418/ 906 名前:root ★[sage] 投稿日:04/06/23 23:30 ID:??? リブートを待っていましたが、速攻ではかからない模様なので、 いったんオフラインになります。 game6が上がって私がオンラインになり次第、設定変更をトライします。 Apacheの数を思い切って減らして、MaxRequestsPerChildを思い切って少なくする予定。 しかし、不安定な状態(read.cgiを動かした状態)でないと試せないところがきついなと。 read.cgiを止めれば安定する(20日以上ダウンなし)ので、 何らかのトリガであることはもう間違いないと。 >>88 まぁ、そんな領域で実験できるのは2ch位なのでむしろ楽しめるかと。 よーわからん2号だけど Writeで SCSI320:ATA100(?)おおむね1.5倍ってかんじ IDEもキャッシュ多めなのか、こんなものかなあ。 readは2倍前後でてるもより。 帰宅。game6はリブート待ち。 で、PCからでもここ↓だけ読めるようにしたので、 ここをチェックいただいている各位におかれましては、ご対応いただけると。 http://c-au.2ch.net/_service/ game6が上がったら、>>86 よりも素直に負けを認めて、 Single CPU設定にしてみるかなぁ。そのほうが簡単だし。 >>93 Single CPU設定にする前に、 いま一度、>>86 でトライして欲しいねぇ・・・ >>94 正直迷っております。上がるまでには心を決めておこう。 >>93 MaxRequestsPerChildを(5000あたりまで)ガッツリ減らす方が効果あり そうな気がする。read.cgi動かしているサーバで希にでも落ちるのは pekoだけじゃないですよね、確か。 今時swap使い尽くすような使い方は滅多にされないから、仮想記憶 使い尽くすあたりにカーネルのバグがあっても不思議じゃないし。 もちろん、SMP特有のバグという可能性もありますが。 サーバダウン(鯖落ち)情報 Part40 http://qb5.2ch.net/test/read.cgi/operate/1088002146/345 345 名前:root ★[] 投稿日:04/06/24 02:19 ID:??? etc2 (cobra2247 = oyster247)のSCSIカードを交換する予定とのこと。 今日になるかどうかはまだ未定。 サーバダウンしたgame6は正規パスでしかリブートをしない方針とのこと。 ただ、シリアルコンソールが復活するかもしれないので、そうすると様子が見られる可能性あり。 【'A`】エトセトラetc鯖なんとかしてえぇぇ【ノД`】 http://qb5.2ch.net/test/read.cgi/operate/1081010089/659 659 名前:root ★[] 投稿日:04/06/24 02:27 ID:??? サーバダウンスレがgame6問題で流れてしまっているので、こちらに。 SCSIカードに問題をかかえているetc2(oyster247 = cobra2247)ですが、 本日午後(現地時間)、SCSIカードの交換作業を行うとのことです。 ということで木曜の午前中にサーバダウンが発生すると思います。 あらかじめご承知おきくださいです。 続報 660 名前:root ★[] 投稿日:04/06/24 02:34 ID:??? >>659 続報が入り、他の作業との兼ね合いで 本日作業が入らないかもしれないとのことでした。 その場合は後日スケジュールということになります。 >>100 どもです。レスしておきました。 なんだか誤解があるようなので。 向こうにも書きましたが、 今回、外にアナウンスする入り口のURLは変更して*いません*。 従来通り、c.2ch.netが入り口となります。 あくまで、内部処理をするホストを変更しただけです。 明日以降DoCoMo専用の受付嬢も作る予定ですが、 それについても同様です。 ということで。 グラフが変というかnews13がこのところずっと不調なわけで LAがそれほど上がっているわけでもないのに激重で ネットワークかハードが怪しいんだが放置されてるわけで >>104 漏れは「転送量限界説」かな?とおもうのですが このグラフが見れないことにはなんともなわけで。。。 ※早朝は軽かったですよ bananaでnewsplusをまかなうのは正直つらいような希ガスです。 game6のApacheの設定を変えた。 メモリを節約する方向。 従来: <IfModule prefork.c> StartServers 64 MinSpareServers 5 MaxSpareServers 32 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 100000 MaxMemFree 2048 </IfModule> 現在: <IfModule prefork.c> StartServers 64 MinSpareServers 5 MaxSpareServers 32 ServerLimit 160 MaxClients 160 MaxRequestsPerChild 100 MaxMemFree 1024 </IfModule> cobra2247 (etc2, food5)のSCSIカードがAdaptecから 他のcobraと同じLSI Logicのカードに交換され、 転送速度が本来の速度になりました。 da0 at mpt1 bus 0 target 0 lun 0 da0: <SEAGATE ST336753LW 0006> Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) da1 at mpt1 bus 0 target 1 lun 0 da1: <SEAGATE ST336753LW 0006> Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) ただし、デュアルチャンネルのかたっぽに両方接続されているので、 ぼちぼちケーブルの接続方法を他のcobraと同じに変えてもらうということで。 >>108 DNSサーバのダウン(不調)の原因は何だったのでしょうか? 帰宅。 今日は午後からずっとオフラインでした。どうもいろいろとあったようで。 >>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が、、、。 該当時間、負荷は高かったみたいですが、 これが負荷が理由なのか、はたまた例の突然死なのか。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる