【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/ >>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
(((( ;゚Д゚)))ガクガクブルブル 他に残ってる板(まだ移転してない板)は書き込みとか読み込みはできるけれど…
どうなのだろう>comic4 bbs.cgi@comic4 とめます
何か不吉な予感ということで、 HDD交換ってことなら
どうせなら不治痛MAUの導入実験きぼんぬ。
実験、実験。たのしい実験。 comic4って鯖落ち回避のためにバックアップをしてないはずだけどログとか大丈夫なのかしら。 root ★さんへ
一度 comic4 の状況見てくださいー
>>208
>>210
>>215 裏で復帰作業が入っていたがそれが原因ってことではないよね。 >>221
壊れたかもしれないcomic4とcomic5は別マシンなので
無関係だと思うです。 comic4から移った板は通常営業って事でいいの? >>223
なんでだろ・・・
comic4 -> comic6
comic , wcomic , csaloon の移転(dat)移し&index.html変更おねがいできますかー
んで bbs.cgi 再開してくださいー 今気が付いた、俺>>221で何を書いてんだろう。
comic5と見間違えちゃった。
>>225
移転できたのは通常でOKだとおもいます。 留守番さんがpeko246に嫌われちゃったとか(マテ
で、それぞれ3板しか移ってないのは何か意味あるのですか? システムメッセージ 正常
fsck -n 問題なし
その他システムレスポンス 正常
不審なプロセス・不審なコマンドの形跡 なし
攻撃の形跡・異常なアクセスの形跡 なし
ロードアベレージの急な上昇 なし 気のせいだったということで、
私が入れるようになったら他のも移転しまーす
が、
サザン ★さんが適当に割り振って移転してくれても ok でーす
comic4 -> comic5,comic6
私は次に tmp3 -> tmp4 をやりまーす comic6 にログインして comic4 にFTPかけて、
public_html に移動してファイルいくつか転送してみたけど、
何の異常もないなぁ。 >>233
んじゃ、
>>235 のスレを参考に移転しますー、 うーむ、、、。でもおじさんの勘はすごいからなぁ。
http://newsplus.jp/~gedo/bbs/test/read.cgi/gedo/1076046104/7 ■ このスレッドは過去ログ倉庫に格納されています