2ch特化型サーバ・ロケーション構築作戦 Part45
■ このスレッドは過去ログ倉庫に格納されています
2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
前スレ:2ch特化型サーバ・ロケーション構築作戦 Part44
http://qb5.2ch.net/test/read.cgi/operate/1276342978/ 無反応にはならなかったっぽいな。
最大で本スレが2000/10secぐらいいった。
2xx 3xx 4xx 5xx URL
1596 30 5 0*/livenhk/dat/1276520549.dat
701 9 0 0 /livefoot/dat/1276520214.dat
477 2 0 0 /liveanb/dat/1276520783.dat
338 0 0 0 /livenhk/subject.txt
298 42 0 0 /test/bbs.cgi
283 2 0 0 /livenhk/dat/1276519628.dat
186 2 0 0 /news4vip/dat/1276518185.dat
172 12 0 0 /livefoot/dat/1276519299.dat
169 21 1 0 /liventv/dat/1276520222.dat じっぷらyutori7に戻した
次ぎ戻すとしたら liveanbか
atlantaだった? つぎの閾は、FIFAアンセムか君が代かキックオフか。 取り合えずこの設定がlive28の目安になりそうですな 前スレで一般用と bbs.cgi 用で httpd を分けて
一般用では worker MPM 等を使ったらみたいなことを書きましたが,
bbs.cgi 用のは非特権ポートで動かす形にすれば
そっちは root 権限いらなくなるので柔軟に操作できますね. これ以上httpdを増やすのは冒険ゾーンな気がするし、
良い知恵はないものかな。
>>87
それはちと避けたいですね、、、。 >>100
news4vipはyutori7だったはず。 >>99
logは止めない方がいいよ。
どう考えても >>93
サンキュ 適度に誘導して回る
全鯖規制解除も検討よろしく というか、サーバの中はそうやって移転作業できるぐらい軽いんですよね。
ううむ。 記者キャップで荒らし〈(`・ω・`)〉 ◆EQUAL/Pi.Qに嵌められたおいちゃん >>107
やっぱ実況だからみんなそんな長文書かないせい? こないだあふれたmbufは今のところ良好なんですか?
そろそろ100Mbps突破 >>115
アニメの実況でない限りは、長文なんか殆ど書かないよ。
日本戦は茸AAが多少出てるけど。 swapなんか気にしねー、鯖が落ちなきゃなんでもいいや
ってことで、次におかしくなったらさらにhttpdを増やしてみるとか >>116
netstat -m 的には、今のところmbufは大丈夫なようです。 >>120
どもども
なら最後の壁はhttpdの溢れだけか Preforkとworker併用というのは
local雪だるま的使い方と言うことでしょうか >>113
まだまだパフォーマンスをフルに活かせてないですねぇ。
メモリ増やせばもう少しhttpd増やせるかな? 掲示板システムの方を見直した方がいいかもね。
変なボトルネックが多すぎる気がする。 >>123
SunOSさんが前スレで書いてましたね。
普通のサービスはworker MPMでして、
mod_speedycgiのサービスだけ、
mod_proxy で振って、127.0.0.1 で待たせている prework MPM ですると。 ・店の間口を広げた
・応対する店員の数を増やした
・店に入りきる限界まで店員を増やしたけどどうしよう<-now!!
ってところ? >>93
〈(`・ω・`)〉 ◆EQUAL/Pi.Q
こいつの全ての★消しておいてね。
いないと平和だから。 http://qb5.2ch.net/test/read.cgi/operate/1275793849/588n
588 :動け動けウゴウゴ2ちゃんねる :2010/06/14(月) 13:38:43 ID:CIx66JYe0
TOP10で
ニュース速報+と芸スポが反映されなくなってる
-----------
そうです。 >>125
規制システム撤廃すればかなり負荷が下がる気がするけどなあ
その分書き込みが増えて落ちるだろうけど news4vipがyutori7に戻ったのかしら。 日本戦は本当に負荷上がるのねえ。出来るかわからないけど、
次戦には実況系鯖以外は無くした上で日本戦の状況を見てみたい気がする。 worker MPMとSpeedyCGI_Perl(モジュールで組み込まない)の組み合わせは動いたはず >>139
どこかにも書きましたが、雪だるまフロントではそれで動かしてました。
そもそも複数バーチャルホスト入っていて、
SuExecしていたです。
で、単体サーバ(speedy_backendがディスクI/Oもするモード)で
mod_speedycgiじゃない状態だと、
「どーん」で、先に音を上げてしまうようです。 [728]動け動けウゴウゴ2ちゃんねる [sage] 2010/06/14(月) 22:29:03 ID:yPyLyr/t0
AAS
>>717
SSDの転送量オーバープチフリに気づかないド素人どもが運営 >>144
ど素人が聞いてしまいますが、
SSDの転送量って、上限があるんでしょうか。 >SSDの転送量オーバープチフリ
川・∀・)ニヤニヤ SSDキャッシュあふれと言う意味なのかしらん
#ド素人 >>146
liveplusのログは戻してくださいな >>145
……いや、そりゃあるって。
X25-Mで250MB/sだっけ? 帯域上限て通信速度よりあるんじゃないの?
おれ度素人だけdふぉ >>152
んと、
250MBytes/secですよね。 >>152
リードはそれくらい
ライトは85くらいかな
非RAIDの場合ね >>143
prefork + mod_speedycgi → あらかじめforkしてあったhttpdで対応
worker + speedy → リクエストが来てからspeedyをfork-execして対応
の差かな? ワクワクするな鯖状況がこんだけ詰め込んだlive28 どこまでやれるんだろ? >>160
ダメだよ。
ちゃんと(キリッ って付けないと。 >>156 >>158
それに容量的にひっかかっているとは、
ちょっと考えにくい気が。
で、それだと、
SSDへのwriteが詰まっている、という話はあるかもですね。 >>161
そうですね。
で、SuExecしてるともう一つプロセスが増えると。 >>162
ヤムチャばりに即死だろ。前座で落ちてるんだから。 >>164
過去の記録的な落ちた時、
HDD側に押し寄せたwrite値なんかは分かります?
仮にその値ををSSD側が裁けるかどうか推測できますかねえ? live28全サーバ規制が解除されているような・・・ >>155
残念。それ160GB版の速度
80GBはそれよりちょい落ちる >>169
HDD時代のサーバの話ですよね。
あんまりとっていないかも。
で、直感だけで話すと、
SSDって、読むのはめちゃくちゃに速いし軽いけど、
書くのって、あんまり速くないというか、
なんか今までのHDDとも違っているような気がします。 気がついたらまたlive28の規制がスルーになっていた 91Mbps
last pid: 19229; load averages: 76.54, 63.71, 41.46 up 0+11:51:54 06:46:49
1505 processes:72 running, 1426 sleeping, 2 zombie, 5 lock
CPU states: 51.5% user, 0.0% nice, 48.0% system, 0.4% interrupt, 0.2% idle
Mem: 4479M Active, 2096M Inact, 756M Wired, 307M Cache, 214M Buf, 92M Free
Swap: 8192M Total, 8K Used, 8192M Free
SSDを2ちゃんなんつうハードな鯖につかっちゃうと
どれくらいで寿命を全うしてくれるんだろうか >>173
なるほど・・・
そのあたりをもう少しデータ収集した方かいいかもしれないですね。
どーんときたので止まっちゃっていますから
つかSSDだけの問題だけで解決できりゃ苦労は無いw
バランスが大事ってテレビでも言ってる >>179
どーんで一時的に止まるというか苦しくなるのは、
live20(tiger503)時代から変わっていない傾向ですね。 日本vsカメルーン戦が始まったけどストレスたまりそうだな・・・ じっぷら、スレッド一覧( http://yutori7.2ch.net/liveplus/subback.html )は戻ったけど
スレを開くと「■ このスレッドは過去ログ倉庫に格納されています」が表示される件。 91Mbps
last pid: 19930; load averages: 92.08, 67.31, 46.57 up 0+11:55:10 06:50:05
1512 processes:61 running, 1450 sleeping, 1 lock
CPU states: 46.2% user, 0.0% nice, 53.7% system, 0.1% interrupt, 0.0% idle
Mem: 4645M Active, 1975M Inact, 764M Wired, 219M Cache, 214M Buf, 127M Free
Swap: 8192M Total, 8K Used, 8192M Free
■ このスレッドは過去ログ倉庫に格納されています