2ch特化型サーバ・ロケーション構築作戦 Part49
レス数が1000を超えています。これ以上書き込みはできません。
2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
前スレ:2ch特化型サーバ・ロケーション構築作戦 Part48
http://qb5.2ch.net/test/read.cgi/operate/1276848371/ %telnet hayabusa.2ch.net 80
Trying 206.223.151.80...
telnet: connect to address 206.223.151.80: Connection reset by peer
telnet: Unable to connect to remote host
% last pid: 32664; load averages: 0.92, 4.92, 7.03 up 2+02:53:03 06:22:01
2167 processes:3 running, 2163 sleeping, 1 zombie
CPU states: 7.0% user, 0.0% nice, 3.3% system, 2.0% interrupt, 87.7% idle
Mem: 4997M Active, 15G Inact, 1065M Wired, 9916K Cache, 214M Buf, 2439M Free
Swap: 24G Total, 24G Free
とんでたの1分間くらい?
> 99 名前: 名無しステーション [sage] 投稿日: 2010/06/19(土) 22:18:40.80 ID:SwvolWbR
> ちくしょおおおおおおおおおおおおおおおおおおおおおおおおおおおおお
>
> 100 名前: 白ヱビス [sage] 投稿日: 2010/06/19(土) 22:19:38.65 ID:O8wHYKHz
> あああああああああああああああああああああああああああああああああああああああああああもおおおおおおおおおおおおおおおおお ApacheのListenBacklogも増やしたほうがいいな。 >>10
さっきいったのよりもふやす必要があるかな。 負荷試験としては理想的な試合運びだったんじゃねw
最後にドーンってw
>>12
httpd売り切れでCPU空きましたねえ・・・
とりあえずhttpdを増やすと 2148 processes:7 running, 2140 sleeping, 1 zombie
CPU states: 14.8% user, 0.0% nice, 6.7% system, 3.0% interrupt, 75.5% idle
Mem: 5046M Active, 15G Inact, 1093M Wired, 10M Cache, 214M Buf, 2349M Free
Swap: 24G Total, 24G Free
109.990Mb/s
これが破られるのはいつになるだろうか 力を使いきれなかったか。
すぐに復活できたから、
今日は2-2でドロー、ぐらいでしょうか。
次の戦いが待たれます。 落ちてなくて売り切れなんでしょ?
httpd増やすで対応できるのが恐ろしい %netstat -m
35450/2185/37635 mbufs in use (current/cache/total)
22566/1728/24294/131072 mbuf clusters in use (current/cache/total/max)
22566/1370 mbuf+clusters out of packet secondary zone in use (current/cache)
12106/631/12737/65536 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/32768 9k jumbo clusters in use (current/cache/total/max)
0/0/0/16384 16k jumbo clusters in use (current/cache/total/max)
102418K/6526K/108944K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
195 requests for I/O initiated by sendfile
0 calls to protocol drain routines
売り切れの時。 全部httpdにすれば良いんじゃね?
何のことだか知らんが >>40 は mbuf 的にはまだ余裕ありかなと。 実況ばかりに気が行ってたけど、運用情報臨時も落ちてるのか重いのか…
>>37
次は夜中の27:30〜というのが・・・。 >>42
httpdがどんなものと思ってるのか知りたい 落ちた時は相変わらずですが、復帰までの待ち時間も復帰後の重さも
live28より格段に良いですねえ >>48
日本戦で無いとここまで負荷かからないんじゃ… >>40
純粋に httpd の待機数が足らなかった感じ?
乙でした!
CPU的には余裕だったのと改良点が見えて良いテストだったんじゃない?
試合は興味ないからずっとこことグラフ見てたw さて、
書き込ませるほう(speedy_backend) まだ問題なさげ
logbuffer うまく動いてた
★httpdの数 増やす必要あり
★Backlogの数 (httpd) 上記に合わせて増やす必要あり
まずはこんなところでしょうか。
ROMの嵐、おそるべしということで。 >>54
次の日本戦が日テレ系でその時間6/24(木) >>57
既にほぼ通常の3倍ですからお帰りください(704→2049) >>49
きっとhttpdはhttp、httpsに次ぐもので、凄いやつに違いない
VHS、S-VHS、D-VHSみたいに >>54
いや、この結果によって日本がどうなるかがかかってる >>58
ありゃ、そんな時間からだったんですか。
伸びるかなあ? >>37
次のデンマーク戦は夜中3時半だからこれは期待薄だね。 >>65
正確にはこのあと27:30からのカメルーン×デンマークで
状況が少し変わりそうだけど >>67
進出かかってるからみんな起きてそう・・・。 httpd増やすのは、リブートいらないんでしたっけ
今日やる予定なら、深夜アニメ前にお願いしますです でも、サーバ負荷的にも内容的にもいい試合でしたね。
大虐殺という前評判もあったようですが、そんなことなかったみたい。 何か今度は試合終了と共にlive28があほくさい負荷かかってるんだが・・・ hayabusaすごーい
hayabusaつよーい >>74
調子に乗ってnewsとmorningcoffee詰め込む話はどうなったの? どうせ駄レスの嵐だし誰も読めないし読まないしって話が無いのは麻痺ですか? >>76
じっくり内容考えてから、週明けに依頼しようかなと。 >>75
コアなサッカーファンには見逃せないかも知れないけど、今日見たいに一般の人まで
巻き込んでの大騒動にはならないのじゃないかと。 >>75
鯖負荷だけじゃなくみんなが起きててくれりゃいいですよね >>48
今回この戦いしたから、時間帯がそれでもかなり集まりそうな気がする。
まあ少なくとも朝5時以降の最後の15分はかなり起き出してくるだろう。
楽々とさばいてた。 @ live28
last pid: 91071; load averages: 2.82, 3.00, 2.27 up 2+09:09:11 06:32:23
1163 processes:4 running, 1159 sleeping
CPU states: 35.7% user, 0.0% nice, 15.5% system, 0.1% interrupt, 48.7% idle
Mem: 3145M Active, 3501M Inact, 620M Wired, 93M Cache, 214M Buf, 403M Free
Swap: 8192M Total, 8192M Free >>90
「世間一般」は落ちるけど、「2ちゃん一般」は・・・?
でもダイジョウブな感じ? mnewsplus @ live28
2xx 3xx 4xx 5xx URL
471 49 0 0*/mnewsplus/dat/1276954262.dat
287 0 0 0 /mnewsplus/subject.txt
163 0 0 0 /mnewsplus/
131 0 0 0 /test/bbs.cgi
111 3 0 0 /favicon.ico
72 0 0 0 /test/read.cgi/mnewsplus/1276954262/
60 0 0 0 /test/read.cgi/mnewsplus/1276953600/-100
56 0 0 0 /ghard/subject.txt
54 0 0 0 /test/read.cgi/mnewsplus/1276954262/l50 httpdはおんにゃのこ
客が大勢来てあぶれた人が暴れるから鯖が落ちる! >>40
mbuf周りはまだ問題無しなんですね
>>80
これは…
ttp://mumumu.mu/bremen/live28.html 実況から芸スポに流れるいつものじゃないの。live28 今日一番驚いたことは、100Mの壁がサーバー側の問題でなく、
利用者側の問題だった事。
サーバー側疑ってすみませんでした。 >>90
つ[有休]
つ[会議で転寝]
つ[学校で転寝] >>99
vipとかはlive28じゃなかったっけ >>97
そりゃ平日深夜だし減るでしょう
今日は土曜の夜
>>95
どうなんでしょうね? 4年に一度のお祭りで決勝トーナメント進出がかかった試合ですから
でも、サーバー的には今日の負荷の方が多いんじゃないのかな? 予選リーグでは。
live28は芸+だな
試合終了でスレが立つだろうから 次の次に期待ということで。
E組1位 対 F組2位
6/28 23:00〜
E組2位 対 F組1位
6/29 23:00〜 >>89
了解です
>>103
けいおん、アニメシャワーなどの日です >>113
書き込みが足りないから届かなかっただけって事 【サッカー】W杯E組 日本、オランダに惜敗! スナイデルに一発浴びるも積極的な守りで最少失点、終盤攻め合う健闘見せた![06/19]
http://live28.2ch.net/test/read.cgi/mnewsplus/1276953600/
1 名前:はぶたえ川 ’ー’川φ ★[] 投稿日:2010/06/19(土) 22:20:00 ID:???0
1000 名前:名無しさん@恐縮です[sage] 投稿日:2010/06/19(土) 22:22:36 ID:CwB5rWnQ0
【サッカー】W杯E組 日本、オランダに惜敗! スナイデルに一発浴びるも積極的な守りで最少失点、終盤攻め合う健闘見せた!★2
http://live28.2ch.net/test/read.cgi/mnewsplus/1276953774/
1 名前:はぶたえ川 ’ー’川φ ★[] 投稿日:2010/06/19(土) 22:22:54 ID:???0
1000 名前:名無しさん@恐縮です[] 投稿日:2010/06/19(土) 22:26:25 ID:RnFRfkagO
【サッカー】W杯E組 日本、オランダに惜敗! スナイデルに一発浴びるも積極的な守りで最少失点、終盤攻め合う健闘見せた!★3
http://live28.2ch.net/test/read.cgi/mnewsplus/1276953993/
1 名前:はぶたえ川 ’ー’川φ ★[] 投稿日:2010/06/19(土) 22:26:33 ID:???0
1000 名前:名無しさん@恐縮です[] 投稿日:2010/06/19(土) 22:31:01 ID:q+yHpC800
【サッカー】W杯E組 日本、オランダに惜敗! スナイデルに一発浴びるも積極的な守りで最少失点、終盤攻め合う健闘見せた!★4
http://live28.2ch.net/test/read.cgi/mnewsplus/1276954262/
1 名前:はぶたえ川 ’ー’川φ ★[] 投稿日:2010/06/19(土) 22:31:02 ID:???0
1000 名前:へっぽこキーパーのせいで日没[age] 投稿日:2010/06/19(土) 22:36:10 ID:U4wqjcY40
・・・・・・。 >>111
109.990Mですもんねえ。つよいこだなあ。 >>104
そこまでこの国の皆さんがラテン系なら嬉しいですよねー
>>102
あんだけ常にギリギリになってたら疑うよねぇ、、、てへっ♪
いい実験だったなぁ でもまだ余裕あるから、だいじょうぶ、だいじょうぶ。 < live28 あ、今日は関西圏でのけいおん、AB、迷い猫などのアニメタイムか >>103
土曜23時以降は全国(主に関西・関東・BSだけど)で色々あるアニメマラソンタイム。 金土日のアニメマラソンもすっかり衰えたよなあ
ついったーから実況民強奪してこないと無理だな >>118
これが巻き戻しですか。実況と変わらないぞ、と。 >>88
おいちゃんへ、サッカー終わったのでまた規制戻しておいてくださいです。 >>113
>どーゆーことですか?
live28,hayabusa共にインターネットに1Gbpsの回線でつながっているサーバで、
ハードウェア的にもそのように設定されていることが確認できるにもかかわらず
なかなか100Mbpsを越える瞬間通信量がでなかった。
このためPIEのネットワーク内のどこかで最大100Mbpsに絞る処理がされているのではないか
(あるいは他のサーバ同様100Mbpsになっていて1Gbps開戦向けに設定変更されていないのではないか)
と疑っていた。
が、今回109.990Mを記録したのでそういった絞り処理はなさそうだ、という結論に達した。
BS実況chのスレ保持数変わってる?
やたら少ないんだが・・・ ちょうど隼がhttpd売り切れで書き込めなくなったのもあったから・・・
にしてもひどいなw last pid: 91296; load averages: 4.04, 2.80, 2.44 up 2+09:17:38 06:40:50
1136 processes:8 running, 1128 sleeping
CPU states: 39.3% user, 0.0% nice, 16.7% system, 0.2% interrupt, 43.8% idle
Mem: 3101M Active, 3557M Inact, 629M Wired, 88M Cache, 214M Buf, 390M Free
Swap: 8192M Total, 8192M Free
live28 はうまくチューニングできてるかんじですね。
実況型ではないのを、もっと詰め込むんでしたっけか。 なんだろう、実況って街頭テレビに熱狂する人々というイメージが<さすがにニュースでしか街頭テレビなんか見たことないけど。 >>130
やめてよー
せっかく散ってくれたのにー 実況鯖向けセッティング:live28→hayabusa
通常鯖向けセッティング:live28→??
live28はけなげや。。。 >>141
実況チューンですから、この程度では鯖落ちしないですよね。 >>142
>街頭テレビ
日本時間の平日午後に国際的スポーツイベントがある場合、大きめの電気屋のテレビコーナーに行くと見られるよ
>>141
まあhayabusaの前にがんばってもらいましたから。
実況鯖でなかったらほんといい子に育ってくれたと思います。 hayabusa…なんて恐ろしいものを開発してしまったのだ・・・ live28級3台とhayabusaだけで2ch全部賄えるんじゃねこれ 放送が終わったとたん実況板からニュース板にごっそり移るとは、なんて律儀なw hayabusaの底が見えてないこの時点で、その議論はまだ尚早w >>137
じゃあ理論的には1Gまで大丈夫なの?
回線的には余裕ありまくりってこと? >>152
FOX が板たくさん詰め込むと管理が面倒とかなんとか言ってたよ 賄えるかもしれないけど、板という2ちゃんの仕組みではあまり詰め込みすぎると逆に
運用がしにくそう。 >>157
余裕
この前99Mとかでとまってしまったのが勘違いの原因 >>157
理論上は。
実際には太平洋あたりのQoSでそこまでは出ないと思う。 >>154
ちょうど反応なくなったせいもあるんじゃないかな >>152
掲示板鯖3台と、運用系鯖2台くらいでいけそうですね 100Mbps超えていた時も、
ログインしていて何のストレスもなかったので、
ネットワークには壁はなさそうなかんじですね。 1Gを目指すなら、、、
とりあえずスレの保持数を上げることなのだろうか?
特赦との組み合わせでどうだろうか。 >>160-161
なるほど・・・すげーな
つか動画じゃないのに100M超える事自体すごいんだろうけど >>167
けどそこまで目指す必要があるとは思えないけどね。
その前に目指す場所がその場所ごとに湧いて出てきそう。 現 live28は改名しようと思っている
来週 kamomeに >>152
あまりまとめると専ブラで新着1、2レスくらい読んで次スレとかやってるだけで
エラーとかなるし、ヘタするとボボンとかありそうで恐いんだよね。 live28のブレーメンmax:6.61kってww >>171
kamomeてw
nozomiにしようって。 >>171
特急つながりでいいんじゃないですか?>kamome >>171
ほーい
混乱をなるべく避けた時間帯にお願いしますね ということは・・・
その先は hatoとか suzumeとか karasuか ■一羽の鴎作戦の六月の予定(live28) 【歌の練習よろしく】
のkamomeかとw 鴎と隼だと時期も時期ですし、なんか兄弟機って感じですね 一羽の鴎作戦て言うから実況鯖の方に kamome って付けるのかと思ってたよw >>187
あっちはもうつめ込まないらしいので
live28でってことかと >>182
hatoは退陣して縁起が悪いのでやめましょうよ。 >>188
ページ名であって、鯖名ではないような。 「かもめ」か・・・九州の特急か
次は「鳩」ですかねえw 新プロジェクトは「鳥さんシリーズ」なんですねw
焼き鳥にならないように祈ってますw >>182
hatoはいいけど、
statに使ってるのはちょっと ローマ字読みですか。英語だと seagull か gull かな。
∩
♪ ∧__∧ ∧__∧|l| ♪ ∧__∧
(´・ω・`)三三) (´・ω・`)| (´・ω・と_) ))
| / | / | ./
♪ U 〈 ♪ U 〈 U 〈 ♪
(__ノ^(___) (__ノ^(___) ♪ (__ノ^(___)
たまの失敗はスパイスかもめ♪
鉄オタうぜえええええええええええええええええええええええええええええええええええ >>182
ぽっぽっぽ〜♪
カラスの赤ちゃんなぜ泣くのー♪
雀が思いつかない TSUBAME だっけどっかで作ってるスーパーコンピューターは? >>205
サーバはまだ余裕綽綽ですので、
遠慮することなく、普通に運用しておkです。
日本の歴史の一幕ですし。
とお伝えください。 >>201
じゃあエミューとかキゥイとかドードーとか? >>214
いい時間ですねー
でもなんか気が抜けちゃってて、
ぼーっとしていたい気分
どっかから誘いがくれば別ですが、 >>188
statsのこと?
http://stats.2ch.net/karasu2.cgi karasu.cgi からす
suzume.cgi すずめ
kamome.cgi かもめ
tonbi.cgi とんび
tubame.cgi つばめ
...などなど 今日、ここにlive28と言われた鴎が巣立った・・・ last pid: 40090; load averages: 0.87, 1.04, 1.61 up 2+03:29:24 06:58:22
1277 processes:2 running, 1274 sleeping, 1 zombie
CPU states: 7.0% user, 0.0% nice, 2.1% system, 1.3% interrupt, 89.7% idle
Mem: 3421M Active, 15G Inact, 979M Wired, 11M Cache, 214M Buf, 3953M Free
Swap: 24G Total, 24G Free
おっさんちょっと携帯いじってよ
向こうで何処に居るのか判らん >>211
すずめの兄弟は電〜線に♪
大きくなったら何になる♪ >>216
じゃあ鉄道系の板全部hayabusaにつっこめばいいんじゃね(`・ω・´) すずめ sparrow
鳩 pigeon, dove
カラス crow
>>229
鉄オタじゃないから正確には分からないけど、鉄道系の板5〜6あったんじゃないかな? 今のまねきねこダックCMを見てると
shoebillもいいんじゃないかと思えてくるw >>182
おいちゃんおいちゃん、
せしりあ★さんはおいちゃんの中の人? >>240
kawasemiブルー( ・∀・ )イイ penguinが出るときはlinux鯖になるかと♪ >>222
うーむ、これだけ飲んでなければお誘いしてすすきのへ行きたかったところ。 今日のレコードは、
・単体サーバとしての転送量(@ hayabusa) ________Mbps
・ブレーメン値(apachetop -T 10 @ hayabusa) ________access/10sec
・ブレーメンメーター(mumumu.mu/bremen @ hayabusa) ________access/10sec
・揺り戻し転送量差分(@ live28) ________Mbps
結局、それぞれいくつだったのかしら。 レス数ピークは1715res/minだった模様。
(数だけ見ればそれほど珍しい数値ではないです)
http://www.tv2ch.info/?anb kiwiとか
pukekoとか
keaとか
takaheとか >>244
んじゃdaemonとか
>>248
それが瞬間値で出ているのか、ある程度継続して出ているのかにもよりますが
hayabusaの処理能力は半端ないですね・・・
転送量は109.990M
ブレーンメーターは26.82kかな? 鯖名に鳥類は鯖が「とぶ」と連想できることを考えると
縁起は良くはないのだが、嫌いではないね
eboshidori
buppousou
uzura
misago
tageri
… daemon.2ch.net・・・
なんかサービス系の鯖名によさそうw >>247
・ブレーメンメーター(mumumu.mu/bremen @ hayabusa) ________access/10sec
28.23k は見ました >>201
つまり
emperor
king
gentoo
とかやるわけか >>251
もう1こ下のグラフを見よう。28.23kだ。 >>253
mail to daemon思い出した(´・ω・`) 飛ばない鳥、ヤンバルクイナは…
おいちゃんrootタン今日はおつかれー おいちゃんの趣味を考慮して
Condor
でどうだぁ
また、歌えるよ ねえ 避難所って今日の移転でまた変わったの?
エロイ人ぉ 板おせーて サッカーにちなんで日本サッカー協会のシンボルマーク・ヤタガラスで
ヤタガラスかわいいよヤタガラス dat ってどのくらいの圧縮率で転送しているんだろう。
一時的に圧縮率下げたら、(内部処理を考量しても)転送量増えるかな。 ふと思ったんだけど、サーバー再編成が完了した頃には
ニュース系でおきまりの「地震は地震板で」っていうのも
解消出来ちゃうのかな? 2001年8月の閉鎖騒動を体験した人間にするとそれは…w >>274
鯖能力的には出来るんだろうけど、やはり該当する板へ書き込んだほうが話が
見えやすくて良いんじゃないかな? datが圧縮効くとするならSSDにSandforce使うのも一つの手か >>275
今のところ1/10位しか帯域使ってないから、経路上の帯域が100M程度なのかがわかるんじゃないかと。
当時とはネットワーク状況が全く違っているし。
もちろんあくまでも「一時的に」ね。 100Mbpsよゆうでしたって上に書いてあるし…
そして帯域テストしてる分けでもないし…
圧縮であっぷあっぷならまだしも tsusimaに移したネ実をhayabusaに戻そう hayabusaってFreeBSD7.0Rのようなのですが、
7.0->7.1でULEスケジューラに結構大きな変更が入っていたので、
せめて7.1以降にした方がいいと思います。
live28との比較のためというのは分かりますが。
そういう私もまだ7.0-RC1とか使ってて、結構スケジューラに関係したテストを行ったのですが… >>247
こうかな。
・転送量(@ hayabusa)
109.990Mbps 単体サーバのレコード
・ブレーメン値(apachetop -T 10 @ hayabusa)
5459+86 access/10sec レコード
http://qb5.2ch.net/test/read.cgi/operate/1276848371/931
たぶんPK疑惑あたり
・ブレーメンメーター(mumumu.mu/bremen @ hayabusa)
28.23kaccess/10sec 単体サーバのレコード
・揺り戻し転送量差分(@ live28)
+55Mbps レコード? (これは未確認、もっといった例はあるかも)
http://qb5.2ch.net/test/read.cgi/operate/1276953456/118
芸スポ速報+(mnewsplus) >>285
なるほど、
SCHED_ULE は、特にマルチコアでは7.1R以降とそれ以前だと、
確かに明らかに違う気がしますね(特に高負荷時の挙動)
>>283
おお。 >>288
ありえますね。
確かに 7.0R の SCHED_ULE は、たまに挙動不審になることがあるです。
で、今見たらパッチが出ているですね。
http://security.freebsd.org/advisories/FreeBSD-EN-10:02.sched_ule.asc
7.0Rでも、このパッチ当たるのかな。 >>289
8.0RでSCHED_ULEはさらに色々手が入って挙動が更に変わっているようです。
ahciのNCQ実験もしてみようとか考えたら一気に8.0Rへ、もアリかも。
一応、8.0RをCDブートしてahci有効にしてインストールも出来ました。
ブートメニューで6を押してブートローダに戻る
load ahci でahci.koを読み込む
boot でインストーラー起動まで行って普通にインストール
CD抜いた後の初回起動だけ同じ手順でahci.koを読ませて起動後に
/boot/loader.conf に
ahci_load="YES"
を記入すれば次回以降は自動でahci.koを読んでくれると。
後でfstab書き換える方法よりは
このやり方が同じ手間でも多分ハマりにくいと思います。 先週と同じくらいの勢いで実況してたらバーボン食らったが、
また設定キツくなった? >>292
リロードバーボンはずっとオン
バーボン食らうとROMもできなくなるのだけが
雪だるまより不便になったな リロードバーボン食らう人はどんだけリロードしてるんだか
もっとリロード頻度落とせばいいのに samba=5で目一杯書き込むと多分リロードの方のバーボン貰うよね とき を忘れてね?
わしゅう とかww
Hakutyou
raicyou
kagayaki
kirameki
SANNDA-BA-DO
mizuhofinannsyaruguru-pu >>295
専ブラだから書き込むと勝手にdat読み込むんだよね。
どうにかならんのかな。 >>298
読み込みには串でもさしておけばいいじゃんか
バーボン食らったら取り替え >>298
それ、かちゅ〜しゃだっけか?
ギコナビ使え。 >>294
あ、なんだリロードバーボンか
書き込みのほうかと思った >>171
今の鯖名っていちいちくだらない時事ネタばかりでセンスの欠片もないね
まあ虫けらレベルのカス脳味噌じゃしょうがないけど >>290
おお、その方法は /etc/fstab 変える方法よりも賢いですね。
で、httpd ですが、
ベースメントはある程度増やすにしても、
たぶん「のりしろ」を大幅に増やしておくという方向性なのかなと。
へたしたら8192とかそんなのね。 で、8.0R は 8.0R で色々と微妙なので(下記リンク参照)、
8系でいくなら 8.1R からがいいと思われですね。
8.1R は今のところ、割と安産の様子。
http://security.freebsd.org/advisories/FreeBSD-EN-10:01.freebsd.asc
例の「emだけ別にドライバ入れてなんたら」とか、
手間のかかることをしなければいけない確率も、
確実に減少するだろうし。 オートリロードだから使うのやめろとか本末転倒な奴が居るな
何のために1Gbpsも確保したんだ
リロードバーボン緩くしないとトップスピードも鈍くなるので
hayabusaの設定ゆるめにしてもらえませんか? >>305
よくわからないですが、
サーバ別とか、今できるんだっけか。 デンマーク戦は勝つか引き分けで決勝トーナメント進出という条件に
なったので、さらにすごいことになりそう。 んで、今後の流れはどうするんです?
kamomeに詰め込むんですか? >>307
Atlantaの時に誰かがゆるめていたはず
やり方はさっぱりわからんですが 出来るか否かなら可能だったと思います こんにちは(´・ω・`)
昨日の鯖落ちって結局何が原因になるの?
トラフィックの急激な増幅に伴った・・・
そもそも、鯖落ちの要因をはっきり把握してない俺 >>311
落ちてないよ。
ただ、中の小人さん達が出払ってしまっただけ・・・ >>312
つまり、httpd・・が上限を超えて・・・
ってことですかー もう1:nでサービスするモードに切り替えた方がいいんじゃね?
Speedycgiが使えないって言うけど代替物が間に合わなくてもCPUは余ってるんだろ 色々改良案が出たけど、httpdを増やすだけで何とかなりそうなhayabusaが恐ろしいと…
kamomeは8.1を入れて、実験機扱い。ってのはどうですかね?
ただ、実況系が無いと、負荷がわからないかな? >>303
8192とは凄い数字…live28導入時の見積もりから実に10倍以上ですかー。
それでも大丈夫そうなhayabusaたん、恐ろしい子。 >>303
サッカーの3戦目は試合内容に関わらず、どかーんが来そうなので、
httpdを8192する作戦は、是非是非ですね。 メモリを24GBも積んでるんだし、httpd売り切れで繋がらなくなるより全力を出し切る設定にしたほうがいいと思う
httpdの最小待機数も増やした方がいいような >>321
それhayabusaだけ?
tsushimaもフリー? >>321
hayabusaのセッティングが固まるまでだろ
人が多くなきゃ昨日のhttpd売り切れも100Mbpsの壁が幻だったことも判明しなかった訳だし 遅れてましたが、oyster243取替え用のbbq2/m2 at tiger3546、ほぼ仕上がったので、
移行の準備にとりかかる予定。
で、oyster243にsshで入れないので、
これから一度リブート要請入れます。 >>324
移行の時間帯はBBQチェック出来なくなるって事はありますか? >>325
bbq.2ch.net が動いているので、
そうはならないです(はじめから1台死んでもそうはならないように作ってある)。
で、セカンダリの方(bbq2.2ch.net)が終わったら、
次はbbq/boo/hack72/mあたりの取替えかなと。
(たぶん上記まとめてA-tiger1台に同居でいけるのではないかと)。 >>323
サッカーないときは全鯖規制と板別規制は戻してくれよ… rootたん、メインとセンダリに分けてるのを1台にすると、鯖落ちの時に機能しなくなるのでは?
メンテの際にも、完全に使えなくなるわけだから、セカンダリをメインと同じ鯖に置くのはどうかと…
1台に纏めた時、メンテや鯖落ちの場合BBQチェックを無視するのかな? >>328
ん、bbqとbbmについては、その2台をまとめる気ないです。
今
bbq: bbq(cobra2245) + bbq2(oyster243)
bbm: m(tiger2513) + m2(oyster243)
予定:
bbq: bbq(新) + bbq2(tiger3546)
bbm: bbm(新(bbqと同居)) + bbm2(tiger3546)
なので、bbqとmを合体させて、
今よりも1台サーバを減らすというだけのことで。 それはproject pekoの終わりも意味するのか・・・・ 規制全て解除されたときに耐えうるのかをみてみたいw
しかしこれは叶わぬ夢だろうww >>329
なるほど、bbqとbbmのメイン側だけ別々の鯖だから、新鯖1つに纏めるのか
いらぬ心配をしてしまったようだ…orz なんか一部au民がおかしいんですけど。運営の身内の死を望むバカ沸いてますね。
そいつら見てると、auの為だけに2ちゃんのシステムを手間隙かけて変えるよか、denyにした方が健全な感じがしますね。 >>327
サッカーの時だけ解除しても急に人は戻ってこない
荒らしがいるのなら今のうちにログ貯めとけ >>342
先週の月曜は日本のサッカー終わったらすぐ規制を元に戻したじゃん… bbq2 と m2 関連の DNS 設定変更は、
明日出す予定。
で、TTL=3日なので、
最大3日かかって徐々に変わる予定。
切り替わり終わったら oyster243 は退役へと。 >主に未承諾さんとサザンさんへ
既に新 bbm2 と m2 は動いています。
データの自動同期も既に動いています。
ログインの方法は前と同じです。
BBMのほうはDNSサーバのIPアドレスが変わった時に、
中身1箇所ちょさないといけないです。
明日申請の際に、私がやっておくます。 >>346
「ちょす」は伝わらないかもしれませんよ。 >>346
あれ?おいちゃん、「ちょす」は方言ですぜ。しかもうちの地方の。 >>343
つーか週明けに比べて週末の規制緩すぎ
まさに終末 ちょすってなに
ちょすってつかうちほうってどこ
とくていまだー? ぐぐってみたけど
そ、そんなとこちょすっちゃらめぇ・・・///
これで用法あってる? >>352
・・・ちょしちゃ・・・
でしょうね。うちの地方では使います。 >>352
微妙に間違ってる。
やめてけれぇ・・・///そんなとこちょしたらいってしまうぅ///
こんな感じだと思う。 「ちょする」の意味も知らないで、それでも運営家族か
「むぎゅ」ぐらい頻出の呪文だぞ ちょうおんぱでかがよってこないってやつ
あれってこうかあるの >>361
ネズミ除けの方なら20歳以下には聞こえて非常に迷惑 明日の設定変更お願い @ hayabusa は、
これでいこうかと。
(現状)
最初にhttpdを1024個起動し、アイドル状態のhttpdが常に704(703+1)個以上に
なるように起動数を変化させ、非常時には待機数を2048個まで増やす設定
StartServers 1024
MinSpareServers 703
MaxSpareServers 1024
ServerLimit 2048
MaxClients 2048
MaxRequestsPerChild 10000
MaxMemFree 2000
↓
(変更後)
最初にhttpdを1536個起動し、アイドル状態のhttpdが常に1024(1023+1)個以上に
なるように起動数を変化させ、非常時には待機数を8192個まで増やす設定
StartServers 1536
MinSpareServers 1023
MaxSpareServers 1536
ServerLimit 8192
MaxClients 8192
MaxRequestsPerChild 10000
MaxMemFree 2000 日本戦の前に今週はなんか盛り上がりそうな試合ありますか? 合わせて、
#
# Increasing maximum length of the queue of pending connections.
# (Default value is 511)
#
ListenBackLog 4096
↓
#
# Increasing maximum length of the queue of pending connections.
# (Default value is 511)
#
ListenBackLog 8192
もやってもらおうかなと。 speedycgiの512 はあんなにいらんな
とは言ってどれくらいにしとこうか
128 にしておこう ← 根拠なし した
#!/usr/local/bin/speedy -- -M128 -b1048576 -t660 -T/md/tmp/haya
>>370
後のない同士のフランスー南アくらい?
もしくは明日の北とか
てかウィンブルドンも始まるのか 日本戦も夜中だからどうかな
前だと ポルトガルVS北朝 明日の20:30キックオフくらいかな まだ 64 使われたのすら、見たことがないです。 < hayabusaのspeedy_backendの数
投稿バイト数がでかいと多くなる傾向なので、
ジブリとかアニメとか、AA連投系があると見ることもあるかも。 ♪ ◆/y.Ychk2JQ
うぜえからNGしようか思案中 >>370
22日深夜のナイジェリアVS韓国とギリシアVSアルゼンチンの結果で
韓国の決勝トナメ進出が掛かってるから、2ちゃん的にはこれかな?
ただ、24日深夜の日本戦と同じで夜中の3時過ぎからだからなぁ そもそも3戦目はどの試合もゴールデンタイムでの放映が無いんだね。 現地でのゴールデン(20:30〜)で同組2試合が同時試合スタートだからね >>376
それは来月9日の耳をすませばまでお待ちください
あれのラストはコマンドー以上の勢いに加え、1スレ300KB前後になるくらいのAA集中があるので と思ったら、A・C・F・Gの3戦目は日本時間23:00スタートなんだな >>368 の心は、
・いつでも相手可能な(アイドルな)httpdを常に1024以上用意しておけば、
とりあえず急に来ても事足りるだろう
・平常時はhttpdの数が足りているなら、必要以上にhttpdを増やすよりも、
メモリは他の用途(バッファキャッシュ等)に使えるようにしておこう
・でも、実況サーバには常識外れな量のリロード要求が押し寄せることがあるから
(例: 昨日の試合終了時)、httpdの実行可能数のマージンはとても大きくとっておこう
といったかんじです。
>>381
しってますw
7月のジブリ連続月間が、チューニングのもう一つの機会と見ています。 あとは、>>289 の SCHED_ULE のバグ修正パッチが
現在の maido3.com なサーバのインストールパッケージに
うまく適用できるかどうかを調べてもらって、
もし適用できるなら、live28 と hayabusa への投入を手配しようかなと。 で、、、。
今 mod_speedycgi2/mod_speedycgi2.c を読んでみたら、
なんと最近の mod_speedycgi は、
スレッド対応環境でも、動くようになっているっぽいです。
#if APR_HAS_THREADS
static apr_thread_mutex_t *speedy_mutex;
#endif
といっても、単純に排他制御をちゃんとやるようにして、
worker MPM でもとりあえず動くようにした、というものっぽいです。
#if APR_HAS_THREADS
/* Speedy routines are not thread safe */
if ((rc = apr_thread_mutex_lock(speedy_mutex)) != APR_SUCCESS) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, rc, r,
"Cannot lock speedy_mutex");
return rc;
}
#endif
それでも、試してみる価値はある気がします。 こんな記述もありました。
やはり、
> worker MPM でもとりあえず動くようにした
ということの模様。
#if APR_HAS_THREADS
/* Two problems with threaded mpms:
*
* Speedy routines are not thread safe. We can workaround that with a big
* lock, though that may cause excessive waiting when Maxbackends
* is used.
*
* Frontends are sent SIGALRM to wake them up, and signals don't get
* delivered to the waiting thread.
*/
ap_mpm_query(AP_MPMQ_IS_THREADED, &is_threaded);
if (is_threaded)
return log_scripterror(r, HTTP_FORBIDDEN, 0,
"cannot use mod_speedycgi with a threaded mpm");
#endif というか、
> "cannot use mod_speedycgi with a threaded mpm");
だから、わざととめてあるのか。>>389
とりあえず、これはもっと後で試すかんじですね。
SunOS さんが言われていたように、これだけ別インスタンスの httpd にやらせる、
みたいな手の方がいいのかも。 この時間でもこれだけ跳ね上がっているのは
酷過ぎる審判の欧州びいきの成果かな?w しかしね たらこ裁判資産差し押さえで 運営びびってヤバイの規制は判りやすくていいけどね
人すくな杉 鯖代払えない 鯖統合移転頻繁 継んない さらに人居なくなる 悪循環だと思うんだ
つうかあ いつ2ちゃん閉鎖するんですかあ? それぐらいは言う義務があるとおもうんだ
さんざんおいら達の世話に成って来たんだしい ねえ運営さん。 おれはあると思いますwww 守りに入ったら2ちゃんじゃあねえwww よくもまあそこまで根拠ゼロの妄想を並べられるもんだ… 5分アベレージ109Mbps=13.6MB
1時間で560万PV 5分で46万PV 10秒で平均15550PV
1PV=平均8KB
大体こんなんだな
ブレーメン28000行ったから瞬間的には200Mbps近くいってる感じかな
祭時はトラフィックの10秒アベレージ見たいな まず、bbq2 / m2 関連から。
(現状)
+bbq2.2ch.net:206.223.151.220
+m2.2ch.net:206.223.151.221
&niku.2ch.net::nikuns2.peko.2ch.net
&bbm.2ch.net:206.223.151.221:b
(変更後)
+bbq2.2ch.net:207.29.225.195
+m2.2ch.net:207.29.225.196
&niku.2ch.net::nikuns2.2ch.net
+nikuns2.2ch.net:207.29.225.195
&bbm.2ch.net:207.29.225.196:b 先生∩
kern.ipc.somaxconn = 32768では足りないと思いますがどうでしょう?
MSLごにょごにょして無ければ、1コネクションがクローズするまでに最短で60秒(でしたっけFreeBSDのTIME_WAIT状態)。
先日のリクエスト最大5459/10秒。で、5459×6 = 32754コネクション/60秒。
使い果たしてる気がしますが、見当違いな事言ってたらゴメンナサイ。 >>410
変更完了しました。
新しいサーバにリクエストがきはじめました。
>>414
ん、kern.ipc.somaxconnは「listenキュー(つまり、つながろうとするやつ)」
の最大数だったような。
「つながるやつ」の数の最大値は、
%sysctl kern.ipc.maxsockets
kern.ipc.maxsockets: 65536
だった気がしますです。 >>368 依頼済。
>>371 も合わせて依頼済。 >>415
なるほど。わざわざ解説ありがとう。
お邪魔しました… 見せてもらおう、2ちゃんねるの新型とやらの性能をw これからhttpdの再起動入ります。
少しの間、hayabusa.2ch.net へのアクセスができなくなります。 >>418
いえいえ、そういったご指摘はとてもたすかりますです。 httpd の設定変更 @ hayabusa 完了。
一度だけこれ貼っておきます。長いので注意。
______________W_______CC____________C___________________________
__________CC______C__C__________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
___________C____________________________________________________
_________________________C______________________________________
___________________________________C____________________________
__________________W_____________________________________________
_______________C____C___________________C_______________________
_____C__________________________________C______C________________
__C____________C____________WC_____CC___________________________
_________________________C____________________________C_C_______
_______W___________C__________________________________C_________
__________C_C______________C_____C_______________C______C_____C_
__C____C__________C___C______________________C______C___________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................ 海で泳いでいるトライアスロンの選手たちを
砂浜から見ているように見えた
Wが水しぶき >>root▲▲ ★さん
ところで以下の案件はどうなりましたか?
2ch特化型サーバ・ロケーション構築作戦 Part48
http://qb5.2ch.net/test/read.cgi/operate/1276848371/324-
路線b)
PCSVからの投稿は一切お断りする
何か進捗とかあれば、嬉しいです。
>>430
あれから特に何も。
ちなみに今かかっているらしい ezweb.ne.jp 規制って、
「時限解除」みたいなのって、あるんだっけか。 >>431
広範囲地震発生とか
自然災害時には一旦解除はあったような。 >>432
いや、そういうのではなく、通常の流れで。
というか多重に規制されたのかな。
#6/21 http://qb5.2ch.net/test/read.cgi/sec2chd/1277038042/
#また再発だよ
_2CH_\.ezweb.ne.jp ということは、>>433 の規制がもしEZwebからの書き込みに対してのものだったら、
a) をやろうが(私はやる気ないですが) b) をやろうが、状況は何ら改善しない、
ということになりますね。
ということで仮に b) をやるにしても、
まだかなから_2CH_ezweb.ne.jpが外れるタイミングでやらないと、
意味ないような気がします。 >>431 root▲▲ ★さん
>あれから特に何も。
あらw
では、次の日本戦終わったら、少し考えてみて下さいませ。
>ちなみに今かかっているらしい ezweb.ne.jp 規制って、
>「時限解除」みたいなのって、あるんだっけか。
路線b)やらないと、無理かと……
レス有り難うでした。
>>435
今 >>433 のリンク先を見ましたが、
やっぱり >>434 なような。 >>435
rootさんは規制の判断者でも実行者でも無いよ。
既にあるルールの実装しか行いません。
b)案は既にあるルールに則ってるから行えるだろうけど>>434と、
また他の鯔がほとんど反応無いから自重してると言うのも多分あるんじゃ無いかと。
auの件はまず規制判断・実行者の方をあなた方が説得出来ないと駄目なんじゃ
無いですかねえ。
>>433もPCSVじゃ無いし。 >>436 root▲▲ ★さん
重ね重ね有り難うです。
まー、気長に待ちますです。
では、この辺で失礼いたします。
> 今 >>433 のリンク先を見ましたが、
> やっぱり >>434 なような。
数スレ前でMacOSXな自鯖でのchangi設定を質問したものです。
MacOSXには、nullfsがなく、blind mountもなく、unionfsがあるとはいうものの
標準なファイルシステム (HFS+)で動作させているときにはどうも使えないことが分かったので
Fuse (MacFuse)をいれてunionfs-fuseをいれてようやくマウントさせることができました。
2.5インチの内蔵ディスクだったので今ひとつのレスポンスだったのが
ヌルッとレスポンスが速くなったようです。 http://qb5.2ch.net/test/read.cgi/sec2chd/1276415362/728
> 728 :ちきちーた ★ :2010/06/21(月) 16:10:20 ID:???0
> 近々 nanimameはなくなる予定
> live28,hayabusaで全ての機能が動けばok
> 新しいサーバは lie28 からシステムをそっくりコピーする
いつですかー? 2chには759もの板があるんだ
めんどくさいぞー
すごくめんどくさいぞー ただ単にリフレッシュでnamidameという名前がなくなるだけでしょ namidameの名はあの方がくれた名前だから存続しそうだな こういうときにはやっぱり板ごとのPV数とかROM人数とかわかればなと思ってしまう
書き込みは少ないけどROMは多い板とかもありそうだし >>434
葱さんが報告して返答貰ったけど、
対応完了してないみたいだからreffiさんは放置してるんじゃないかな。
>>433のはEZ番号有の荒らしだから報告すればすぐに対応完了して解除になると思う。
報告人作戦返答処理スレッド★19
http://qb5.2ch.net/test/read.cgi/sec2chd/1276260477/47,146 ゴールの瞬間に本スレが立ってなかった(´・ω・`) 新しい日記がうpされた模様。
http://www.maido3.com/server/zousan/nikki182.html
hayabusaサーバに何かあれば、今後はここが増えていくことになる、と。 >しかもhayabusaサーバーには、
>httpdの最大接続数をまだまだ増やす事が出来るだけの余裕があります。
なぜかフリーザさんの声で脳内再生された ちょっとだけ書き込みに時間がかかったけど、4点目も平常運転 50Mちょい
だけどreceiveの割に送信してるわねえ httpdの最大接続数をまだまだ増やす事が出来るだけの余裕がある・・・
なんで、最初から増やしておかなかったの?
やっぱり負荷テストって事で控えめだったんですかね... 今ゴールラッシュですが重くないですね
すげーなwwwwwwwwwwwwww ,ヘdヘ
▼/wヘ ▼
〈_(・ω・)_〉 次はコートジボワール戦か…
.c(,_uuノ
初期起動数1536は増やし過ぎだったとか。
いずせにせよ日本戦までに微調整するかんじなのかなと。 >>470
たまってるhttpd処理の所ですかね?
今の設定って要求多いと数値が多くなる可変設定でしたよね?
一気に要求が多くなったのかな? 誰かログインできる人がいないとわからないな・・・
多分httpd周りなんだろうけど あるいは常に待機させる最大起動数1023が大きすぎとか、
Backoffが8192も要らなかったとか、
いろいろな場合が考えられますが、
いずれにせよ肌で感じないことには何とも。 実際に実況板にいた身としては鯖が重くなった感じを受けませんでしたけど?
SSDのプチフリとかまったく別の要因だったりして。 >>478
アクセスしたときにhttpdが足らなかったり問題がおきたりして繋がらない感じかと
受信が一気に上がったし >>480
これかな?
あとhayabusaでは問題無いけどメモリも。
>110 [2010/06/15(火) 12:26:34 ID:???0 BE:1094843-DIA(113355)] root▲▲ ★ <>
>
> httpdが増えてくると、起動がかかって数だけ充填されるまでの時間が
> 無視できなくなりますね。その間は不安定な状態になるし。
> httpdが可変したときの準備による落ち込みなのかな? > 「Nehalem版Xeon」であるXeon 5500番台に対応したIntel純正マザーボード。
却下 >>484
;;*。+ _、_゚ + ・ 人に薦めるのは自分も欲しいからでしょう!自分でも試しましょう!
・.(<_,` )_゚ ・ なあに、貴方の行動に皆も歓声上げますよ!
/,'≡ヽ.::>
 ̄ ゙̄-' ̄`-´ とりあえず帰宅。
今見てもわかんないな。
とりあえず httpd は最初より*減ってる*。
%!pgr
pgrep httpd | wc -l
1320 そういえば、これにレスするの忘れてた。
>>439
うまくいったですか。 一時的に、このへんまで増えた形跡あり。
_____C_____WC______________C________C______CC___________________
C_C_____CC____C_________C__C__C____C__C__C____C______C__C____CC_
__W___W________C_________________C___C__C__C________C__W______C_
____________CC__________C_____W___________C___C_____C__________C
_________________C_______C________________C________W_C__C_______
_________C_________WC____________C___C__C______C______________C_
_________________________________C__C__C__________C_............
.........._........__..................._.......................
..............._..........._..._...................._...........
.........................._......C..............._........._....
........._.................__..._..........._...._............_.
.__........._......._._......................................_..
.__.._.....__..............................._.......C...........
.............._.........................._..............C..__...
............................................._........_.........
..._..._...._............_......................._..............
....._.............__....................C............._........
.............................._.._.._....C....__............__..
................................_......_..._........C...........
..._..........._....._......C...._..........C.._.._............_
............._................._.._.............................
......................_............._...........................
.....C.................................._....._.......__._......
...._................................C........................_.
_..__C.__._._._____.___..__._______..._._._._C.__.__.____.____C_
_.C___.._.___._._._____..._.._..._.___....._._____..__C_.____C._
.____._C......_._..___C___C.C_.____._..._.C..____.._.C__.____...
.__..._.._.__.___..C_...__..._C_._.____.____._._C._.._..._......
_.._..__._._.C__.C____.C__.__......______.__.C.._.._....C__.._._
._._._W..__C.C__..._._______.__._C____....._C_..___._.__..____._
____W__.______......_.____C_.__..._C...__.._._..C_C.._..._...._C
_____._.___._.._.___..._____.._______._._..._...._..._.._.C__...
.C_C___.C__WC.CC._._C._..________..__._..__..C___C____..___.____
C....______.__.C.__.._._._._._._.W___C.._._..__._..C__...C__C___
.._.__._C.._.__...____._C_C..___..C.C._._......._.C._..__._..___
___._.C..._._.._.__.._.._W..__._._.._.__C.C___C._..__._..._.....
C___._.__.._C.._.__......_.._.C.._._._.._.._._.._......_...__C__
.__.C_...__..._..._._._._____.__.___.__........_._.___..._._C.__
____._...._____.._._....C__._._C_C_._.....C__.___.___...____....
___C__.C..__._.__._..____C.__..____._.___..._._____.CCC_.__.___.
.W_.._.._.__.__.C.__C__.__..C.___._..C.._.._..____.__.__.__.__C.
__.__._._.___W._.___C__C..__.C___....._..___._..._..._.__C._...C
._...__.._..__._..__..____.__......___..._______..C......__.._..
_._.C.W_.C.C__.W__._.._...C__.__.C._._._.___.___._...__._._..__.
._.C___.C_...____._.._._.C._C._._________.___.___.._..W_._._.__C
........_.C.._..______.___C__..______._____.__.C_....C_C___.._._
.._.C...........................................................
(以下、のりしろのみ) >>484
http://www.supermicro.com/products/motherboard/Xeon7000/7500/X8QB6.cfm?SAS=Y
最大メモリ256GBなんて化け物が
マザーボードだけで25万円超しますけど
これのフルスペックだと200万円超ぐらい?
冗長性の問題は出るけどレンサバ屋がこれに顧客を大量に詰め込んだら
管理コストが減って元が取れるんだろうか とりあえず、今の状況証拠としては、
・初期値1536が若干大きすぎかも
・待機数1023が若干大きすぎかも
といったところが考えられるかな。
今日はもう負荷かからないんでしたっけ。 で、状況証拠からみた結論としては、
・基本的に「のりしろ」だけ増やしておけばよさげ
ということになるのかな。
いずれにせよ、もう1回は観察したいところ。 >>492
私が見られる範囲では、特に変なログはなさげです。 で、いずれにせよ今日詰まり気味になったのは、
いずれも書き込み集中時だった、ということでおkなのかしら。 >>495
ですな。
http://traffic.maido3.com/KW2n/P4v7/y2X9/day.png
これ見ると、Sentの凹のところでRecvが凸になってるので
どーんに対応し切れてないようですな。 キスシスでどーんしてごめんなさい
でもびくともしないんだなあ >>491
・初期値1536が若干大きすぎかも
・待機数1023が若干大きすぎかも
>493
・基本的に「のりしろ」だけ増やしておけばよさげ
これってのは初期値・待機値を減少してメモリへの負荷を減らし
のりしろ(最大値?)を増やすチューニングって事ですか? >>499
ようは、
StartServers 1024
MinSpareServers 703
MaxSpareServers 1024
ServerLimit 8192
MaxClients 8192
MaxRequestsPerChild 10000
MaxMemFree 2000
にするのはどうか、という話です。
ServerLimit と MaxClinents 以外、変更前の値にしてみると。 >>491
なんとなく逆のような。
>>489
をみると3072ぐらいまで起動しているので、
一気に1000プロセスforkしているようなかんじなので、
起動が間に合っていないような。
雪だるまのときbackendではMaxSpareThreads 3072ぐらい
だったと思うので、それぐらい元々立ち上げておいても
よいのでは。 >>410
207.29.225.196の逆引きが出来るようになるといぃよねーねー♪
りょうかいしますたm(_ _)m深謝 >>491
現在 チリ vs スイス
3:30 スペイン vs ホンジュラス
さっきのが、ポルトガル 7-0 北朝鮮
「やめて!北ちゃんのHPはもう0よ!と言うかマジ帰国後ヤバい」以上のは今日は
多分無いと思いますw >>501
いずれにせよ、forkがどっさりがつらい、
は、間違いなさげですね。
で、3072までいったということは、
常に1536個用意しとけ、が多すぎるのかも、
というのが私の読みで、
そんなの最初から多くしときゃいいじゃん、
というのが、>>501 さんの読みか。
いずれにせよ、基本forkしないでやりすごせるのがよさそうですね。
初期値 4096
暇になっても減らないようにする
残りが 256 を切ったら fork しはじめる
のりしろは 8192 まで
とかですかね。 この後の地上波
6/22(火)
23:00 A フランス vs 南アフリカ NHK総合
6/23 (水)
23:00 C スロベニア vs イングランド NHK総合
6/24 (木)
23:00 F スロバキア vs イ イタリア TBSテレビ
27:30 E デンマーク vs 日本 〇 日本テレビ MaxSpareServersを4096くらいまであげて一度forkしたプロセスは
どーんがきたあとすぐにkillさせないでMaxRequestsPerChild回数分働いてから徐々に死んでいただく、とかどうでしょう。
これでfork&killのコストも下がるはずですが大きいのは触ったことが無いのであてずっぽうです。 カウンターの店員さんは多めにスタンバイ、
通常はお仕事やや暇になってもがまんがまん。
御客押し寄せて忙しくなり始め、やばそうなら増員開始、
店側は最大戦力8192まで投入できます
こんな感じですか。 >>505
> そんなの最初から多くしときゃいいじゃん、
> というのが、>>501 さんの読みか。
です。
CPU/メモリが十分なら、物量作戦で
いくのもよいかと。
bbsdをいれるとか、prefork/workerを分けるとか、
よりスマート(?)な方法もあるかもしれませんが。
>>503
ttp://m2.2ch.net/_service/ が403返してきていますー いっそのこと8192個立ち上げて、待ちかまえてみるとかw 忙しいときに新人を入れようとしすぎなのね
MinSpareへらせば? ◆【宇治金時】負荷監視所_20100505
http://namidame.2ch.net/test/read.cgi/liveuranus/1273040905/651
651 名前:今、天王星のwiki見てきたら軌道傾斜角(i) が0.774°だった[sage] 投稿日:2010/06/21(月) 22:19:05 ID:veYB/iYv
1731res/min [フジテレビ]2010FIFAワールドカップ
http://epg.2ch.net/test/read.cgi/tv2chwiki/1277126301/
レス数的には日本戦並みだったのね。 メモリ8Gだと、
2048ではswapが起こって、
1536でもswapが起こりはじめるかんじだったと。
で、結局今の設定
↓
StartServers 1024
MinSpareServers 703
MaxSpareServers 1024
ServerLimit 2048
MaxClients 2048
MaxRequestsPerChild 10000
MaxMemFree 2000
に落ち着いたと。
今度のサーバは、その3倍のメモリ24G。
さて、どうするのがいいか。
できる限り多めに配置して、非常時以外は固定で動かす、
という感じなのかな。 実装メモリは単純に3倍ですが
changi設定に使われているmd分の確保領域などを考えると
実際に使えるのは8GBの3倍の24GBという計算ではありませんよね?
倍数計算はもう少し増やせるのでは? >>516
確かにそうですね。
またしてもじっくり考えて、明日昼間に変更依頼するパターンかなと。
基本は「できるだけforkを避ける方向性」にて。 >>63
3倍どころか4倍になったぢゃないかー λ=3 >>434
シベリアだとBBQも規制もスルーで書けるのでないかと
というか、#6/12の分は規制中も続けてた分のような
今は再発してないはずだけど
ucomのBBQ済みので延々とコピペし続けたのもだけど
シベリアもBBQを入れてしまったほうが
BBQでも書けるのはシベリア文化なんだろうけど... ブリザードはシベリアの特色ですのでどうか取り上げないで下さい_ノ乙(、ン、)_ >>521
仕方あるまい、度重なる規制で 報告厨が辺境まで散って行って、
自分の思った通りの2chを 周囲に押し付けた結果だよ…
じっぷらなんか 大概のコピペは 「ウザイねぇ」で済まして、
極稀に 金沢荒しと雑談する奴までいたのに… 変化を恐れる人間は2ちゃんねるには必要ないです。
変わった事実を受け入れられない人は2ちゃんねるには必要ないです。
多分 BBQのさらに上のシャットアウトリストとか
完全にどこにも書けなくするってのはポリシーに反するのかもしれないが
しかし、永久規制を重ねても解決には至らない、どっち側も
まぁ、スレ違いですが >>515
StartServers = n(MaxSpareServers) + (1-n)(MinSpareServers)
みたいな計算式とかないの
どーん時のΔprocsをおさえたいんだよね さて。
・初期値は思い切って4096で
・すいている時でも、(4096-512)よりも少なくならないようにする
・混んできて残りが512を切ったら、最大8192までforkするのを許す
というかんじでいこうかと。
今 live28 で使っている初期値も、
できるだけ大きな値でかつスワップしない値、を探して、
いろいろ値を調整した結果、そうなったものなので。 StartServers 1024
MinSpareServers 703
1024 - 703 の差分は、変えないほうがよさげかな。
4096 - (1024 - 703) = 3775 か。 もう少し一般化するか。
今の live28 のパラメータから割り出すと、
StartServers N
MinSpareServers (N - 320 - 1)
MaxSpareServers N
ServerLimit N + M
MaxClients N + M
MaxRequestsPerChild 10000
MaxMemFree 2000
N: 初期値
M: マージン
というかんじなのかな。 320も一般化するか。
StartServers N
MinSpareServers (N - k - 1)
MaxSpareServers N
ServerLimit N + M
MaxClients N + M
MaxRequestsPerChild 10000
MaxMemFree 2000
N: 初期値 (live28 では 1024)
M: マージン (live28 では 1024)
k: 平常時の込み具合 (live28 では 320) どーん対策なら早めにfork開始したほうがいいのでは?
fork開始は2048切ったあたりからとか >>507 も加味するか。
StartServers N
MinSpareServers (N - k - 1)
MaxSpareServers N + m
ServerLimit N + M
MaxClients N + M
MaxRequestsPerChild 10000
MaxMemFree 2000
N: 初期値 (live28 では 1024)
M: マージン (live28 では 1024)
m: アイドル定数(M >= m >= 0) (live28 では 0)
k: 平常時の込み具合 (live28 では 320) >>530
追い込まれるより先に fork してしまえ、というかんじですかね。
どっちがいいのか。
ゆっくり増えるならそれもありかもですが、
基本は断崖絶壁みたいなので、
個人的には「足りているならぎりぎりまでforkしない」というのもありかもなと。 >>531
N = 4096
M = 1024
m = 1024
k = 320
あたりかな。
あと、思い切って可変をやめてしまって、
StartServers N
MinSpareServers N - 1
MaxSpareServers N
ServerLimit N
MaxClients N
MaxRequestsPerChild 10000
MaxMemFree 2000
N: 終始この数で固定
にするという力技もありますが、微妙なところ。 で、>>533 だと、
4096 ではじまって、(4096 - 320 - 1) よりもひまなhttpdが少なくなると、
最大で1秒に1個の割合でforkかかるので、早めにforkかかるかんじになりますね。
>>530 なかんじ。 >>532
早めにforkし始めればCPUのidleも多いので処理しやすいかと思いましたが
どーんは瞬間的にやってくるものなので、あんまり意味ないかもです
奴らは常に想定を超えてやってきますしねw これでいってみるか。
StartServers 4096
MinSpareServers 3775
MaxSpareServers 5120
ServerLimit 5120
MaxClients 5120
MaxRequestsPerChild 10000
MaxMemFree 2000
N: 4096
M: 1024
m: 1024
k: 320
--------
StartServers N
MinSpareServers (N - k - 1)
MaxSpareServers N + m
ServerLimit N + M
MaxClients N + M
MaxRequestsPerChild 10000
MaxMemFree 2000
N: 初期値 (live28 では 1024)
M: マージン (live28 では 1024)
m: アイドル定数(M >= m >= 0) (live28 では 0)
k: 平常時の込み具合 (live28 では 320) >>535
> 奴らは常に想定を超えてやってきますしねw
そうですねw そんでは、>>536 の変更申請は午後1時あたりにでも。 万一 4096 でしばらく動かしてスワップが起きるようなら、
コンセプトそのままに、少しずつ減らしていくかんじで。 どーん用に3775個常に用意しておくって感じですね
素敵です >>536 で申請済み。
変更作業の際には以下同文。 今これ。
%pgrep httpd | wc -l
1076
これが変化する予定。 7.0はもうjemallocを使ってたと思うから、これ以上forkが速くなるのは難しいかな? 完了。
%pgrep httpd | wc -l
4097
>>546
おお、forkの速度問題ですか。 例のやつ。
________________________________________________________C_______
________________________________________________________________
________________________________________________________________
________________________________________________________________
____________________C___________________________________W_______
_____C__________________________________C_______________________
__________________C_____________________________________________
________________________________________________________________
_______________________________________________________C________
___________C____________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
_______________________________________C________________________
________________________________________________________________
____C___________________________________________________________
________________________________________________________________
________________________________________________________________
__________C_____________________________________________________
________________________________________________________________
________________________________________________________________
_________________C___________________C_____C____________________
________________________________________________________________
_______________C________________________________________________
________________________________________________________________
____________C_______________W___________________________________
________________C____________________________C__________________
__________________C_________________________C__C________________
____________________C_________________________C____________C____
__________________________________________C_____________________
____________________C___________________________C_______________
______________________________________________________C_________
C_______________C_______________________________________________
____C____C______________________________________________C____C__
___________________________________C______________C________C____
____________________W___________________________C_______________
_____________C________________________C_______________________C_
___________________________________________________C____________
________________________________________________________________
__________________C_____________________________________________
______________C____________________________________________C____
___________________________________________________C________C___
________________________________________________C_______________
______________C___C_______C_____________________________________
________________________________________________C_______________
________________________________________________________________
_____________________C__________________________________________
___________________________________________C____________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
____________________W_____________________________________C_____
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
___________________C____________________________________________
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................ 今日の中継は1試合だけか
34 6/22 23:00 A フランス vs 南アフリカ NHK総合
けいおん!!の放送日だけど、アニメ実況はどーんじゃないしなあw >最大で1秒に1個の割合でforkかかる
この割合を変更できればいいのになぁ 555(笑)
でも 板が無いのか・・・・・ アフォだな♪ MaxRequestsPerChild を小さくするとトータルでのメモリ使用量を節約できたりしないかな。
fork回数はもちろん増えるだろうけれど。 そもそもメモリ使用量を節約する必要はあるのだろうか >>556
今の 10000 は割と小さめと思っていますが、
httpd の数が増えてくると、どうなのかしら。
で、メモリ使用量もさることながら、
フレキシブルに数を変える効果とかの話もあるのかしら。 メモリリークが発生しても大丈夫なように一定回数応答したら殺してしまえってのが
この設定の目的だと思うので個人的にはもっと増やしてみてもいいと思ってる。 あ、日記更新されてる。
スペシャルセッティング2の説明が
>>536の計算式になってる。 >>561
投げたブーメランが全部自分に命中するんです(与党幹部) >>558
最近の仮想メモリ管理の実装はまともに勉強したこともありませんが。
一度あるプロセスに malloc() され、さらに実メモリ(swap領域を含む)が割り当てられた場合、
そのメモリ空間を free() すると、そのタイミングまたは、次のリクエストの処理前に
割り当てられた実メモリが解放されるのか?
これが yes であれば、 >>559 の通りなのですが。
プロセスが起動して、大きな実メモリを使用するリクエストを受けた場合、
そのプロセスに割り当てられた実メモリのサイズは、
その後の小さな実メモリしか使用しないリクエストの処理中も確保され続けるのではないかと。
で、プロセスの寿命を短くしてやれば、トータルでの実メモリの使用量を抑えられるんじゃないかなと思ったわけです。
今時のOSじゃそんなことはねーよじじー、ということであれば笑い飛ばしてやってくださいな。^^; 1500res/minクラスのどーんな書き込みがないと詰まった感を感じないですね datは500KB、各種htmlやsubject.txtは精々25KBだからそんなに大きいメモリ食うことあるんだろうか。 このままフルボッコの展開ならある程度の負荷が来るかも。 ちょっと重くなった
回線には余裕があるはずなのにDLの速度自体が落ちる感じなのはなぜだろう いろんな意味ですごいねー
組織の団結って重要なのね。 1秒間に処理できるリクエスト数はCPUが空いててもあまり高くないとか? きたく。
少し増えた模様。
%pgrep httpd | wc -l
4650
hayabusaサーバトータルの動きとしては、概ね想定通りの模様。 昨日も話題になってたけど、forkが始まると重いのかもしれないね 明日は、SCHED_ULE へのパッチがうまく当たるのかを調べてもらって、
当たるようなら当ててもらおうかなと。 >>581
ありえますね。
swapは今のところ使用せず。
まったくforkしない設定を、
試してみる意味はあるのかも。(>>533 の下の方のやつ) last pid: 28349; load averages: 1.29, 0.97, 0.94 up 5+04:56:29 08:25:27
4721 processes:1 running, 4719 sleeping, 1 zombie
CPU states: 7.6% user, 0.0% nice, 4.0% system, 3.7% interrupt, 84.8% idle
Mem: 9948M Active, 11G Inact, 1381M Wired, 472M Cache, 214M Buf, 557M Free
Swap: 24G Total, 24G Free ゴール来たけど httpd が増えることもなく、
詰まることもなく軽くこなしてしまった。
これだと設定変更の参考にならないかも。 最大数8192だとドーンと来た時にfork祭りになってまた・・・っとなりそうな気が
5000程度でMAXにしてみたらどうだろう? >>586
設定変更は様子を見つつ、ってかんじですかね。
まずは肌で体験しないと。 こうなったら試合終了後の神田愛花アナの爆弾発言に
ドーンの期待をするしかないか。
「フランスってホント空気読めないですね。」とか・・・ しかし、23:38あたりのグラフはいかにも実況風味。
http://mumumu.mu/bremen/hayabusa.html
2010/06/22 23:37:38 6731
2010/06/22 23:37:48 6097
2010/06/22 23:37:58 14555
2010/06/22 23:38:08 16424
2010/06/22 23:38:18 13175
10秒のうちに、アクセス数が2.5倍になる世界と。 ジブリではまず出せない急加速w
これがスポーツ実況なんだなあ 2試合が同時刻なので、テレビやネットで観るので精一杯の人もいると思われます saborinキャンセル出来ないですか?余裕ありそうなのでよかったら… hayabusaの転送量のグラフがモンサンミッシェルに見えてきた レスする奴が1人居たら30人はROMってると思え
あれ?実況民がGに思えてきた 今って実況でもAA規制が厳しいらしいんだけど
ジブリでテストするの期待出来ないんじゃない liventv
BBS_LINE_NUMBER=6
BBS_MESSAGE_COUNT=4096
4096だったっけ?てのは置いといてどの辺が厳しいのか書かんと >>597
けいおんの実況で作品に関係有るAA出したら埋め立て荒らしと判断されて規制されたとかいうのを見たような。 >>592
> だからなに?
>>591に対してでしょうか?
同時に2試合観るので(1つはPCで観てる方もいます)
実況をロムる事は簡単でもレスするのは容易ではない方もいると思います
言葉足らずですみませんでした 次スレ用意しておいたら●焼きされるくらいだし流れが速いジブリなんかはスレ難民出て勢い落ちる悪寒
%pgrep httpd | wc -l
4649
増えたままですね。
MaxSpareServers N + m
の m を大きくしたことが効いていると。
で、相変わらずswapは起こっていない模様。
last pid: 91961; load averages: 0.18, 0.16, 0.17 up 5+14:40:44 18:09:42
4711 processes:1 running, 4710 sleeping
CPU states: 1.9% user, 0.0% nice, 1.0% system, 1.1% interrupt, 96.0% idle
Mem: 12G Active, 9049M Inact, 1396M Wired, 974M Cache, 214M Buf, 11M Free
Swap: 24G Total, 24G Free
もう少し観察継続で。 どうやら、
sched_ule.c へのパッチ自体は、RELENG_7_0 の sched_ule.c (1.214.2.2)
にも当たるようだ。
以下を hayabusa と live28 に対してお願いする方向で。
<タイミングによりデッドロックが発生する問題(ULEスケジューラの不具合)の修正>
1) パッチを入手する
# fetch http://security.FreeBSD.org/patches/EN-10:02/sched_ule.patch
# fetch http://security.FreeBSD.org/patches/EN-10:02/sched_ule.patch.asc
2) パッチを適用する
# cd /usr/src
# patch < 入手したsched_ule.patch
3) 通常の方法でカーネルを更新する
4) リブート で、いきなり本番でやるとこわいので、
1. まずは実験環境で 1) 〜 4) がうまくいくかを試してもらう
2. うまくいくようなら、live28 と hayabusa に適用する
という手順でいこうかなと。 FOXのおいちゃんに「せっかくだから hayabusa で実験してみるか〜」って言われる予感 >>606
> 1. まずは実験環境で 1) 〜 4) がうまくいくかを試してもらう
調査をお願いした。 あ、ちなみに今 hayabusa で使っているのが SCHED_ULE なのは確認済みです。
%sysctl kern.sched.name
kern.sched.name: ULE >>606 >>609 がうまくいった旨の連絡がありました。
ちと私が今時間とれないので、
続きはちょっとあとで。 前へ進む旨のお返事をしますた。>>611
1) 仕込み作業(カーネル更新) # 少し時間かかる、動かしながら可能なはず
2) リブート
という手順を live28 と hayabusa で、たぶんそれぞれ実施する必要があるわけですが、
・作業は上記 1) 2) の手順、という認識で問題ないでしょうか
・もしそうであれば、1) はすぐやっておkです、1) ができたら連絡おながいします
・連絡いただいたところで、2) のトリガを改めてこちらで引きます
という内容を送りますた。 一羽の鴎もまあまあうまくいってるし(まだ日本戦を迎えてないから分からんが)、
次は新banana(i5+SSD+HDD+8GBメモリ)でpc13を作ってよ 突沸するような板がどれだけ入るかある意味楽しみ>NEWbanana i5に突沸するような板ぶち込んでどうするねん・・・
>滅多に突沸しない板 http://www.nhk.or.jp/fm-blog/200/50976.html
今日は一日“ゲーム音楽”三昧
8月7日(土)後0:15〜11:00(中断あり)
まだかなり先ですし、時間もアニソン三昧よりかは短めですが。
ゲーム音楽のジャンル?指定によってはかなり負荷が増えそうです。
#なんかこのホテルNWが変…… あああああああああ
それまでにFMアンテナ用意できるかなぁ… >>617
ループアンテナおすすめ
VHFテレビアンテナがあるならそれにつなぐのが1番 親愛なるちきちーた★様へ
2ch運用情報板にdocomo携帯からスレ立て荒らしが出没したので御報告に参りました。
docomo携帯規制発動をした方がよろしいかと存じ上げまする次第であります。
2ch大本営のご判断にお任せ致しますがピンポイント規制より全面docomo携帯規制の方がよろしいかと…
よろしくお願い申し上げまする。
2ch公式コテってちきちーたが言ってた
ま、だから何ってことだが >>616
>>669
これもそうだけど、BS2でやる2000年代アニソン特集の時間も決まってるね
8/14 午後8:00〜11:00
http://www.nhk.or.jp/n-stadium/anison/index.html
んで、その前にこれ
全駅停車!全部魅せます「銀河鉄道999」
8/9〜8/13 午後8:00〜12:00
http://www.nhk.or.jp/n-stadium/g999/index.html >>627
ぉぃ!ww
ところでrootさん、live28とhayabusaのリブートは何時するの? まあようするに●買えってことだ
中尾のおっさんもまだローン残ってるだろ >>626
ぼう○○党からもらった
ぼうえいきみつひで新鯖をかっt
ん?誰かきたみたいだから行ってくる… 札幌に来たことだし、その背後の巨大組織について調べなければ!
早速、聞き込みをしにススキノへ行こうっと。 >>627
それは・・・・スティーヴン・セガール? そういや背後で暗躍する謎の鯔、墨幕 ★なんてのもいたよな。 きたく。
>>631
うんこみたいなもんで、思い切り踏めば時期が早まるだろうし、
踏まなければそのまま幸せ、という感じなんじゃないかなと。 減ったと。
%pgrep httpd | wc -l
3911 ちょっと増えた。
%pgrep httpd | wc -l
4260 >>627
なんか、その割には韓国には弱いんじゃ?w
舐められっぱなしじゃんw >>612
> 1) 仕込み作業(カーネル更新) # 少し時間かかる、動かしながら可能なはず
> 2) リブート
hayabusa と live28 で、1) が終了した旨の連絡をいただきました。
順次、再起動の手配します。
まず hayabusa いきます。11:00 JST にはじめます。
問題なければ、15分程度で戻る予定。
その後 live28 にいきます。
hayausa で問題がなければ 11:30 からで。 さんびゃく
にひゃくきゅうじゅうきゅう
にひゃくきゅうじゅうはち
にひゃくきゅうじゅうなな
にひゃくきゅうじゅうろく
りいいいいいいぶううううううううううううううううとお ∧_∧
⊂(#・ω・) きょうの料理実況させろ!
/ ノ∪
し―-J |l| |
人ペシッ!!
__
\ \
 ̄ ̄
はやぶさはM-Vだから実際のカウントダウンは人がやってたっけ
H-IIAだと自動音声で萌えるんだけどなー ところでlive28,live29(hayabusa,tsushima?)が壊れたときはどうなるの? なんか再起動するといくつか現役スレ消えちゃうっぽい? スレの復帰は?
復帰してるスレと消えたスレがあるようだけど? 一応、全板復帰かけたつもりですが、
もう1回復帰しておくます。@ hayabusa 問題なさげですね。
あとは、明日未明を待つということで。
日本が3-0ぐらいで安全に勝つような、平穏無事な試合展開を期待したいですが、、、。 >>681
乙かれさまです
そんな試合になったら実況と試合後のニュース速報が大変なことにw 乙です。
これでsystemが突然CPU使うのは解消されたのかなぁ
さて私が試合見ると負けるジンクスがあるので今日はみないでおこう、頑張れ日本
こないだは実況してごめんね日本 サスペンデットで3日目突入とかパねぇっす、1回戦だけど http://stats.2ch.net/tubame.cgi
つばめがはやぶさのせいでごちゃごちゃになってる(hayabusaがLIVEではなくその他に振り分けられていて、live28がLIVEに振り分けられている)
直せる人直してちょ >>690
個人的には hayabusa 初の、2000res/min 超えを期待したいところです。
参考: live20時代の最高記録
(既にhayabusaは単体でこれを破っているはず)
> 1628res/m EX* 05/06/04 03:30 W杯アジア地区最終予選「日本×バーレーン」 live20 6/19に2000res/minを超えてた気がする
こんなレスもあるし
( ´_ゝ`)流石だよな俺ら の運用情報 part.3
http://qb5.2ch.net/test/read.cgi/operate/1260797404/98
> 98 名前:動け動けウゴウゴ2ちゃんねる[sage] 投稿日:2010/06/20(日) 13:03:24 ID:s8zW6g/w0
> 昨日のWCでhayabusa鯖が本気を出そうとしてたな
> ∧_∧
> ∧__∧ (´<_` ) スクリプト爆撃でもないのに2000res/min超え、100Mbpsの壁を突破とか流石だよなhayabusa
> ( ´_ゝ`)/ .⌒i 結局、httpdが足りなくなって本気を出す前に繋がらなくなったが
(以下略) 地上波は1700res/minくらいだったけど、同時にサッカーchが1000res/minくらいになってて
hayabusa全体では10分平均で2800res/minくらいになってたんだっけ 6/21のこれがhayabusaでの最高記録かな。
1731res/min [フジテレビ]2010FIFAワールドカップ すぐ上に書いてあるけど
1731res/minがhayabusaでの最高記録ではないな・・・ 市況2問わずhayabusaやtsushimaになったlive28全てでした BBONの設定弄りました?
いきなり食らって焦った。 BIG-server.com 2ちゃんねる向けハイブリッドTigerサーバー試作機を実戦投入
http://www.maido3.com/server/news/20100624.html
> レンタルサーバーの BIG-server.com(http://server.maido3.com/:北海道)
> では、2010年度版新サーバー「ハイブリッド Tigerサーバー」の開発を開始し、
> 試作機を2ちゃんねる様(http://2ch.net/)の実況用掲示板サーバーとして
> 実戦投入しました。
(ry)
> BIG-server.comでは、ハイブリッド Tigerサーバーを価格据え置き(予定)で
> 2010年 7月の発売を目指し、例によって2ちゃんねる様の協力で試作機を掲示板
> サーバー(hayabusa.2ch.net)に投入し、連続耐久テストを行っています。
http://www.maido3.com/server/hybrid-tiger/
hayabusaタイプのサーバーの正式名称が決まったみたいだね defaultは12Gじゃないかなー 2GBモジュールがいちばん単価良いし
ホームページにもそう書いてる品 >>705
「このサーバは極めて高速かつパワフルなCPUを備えています。
また、今回データディスクとして新採用されたSSD、従来よりも拡大されたメモリ搭載量ともあいまって、
特にアクセス数の多い大規模なウェブサーバーを運用されている皆様にとって、
日々押し寄せる大量のアクセスをスムーズに処理し、高い顧客満足度を実現するための、
大きな力となることでしょう。」
「2ちゃんねるでは未だ、この偉大なサーバを十分に溢れさせることができていません。
大きな器を十分に大きく使えるようにすべく、今後も皆様が日々生み出す高い負荷を受けながら、
日々努力していければと考えています。」
こんなところでしょうか。 今日は何時ころからが本番ですか?
昨日寝そびれてそのままなので、もう眠い 日々押し寄せる大量のアクセスをスムーズに処理はできるのだろうけど
まれに押し寄せるF5ボット攻撃は処理できるのだろうか
誰か試しに連中怒らせてみよう >>714
>>716だから今から寝ればちょうどいい鴨 >>711
このサーバーを酷使できるほどのサイトが、現状存在するとは思えんのだけどなw 日本中みんな寝過ごして全然大したことなかったりして 27:00〜だから今の内に寝て夜中に起きてくればちょうどいいんじゃないかな おまえら、目が覚めたら朝だった って展開を期待してるだろw そっすよね
私がいたところで何をするわけでもないし、
でも、現場にいつづけたい 訓練された実況民(@鯖負荷担当)でも、仮眠は大事ですね >>724
じゃあ7時間ほどずっとpcのモニターの前ではり付いててください >>724
事件は現場で起きてるんじゃない!
寝床で起きてるんだ! 明日起きたら、ちきちーた★の顔にキーボード跡というオチをきぼんw >>708
何故か、ヘンタイガーって読んでしまった
>>732
二人(以上)で赴く戦地ですね、分かりますん >>733
それは無理w
噂話では桑園あたりで起こされたとの話が・・・ >>732
北海道にそんな名前の世界遺産があったような 狐も▲▲も爆睡で朝5時ごろ落ちっぱなしというオチか。 これから oyster243 を電源落として返却します。
BBQ/BBMのアクセス共に完全移行したのを確認。 >>730
みろよ暇つぶしの芋掘りの影で泣いている普通の奴らを
書けない奴らから比べたら好きなところに書けるだけましだろうがとあまったれんなと
伝えてくれ。と言われた気がした。
http://sports2.2ch.net/test/read.cgi/entrance2/1276508071/258-
以下を送信。
↓
tiger3546サーバへの機能移行が完了しましたので、
oyster243サーバを返却します。
なお、該当サーバは既にhalt -pコマンドで電源を落としてあります。
以上、よろしくお願いします。 >>742
ウワァァ━━。゚(゚´Д`゚)゚。━━ン!!! oyster 来週は、BBQ(cobra2245)とBBMのサーバ(tiger2513)を1台にまとめて、
新サーバにする方向性かなと。
明日、tiger3546と同じスペックのサーバの手配を、
お願いする予定。 ちゃんと間違って違うPCを落とさないように書いとかないとw 今後もサーバーの再編制進めるんですかね。
流石にhayabusa級は入れないまでもi7/i5&SSD搭載で
メモリ減少した量産新型艦投入でいっきに再編制進みそう。 >>748
うむw
どっちかと問われれば、薬師丸ひろこのが好きだなwww >>724
現場にいつづけたいだ?
現場を見続けるだけで何も書けず
書き込みがないので現場からも人が去っていき
そういう中でもずっと書けない巻き添え者の事も考えろよ
半年間くらいこのスレに書き込めなくなったら
巻き添えで書けない普通の人たちの気持ちがわかるんでねえの。 人のことは知らんがな
自分のことは自分でやれ
わたしはお手伝いしません 俺が第二のFOXだとか言う猛者は
最近は北海道に乗り込んで来ないの? 札幌にいるけど、そんなことよりススキノで遊びたい♪
んじゃ今夜も遊びに行こうっと まあ半年書かけなかったらわかるよ。
人のせいで。
経験してみるといい。
自分が。 FOXのキャップって讃岐にあげるって言っていなかったっけ
わがままは狐の罪 >>742
> oyster243.peko.2ch.net を受け取りました。
>
> 上記サーバーの退役にあたり、該当サーバー以外で
> 作業を行わないよう、十分に注意して作業を行います。
とのこと。 少しやる気がでたようですね
人様に迷惑をかけない範囲でがんばれよ イタリア戦盛り上がんなーい
やっぱ日本戦じゃないと人増えないかな ブレーメンも8000台か
この時間帯のWCは人集めるコンテンツじゃなくなったか ピラミッドは期待できないけど、どーんはあるんじゃね? >>770
前の谷が深いほど、その前に立ちふさがる壁は高いじゃない?
みなさん27:30に向けて睡眠中かと 19Mbps
last pid: 88156; load averages: 0.77, 0.81, 0.82 up 0+13:05:54 08:09:18
4225 processes:4 running, 4220 sleeping, 1 zombie
CPU states: 6.8% user, 0.0% nice, 4.1% system, 2.6% interrupt, 86.5% idle
Mem: 9735M Active, 3551M Inact, 1183M Wired, 17M Cache, 214M Buf, 8933M Free
Swap: 24G Total, 24G Free
>>773
今満を持して>>773を貼ろうとした時に
貼れなかったらがっかりするだろう?
それが巻き添え。
おわかりかな? 41Mbps
last pid: 98779; load averages: 1.05, 1.32, 1.13 up 0+13:32:32 08:35:56
4544 processes:2 running, 4542 sleeping
CPU states: 5.8% user, 0.0% nice, 2.8% system, 2.7% interrupt, 88.7% idle
Mem: 10G Active, 3580M Inact, 1228M Wired, 15M Cache, 214M Buf, 8505M Free
Swap: 24G Total, 24G Free
そういやスケジューラのデッドロックは出てないですか?
まあ一度実験してるようだから大丈夫かなぁ >>778
今夜はFree全部使い尽くしてメモリ解放が発生しますかねぇ 1526res/min [TBSテレビ]2010FIFAワールドカップ・F組「スロバキア×イタリア」
かー 48Mbps
last pid: 1042; load averages: 3.94, 3.21, 2.15 up 0+13:46:39 08:50:03
4872 processes:59 running, 4813 sleeping
CPU states: 43.3% user, 0.0% nice, 20.1% system, 10.7% interrupt, 25.9% idle
Mem: 11G Active, 3723M Inact, 1302M Wired, 16M Cache, 214M Buf, 7097M Free
Swap: 24G Total, 24G Free
67Mbps
last pid: 1276; load averages: 3.52, 3.26, 2.46 up 0+13:51:28 08:54:52
4869 processes:5 running, 4864 sleeping
CPU states: 13.2% user, 0.0% nice, 8.1% system, 7.1% interrupt, 71.6% idle
Mem: 11G Active, 3788M Inact, 1299M Wired, 16M Cache, 214M Buf, 7083M Free
Swap: 24G Total, 24G Free
77.511Mbpsで余裕だなーとか言えるこの素晴らしさ 日本-韓国の決勝戦になったらはやぶさ陥落するかな(´・ω・`) >>795
土曜日の21時過ぎとか開始だとこれ以上無いかも知れんw
通常の観戦以上に、こう横槍はいりそうだしなw コアルーターあたりに。 hayabusaが陥落してるかおいちゃんが歓楽してるかどっちかだな そうなったらパケットがhayabusaに到達できないに100ペリカ >>773,790
のprocessの増加数と、Freeの減少量をみると、
1httpあたり、3M弱使っていそう。
>>536
最初からN = 6144で固定であげていてもよさそう。
おおきく振りかぶってと入れ替わりで日本戦が始まった 次スレを立ててもイイという解釈でヨロシイでしょうか(笑) libetbs は、、、。
あぁ、あのアニメか。
2xx 3xx 4xx 5xx URL
884 14 0 0*/liventv/dat/1277402460.dat
785 83 1 0 /livetbs/dat/1277402929.dat
280 4 0 0 /liventv/dat/1277403021.dat
264 0 0 0 /test/bbs.cgi
258 1 0 0 /liventv/subject.txt
222 12 0 0 /livefoot/dat/1277403141.dat
220 2 0 0 /livefoot/subject.txt
191 13 0 0 /livefoot/dat/1277403577.dat
187 23 0 0 /livefoot/dat/1277402022.dat
182 10 0 0 /liventv/dat/1277403037.dat
149 9 0 0 /livevenus/dat/1277395755.dat
141 3 0 0 /livetbs/subject.txt 32Mbps
last pid: 36240; load averages: 1.38, 1.33, 1.18 up 0+16:17:41 11:21:05
4870 processes:7 running, 4860 sleeping, 3 lock
CPU states: 9.2% user, 0.0% nice, 6.0% system, 4.5% interrupt, 80.2% idle
Mem: 11G Active, 4603M Inact, 1355M Wired, 21M Cache, 214M Buf, 5630M Free
Swap: 24G Total, 24G Free
前の試合の関係で、適当に増えた状態からスタート、となる模様。
%pgrep httpd | wc -l
4774 間もなく怒涛の鯖落ち→ギャーギャー登場→次スレが必要かも >>810
いや
もう寝るから立てるわ(笑)
雑談組が居なきゃ必要ねえだろうが・・・ 試合前。
2010/06/25(金) 03:23:11
NHK総合の勢い: 24res/分 00:35〜04:15 ウィンブルドンテニス2010
NHK教育の勢い: 1res/分 02:52〜05:00 放送休止
日本テレビの勢い: 646res/分 03:00〜05:40 2010FIFAワールドカップ・E組「日本×デンマーク」
TBSテレビの勢い: 305res/分 03:00〜03:30 会長はメイド様!
フジテレビの勢い: 11res/分 02:00〜03:30 スーパーGTコンプリート
テレビ朝日の勢い: 9res/分 03:10〜03:35 ベストヒットUSA2010
テレビ東京の勢い: 1res/分 03:05〜03:35 良品セレクション >>817
結構厳しいかも、
ベースラインが60Mbpsでそれにどーんが来て 110Mbps こなせるか !? >>819
5分平均で110Mbpsいくと、グラフ的に32bitを一週しちゃうんじゃ。 40Mbps
last pid: 36576; load averages: 3.81, 2.20, 1.60 up 0+16:23:44 11:27:08
4869 processes:6 running, 4863 sleeping
CPU states: 14.1% user, 0.0% nice, 8.5% system, 5.7% interrupt, 71.6% idle
Mem: 12G Active, 4703M Inact, 1316M Wired, 20M Cache, 214M Buf, 5439M Free
Swap: 24G Total, 24G Free
2010/06/25(金) 03:28:39
NHK総合の勢い: 18res/分 00:35〜04:15 ウィンブルドンテニス2010
NHK教育の勢い: 1res/分 02:52〜05:00 放送休止
日本テレビの勢い: 1083res/分 03:00〜05:40 2010FIFAワールドカップ・E組「日本×デンマーク」
TBSテレビの勢い: 117res/分 03:30〜04:00 アカデミーナイト
フジテレビの勢い: 11res/分 03:30〜04:00 DJモノフェスタ通販
テレビ朝日の勢い: 11res/分 03:10〜03:35 ベストヒットUSA2010
テレビ東京の勢い: 0res/分 03:05〜03:35 良品セレクション >>826
まだわからんです。
深夜なので今日はレス数が伸びる方向性かなと。
はじまたか。 51Mbps
last pid: 38111; load averages: 2.15, 2.22, 1.77 up 0+16:28:20 11:31:44
4875 processes:5 running, 4870 sleeping
CPU states: 8.7% user, 0.0% nice, 5.1% system, 4.2% interrupt, 82.0% idle
Mem: 12G Active, 4547M Inact, 1352M Wired, 19M Cache, 214M Buf, 5175M Free
Swap: 24G Total, 24G Free
>>820
ほ〜い立〜てま〜した〜♪
>>816
done ♪
2ch特化型サーバ・ロケーション構築作戦 Part50
http://qb5.2ch.net/test/read.cgi/operate/1277404142/
オレ様が起きるまでこの次スレ使い果たすなよ(笑) >>832
2xx 3xx 4xx 5xx URL
2402 36 0 0*/liventv/dat/1277403825.dat
1212 15 0 0 /livefoot/dat/1277404047.dat
896 0 0 0 /liventv/subject.txt
454 33 0 0 /liventv/dat/1277404013.dat
422 0 0 0 /test/bbs.cgi
381 33 0 0 /livefoot/dat/1277403141.dat
352 5 0 0 /liventv/dat/1277403215.dat
340 28 0 0 /liventv/dat/1277404331.dat
308 19 0 0 /livejupiter/dat/1277403434.dat
278 17 0 0 /livevenus/dat/1277403486.dat
268 0 0 0 /livefoot/subject.txt
229 0 0 0 /liventv/ ROM数自身はオランダ戦に比べると少なそうなかんじですね。
しかし、その分どーんの破壊力はあるのかも。 ちょっとあぶなかった。
2xx 3xx 4xx 5xx URL
3127 32 0 0*/liventv/dat/1277404331.dat
1284 21 0 0 /livefoot/dat/1277404455.dat
808 2 0 0 /liventv/subject.txt
620 0 0 0 /test/bbs.cgi
424 20 0 0 /livefoot/dat/1277404104.dat
355 10 0 0 /livejupiter/dat/1277403434.dat
343 7 0 0 /liventv/dat/1277403215.dat
259 8 0 0 /livevenus/dat/1277403486.dat
239 0 0 0 /test/read.cgi/liventv/1277404331/l50
213 2 0 0 /liventv/dat/1277404234.dat
209 0 0 0 /liventv/ 笛なし。
2xx 3xx 4xx 5xx URL
2237 55 0 0*/liventv/dat/1277404627.dat
1476 17 0 0 /livefoot/dat/1277404455.dat
864 40 0 0 /liventv/dat/1277404394.dat
494 1 0 0 /liventv/subject.txt
396 40 0 0 /livefoot/dat/1277404104.dat
367 0 0 0 /test/bbs.cgi
322 20 0 0 /livejupiter/dat/1277404524.dat
301 7 0 0 /livevenus/dat/1277403486.dat
270 5 0 0 /liventv/dat/1277404635.dat
last pid: 39076; load averages: 2.12, 2.12, 1.89 up 0+16:38:47 11:42:11
4877 processes:89 running, 4788 sleeping
CPU states: 35.6% user, 0.0% nice, 20.7% system, 10.5% interrupt, 33.2% idle
Mem: 12G Active, 4675M Inact, 1348M Wired, 18M Cache, 214M Buf, 5271M Free
Swap: 24G Total, 24G Free
斜めに走ってくる。
2xx 3xx 4xx 5xx URL
3253 77 0 0*/liventv/dat/1277404394.dat
1069 25 0 0 /livefoot/dat/1277404875.dat
822 0 0 0 /liventv/subject.txt
786 0 0 0 /test/bbs.cgi
525 21 0 0 /livefoot/dat/1277404104.dat
437 23 0 0 /livefoot/dat/1277404451.dat
424 16 0 0 /livejupiter/dat/1277404524.dat
382 16 0 0 /liventv/dat/1277404642.dat
357 11 0 0 /liventv/dat/1277404635.dat
344 18 0 0 /livevenus/dat/1277403486.dat
287 10 0 0 /liventv/dat/1277404224.dat
シュートおしかった。
2xx 3xx 4xx 5xx URL
5022 61 0 0*/liventv/dat/1277404642.dat
1582 28 0 0 /livefoot/dat/1277404875.dat
1350 2 0 0 /liventv/subject.txt
894 0 0 0 /test/bbs.cgi
726 12 0 0 /livefoot/dat/1277404104.dat
667 14 0 0 /livefoot/dat/1277404451.dat
581 14 0 0 /liventv/dat/1277404635.dat
523 14 0 0 /livejupiter/dat/1277404524.dat
453 7 0 0 /liventv/dat/1277404224.dat
427 0 0 0 /test/read.cgi/liventv/1277404642/l50
366 5 0 0 /liventv/dat/1277404234.dat
360 0 0 0 /liventv/ >>845
%pgrep httpd | wc -l
5121
LA=390いった時間があった。
last pid: 39605; load averages: 372.47, 91.50, 34.31 up 0+16:41:16 11:44:40
5234 processes:55 running, 5173 sleeping, 2 zombie, 4 lock
CPU states: 34.8% user, 0.0% nice, 32.9% system, 8.2% interrupt, 24.1% idle
Mem: 13G Active, 4746M Inact, 1407M Wired, 18M Cache, 214M Buf, 4167M Free
Swap: 24G Total, 24G Free >>848
たぶん増えたと思うんだけど
その時 SystemさんがたくさんCPUを使い CPU idle は7.4%まで下がった
それが >>851 の時なんだと思う last pid: 41056; load averages: 580.68, 172.61, 71.46 up 0+16:44:19 11:47:43
5235 processes:1600 running, 3627 sleeping, 8 lock
CPU states: 8.0% user, 0.0% nice, 88.2% system, 3.7% interrupt, 0.0% idle
Mem: 13G Active, 4766M Inact, 1445M Wired, 18M Cache, 214M Buf, 3922M Free
Swap: 24G Total, 24G Free
>>869
使い切ったwwwwwwwwwwwwwww 2xx 3xx 4xx 5xx URL
2632 0 0 0*/liventv/subject.txt
2128 0 1 0 /liventv/dat/1277404952.dat
1538 1 6 0 /liventv/dat/1277405037.dat
1049 0 0 0 /livefoot/subject.txt
787 0 1 0 /livefoot/dat/1277404451.dat
674 0 0 0 /liventv/
668 0 0 0 /test/bbs.cgi
594 0 0 0 /livefoot/dat/1277405115.dat
453 0 1 0 /livefoot/dat/1277405090.dat
322 7 0 0 /livefoot/
一瞬様子がおかしかった。
http を受け付けられない状態になったようだ。
一時的に。 どこまで行ってもCPUがボトルネックか
そろそろ2WAY4WAY考えなきゃいけないのかなー 売り切れは起こらなかったのかな。
%!p
pgrep httpd | wc -l
5121 Apachetop がすーっと下がった時間がありましたね。 >>904
AA投入がないのと他局のROMが少ないので、
転送量はたぶんそんなには出ないと思われ。 >>906
今はi7 960だからCore i7 980Xとか? %pgrep speedy_backend | wc -l
59
64まではいきましたね。 >>908
それは贔屓目すぎるような
鋭角なグラフを出せていない
さっきの試合の最後と同じ高さだけど形が違う speedy_backend が足りなかったっぽい。
そういえば思い出しました。
mod_speedycgi で動いている場合、
確か bbs.cgi の1行目では、コントロールできないかも。 >>915
↓
>>917 じゃないかなと。
今いくつになってるか、ちょっとみてみます。 冷や冷やする場面の連続がこないと100M超えない感 %ps ax | grep speedy_backend | head
5555 ?? Ss 0:00.56 /usr/local/bin/speedy_backend -- -M64 -t660 -T/md/tmp/SpeedyT
41012 ?? S 0:04.98 /usr/local/bin/speedy_backend -- -M64 -t660 -T/md/tmp/SpeedyT
41043 ?? S 0:05.39 /usr/local/bin/speedy_backend -- -M64 -t660 -T/md/tmp/SpeedyT
41046 ?? I 0:01.08 /usr/local/bin/speedy_backend -- -M64 -t660 -T/md/tmp/SpeedyT
41053 ?? S 0:04.38 /usr/local/bin/speedy_backend -- -M64 -t660 -T/md/tmp/SpeedyT
41054 ?? S 0:01.79 /usr/local/bin/speedy_backend -- -M64 -t660 -T/md/tmp/SpeedyT
41060 ?? I 0:00.44 /usr/local/bin/speedy_backend -- -M64 -t660 -T/md/tmp/SpeedyT
41061 ?? I 0:00.53 /usr/local/bin/speedy_backend -- -M64 -t660 -T/md/tmp/SpeedyT
41062 ?? I 0:00.50 /usr/local/bin/speedy_backend -- -M64 -t660 -T/md/tmp/SpeedyT
41065 ?? S 0:04.79 /usr/local/bin/speedy_backend -- -M64 -t660 -T/md/tmp/SpeedyT
-M64 ですね。
httpd.conf の設定だと思われ。 >>921
ハーフタイムに要請してみるとか
ただちに要請した見るとか、 審判デンマークに買収疑惑でサッカー実況が混沌としてきているな http://www.maido3.com/server/zousan/nikki151.html
<IfModule speedycgi_module>
SpeedyMaxBackends 64
これか。 >>922
ハーフタイムに要請してみます。
大きくしてもそれで常駐数が大きくはならないので、
思い切って 256 あたりで。 >>928
4倍いきますかw
もう512あたりいってもいいかもw >>931
128は直感でしたが、
httpd と違って、それでいつもの数が増えるわけではないので、
(speedy_backend は苦しくならないと援軍を呼ばない)
で、こうなった。
2xx 3xx 4xx 5xx URL
11 0 0 0*/liventv/dat/1277405684.dat
5 0 0 0 /liventv/subject.txt
3 0 0 0 /livefoot/dat/1277405540.dat
2 0 0 0 /livejupiter/dat/1277405617.dat
1 0 0 0 /livebase/dat/1277396097.dat
1 0 0 0 /livefoot/
1 0 0 0 /livejupiter/dat/1277404578.dat
1 0 0 0 /test/bbs.cgi
1 0 0 0 http://hayabusa.2ch.net/liventv/subject.txt
1 0 0 0 /liventv/dat/1277405101.dat
1 0 0 0 /livefoot/dat/1277405475.dat
last pid: 43475; load averages: 113.61, 78.55, 67.527 up 0+16:57:32 12:00:56
5269 processes:7 running, 5260 sleeping, 1 zombie, 1 lock
CPU states: 47.3% user, 0.0% nice, 25.7% system, 6.6% interrupt, 20.4% idle
Mem: 14G Active, 4717M Inact, 1511M Wired, 17M Cache, 214M Buf, 2920M Free
Swap: 24G Total, 24G Free
だいじょぶのような でも、回復は早かった。
2xx 3xx 4xx 5xx URL
2693 2 0 0*/liventv/dat/1277405674.dat
2212 1 0 0 /liventv/subject.txt
1078 1 0 0 /livefoot/dat/1277405540.dat
895 0 0 0 /test/bbs.cgi
758 35 0 0 /livefoot/dat/1277405475.dat
742 0 0 0 /livefoot/subject.txt
725 3 0 0 /liventv/
412 3 0 0 /livefoot/dat/1277405588.dat
305 1 0 0 /liventv/dat/1277405835.dat
305 1 0 0 /livejupiter/dat/1277405617.dat
291 48 3 0 /liventv/dat/1277405684.dat
280 8 0 0 /livefoot/
247 3 0 0 /livevenus/dat/1277405296.dat %!130
pgrep speedy_backend | wc -l
81
あれれ。
ちょっとみてきます。 >>955
なくなった形跡はなさげ。
%netstat -m
3143/18502/21645 mbufs in use (current/cache/total)
1542/13904/15446/131072 mbuf clusters in use (current/cache/total/max)
1542/13690 mbuf+clusters out of packet secondary zone in use (current/cache)
1545/4286/5831/65536 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/32768 9k jumbo clusters in use (current/cache/total/max)
0/0/0/16384 16k jumbo clusters in use (current/cache/total/max)
10049K/49577K/59627K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
130 requests for I/O initiated by sendfile
0 calls to protocol drain routines last pid: 43915; load averages: 18.98, 51.80, 58.45 up 0+17:00:11 12:03:35
5296 processes:20 running, 5258 sleeping, 18 zombie
CPU states: 38.8% user, 0.0% nice, 35.5% system, 10.2% interrupt, 15.5% idle
Mem: 14G Active, 4797M Inact, 1482M Wired, 17M Cache, 214M Buf, 2662M Free
Swap: 24G Total, 24G Free >>956
64超えた?
さっきは超えなかったみたいなのに•••? last pid: 43983; load averages: 278.80, 104.88, 77.00 up 0+17:00:52 12:04:16
5279 processes:2134 running, 3135 sleeping, 10 lock
CPU states: 8.3% user, 0.0% nice, 77.3% system, 3.9% interrupt, 10.5% idle
Mem: 14G Active, 4816M Inact, 1469M Wired, 17M Cache, 214M Buf, 2783M Free
Swap: 24G Total, 24G Free
厳しいぞ ちゃんと80人以上いるな。
苦しくなると -M の値を勝手に突破するのか? 勝手に突破するんじゃ設定の意味が。。。
どこかで上書きされてる? >>965
この時間帯に…
ゴールデンにこの試合放送してたら、確実に鯖落ちましたね >>965
記録でしたっけ、
これゴールデンタイムだったら・・・ logbuffer が苦しそうだな。
logbuffer にもっとCPUをあげたいところ。
活入れいってみるか。 ゴールデンなら既に112Mbpsいってなかった?
深夜でその速度の時点で恐ろしいが >>971
19日の試合では 109.990Mbps 出てました この分だと決勝T1回戦日本-パラグアイで大合唱かな TransferLog "| exec /usr/local/sbin/logbuffer"
のような行があるはずなので、
TransferLog "| exec /usr/sbin/rtprio 31 /usr/local/sbin/logbuffer"
に変更を依頼で。 本当は同じ手法で、speedy_backend も活入れしたいけど、
どうすればできるのか。 i7二つ乗るマザボかよw
危なかったけど鯖は大丈夫 last pid: 45408; load averages: 148.24, 61.44, 57.04 up 0+17:10:54 12:14:18
5274 processes:89 running, 5182 sleeping, 2 zombie, 1 lock
CPU states: 31.7% user, 0.0% nice, 34.1% system, 11.6% interrupt, 22.5% idle
Mem: 14G Active, 4971M Inact, 1483M Wired, 19M Cache, 214M Buf, 2219M Free
Swap: 24G Total, 24G Free
2xx 3xx 4xx 5xx URL
3428 157 0 0*/liventv/dat/1277406561.dat
2097 35 3 0 /livefoot/dat/1277406365.dat
1382 0 0 0 /liventv/subject.txt
712 0 0 0 /test/bbs.cgi
646 23 0 0 /livefoot/dat/1277406387.dat
560 11 0 0 /liventv/dat/1277406524.dat
480 8 0 0 /livevenus/dat/1277405296.dat
449 27 0 0 /livejupiter/dat/1277406134.dat
398 0 0 0 /liventv/
398 17 0 0 /liventv/dat/1277405970.dat
284 13 0 0 /liventv/dat/1277406752.dat
250 0 0 0 /livefoot/subject.txt
httpd はじゅうぶんさばけているな。 ハーフタイムか。
申請の準備します。
-M を増やす
logbuffer活入れ >>979 >>981
単純にCPUがもっと強ければいい気もするし
そうでない気もする >>996
そしてはやぶさががもっと強い子になります というかspeedycgiって-M 0でなんか問題あんの?
256とか設定するならもうデフォルトのままでいいんじゃ このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。 レス数が1000を超えています。これ以上書き込みはできません。