2ch特化型サーバ・ロケーション構築作戦 Part43
レス数が1000を超えています。これ以上書き込みはできません。
2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
前スレ:2ch特化型サーバ・ロケーション構築作戦 Part42
http://qb5.2ch.net/test/read.cgi/operate/1275745544/ 乙です。
KDDI-TS3O UP.Browser/6.2_7.2.7.1.K.4.303 (GUI) MMP/2.0 >>7
だからいい加減1をあぼーん対象から外せる専ブラにしろ というか自分であぼーんしておいて見れないとかバカ?? 向こうは今の時間は夜だよな?
jimさん残業か
かわいそうに あがったのかな。
bbs.cgi は落ちる直前に停止済。
作業完了報告を受け取り後、板復帰とbbs.cgiの復活の予定。 カリフォルニアだっけ?
太平洋時間なら、今昨日の19時半過ぎw 終わったっぽいね、意外に早かったなw
あとは板復帰を待つだけか。 作業報告受け取りました。
全板復帰、bbs.cgi動作済。 1) mod_speedycgiの有効化
→ 成功、bbs.cgiは正しくmod_speedycgiで動作するようになった
→ この部分、本来のパフォーマンスが出るようになった
2) md を 400M から 600M に拡大
→ 成功
%df -h /md
Filesystem Size Used Avail Capacity Mounted on
/dev/md0 512M 258M 213M 55% /md
3) dnscache のログ省略化
→ 失敗、私の提示した方法がまずかった模様
→ 中の人から「とりあえず元に戻した」旨返事いただき、了解しました。
3) については、別途作業手順しこんで、
再挑戦する方向で(リブートは不要のはず) mod_speedycgiが有効になったので、ちゃんと、
top で左上に出る、
last pid:
が、ほとんど増えていかなくなりました。
これで私、いったん本業に戻ります。 USBにマイコン一個繋いで定期的に割り込みかけようぜ
ドキュメンタリーですねー
どきどきしますねぇ
もっと直前にあと何時間しかないなんて状況が加わればもっと・・・ 今日の「その時2ちゃんが動いた」スレはここですか? さてと。
dnscache のログの件を依頼します。
anchorage で、この方法でOKなことを検証済。
リブートは不要で、すぐに切り替わる予定。
#!/bin/sh
exec 2>&1
exec <seed
exec envdir ./env sh -c '
exec envuidgid dnscache softlimit -o250 -d "$DATALIMIT" /usr/local/bin/dnscache
'
↓下記に変更し、
#!/bin/sh
exec 2>&1
exec <seed
exec envdir ./env sh -c '
exec envuidgid dnscache softlimit -o250 -d "$DATALIMIT" /usr/local/bin/dnscache
' >/dev/null 2>&1
# svc -t /var/service/dnscache live28の動きを踏まえて、
次のハードウェア構成の話をしちゃうかな SSDのRaid0&1Gbps&opteron12コア&メモりたくさん
めざせ2ちゃんの鯖1台 贅沢すぎ
それよりも冗長性を持たせて鯖落ち後即復帰の実現 + +
∧_∧ +
(0゚・∀・) ワクワクテカテカ
(0゚∪ ∪ +
と__)__) + そんなことをしたらいつ落ちるかわからないスリル感がなくなるだろ 鯖減らしてるのはF5攻撃のときにルーターより鯖が先にダウンするようにしてるの? >>31-32 の設定変更 @ live28 が完了しました。
実行されたとたん、SSD への I/O 負荷が下がったことが観測されました。
top -m io -o total の出力を見る限り、かなりいい感じになったようです。
スペシャル、というほどのものでもないですが、効果を考えると、
スペシャルセッティング3
・dnscacheのログ出力を省略
というかんじでしょうか。 >>33
・やっぱりSSDがいいな
・メモリアクセスが高速なのがいいな
・メモリをたくさん積んでいる、積めるのがいいな
というぐらいでしょうか。 もっと板を詰め込んで、日本戦の前に一回落として限界を知ろうぜ あとでかい板はnews morningcoffee ghardぐらいしかないなぁ んじゃ
狼
http://yutori.2ch.net/morningcoffee/
ゲームハード
http://yutori.2ch.net/ghard/
を移転してみようぜ。
ワールドカップが終わったら、実験できないんだし、後半戦前に一回落として、どんぐらい耐えるか見てみたい。
>>45
14日の試合で落ちる
次の試合(19?)までに新サーバ投入、なんなくきこなして
>>46 あたりを詰め込む、その次の試合で落ちる→みんなで大合唱
ってなシナリオで進んでいます。 >>50
できればlive29はroot権限ありがいいなあ 次期サーバ決定、発注した
Core i7-960 + RAM24G(最初ケチれたらケチる)
HDD + SSD (live28と同じ構成)
OS等セッティングもlive28と同じにする
これでいこう 次のlive29?に全部乗せ+バックエンドいくつかみたいな無茶振りではないのか >>43
CPU使用率が変化したかが気になるかも。
>>50
先に三板移転しても良いんじゃね? >>53
正常進化モデルという感じですね。
8 x 3 = 24G が豪華構成、
4 x 3 = 12G がケチった構成、というかんじでしょうか。
そのマザボとそのCPUで、
OSが7.xでいけるかどうかが、ちょっとだけ気になります。 Core i7 キタ━━━━(゚∀゚)━━━━!!!! >>57
感覚では、CPU idle timeが増えたように思いますが、
今のところ負荷かかっていないので、なんとも言えないです。 >>56
21:00から人気声優がゴールデン番組に出演します
同じ声優が去年末紅白に出たときには、実況とyutori7が陥落、tsushimaも相当負荷が上がったような
そして主要因だと思われるvipとν速と実況は現在全てlive28に集中しているという恐るべき状況 間違えたν速はまだtsushimaのままでした失礼 ちなみにゲーハーは来週の大規模イベントで新機種発表があり、負荷がかかる予定です。とのこと。 専ブラのJane Style、一鯖当たりの同時アクセス数絞ってるんだが
gimpoやlive28では撤廃するよう要望してみていい? ほう、また貴重なデータがとれますな
他のanime系もいれといたほうが期待持てる? そろそろスポ2鯖の運用あたりも・・・整理つけたほうがいいんじゃないかな プレスカンファレンススケジュール(日本時間)
14日(月)
11:00 マイクロソフト(Natal)
15日(火)
03:30 マイクロソフト
07:00 EA
10:00 UBI
14:00 Activision
16日(水)
02:00 任天堂
04:30 ソニー
IGN
http://e3.ign.com/
Gamespot
http://e3.gamespot.com/
1UP
http://www.1up.com/e3/
G4TV
http://g4tv.com/videos/45957/e3-10-live-starts-june-14/
Gametrailers
http://www.gametrailers.com/e3/ >>62
同時間帯に、NHK総合でワールドカップのアルゼンチン×韓国もあるみたいね
ついったーもworldcup特設作ったのは、裏で対策してるからかな アニメ板は再来週の1クールアニメ終了ラッシュで高負荷が期待できます >>67
現状のanimeとasalonがあれば十分かと
↓の二つはあまり期待できないので無視してもいいレベルかな
声優総合
http://changi.2ch.net/voice/
声優個人
http://changi.2ch.net/voiceactor/ news morningcoffee は後にとっておくとして
今日ちょっと詰め込んでおくかw
ghard?
あとどこがいい? >>74
軽くなった分をきっちり埋めておこう、
というかんじですか、、、。 単純にでかい順でいくなら nanmin
実況詰めたいならliveplus liveuranus辺りかな newsは抜けたらせっかくのSSDサーバーがハングル板だけになっちゃうんだよね >>53
おお〜、コレは期待
>>62
そう言えば食わず嫌い王に出るんだったね multilog のログ出力省略ってどういう意味ですか? なんかハリウッド映画の主人公たちが「さていっちょやったるかぁ(指ポキポキ)」みたいな雰囲気ですね
2時間映画の90分目あたりな感じ >>74
ここはどうでしょう。
http://pc11.2ch.net/iPhone/
iPhone 4発売の6月24日が迫ってますし。 >>81 誰も見ていないログは取らなければいいんじゃね?作戦かと、
そういえば前スレで出ていた
subject.txt index.html 等の更新を雪だるまと同様に非同期なデーモン閣下で行うという案は
とてもいいように思えるからやってみたほうがいいと思うんです
なぜなら あのsubject.txt index.htmlの更新処理部分は太古の昔から変っていない、
ひろゆき(たぶん)が書いてそのまま、手を入れようかなと何回か思ったけど複雑すぎて
常人には理解しがたいという
あとbbs.cgiとしてはこの件がらみもあるけど 1,000超え判定回りが重い処理だと思う
付け焼刃で多人数でよってたかってbbs.cgiなおしていたときのなごり >>77
そこは何気に万が一・・・100万が一の押さえにキープしておきたい気もするが 実況禁止の板であっても実況しちゃう住人がいる板が
今live28に一堂に会する。
ローかルールールを超越できるハードのすごさ。 >>89
タイミング見て正義で報告すればいいじゃん >>87
リスク管理なら保管場所分散が最強
管理の効率化なら集中管理方式
そこはセンスと好みの問題かと >>87
subject.txt 更新のところは、SunOSさんがスマートにしたはずです。
グロテスク((c)SunOSさん)ではなくなったはず。
> そういえば前スレで出ていた
> subject.txt index.html 等の更新を雪だるまと同様に非同期なデーモン閣下で行うという案は
> とてもいいように思えるからやってみたほうがいいと思うんです
これは面白そうですね。
同じサーバで「雪だるまな板」と「非雪だるまな板」を混在させられる
ようになると、さらにうれしいかも。
1,000超え判定の部分は、私もいろいろいじりました。
今のやつは、まあまあちゃんと動いていますね。
1,000超えストッパーのところは、
今や呼ばれる気配がないサブルーチンが確か2つぐらいあったはずなので、
それらはもう除去してもいいかもですね。 index.html を作るところは、なかなかですね。
いろんなことをやっている。
あと、html/*.html を作るところが結構きもかったです。
今書こうとしている dat *以外*のものも
合わせて作るようなしくみになっていて、
最初、何がなんだかわかりませんでした。
必死に読んで、かなりきれいにした記憶がありますが、
さてどうだったか。 subject.txt index.html はsunosさんのやつで、一気に非同期にしてしまいましょうよ、
これは現在のをそのまま使えるのかな? それとも改修等入れるのに時間がかかる? >>95
SunOSさんの降臨待ちですかね。
ローカル雪だるまにするなら、基本okな気がします。
ただ、そうするとsubject.txtをbbsd経由ではなく直接いじっているプログラムがあると、
ちゃんと動かないですね。意外なものが触っていそうな気もします。
復帰や削除関係の主なスクリプトは、SunOSさんが対応していたような気がします。
で、個人的にはこれからやる対応(非同期化も含め)
&今の問題の洗い出しのために、
subject/subback/indexについては現在の設定のままで、
14日を迎えてみたい、という気がしています。 liveplusは13日にはやぶさ大気圏突入で多少の負荷は期待できそうだけど、
それでも他よりは低いからなあ。
どこかTV局で中継やってくれれば多分局実況の方が集まるだろうしw ようは、
まずは >>50 路線かなと。
14日の試合でどうなるか。というか、今日の21:00の番組でどうなるか。
個人的には、単体サーバでの100Mbps超えが見たいです。 ソース公開してプログラマー板とかLinux、UNIX板の連中に任せてみては 924関係が直接さわっているなー
もちろん復帰スクリプトも、復帰しなくて良くなるのはメリットと思えるけど
風情がなくなっちゃうなぁ
これは live29投入後に再度検討しよう
■一羽の鴎作戦の六月の予定(live28) 【歌の練習よろしく】
http://qb6.2ch.net/test/read.cgi/operate2/1276240503/ あと、bbsdをローカルで動かすなら、bbsdのrtprioコマンドでの「活入れ」が必須です。
パフォーマンスが全く変わります。
それには何らかの方法でroot権限を使う必要があるので、
スペシャルセッティングが必要ですね。
その際にはまた、中の人とも共同で作業するかんじで。 >>101
りょうかいです。>>102 も参照なかんじで。
で、また、924カキコへの誘いが。 >>99
今日の21時?
>>62の件(水樹奈々@みなおか)なら来週だけど、他にあったっけ? 今晩22時から、オープニングセレモニーなどの中継はあるね >>99
rootさん
21:00の件は来週17日です
わかりづらくてすいませんです おいたん、ニュー速+で荒井大臣問題のスレが祭り状態になってるけど、政治ニュース+板を作ってくれよ。
立って一週間程度のあらゆるニュースをきっちり話す板だって明言してたじゃん。
政治系は別板に分けて、ビジネスニュースみたいに一ヶ月みっちり話し込んでもらおうよ。
このままじゃ、参議院選挙まで政治ニュースで埋め尽くされちゃうぜ。 ついでにゲーム速報やPCニュースも+化しないかな。
PCニュースはID強制表示でもいいけど。 そもそも、キャミソール荒井がそんなコトしなければ
良かったんだから、政治うんぬんではないだろw グロテスクなラスボス、bbs.cgiが打ち破られる日が近づいてきたと。
それこそ鯖一台で済んでしまうぐらい負荷が下がりそうな予感。 雪だるまサーバ群を解体して返却しよう思うんだけど
できるかな? >>117
私は今オフラインです。
深夜までオフラインの予定です。
で、解体にはwww2を移す器が必要です。
a-tigerのSSD+HDDものなら、
1台でまかなえると思います。 >>93
そういえばlive28になってから実況で1002まで行くスレを見かけるようになった
live23/live24の頃はなかったのに ということで1台rootありサーバをご準備いただければ、
明日にでもたんたんとわたしのほうでセットアップして、
さくっと移せると思いますです。 SSDにする心は、背景のレンガとか、
クッキーのためのjsとかの、
あらゆるところから参照されるものが入っているからです。
そんなわけでアクセスを速くしておきたいなと。 ふむふむ どっかから調達するか
ん? tsushima? あとはlive23/live24の花子への収容、
あたりかなと。このあたりはたんたんと進めればよさげで。
で、もう少しすると携帯的にもしばらくオフラインになる予定。 >>121
メモリに乗るだろうからSSDの意味無いような それもそうねぇ
容量もたいしたことないから public_htmlを/mdに振っちゃえばいいような
転送量もたいしたことないからT-bananaで十分な気が >>122
SSD+HDDのA-Tigerだとyutori7のような
もしくは、空く予定のlive28
8号機の追記早
8号機 次期サーバ決定、発注しました 発注
8号機 Core i7-960 + 24GB + HDD + SSD(X25-M G2) + 1Gbps...準備中 >>126
そうかもですね。
100Mbpsの従来型1台でいけるかも。 んじゃ T-Banana RAM4G root付きを用意して送りますー 復帰がなくなるのは寂しいなぁ
もう何年もやってないけど >>129
了解です。
これで私はしばらくオフライン。 次のi7鯖の名前はainama.2ch.netにしてよ
あいななをもじって、liveとかけてあいなま はやぶさ帰ってくるからhayabusaとかどうですか 「あいなま」でググったらアニメ声優が出てきたんだが >>133
豊崎愛生とか誰も知らないからやめようぜ なんかgimpoのsystem、E1が昨日から増加傾向にあるんだけど何かしたんだっけ? 韓国に敬意を表して
narodokan (羅老(ナロ)」ドカン!)
F5アタック期待できるよ >>141
何かある度に、rootさんが
「こんなこともあろうかと」と、登場するんだろ。
おいちゃんは「プロマネ(ProjectManager)」に改名だな。 gimpo、鯖負荷じゃなくて回線の方の負荷は余裕? >>143
Prof.Sanadaでお願いしたいところ myu10.2ch.net
イオンエンジン
xenon.2ch.net
推進剤のキセノン
woomera.2ch.net
カプセル落下予定地のウーメラ砂漠
uchinoura.2ch.net
M-Vを打ち上げた内之浦射場
itokawa.2ch.net
説明不要
minerva.2ch.net
イトカワ探査機(の予定が衛星)
cheesecake.2ch.net
伽ス公式デザート >>145
俺の感じだと、おいちゃん→川口プロマネ、rootさん→國中先生だな。
ちなみに、探査機「はやぶさ」のCPUはSH-3、OSはμITRONだ。 >>87-97 あたりの話 (bbsd を localhost 上で動かす)ですが,
削除系スクリプトや F22/F15 はおおかた対応済みのはずです.
ざっと見てみたところ,改めて対応が必要なのはお止めとかその辺の感じですね. >>147
次は1チップSH-mobileを使ったブレード鯖か
胸が熱くなるな >>146
xenon.2ch.netかっこいいな。
muses.2ch.netも入れてよ。 MUSESを忘れるとはなんたる失態!
muses-c.2ch.netか、次に期待してmuses-d.2ch.netか? aio.2ch.net で良くね? aio=All-in-One aioはなんか調子よくない
master.2ch.netとかbbs.2ch.net(はもうある?)とか hayabusa.2ch.net なんか素敵ですなぁ・・・。 ニダランで一番とったら命名できる
課金で効率あげるアイテム販売する
これでどう? 俺の携帯からニダラン入ると携帯から来いって突っ返されるんだけど >なかのひと
ExtendedStatus On
をhttpd.confに追加
を、
http://maido3.com/server/kamome/
に記録しておいていただけると、
次を作るときの作業漏れが防げて、よいと思いますです。 hayabusa
akatsuki
ikaros
shinen
suzaku
akari
hinode
akebono
daichi
ibuki
geotail
aqua
trmm
衛星系はラインナップが多くてしばらく困らないねえ 衛星というくくりにするなら最初はsputnikかoosumiにしていただきたい
adeosはなしね >164
ヤフオクでも出せば、軍資金貯めれそうだな hayabusaいいな、でもこれにすると不具合多発しそうw その度に「こんなこともあろうかと」で
危機を乗り越えられるから結果オーライ >>172
いいんだよ。
むむむさんが「こんなこともあろうかと」と言って、対策してくれるから。
でも、live28で調整・不具合のあぶり出しは「さきがけ」
続けて、live29(仮)が本番なので「すいせい」に見えるな。 こんなこともあろうかUSBモデムをサーバに繋いでおいたのだ ただしプリペイドなので音声しか通らない
root▲▲★ # dialup 1-808-1234-5678 >>163
鳥の名前は既に別の意味で使ってるからNGかな ネタを思いつかない…
> [999]root▲▲ ★<>
> xxxx/xx/xx(金) 16:43:51 ID:???0
> # cu /dev/cuaa0
> Welc騰ェ o thィeni ・2ch.net!
> log n:
> ケーブルのつくりかた、間違ったかしら。 pencil がいいなー、ここから始まったんだしさ きたく。
ほんとにこんなに転送量出てるんだろうか。っていう反応。
http://traffic.maido3.com/nLMZ/FaFC/FNcf/
>>181
うわあ、、、。
Even parityですか。 あと、この転送量グラフって、
112Mぐらい(だっけか?)で、32bitカウンターがあふれて、
0リセットされる、みたいなことが起きたりするのかしら。 >>188
last pid: 72185; load averages: 7.66, 7.70, 6.91 up 0+10:56:02 06:24:32
795 processes: 3 running, 792 sleeping
CPU states: 39.4% user, 0.0% nice, 25.4% system, 0.0% interrupt, 35.2% idle
Mem: 3823M Active, 2840M Inact, 519M Wired, 372M Cache, 214M Buf, 228M Free
Swap: 8192M Total, 8192M Free
> 35.2% idle これぐらいねっとりと色々観察したいんでmaido3.comの中の人頑張って!
ttp://mumumu.mu/mrtg/mrtg-rrd.cgi/
って言ってもやっぱり難しいかな色々と。 >>191
dnscacheのログをとらなくしたのも、
かなり効いている様子。 アイドル35%ってやばそう
日本戦きたら瞬殺しそう
2xx 3xx 4xx 5xx URL
1149 47 0 0*/liventv/dat/1276262016.dat
471 27 0 0 /livenhk/dat/1276262236.dat
318 34 0 0 /livenhk/dat/1276262733.dat
284 0 0 0 /test/bbs.cgi
229 24 0 0 /liveradio/dat/1276261777.dat
167 0 0 0 /livenhk/subject.txt
162 65 0 0 /livevenus/dat/1276250205.dat
liventvか。 httpdコール数12658ww
以前なら確実にだんまりするところをさくっと動作するところは胸熱
雪だるま末期でもそのくらいはできてたような
6〜7台体制の頃は25000でも何とかしてなかったっけ >>202
これは携帯用BGのプライベート側ですね。
まずはこの状態を見せるのがマイルストーンなのかしら。 で、測れないのは困るので、何らかの対応を、
ということになるのかしら。 >>121
それならRAMディスクに突っ込んでおけばいいんでない?
モノとしてはそんなに容量無いんだろうし。 >>204
110M超えたら0に戻って、2周めは表示+110MBですね。
2周、3周してるとわけがわからなくなったりします。
weekly、monthlyのグラフは表示値のまま平均されてしまうので
読み取れなくなってしまいます。
↓みたいなページあるけど
Africa Ubuntu 2010 World Cup Football Accomodation
やっぱUbuntuの関係から開催資金が提供されてるのかな? 鯖の名前なんか和菓子シリーズでいいじゃん
suamaとかさ rootさん
multilog のログ出力省略ってどういう意味ですか?
教えてください。
映画と開会式の合わせ技でいい感じに負荷が上がってきた
明日は野球の終盤とアルゼンチン-韓国の合わせ技が楽しみ >>214
上の方にありませんでしたっけ。
誰も読んでいないログの出力(しかもかなり資源食っていた)
をやめたということで。 鯖監視所のグラフ、いつの間にか上限5000になっとったw >>218
誰も読んでないログは見れなくなるんですか? >>220
鯖ログとかであって、datとかの話じゃねーぞ? >>220
なりますけど、掲示板のログとは関係ないやつですね。 しかしスリリングだな。
top の出力が変化するのを見るだけでこんなに興奮する感覚は、
久しぶりだ。 これだけ詰め込んで10分平均1800res/minまで行ってもまだ重くならないw >>224
じゃあ普通に読む分には今までと変わりないという事ですか? >>227
今のところ、うまく受け止めれてますね。 >>228
今日変えたのは器(サーバ)のほうだけで、
掲示板のシステムには何ら手を加えていないです。 なんかlive28にこそhayabusaがふさわしい気がしてきた くそ、らっきーれーさーまで寝れないとか言ったせいか こりゃ毎日落ちるなwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww 何この糞鯖
なんでこんなしょうもないもん導入したの mbuf満タンだ。
%netstat -m
38855/925/39780 mbufs in use (current/cache/total)
あれ?鯖てこんなに弱かったっけ?
弱い鯖に移転したの? %netstat -m
42749/871/43620 mbufs in use (current/cache/total)
16050/374/16424/65536 mbuf clusters in use (current/cache/total/max)
16050/360 mbuf+clusters out of packet secondary zone in use (current/cache)
24849/435/25284/32768 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/16384 9k jumbo clusters in use (current/cache/total/max)
0/0/0/8192 16k jumbo clusters in use (current/cache/total/max)
142183K/2705K/144889K bytes allocated to network (current/cache/total)
増やす必要ありだな。
CPUより先にネットワークがいったか。 CPUが足りないの?SSDが追い付かないの?
回線が細いの? CPUどんづまりキタ━━━━━━━(゚∀゚)━━━━━━━ !!!!
かな >>22のやつの事?
400から600に増やしたけどおっつかなかったってこと? こいつをもっと増やさないといけない、
というかんじかな。
/boot/loader.conf
# increase nmbclusters, maxsockets, etc.
kern.ipc.nmbclusters=65536 CPUより先に、ネットワークがふんずまりのようす。 いや、mbuf clusters はまだあいているか。
単純なmbufの数のほうかな。 psで見ると、httpdはDが多い。
74153 ?? D 0:05.48 httpd -k start -DSSL
74154 ?? D 0:05.59 httpd -k start -DSSL
74155 ?? D 0:05.60 httpd -k start -DSSL
74157 ?? D 0:05.49 httpd -k start -DSSL
74159 ?? D 0:05.52 httpd -k start -DSSL
74160 ?? D 0:05.39 httpd -k start -DSSL
Dじゃないのもいるみたい。
73990 ?? I 0:05.67 httpd -k start -DSSL
73991 ?? D 0:05.79 httpd -k start -DSSL
73992 ?? S 0:05.52 httpd -k start -DSSL
73993 ?? I 0:05.64 httpd -k start -DSSL
73994 ?? D 0:05.69 httpd -k start -DSSL
73995 ?? I 0:05.73 httpd -k start -DSSL 落ちれば落ちるほど、改善できるね。
CPUが原因で落ちたら、終了 日本と関係ない試合なのにこれですよ。
これが日本代表戦だったら・・・・。
早急に対応お願いしますよ(-人-)>root氏 日本戦じゃないのが救いだ
これで鯖の調整も一歩進むだろうし SSD云々じゃなくて、ネットワークが脳梗塞状態なのか >>257
ちょこっと設定いじるような、今日明日で何とかなるようなものなの?それ。
それとも、部品変えたりとかしなくちゃで、時間がかかりそうなものなの? >>294
そうそうバランスが一番大切です。
ワインばっかりとか駄目です。 しかしSSD、ほんと底が見えないね
相当チューニングのし甲斐があるんだろうな。
最終的にどんな化け物サーバになるんだか。 これだな。
/boot/loader.conf
kern.ipc.nmbclusters=131072
に変更で(旧値は65536)。
で、
/etc/sysctl.conf
# nmb (number of mbufs) tuning for FreeBSD 7.x
# note: kern.ipc.nmbclusters=65536 should be set at /boot/loader.conf
kern.ipc.nmbjumbop=32768
kern.ipc.nmbjumbo9=16384
kern.ipc.nmbjumbo16=8192
も、合わせて変える必要があると。 これってどれくらいアクセスしたら落ちるか試してるんだっけ? mbufを64MBから128MB(例えば)にしたところで、以前と違って物理に8GBも確保されていれば大きな影響無いと思うけどなあ・・・。 これ実験終わったら詰め込んだ板再移転したりするのかえ? >>297
もう少し調べて確定したら、
設定の変更依頼を出そうと思うんですが(要リブート)、
今依頼出したら、設定は変更されるでしょうか。 >>299
おお、いきますかー。うまくいくといいな >>297
エチルだけじゃなくバランスとるためにたまにはメチルも呑まなきゃね こんなの見つけた。やっぱりLinux使おうぜ。
http://slashdot.jp/comments.pl?sid=285706&threshold=1&commentsort=3&mode=thread&pid=830046
>BSD系は,mbuf構造が足を引っ張っているためか,Linux系に
>比べて,Networkのスループットが出にくいですよ.
>loに対して,TCPでぐるりとまわすと,Linuxは4Gpbsもいくの
>に,同じマシンでFreeBsdは,700Mbpsしかでなかったことがあります. 倍じゃ足んなくない?
一気に256位まで拡張してもいいと思うけどなあ kern.ipc.nmbclustersってyutori7でも上がってた奴か。
バランスが大事ってどこぞの消費者金融のCM?w >>310
BSDとLinuxじゃ限界時の信頼性が一桁違うぞ。
99.999が99.99になるってレベルだけど。 >>297
某病院に勤めてたことがある知り合い曰く
ビールが一番依存症になりにくいそうな。 じわじわっといじるのが一番なんですよねぇ。一気にいじくって何がおかしくなったかわからなくなるより。 一気に上げすぎて、オーバーフローをを起こしても何か >>299 は、sys/kern/kern_mbuf.c によると、
nmbjumbop = nmbclusters / 2;
nmbjumbo9 = nmbjumbop / 2;
nmbjumbo16 = nmbjumbo9 / 2;
か。ということはそれぞれ倍で、
/etc/sysctl.conf
kern.ipc.nmbjumbop=65536
kern.ipc.nmbjumbo9=32768
kern.ipc.nmbjumbo16=16384
ということか。 >310
2005の記事だけど、最近のFreeBSDはどうなんよ? >>304
あんたもしかしてじっぷらで
キャップ剥奪になった人? 落ちるのは良いけど、実験してるんならバックアップ鯖用意しとけよ。
迷惑掛けんな。 >>314
ネットワークのリングバッファが固定サイズっていう筋の悪い仕様は当時から変わってないわけで。 >>311
kern.nmbclustersをメモリ容量と不釣合いに大きくすると、
立ち上がらなくなるです。経験済み。
ここは、メモリ4Gの設定をそのまま使っていたので、
倍まではいけるかなと。 >>320
りょうかいです。
まずはたんたんとやってみます。
やっていただけたらもうけものというかんじで。
だめだったら、、、rootなしでもできることをやろうと。
観察とかデータとりとか、悪あがきとか。 kern.ipc.nmbclusters=262144
でも良い予感 live28はまるでダイヤの原石だな
どんな仕上がりになるかは中の人の腕しだい >>326
なんのために、面白くないじゃん
お断りします。 で、
kern.ipc.nmbclusters=131072
は、Googleしても設定例があるようなので、
とりあえずいけてるのかなと。 >>333
磨きすぎて砕けるんですね、わかります。 サービスを止める実験はどうなんだろう
やはり冗長性を持たせて代替鯖に瞬時に・・ >>331
設定例はあるようですね。< Googleしてみた
しかし、ちょっと怖いかも。 >>344
最初からサービス落とすのが目的なんだぞw 300 名前: root ★ 投稿日: 04/02/08 00:44 ID:???
># added for 2ch
>kern.maxusers=2048
>kern.ipc.nmbclusters=131072
>kern.ipc.maxsockets=131072
>vm.pmap.shpgperproc=2048
>kern.ipc.maxpipekva=41943040
>にしてみた。
6年前か 今は動いてるのかしら。
mbufは空きました。
%netstat -m
37130/20440/57570 mbufs in use (current/cache/total)
12433/8855/21288/65536 mbuf clusters in use (current/cache/total/max)
12433/8841 mbuf+clusters out of packet secondary zone in use (current/cache)
23051/9717/32768/32768 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/16384 9k jumbo clusters in use (current/cache/total/max)
0/0/0/8192 16k jumbo clusters in use (current/cache/total/max)
126352K/61688K/188040K bytes allocated to network (current/cache/total) >>345
何事も、実験なので失敗をおそれないで。 安全だとわかっている最大値でいくとか?
それでだめなら>>331でいく だんまりにはなるけどリブートにはならないっていうことか 昨年夏はこの後NICがお亡くなりになったんだっけ
デジャヴになりませんように・・・。
>>353
今動いてるということは、やはりmbufあふれが有力ですね。
動いてるなら、もう少しじっくり調べてみよう。
どうせ韓国戦や日本戦など、試す機会は豊富だから、
あせってもしかたがないし、
CPUもSSDもまだ余裕あったんだから、うまくいけばさらにパワーアップできるわけで。 バックアップは狼でいいじゃんw
実況常習板なんだし
狼移転してないのってそのためなんじゃね? 運営叩いてる奴今のlive28の目的わかってないだろw
最高のCPUを用意して落ちたら設定とかメモリを増やしていって実験してるんだよw >>345
Mac鯖ではいけた記憶が(ry
FreeBSDは経験ないので何ともですが、行けるんじゃないですかね 2ちゃんねる サーバ負荷監視所
http://ch2.ath.cx/
正常、live28 19.64 オレンジ
ピンチ? 科学技術振興機構
JSTバーチャル科学館|惑星の旅
ttp://jvsc.jst.go.jp/universe/planet/data/main/index.html
暇潰しにどうぞ
>>364
そんなの分かってるが、+見れないのがツマラン(゚ω ゚) >>364
実況板の総意
「よりによって一年で一番負荷かかるWC期間中に実験するな、糞が」 >>372
たまたまラプターから切り替えで発生しただけなんだからしょうがない。 >>372
負荷かかるときに実験しなきゃ意味無いじゃん
なにいってんの >>372
運営の回答は
「一年で一番負荷がかかる今だから実験に最適なんじゃねえかwww」
だがな。 >>362
ですね。チューニングのしがいがありそうですから >>372
むしろそういう時期だから狙ってやってるんだろうがw
今後更に大きな祭りのためにやってるんだからw >>372
千載一遇のチャンスってことですね
皆よくわかっていらっしゃる いずれにせよ変えるのは、
/boot/loader.conf のこれと、
# increase nmbclusters, maxsockets, etc.
kern.ipc.nmbclusters=65536
/etc/sysctl.conf のこれですね。
# nmb (number of mbufs) tuning for FreeBSD 7.x
# note: kern.ipc.nmbclusters=65536 should be set at /boot/loader.conf
kern.ipc.nmbjumbop=32768
kern.ipc.nmbjumbo9=16384
kern.ipc.nmbjumbo16=8192
まずは、それぞれ倍にするかんじかな。
これで。
・/boot/loader.conf
# increase nmbclusters, maxsockets, etc.
kern.ipc.nmbclusters=131072
・/etc/sysctl.conf
# nmb (number of mbufs) tuning for FreeBSD 7.x
# note: kern.ipc.nmbclusters=131072 should be set at /boot/loader.conf
kern.ipc.nmbjumbop=65536
kern.ipc.nmbjumbo9=32768
kern.ipc.nmbjumbo16=16384 得点が入った時、またどうなるかですな。
取り合えず0-0で終わってもらいたくない。 実況なんて何がどうなっても良い
ただ鯖やネットワークの実験にはもってこいなだけ >>380
なるほど。最高に重いときに実験ができるわけか
やってる側としてはやりがいありそうだな まずは「今設定変更は可能でしょうか」って聞いてみることにするです。
可能なら機を見て依頼する(リブートかかる)、
だめなら明日以降に改めて依頼するということで。 実況民としてはバルスとかで落ちない鯖ってのも寂しいんだけどな(´・ω・`) live29(仮)ではさらにメモリ増量になるみたいだから
パラメータもそれにあわせてまた変わる? >>381で200M 位持てば計算上は問題ないのかな >>388
どの道しばらくは詰まり詰まりな感じになるかもですな。 >>390
一番の負荷は、韓国から攻撃された時。
普通にやってる分には、WCがトップぽ。
瞬時だったら、ラピュタと耳をすませば。 >>380
全然話が違うんですが、先日キャップお漏らししちゃいまして、
アングラーさんに停止してもらったんですが、再発行とかは・・・
だめですかね? >>393
サッカーを楽しむか、鯖いじりを楽しむか。
ただそれだけの違いじゃんw 今日おちついたらghard持って来ますね、
これで調度データが取りやすくなる感じだと思う ちょうどこのへん 100Mbpsあたりを突破できれば
次の壁は結構上のような気がするだすよ その鯖をシャットダウンすることで2chが平和になりそうな・・・ >>328
リングバッファのサイズが可変だとリングバッファって言わなくね? >>408
長年の勘ってやつですか。
がんばる価値があると。 >>344
そんな事やるくらいなら、雪だるま構成すりゃいいだけで。
そのノウハウはあるんだから今後はそういう構成になるかも。
駄菓子菓子、鯖のハードとしての限界がわからんことには、次の段階に進めん 今は関係ないけどyutoriってまだ6.2Rですよね
3つしか板入ってなくて7.0Rに更新しようって話も出ていたのに
ゲハとか狼とかの旧dubaiがダメになったときに全部詰め込んじゃって 頑丈な鯖を作って、商売にする気ス?(゚ω ゚)さては >>408
ところで今日金曜日だけど、飲みに行かないの? mbuf(チェーン)は、メモリが少ない時代の設計としては、
たぶんロジカルで、かつ意味もあったんだと思います。
今は、でかいバッファをどんととるほうが、
筋がいいでしょうね。 >>408
次の壁は近いと思う。待ち行列が溜まるとバッファ量なんてあっというまに突破するだろうから。 >>395
韓国から1年に1回攻撃は・・・あるか。 なんかここまでくるともっと限界まで見てみたい気がするな
もっと重い板ってないの >>408
その次の壁となると今までの最高記録である300M程度ですかね。
つうか全板入れた上で番組等のタイミング合わないと
まず届かないであろう壁と思いますw >>388
どうなりましたか?
リブートするなら「今!」 動画サイトみたいな高帯域な鯖のチューニングも
こういうドSな感じを公開してくれると楽しいのに 返事が来ますた。
今現在の対応は難しいとのことで、
今依頼しても、明日の昼の対応になるとのことですた。
>>381 の変更は、明日昼間に依頼します。
で、それならそれで、各部の観察とかいろいろ、
やることはあるかなと。 このやりとりをもっと他のやつらが認知してくれれば落ちたうぜー何考えてんだよ
的なの無くなりそうだよな。実際今日ここ見てみて考え方変わって面白くなってきたわ 地震板はこの実験には役立たずだから仲間はずれにしてほしいお。
ネットにアクセスできる可能性はほとんどないに等しいかもしれないけれど、
もしもの時の情報源は使える可能性がほんの少しでもあれば確保しておきたい。 >>427
×:韓国
△:南朝鮮
○:下朝鮮
◎:馬鹿ども >>437
そうやってギャーギャー騒がれるのも楽しみの一つなんだよ W杯放送予定一覧
ttp://www.enjoy-soccer.net/tv/g-wave.html
よかったらどうぞ 地震板とかいうか自然災害は、切り離した方がいいよなー。 >>316
8.0Rでは解決、というのって、
どんなかんじなんでしたっけ。
今のlive28は7.0Rが入っています。
8.0R以降だと、いいかんじになるのかな。 確かに地震関係は負荷実験に貢献してないし、落ちてる時に大きめの地震が発生したら運営サイドも後味悪い気がする。
代わりに、大学生活板でも入れれば
>>447
その辺はlive29(仮)に期待と言うことで。
8.0Rか8.1Rでの構築要請出してみればいいんでない? >>247
スレチですが、れーさーは先週で終わったんじゃ・・・ もしOS入れ替えるならNCQが使い物になるっぽい8.1以降を… >>359
そうですね。
今回のパターンで落ちたときは、
リブートしてもたぶん状況変化しないです。
で、
あとは、メモリ8G構成で2倍よりも量を増やせるのかどうかも、
ちょっと調べてみようかなと。
気合が乗ればカーネルソースもあたってみますが、
本業多忙だったので、へたれるかも。
>>452
1Gでの接続が前提なら全二重しか規格がないので、
例の半二重になってしまう問題は、踏まないかもですね。 >>447
以前8.0でもmbuf問題起きたような? あれ、8.0 betaだっけ? ほんと、なんで臨時地震+まで一緒なんだろうな。
live28の前は関東震度4でさえ落ちてたのにw で、ここまでのまとめ、
・まず、ネットワーク(mbuf売り切れ)の問題が割り出された
→パラメータを大きくするのを明日依頼する
・CPUはまだ何とかなりそう(でもかなり厳しかった)
・SSDやHDDはまだまだ余裕だった(systat -vで観察)
・今日の設定変更(root権限が要る物)はなし
→観察主体で
で、後半が始まったようですが、そろそろお風呂入ってきます。 >>457
初代yutori7のことを言ってるつもりなら、8.0-BETA2だったような ハヤブサの盛り上がりを加えて地震は外してほしいです>< あとフランス戦中継するのテレビ東京系列だからそっちは今より負荷かからないかと。 >>450
あそこもう過疎板だから実験にはまったく寄与しない。
live28鯖落ちたらしいがボトルネックと解決策は? last pid: 85564; load averages: 5.41, 4.98, 6.32 up 0+12:48:55 08:17:25
807 processes: 1 running, 806 sleeping
CPU states: 5.0% user, 0.0% nice, 4.5% system, 0.0% interrupt, 90.5% idle
Mem: 4360M Active, 2561M Inact, 606M Wired, 212M Cache, 214M Buf, 37M Free
Swap: 8192M Total, 8192M Free
確かにこのスレみてると、落ちるのも楽しくなっちゃうな うむ、mbufは増やすとして、
他にも何か罠がありそうなかんじですね。
うまく資源を供給できなかったかんじ。 まだ、じっぷらって全鯖規制の対象になってるのか?? rootたんいても自然解消待つしかないんじゃないの これだけ状況を作れるといい感じですねぇ
ghardの移転は延期しようかなぁどうしようかなぁ
微妙だなぁ >>487
点が入りそうだったので、まだこれからです、、、。
>>486
なんですよね。CPUを使ってくれなかった。 >>503
1戦と2戦の間に入浴すればいいじゃない 10%しかCPU使わないなんて俺の超スーパーマッスィーンのQ6600と同じくらいか >>508
1戦が終わったところで、たぶん寝るんじゃないかな、、、。
へろへーろ。 >>502
明日設定変更した上で野球と韓国戦の合わせ技があるから1日延期のほうがいいかも 第2戦はいいカードではあるけど中継がテレ東系だから負荷は少ないかと
深夜3時過ぎだし ……これ仮想化して2インスタンス立てた方が効率よくリソース使えるんじゃね?w >>502
ゲハほしー、もっともっと傷めつけてほしー 典型的なネットワークがだめな時の症状ですね。
すぐ閉めてくる。
%telnet live28.2ch.net 80
Trying 206.223.151.120...
Connected to live28.2ch.net.
Escape character is '^]'.
Connection closed by foreign host.
%telnet live28.2ch.net 80
Trying 206.223.151.120...
telnet: connect to address 206.223.151.120: Connection reset by peer
telnet: Unable to connect to remote host >>502
今やるべき。
日本の初戦までにCPUを落とそうぜ。
おいたん >>516
負荷は多すぎても少なすぎてもダメなんだよ
そこら辺分かってるか?
弱点をくすぐる程度の負荷が一番良いんだよ >>465-466
すまんこ。
更新したのが結構前だったのでレスを取得してなかった。
ネットワークの問題かおkd。 専ブラでUnexpected end of file from serverとかConnection resetとか出る >>517
rootさんtelnetって・・・・・・・・。 >>519
いやあ、日本戦でも無いのに落ちたからさ。
これは、日本戦の日だけ2ちゃん止めるのかwww 高い買い物したのに管理者が無能なせいで
10%しか性能を引き出せてないでおk? 72301 ch2live28 1 -16 0 79732K 12428K zoneli 2 0:15 0.00% httpd
72071 ch2live28 1 -16 0 79732K 12244K zoneli 3 0:15 0.00% httpd
72194 ch2live28 1 -16 0 79704K 12480K zoneli 0 0:15 0.00% httpd
72162 ch2live28 1 44 0 79704K 12288K select 3 0:14 0.00% httpd
72450 ch2live28 1 44 0 78632K 12076K select 0 0:14 0.00% httpd
72279 ch2live28 1 -16 0 79696K 12428K zoneli 2 0:14 0.00% httpd
72524 ch2live28 1 -16 0 79628K 11864K zoneli 2 0:14 0.00% httpd
73731 ch2live28 1 -16 0 78692K 12412K zoneli 3 0:14 0.00% httpd
73855 ch2live28 1 -16 0 78596K 12328K zoneli 3 0:14 0.00% httpd
zoneliが出た。
前のyutori7(初代)の時にもあったこれだな。
Zonelimits State: The Silent Killer | Real FreeBSD Tips
http://www.realfreebsdtips.com/networking/freebsd-stopping-zoneli-state/
こいつらを*小さく*しろと。
/etc/sysctl.conf
net.inet.tcp.sendspace=8192
net.inet.tcp.recvspace=8192
それぞれのデフォルト値は、これと。
%sysctl net.inet.tcp.sendspace
net.inet.tcp.sendspace: 32768
%sysctl net.inet.tcp.recvspace
net.inet.tcp.recvspace: 65536 >>532
とはいえ、こんなに簡単に落ちると動かすだけでSSDの寿命がきそうだからさwww
マジで、落とす前提で詰め込むならもっと早く対応しろよと >>515
結局物理NICで詰まってるわけだし、そいつをやってもCPUの前にNICが詰まるだろ。 >>538
詰まってるのはOSでNICは余裕なんじゃね >>540
下手してリブート連発したらSSDの方もやばいんじゃないかと思っただけ。
てか、SSDの方の速度は足りてるの? >>531 にも、nmbclusters は増やせとあるな。
>>381 に加えて、
/etc/sysctl.conf
# Lowering these buffers down will reduce
# your memory usage and save yourself some mbufs.
# http://www.realfreebsdtips.com/networking/freebsd-stopping-zoneli-state/
net.inet.tcp.sendspace=8192
net.inet.tcp.recvspace=8192
これの追加を合わせて依頼しよう。 >>538
OSのNW周りで詰まってんでしょ。
>>542
だよね >>547
スマソさっき気がついた
つまり、ネットワークの方が詰まってるだけね。
この間はなんかリブートがあったみたいだったからさ。 >>531
変更前・・・荷物を大きい段ボールに詰めて発送
変更後・・・荷物を小さい段ボールに詰めて発送
小さい段ボールの方がトラックに効率よく積める
こんな感じですかね? rootたんが着々と分析してるのにFOXは野次馬イジって遊んでるだけじゃねーかw >>542
どーなんだろ。NICのビジー率とか出ればわかるが
ハードウェア側は遊びまくってるのかなぁ >>553
なるほど把握
Unix系は詳しくないからレスはしないけど、
なんかW杯がちょっと楽しみになってきたな・・・ >>555
そんなことないもーん
酒場にくりださずここにいるだけでも大進歩!! >>556
あと疑っているのは em0 の割り込みが忙しい、
あたりですが、その分析は、mbuf 問題対応の後かなと。 >>546
20台でもちょっと引っかかるかな、くらいで済んでる
前にrootさんが言ってたように「はけ」が良くなったのかな、SSDで >>556
1GbpsのNICだから余裕なはず。まぁドライバの出来によるかも知れないけど。 8.0のmbufが云々の話に関係ありそうな記事探したけど古いし結局よく分からん
FreeBSD 10ギガビットネットワーク高速通信の秘密
http://journal.mycom.co.jp/articles/2008/10/29/bsdcon5/index.html >>562
SSDはいまのとこ、ビジー率が5%超えればたいしたもんです。
HDDのI/Oの効率化のために長年腐心してきた身からは、
なんというか、異次元のデバイス、という気がします。 >>364
でもバックアップ用意しときゃいいだけなんだよなw
その回答が>>336なんだけどw だが待って欲しい、酒場にくりだしていないからといって飲んでいないとは限らないのではないか >>559
おいちゃんも新鯖にwktkしてるんだなぁw 実験鯖だけでもroot有りにした方がよかったのでは? >>579
わかりやすいよな
ン名わけね枝路オオオオオオオオオオオオオオオオおおおおがあああああああああああああああああ 今の状態だと、ゴールの度にきっちり落ちるということで。 所詮玉遊びに何を必死になってるんだかw
どっちが勝った所で俺等の実生活にはほぼ影響ないじゃんw NHK総合で暫くは毎日1試合あるからなあ
山場がその間にちょこちょこあるとはいえ、
本当にいい実験期間だなあ 雪だるまって若いもんに体力は敵わないけど老獪なテクの持ち主だったんだな・・・ 今日の開幕戦は収穫あるなぁ。
明日の昼には改良されるんだろ。 のんびり実況したければtwitter行くのが最適解だな 鯖マシンそのものではなくて、回線障害なんじゃないの? >>600
ちょっと上読めば解決してあら鯖落ちも楽しくなる >>600
ネットワーク
といっても回線とかじゃなくてOSがネックになっている >>598
大きな祭りの時はそうなる
去年のエヴァなんて言うまでもないw >>602
twitterの鯖も不安定だったりするw OSがネックとかカワイソスだが、キャップ頑張れー!
W杯なんて今まで興味もなかったのに気になって仕方がないぜww >>602
W杯に限ってはニコニコ実況の方が良くないかなぁ >>610
live28に立てるんですね。わかります。 >>608
少し前に2chの鯖なんかよりうちは金かけてるから凄いんだぜってドヤ顔してたような印象があるんだが >>605-606
OSなのかd
何使ってんだろ
Windows2007-serverかな 要するに無能だから最適な設定が出来ないんだろ?
まぁ途中で投げ出さずに性能フルに引き出せるまで頑張ってね
これから一ヶ月毎日 >>565
仕組み的に考えるとmbufとLROやTOEって相性悪そうな…。 %netstat -m
57094/1076/58170 mbufs in use (current/cache/total)
21682/564/22246/65536 mbuf clusters in use (current/cache/total/max)
21682/564 mbuf+clusters out of packet secondary zone in use (current/cache)
32768/0/32768/32768 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/16384 9k jumbo clusters in use (current/cache/total/max)
0/0/0/8192 16k jumbo clusters in use (current/cache/total/max)
188709K/1397K/190106K 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
161 requests for I/O initiated by sendfile
0 calls to protocol drain routines
あふれてるな。特にこれ。
> 188709K/1397K/190106K bytes allocated to network (current/cache/total) >>619
2chは最初期からひろゆきの趣味でBTRONなんだ >>620
これから一ヶ月毎日楽しめるんだよ、喜ばなくちゃw >>621
NW抜群の安定度でまだ金融系で使ってるというあのOSか
>>623
Web-boyでよろw >>620
本当の無能はこんなアイデアすら思いつかず
一生最適な設定もできない サッカー実況板はこういうときのために鯖分けておけよ
何のために別の板が用意されてるんだよ >>633
何いってんの
こんなに負荷がかかることなんて滅多にないんだからlive28にぶちこんで実験しているんだろ >>633
よう、NHKのアニヲタで鯖落とした萌え豚 TCP Tuning Guide - FreeBSD Tuning
http://fasterdata.es.net/TCP-tuning/FreeBSD.html
これがよさげ。
じっくり読んでみるか。 きゃ。これか。
FreeBSD 7.0 added TCP send and receive buffer autotuning.
There are some additional settings to modify.
(The default for these is 256 KB, which is too small):
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
デフォルトは 262144。
これは確かに小さすぎる気がする。
net.inet.tcp.recvbuf_max: 262144
net.inet.tcp.sendbuf_max: 262144 規制巻き添え組みは落ちた瞬間に実況できなかったからかわいそうに 17日はアニオタが総力を上げて鯖落とすから期待しててくれ >>646
この値はこの例だと、kern.ipc.maxsockbuf と同じになっているな。
ちょっとソースあたるか。
(live28 の kern.ipc.maxsockbuf は既に増やしてもらってある) 鯖落ちして暇な実況人は今回の試合は諦めろw
調整しながら補強してるんだからw
おいちゃんも珍しく頑張ってるしw live28はW杯が終わった頃には見違えるほど逞しくカッコイイ男へと成長していることだろう でさ、こいつらは 100Mbps のセッティングを想定しているから、
1Gbps だとこれに変えないといかん、って書いてあるじゃん。
Here are the new TCP Autotuning settings in 7.0 to know about.
Defaults for these should be fine for 100BT hosts,
but recvbuf_inc in particular should be increased for 1 or 10 Gbps hosts.
Here are the recommended settings:
net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
net.inet.tcp.sendbuf_inc=16384 # step size
net.inet.tcp.recvbuf_auto=1 # enabled
net.inet.tcp.recvbuf_inc=524288 # step size このプロジェクトさえ成功すれば明るい光が
完成したらしたでどうやったら落ちるのかが楽しみになるな >>654
おいちゃんはくだ巻いてるだけのように見えるんだがw 豚程度で落ちるんですか?
せめてムスカ大佐を出さないと。 >>656
net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
と
net.inet.tcp.recvbuf_auto=1 # enabled
は、デフォルトで 1 みたいだから、変えなくてよさそうだな。
net.inet.tcp.recvbuf_inc: 16384
net.inet.tcp.sendbuf_inc: 8192
がデフォルトか。いかにも少ないな。
1Gだと、これらも連動して変えないといけなそうだな。 次の負荷テストは、6/12 (土) 20:30 B 韓国 vs ギリシャ NHK総合 ですかね?
ttp://www.enjoy-soccer.net/tv/t-wave.html 95Mbps付近で落ちたのはやっぱり100Mbpsセッティングだからか >>643
明日の昼間に設定変更してもらって夜に備えるって事で で、
FreeBSD's TCP has something called inflight limiting turned on by default.
This is good for modem connections, but can be detrimental to TCP throughput
in some high-speed situations. If you want "normal" TCP Reno-like behavior, set this:
net.inet.tcp.inflight.enable=0
がーん、速い速度だとこれ、enable じゃいけないんだ、、、。 さっさと元に戻せこの無能集団共が。
お前らのオ○ニーはもう沢山だ 教訓:帯域増やしたらセッティングもちゃんと見直せ。 まとめると1Gbpsのセッティングしなきゃいけなかったのに
100Mbpsの設定だったと? live28ってi7使ってると思ってたけどCore2Duo使ってたのね
そういやCPU変えたらSSD実験の意味ないって誰か言ってたね ネットワークで落ちなくなっても次はCPUで落ちちゃうからつまんないな
90MbpsでCPU使用率65%じゃ、200Mbps行く前に詰まっちゃうな >>675
FreeBSDのデフォルト設定(少なくとも7.0Rでは)が、そう仕込まれている様子。 2ch鯖みたいに少量通信の大量接続だとRWIN小さい方が良さげな気もするがどうなんだろ >>642
のページ、
> c 2003-2009, Lawrence Berkeley National Laboratory
じゃないですか。
なら、書いてあることは、とても信用できそうだ。
LBLといえば、これ。
超プロ集団。
LBNL's Network Research Group
http://ee.lbl.gov/ けどこれが答えとは限らないのもおもしろさの1つ。
これでうまくいっちゃったらツマラナイw >>687
なんですよねぇ
超えるのが楽しいのに超えちゃったらとたん醒めちゃう >>678
転送量はAA爆撃をやらないとなかなか上がらない
スポーツ実況はアクセス数が瞬間的に上がるからCPU使用率が上がりやすいのかも >>642 のページと、
>>381 >>544 あたりの設定を入れるかんじかな。
>>642 のページ読んで、
私の中の疑問がいくつか氷解した気がする。 ここがトップページか。
TCP Tuning Guide - TCP Tuning Background
http://fasterdata.es.net/TCP-tuning/
久々にお宝に当たった気分。 良い出所の様ですし、こりゃうまくいくかな?
明日の夜でまた確認できそうですし。 >>693
つかXPのページ見ると、ADSL時代に流行ったパフォーマンスチューニングそのものって感じなんだが ここまで情報つかめたから、あとはじっくりやろう。
こんどこそお風呂入ってきます。 しかし、2chの鯖がここまで集約出来るとはねえ…… >>701
そうなればlive29(仮)の出番ががが 明日の韓国戦は試合中も終わってからも大変だろうなぁ・・・w >>705
なんだかんだでお祭りは楽しいんだよ
ここも似たようなもんだろ 明日は韓国戦だかんねっ!
今日より盛り上がるよ!プロだからw ちゃんと修正出来たっぽいです
つ http://happy.70.kg/ch2smart/
# gimpoのE9値が下がってきましたね 盛り上がるものが最近ないから
とりあえず盛り上がれそうなものに群がる 明日の昼の設定が終わったら、ゲーハーといくつかの板を移転させて、韓国戦でCPUの限界に達するという感じかな。 6/4にも同じ症状出てたけどあの時は居なかったんだな >>683
それが、>>531 ということなんじゃないかなと。
(以下独り言)
しかしなぁ、ネットワークI/Fの速度はOSでわかるんだから、
1Gbpsだったら1Gbpsっぽい値に自動的にセットされてほしいなぁ、と思うのは、
私だけかしら。
---
で、明日昼の設定変更依頼ですが、
まずは LNBL お奨めのやつを中心に入れてみて(nmbclustersは増やそうかと)、
韓国戦を迎え、何か起こるようなら小さくするやつ(>>531)の導入を検討する、
というかんじなのかなと。 >>719
ありえますね。
明日以降にソース読んでみようかな。
ということで今日はそろそろねるです。
おやすみなさい。 ghardの移転は明日の結果をみつつということで、 >>720
おやすみなさい
>>722
おいちゃんもお疲れさまでした 完全に乗り遅れた
100Mbpsで頭打ちって、雪だるまと比べてまだ半分くらいかな? なんJのTATESUGI値が16になってるからもとに戻して さて。
http://fasterdata.es.net/TCP-tuning/
<バッファサイズ>
> Since ping gives the round trip time (RTT),
> this formula can be used instead of the previous one:
>
> buffer size = bandwidth * RTT.
>
> For example, if your ping time is 50 ms, and the end-to-end network
> consists of all 100 BT Ethernet and OC3 (155 Mbps), the TCP buffers
> should be .05 sec * (100 Mbits / 8 bits) = 625 KBytes. (When in doubt,
> 10 MB/s is a good first approximation for network bandwidth on
> high-speed research and education networks like ESnet).
ということで↓、 バッファサイズは「帯域 × RTT」にするのがいい。
RTTが大きい場合、余計にバッファサイズが必要。
アメリカ西海岸にあって、主に日本の相手をしている
2ちゃんねるのサーバの場合、日本⇔日本なサーバよりも
10倍ぐらい大きなRTTを持っているから、バッファサイズも10倍必要になる。
で、日本からPIEへのRTTはだいたい130msぐらいだから、
適切なバッファサイズは100Mbpsの場合、
0.13 * ( 100000000 / 8 ) = 1625000
1Gbpsの場合、
0.13 * ( 1000000000 / 8 ) = 16250000
となる。 で、これを受けて、
http://fasterdata.es.net/TCP-tuning/FreeBSD.html
では、
kern.ipc.maxsockbuf=16777216
に設定していると。
で、今のlive28の設定では、
kern.ipc.maxsockbuf=20480000
に既に設定済みで(スペシャルセッティング内)、この値はRTT値に逆算すると、
20480000 / ( 1000000000 / 8 ) = 0.16384
となって、164ms の RTT に相当するのか。
この値は悪くなさそうだから、このままで。 >>732
今日は病院に行く日で(定期通院)、ちと早起き。 で、参考までに100Mbpsなサーバだと、
kern.ipc.maxsockbuf=2048000
がよさげということなのかな。
・今のgimpoの設定(デフォルトのまま)
$ sysctl kern.ipc.maxsockbuf
kern.ipc.maxsockbuf: 262144
これはいかにも少ないな。
日本⇔日本なら、これでもいいのかもしれないけど、
日本⇔アメリカでサービスする場合、これを10倍近く大きくしないといけないと。
というかこのデフォルト設定、
「100Mbpsで近場にサービスする」ってかんじなのね。 >>735
これねぇ。
EZwifi(だっけ)も、ezweb.ne.jpなんでしたっけ。
もう少し状況わかるとうれしいかも。
・EZなんとかなサービスにはどんな種類があって、
・それぞれどんなIPアドレス逆引きになるか
(例えばezweb.ne.jpになるとか、brew.ne.jpになるとか) http://fasterdata.es.net/TCP-tuning/FreeBSD.html
これを順に読んでいくと。
> FreeBSD 7.0 added TCP send and receive buffer autotuning.
> There are some additional settings to modify.
> (The default for these is 256 KB, which is too small):
>
> net.inet.tcp.sendbuf_max=16777216
> net.inet.tcp.recvbuf_max=16777216
こいつらは例に従い、kern.ipc.maxsockbuf の設定値に合わせればいいかな。
net.inet.tcp.sendbuf_max=20480000
net.inet.tcp.recvbuf_max=20480000
これでいこう。 例の「7.0Rのデフォルトは100Mbps想定だから小さすぎる、
1Gbpsや10Gbpsではもっと大きくしれ」のところ。
> Here are the new TCP Autotuning settings in 7.0 to know about.
> Defaults for these should be fine for 100BT hosts, but recvbuf_inc
> in particular should be increased for 1 or 10 Gbps hosts.
> Here are the recommended settings:
>
> net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
> net.inet.tcp.sendbuf_inc=16384 # step size
> net.inet.tcp.recvbuf_auto=1 # enabled
> net.inet.tcp.recvbuf_inc=524288 # step size
↓ net.inet.tcp.sendbuf_auto と net.inet.tcp.recvbuf_auto は、
デフォルトで1だから、
net.inet.tcp.sendbuf_inc=16384
net.inet.tcp.recvbuf_inc=524288
これでいこう。
ちなみに今のlive28の値はそれぞれ、
%sysctl net.inet.tcp.sendbuf_inc
net.inet.tcp.sendbuf_inc: 8192
%sysctl net.inet.tcp.recvbuf_inc
net.inet.tcp.recvbuf_inc: 16384
例のゴールの詰まりの時に、
受信バッファの増えていく度合いが少ないな、という印象を持ったから、
感覚とも一致してるな。 > FreeBSD's TCP has something called inflight limiting turned on by default.
> This is good for modem connections, but can be detrimental to TCP throughput
> in some high-speed situations. If you want "normal" TCP Reno-like behavior,
> set this:
>
> net.inet.tcp.inflight.enable=0
高速なネットワークだと、inflightは0の方がいい、と。
で、
tcp throughput and net.inet.tcp.inflight.enable
http://lists.freebsd.org/pipermail/freebsd-stable/2006-February/022589.html
この報告事例とスレッドを読んでみると、
特に1Gの場合はこの値、0にしたほうがよさげなかんじ。
net.inet.tcp.inflight.enable=0
これで。 >>741
設定変更内容が決まったら、
今日の昼の間に1回設定変更&リブート入れていただく予定です。 続き。
> By default, FreeBSD caches connection details such as the slow start
> threshold and the congestion windows size from the previous connection
> to the same host for 1 hour. While this is a good idea for a web server,
> it makes it hard to do network throughput testing, as 1 large congestion
> event will throttle performance for the next hour.
> To reduce this effect, set this:
>
> net.inet.tcp.hostcache.expire=1
>
> This will still cache values for 5 minutes, for reasons described
> in this article from the Centre for Advanced Internet Architectures
> (CAIA) at Swinburne University in Autralia. This article(*1) has a lot of
> other good tuning information for FreeBSD too.
> They also have a (*2)H-TCP patch for FreeBSD that looks useful.
で、ここからリンクされているのは、
(*1)
Tuning and Testing the FreeBSD 6 TCP Stack
http://caia.swin.edu.au/reports/070717B/CAIA-TR-070717B.pdf
(*2)
newtcp
http://caia.swin.edu.au/urp/newtcp/tools.html
と。 >>747
net.inet.tcp.hostcache.expire の今の live28 のデフォルトは、
%sysctl net.inet.tcp.hostcache.expire
net.inet.tcp.hostcache.expire: 3600
ということで 3600秒 = 1時間 になっていて、
この値はWebサーバの場合「短くすりゃいい」ってもんでもなさそうで、
「さじ加減」が必要と。
で、上の (*1) を読め、ってことなのかな。 >>719,720
手元の8.0-Rマシンの、
http://fasterdata.es.net/TCP-tuning/FreeBSD.html
この辺の環境変数のデフォルト値は7.xと違いが無かったので、
恐らく8.xでも弄る必要はありそうです。
私もここを読みながら試しに値を調整して様子見を始めている所ですが
手元のケースでは1G結線部分の通信で改善が見られるっぽい。
(*1)の II の C にこれらの記述があるわけだが(下記はデフォルト)、
%sysctl net.inet.tcp.sendspace
net.inet.tcp.sendspace: 32768
%sysctl net.inet.tcp.recvspace
net.inet.tcp.recvspace: 65536
まずは、変えないでいってみるか。
例の別のWebで、減らすといいって言っていたやつ。 >>751
情報ありがとうございます。
8.xでもこのあたりは変わっていないと。
で、>>750 は変えないでいってみようかなと。
確かにWebや(*1)に書いてあったように、研究とかテストの時は困りますよね。
同じ相手だけど接続環境をしょっちゅう変える、
なんてのは、日常茶飯事で、その時に前の値が最大1時間残ってしまう、
っていう話だから。 つぎ、MTUか。
1Gbpsだからジャンボフレームを試してみる価値はあるけど、
確か同じセグメントというか同じスイッチのを*全部*ジャンボフレームに
設定しないといけなかったと思うので、
今は 1500 (デフォルト)のままでいってみようかなと。
・ifconfig で mtu 9000 などとするのは、今回はなし。 sendspaceとrecvspaceはソケットバッファサイズで
小さくするとmbuf使用量が減る
sendbufとrecvbufはTCPのウインドウサイズで、
輻輳の無い状態なら大きくすればスループットが上がるが
輻輳が有る状態で大きくすると再送が増加しスループットが下がる
という感じかな、何か相反する設定のような気がしないこともない こんなところかな。
ということで、まとめを。
<現在の設定内容変更>
・/etc/sysctl の設定変更内容
(変更前)
# nmb (number of mbufs) tuning for FreeBSD 7.x
# note: kern.ipc.nmbclusters=65536 should be set at /boot/loader.conf
kern.ipc.nmbjumbop=32768
kern.ipc.nmbjumbo9=16384
kern.ipc.nmbjumbo16=8192
(変更後)
# nmb (number of mbufs) tuning for FreeBSD 7.x
# note: kern.ipc.nmbclusters=131072 should be set at /boot/loader.conf
kern.ipc.nmbjumbop=65536
kern.ipc.nmbjumbo9=32768
kern.ipc.nmbjumbo16=16384
・/boot/loader.conf の設定変更内容
(変更前)
kern.ipc.nmbclusters=65536
(変更後)
kern.ipc.nmbclusters=131072 <設定内容追加>
・/etc/sysctl.conf の設定追加内容(1Gbps用のTCPチューニング)
# additional network settings for 1Gbps connection
# http://fasterdata.es.net/TCP-tuning/FreeBSD.html
net.inet.tcp.sendbuf_max=20480000
net.inet.tcp.recvbuf_max=20480000
#net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
net.inet.tcp.sendbuf_inc=16384
#net.inet.tcp.recvbuf_auto=1 # Receive buffer autotuning enabled by default
net.inet.tcp.recvbuf_inc=524288
net.inet.tcp.inflight.enable=0 では、今日の11時にこの設定を入れていただけるかどうか、
今日の10時頃に、中の人に確認してみます。
設定時に一度リブート必要なので、サーバ止まります。
OKなら、それでスケジュールするということで。 >>738
なんとも間が悪い日ってありますね。739は雪だるまへの誤爆です。。
素人ですが調べてみました。
au携帯からのnet接続は通常の Ezweb、PCSV、BREW、オープンアプリプレイヤー(OAP) の4通りで、
今回、問題になってるのはEZ番号を送らない PCSV での BBQスルーのsiberia板 への荒らし書込みです。
http://qb5.2ch.net/test/read.cgi/sec2chd/1275119988/ ★100529 siberia samba突破「.pic.to/」画像URL羅列 連投マルチ報告
PCSVの帯域表
http://www.au.kddi.com/ezfactory/tec/spec/pcsv.html
こちらのPCSVでの書込みをのsiberia板でも不可にして頂きたいという状況です。
かっこいいお兄さんは、とりあえずシベリアのBBQ除外設定を外すことで問題を解決できるとの考えのようです(上記スレ189への193のレス)。
将来的には他のBBQスルー環境での書込みが問題になる可能性もあります。
OAPでのUA等仕様(ホスト名、アドレス帯域の情報なし)
http://www.au.kddi.com/ezfactory/tec/spec/openappli.html
アプリの仕様にも寄ると思いますが、以下の方の場合OAPでのホストはbrew.jpになるようです。
http://qb5.2ch.net/test/read.cgi/operate/1275745544/14n
BREW通信のIPアドレス帯域(法人客向けサポートページ)
http://www.kddi.com/business/customer/tec/index.html
BREW通信の一般のアドレス帯域のソースは見つけられませんでした(先の前スレ14さんのアドレスが含まれるものも)。 >>760
たすかります。
しかし、なんだか複雑ですね。
というかいろんな情報を総合するに、
au って、自分のことを「インターネットサービスプロバイダ」だとは
全く思っていないふしがあるような。
だから、プロバイダが果たすべきことをきちんとしよう、
なんていう気は、そもそもこれっぽっちもなかったりするのかも。 おつかれさまです。
私でよければ先方に問い合わせいたしますが…… >>762
たすかります。
・PCサイトビューアーでの接続の際に、Webサーバ側でEZ番号を入手する方法はあるのか
→ある場合、
・その方法を教えてほしい
→ない場合、
・従来どおりの通報、つまり、
接続元IPアドレスと接続時間での通報、
つまり通常のISPへの通報のパターンで報告した場合、
そちらではユーザの特定は可能なのか
もし可能なら、通常のISPと同様、荒らしたユーザに対し、
きちんと対応していただきたい
もし不可能なら、ISPが果たすべき責任を果たしていないと判断し、
PCサイトビューアーからの書き込みは、今後一切禁止する
こんなかんじでしょうか。 >>764
了解いたしました。後ほど問い合わせいたします。
wifi-winについては問い合わせなくても大丈夫でしょうか。 >>766
wifi-win についてはこんなかんじでしょうか。
・wifi-winでの接続の際に、Webサーバ側でEZ番号を入手する方法はあるのか
→ある場合、
・その方法を教えてほしい
→ない場合、
・従来どおりの通報、つまり、
接続元IPアドレスと接続時間での通報、
つまり通常のISPへの通報のパターンで報告した場合、
そちらではユーザの特定は可能なのか
もし可能なら、通常のISPと同様、荒らしたユーザに対し、
きちんと対応していただきたい
(ここまではPCSVの時と同じ、ここからが違う)
もし不可能なら、ISPが果たすべき責任を果たしていないと判断し、
wifi-winのIPアドレスレンジが公開されていないことから、
EZweb経由ではない場合で、かつDNS逆引きが ezweb.ne.jp だった場合の
書き込みは、今後一切禁止する >>767
ちなみにwifi-winではIPアドレスレンジを公開していないため、
仮に、
・wifi-winでの接続の際に、Webサーバ側でEZ番号を入手する方法はあるのか
→ある場合、
・その方法を教えてほしい
が、「ある場合」だったとしても、
書き込みOK、というわけにはいかないです。
そんなかんじで。 今日の11:00から作業開始、ということで、
スケジュール入りました。
11:00ちょっと過ぎにbbs.cgiを止めます。
その直後にリブートが入り、板復帰→bbs.cgi再開、
という手はずで。
所要時間は昨日と同じか、うまくいけばやや短いぐらいの予定。 >>772
ズズズ
で、午後は病院なんで、
あんまり時間とれないということで。 rootさん、いつもお疲れさまです!
11:00からですね、了解しました。 15分程度と考えて問題ないですか? >>754
webサービスがmtu大きくしても意味無いんじゃ?
どうせinternetに出るときにルータで拒否られて再送する手間が増えるだけではないのかと >>776
IPv4だとそういうのは、たぶんルータでフラグメントされるですね。
IPv6だとpath mtu discoveryっていうやつがあって、
というか設定できたかな。
ちょっと確認してきます。 >>776
で、ローカル通信じゃないのにそんなとこ大きくしても、
っていうのには、同意かも。 >>761なんか見てるとやっぱ携帯ネットは終わりな感がしてくる ファイルの設定変更完了のお知らせがきました。
bbs.cgi 止めて、リブート依頼してきます。 >>778
それブラックホールルータ探す、ってのでしたっけ?
ヘッダ増量して
>>779
家庭内の話ですがjamboってdawn方向には効果あったけど
upには毛ほどの効果もなかったって経験がありまして 正しくあがってきた。
各設定値が、設定内容どおりに正しく増えているのを確認。
さて、板復帰してbbs.cgiあげてきます。 これで、
・むむむスペシャルセッティング(ネットワークバッファ拡大など)の一部改良 (>>756)
・むむむスペシャルセッティング4(1Gbps接続用のTCPチューニング)の実施 (>>757)
が入りました。 何回落ちても、CPUの限界が見えてこない件
どんだけ耐えるんだ、こやつ
i7って、更に凄いのか? >>798
SSDの限界はもっと先みたいです。
限界に行った時の挙動には興味あるかも。 おつです
これで100Mbpsの壁は越えられるのかな そういうネーミングなんだから敬称略さなくてもいいのにw % netstat -m
(略)
425/919/1344/131072 mbuf clusters in use (current/cache/total/max)
ここが正しく131072になったのを確認。 エラーという意味でのSSDの限界は早く来るかもしれませんけど、性能的限界はまだまだですね。
すごいなぁ・・・。
CPUもi7にしなくても問題ないような気がするレベルですよね。 >>804
CPUは昨日の段階で結構、限界見えていたので、
強化する意味がありそうです。
というか、CPUを安心して強化できるように、
ネットワークのチューニングをしている、という話も。
(ディスクはSSDにより、当面限界は来そうにないかんじ) ありゃ、CPUは限界見えていたんですね。
失礼いたしました。
何はともあれお疲れ様です。ご自愛ください。 >>808
いい時間ですね、、、。
しかもNHKですか。 >>807
ワールドカップをググると、1ページ目に出てきたり
試合毎の放送局は間違いもあるようですが
22:30からフジテレビ系で、アルゼンチン対ナイジェリアもあります その韓国戦が終わってしばらくしたころの、
午後10時30分からフジテレビでアルゼンチンVSナイジェリア >>812
はい、たぶん
それよりもマラドーナ監督のほうが気になるんですけど 鯖落ちるからといって自粛したりして
んな訳はないかw 男子たるもの やはり明日の はやぶさ実況だろうに、 ・live23とlive24の花子への収容
を進めます。
と言っても私はこれから、通院の予感。
花子へのアカウント作成の申請だけしておこうかと。 >>821
live23 と live24 収容用の土地作成依頼 @ banana3000 を連絡した。 >>798
i7はこういう用途に強いアーキテクチャだから凄まじい適正を示すと思う。 >>823
ディスクがHDDの時でさえLAがなかなか上がらなかったのを覚えてる@旧yutori7 >>822
作成完了を確認。
帰宅後、ぼちぼち移動作業など。 今日は韓国×ギリシャ戦のキックオフと同時に落ちると予想w rootたん出かけるなら、ブブセラ買ってきたら?w ライトキャッシュが持てば、SSDでは別に落ちないんじゃね?
どんなお祭りだろうが1000まで行けば更新終了。
更新終了したやつを優先的に保存すれば読み込みは早いんだから負担はかからないはず。
問題は大量のスレッドで同時にアクセスが増えることで、
これに結構なメモリを消費すると思う。
クラスタギャップとか調整してあんのかな?してないはずはないと思うけど
最適に調整してあるかないかで負担は倍くらい違うだろうし。
>>828
言うなれば数え役満は単独の手役で作るものじゃない
韓国戦の前半は野球がある。この時間帯に他で負荷の上昇があれば合わせ技で落ちるかも
(あとは瞬間的な負荷上昇が同時に起こるといい感じ)
地上波で巨人戦やってる開始20分あたりまでに点が入れば実験的には嬉しい展開 まずは設定が有効かどうか確かめる。
落ちたらまた再設定。
落ちなければ深夜にゲハ移動。
そしてまたテスト。
>>771
auの事だから非公開です(キリッ
だと思うなー。 明日は明日で、組み合わせや中継の有無はともかく
はやぶさ帰還、MAGネットの水樹奈々特集辺りが、夜の試合に重なってるしね >>783
各ネットワーク機器が十分早くなったので、Jambo自体あまり
意味が無くなってるつぅ話も聞きますね
個人的にはローカルで使う物だと思ってますが(上位は通してくれない)
ローカルレベルなら機器側が耐えられると >>832
はやぶさ実況はアニ特でやるとか、live28を避けて「なんU」でやるとか言ってる。 ネットワーク負荷が高いときにジャンボフレームなんてつかったら最悪バッファ溢れてパケロス出まくるぞ。
あれは低負荷時にスループット出したいときに使うもんだ。 >>834
おいちゃんに「なんU」をlive28に移転させて欲しいってことですね、わかります >>835
と、いうか
現状の1500でもフラグメントが起きている気が・・・
うち1454以上に設定できないからping -fで確認出来ないが >>834
自分たちさえ良ければいいという典型だねw >>834
マジで始めたら鯖落とそうぜ。
文句言ってきたら「お前らの実況で落ちた(キリッ」で どこへ移してもいいけど、規制がないところじゃないと宇宙実況はできないよ ネット実況全般みたいな板があってもいいかもしれないけど
宇宙実況だと「24時間スクラブ→打ち上げでどーん→10日待機→帰還どーん」みたいな
まさにロケットサイエンスなんで考慮してほしい
>>839
http://qb5.2ch.net/test/read.cgi/sec2chd/1275155368/102,103,109,123
(dat落ち)
アニ特については実況難民目的でも使える様にしてもらったから移動しただけでしか無い。
悔しかったらちきちーた★さんに苦情言えよ。
正当な主張ならアニ特の設定戻してもらえるかも知れませんよw >>845
またお前か
邪魔だからまとめて他にいけアニオタ ただいま。
>>827
昨日TVで盛んに鳴ってたやつですか。
で、MTUは1500で変えない、ということで。
そんなわけで、
live23とlive24のデータ移動をば。 live23とlive24のデータ移動ってどういうこと?なう >>850
急というか、予定の行動にて。
F22/F15 @ live23/live24 (フロント・バックとも) 停止。
F35 だけ1日1回に設定。 >>851
使用上の影響はないです。
他の過去ログ同様、花子に収容すると。 >>852
rootたんのことじゃありません><
お疲れ さういえば、花子のポイント受領時の動作は直したのかな
その前にディスク1台破損していてもログを吐かなかった件とか
マァブがいないから触らないのかな >>849
おつです。
雪だるまの各種設定(matd/carpなど)は、
どこかに退避しておいて欲しいな。
2chではもう使わない気もしますが。
>>129 が届きました。
たんたんとセットアップへと。 >>859
解体時に一式、花子(memories2)にバックアップをとっておく予定です。 「雪だるまサーバ群はしばらく待機」の予定もlive28順調で早くも退役か。
ITメディアにたれこんだ内容とはちょっと違ってきた。 遊ばせておくんならいっそlive28に対抗して
実況もニュースも板を次々吸収合併してゆく保持数8000くらいの
超巨大板を一枚作ればいいのに 雪だるまには結構お世話になったから寂しいな
新型live29にも可愛い名前を期待しよう root ★さんへ
live24(live23も?)の移転のときにまだdat落してなかったスレが
丸10日以上たった現在も過去ログ倉庫に落ちてきてないんだけど live29@すぺしゃるせってぃんぐ を雪だるまフロントに利用
バックエンドをlive28
そんな意味の無い構成は何に使えるのだろうか、、、 >>864
FOXが見ているから名前の話は止めよう おきつねさんのネーミングセンスって実は不評なのか?
結構好きな私って、、、 emの割り込み調整ですが、FreeBSDでは、
tunableなパラメータでの調整はintel非推奨
推奨されている調整法で触るパラメータは、ソースコードに書かれていてリコンパイル必須
という感じになっていて、
次の一手ではなく、5手ぐらい先の手になりそうな予感がします。
いじれば多少なりとも"どばっと"に強くなりそうな部分ではあるのですが。 今回はゴール入るたびにPIEのコアルーターが吹っ飛ぶ。 >>870
情報ありがとうございます。
他にもっとやることがあるかんじ、と。 (´・ω・`)さん日記更新。内容はスペシャルセッティング3と次期i7鯖
http://www.maido3.com/server/zousan/nikki177.html
なんかいつもよりカラフル 書き手によって結構かわりますね。
好みの問題はあるでしょうが、
項目事が分かりやすくて私は好きですな。
>Core i7-960を搭載したHDD+SSD構成のサーバーに決定しました!
>しかも既に発注済み!!
>もちろんメモリも8GBよりさらに増えますので全体としてかなりパワーアップするはず!
更に強大なモンスターが・・・。
このW杯での負荷試験がこのモンスターにフィードバックされるんですね。 モンスターマシーンはその性能以外のところでこけてるイメージ 最近の2チャンネル関連の鯖では、P2用にブラジルが用意した
w2鯖が最強だったような気が・・・
これで実況鯖とかしてくれないかなw
ネットワーク帯域: 1Gbps
CPU: Xeon X5570 (4 core) x 2
論理CPU数: 16
メモリ: 24GBytes
Ethernet: Intel 82575EB Gigabit Network Connection
HDDコントローラ: LSI SAS1078 PCI-X Fusion-MPT (SAS 3Gb/s)
HDD: FUJITSU MBD2147RC (147GB 10000RPM 6Gb/s SAS-2) x 8
システムディスク: RAID 1 (上記のうち2台使用)
データディスク: RAID 1+0 (上記のうち6台使用) >>881
HDD鯖というのもあるが
P2サービスは一応課金サービスだから・・・ P2の新型鯖は例に漏れずHDDがネックになってCPUをもてあましている状態だったはず
live29予定が最強鯖は間違いないだろう
本気で2ちゃん鯖が一台になってしまうかも知れない 今回も、SSDはインテルの80Gなのかな?
インテルSLCとかになればさらにすごくなりそうだ。でも容量きつくなるか。 >>880
いかにモンスターでも掃除のおばちゃんには負けるもんな >>891
一方Googleはママンに二次電池を載せた 試合が始まる・・・
まず注目は点が入った時の挙動ですな トラブルやすごいイベント以外は、
>>890 でリアルタイムにやろうかなと。 JAXA 宇宙科学研究所
はやぶさ管制室からライブ中継
6月13日(日)18:00〜24:00
(※音声はありません)
ttp://hayabusa.jaxa.jp/live/ CANADA GP
Practice 3 SAT 23:00
Qualifying SAT (Sun) 02:00
Race SUN (Mon) 01:00
ttp://www.formula1.com/default.html キタ━━━ヽ(∀゚ )人(゚∀゚)人( ゚∀)ノ━━━!! 無能運営の皆様方、しっかりと働いておられますでしょうか 同じか。
%telnet live28.2ch.net 80
Trying 206.223.151.120...
telnet: connect to address 206.223.151.120: Connection reset by peer
telnet: Unable to connect to remote host
次スレを立ててもイイという解釈でヨロシイでしょうか(笑) ここは作業スレだから文句などはこっちへどうぞ
2ch運用情報
http://qb5.2ch.net/operate/ 書き込みの時に、httpd ⇔ speedy_backend の間の通信が、
うまくいかなくなっているっぽいな。 CWWCWWWWWCWWWWWWWCWCCWCCWWCCWWWCCWWCWCWWWWWWWWWCWWCWWWCCWWWWWRWW
CWCWWWWCWWWWWWWWCWWWWCWCWWWWWWCWCWWWCWWWWWWWWCWCWCWWWWWCCCCCCCWW
WWWWWWWCWCWCWCCWCWWWWWWCWCWWCWWCWWCWCWCWWWCCWWCCWWWWWWWWWCCWWCWW
WCCWCCWCWWCCCWCWCWWWCWCCCWCWCWWWCWWWCWWWWWCWCCCCCCCWWWCCWWWWWWCW
WCWWCWWWWCWWWWWCCCWWWWCCWWWCWWWWWWWWWWWWWRCCWWCWWCWWWWWCWCCWWWWC
WWCCWCWWWWCWWWCCWWCWCCWWCCWWWWWCWWCWCWWWWWCCWWCWWCCCCCWWCCWWCWWC
WCWCWWWWWWCCWWWWWWWWCWWCCWCCWWWCWWCCCCCWWCCCWWWWCWCCWW_WWWWWCCWW
WWWCWWCWWWWCCWWCWWWCWCWWWCWWWWWWWCWCWWCCWWWCCWWWWCCWWWWCCWWCWWWW
CWWWWCWCWCCCWCWCWWWWWWCWWWWCWCWCWWCWCWCWCWWWWWCWCWWWWCWWCWCWWWWW
CWWCWWWCCWWCWWCWWCWCWWWWWWWWWWWWWCWWWWWCWWWWWWCCCWCWCWWWWCWWCWCW
WCWCWCWWWWWWWWCWWWWCWWWCWWCWWWWCCWWCCWWWCWWWWWWWCWCWWWCWCWWWWWCW
なるほど、httpdも売り切れか。
というかWになっちゃまずいね。 >>926
いっしゅんrootタンが壊れたのかと思ったw httpが704では足りなそうだな。
増やす必要ありですね。 一瞬rootたんがスクリプト埋め立て荒らししてるのかと思ったw >>926
すみません、これなんです?
なんかの書き込み状況の記号ですか? 今回は mbuf はあふれていないようだ。
netstat -m
56643/852/57495 mbufs in use (current/cache/total)
21197/457/21654/131072 mbuf clusters in use (current/cache/total/max)
21197/403 mbuf+clusters out of packet secondary zone in use (current/cache)
33140/441/33581/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)
189114K/2891K/192005K bytes allocated to network (current/cache/total) rootの中の人が嵐になった瞬間を見たかと思ったのに >>937
動いているプロセスの一つ一つ状態と予想
WはWait? "_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process
Apacheからnginx+FastCGIへの乗り換えクルー? httpdを再起動。
一度つながれば早いですね。
httpd の売り切れの可能性が大きいです。 >>956
>httpd の売り切れ
また、どこかの設定を変更すれば再発しなくなるものなのそれ? 普通に流れている時はこう。
CC___C______C___C_CC___CC_CWCCCCCC__C_C_CWCCCC_C_C__C__WCC_C_C__
C_C____C_CWCWWC___C_C____CC__CWCC____CC__C__C___W___CW___CCC_C__
C_CCC_CC_C___CC__W_W_CC__CCC__C___C__CCCWC__CW_W___C___CCCC__C_C
_CCC__C___WCCCW_C__C___WC_CCC_CC_CC_____CC_CWC____CCW__WCC__C__C
___CC_CCCW_CCC__W__CCC_CWC_CC__C_WC_C__CCCW__CCCC_C_CCC__C_C_WC_
_C__C___C___C___C__C_CC_C_CC_C_CW_C__C_CC_C_C__WC____W__CWC_CC__
WWCCCC_CCW_CCC_CCCC__WCC__C_CCC_CC_C__W___CCW_C_CCCC_CCCC_C_C__C
C__C_W_CC__CC_C__CCCC____CC_CCC_C_CCCC_WCWCCCCC_CWCCCC__CCCC____
_C___CC_CC________C__CCC_____C_CCCW__CCCW_C_W___WCC_C_CC__CC_CCC
CCW_CCC__CW_C_CCC_CCC____C___CCC__C_WC__C_C____WWC_CCCCCC_CCCC_C
__C_C____C_CWCCC_CCCC_CCCCWCC_CCW_CCC_CWCCCCC_C___C______C_CC__C 昨日はmbuf、今日はhttpd。
着実に問題点洗いだしてますね >>961
トイレに行けそうでいけてない人がいっぱいいる、そんな状態ですね。 googleがwave用とか言ってなんか早いwebサーバ作ってなかったっけ
あれどうなったんだろ。 >>968
RTTが高いから、closeに時間がかかっているんだと思われ。
なお、KeepAliveは切ってあります。 落ちたときの転送量は80Mぐらいだから、昨日のセッティングがうまくいったかどうかはまだわからないのか さっき目撃したところだと、
書き込みが集中する
↓
httpdが足りなくなる
↓
一度足りなくなると、なかなか回復しない
という感じに見えた。 オイルショック時のトイレットペーパー騒動か。
噂が広まる(得点はいる)→買いに走る(書き込み増える)
→トイレットペーパーの在庫が無くなる(httpdが足りなくなる)
→供給されるまで店仕舞い(なかなか回復しない) CCCCCCCCCCWCCCCCCCCCCCCCCCCCCCCCWCCCCCCCCCCWCCCCCCCCCCCCCCCCCCCC
CCCCCWCCCCCCCWCCCCCCCCCCCCCCWCCCWCCCCCCCCCCCCCCCCCCCCCCCCCCCCWCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCWCCCCCCCCCCWCCCCCCWCCCCCCCCCCCCC
CCCCCCCCCCCCCCWCCCCCCWCCCCCCCCCCCWCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCWCCCCCCCCCCCCCCCCCCCCCWCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCWCCCCCCCCCCCCCCCCCCCCWWCCCCCCCCCCCWWC_CCCCCCCCCCCCCWCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCWCCCCCCCCCCCWWCCW
CCCCCCCCCCCCCCCCCCCCCCCWCCCCWCCCWCCCCCCCCCCCCCCWCCCWCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCWCCCCCCCCCCCWCCCCCCCCCCCCCCCWWCCCCCCCCCCCCCCCCC
WCWCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCWCCCWCCCCCCCCCCCCCCCCCCCCCCCCCCCCCWCCCCCCWCCC
一瞬あぶなかった。
httpd が少なすぎは確定だな。 あとは、httpdとspeedy_backendの間のやりとりを疑うべきだな。
mod_speedycgi モジュールから、speedy_backend が呼ばれる時って、
どうやりとりしてるんだっけ。
何か、やり取りに使う資源が足りていないような印象もあった。 本当にスムーズな時は____________とずっと並ぶとか、
時たま間にCが入る程度で並ぶもんなんですか? >>974
なるほど別に問題なさそうですね。わざわざアリガトウございます。 >>984
それだと、すいている時ですね。
Cが適当に並んでいて、たまにWがあるの時がいけているかんじ。
Wが多いのは処理に時間がかかっている。 >>981
BufsizGet、BufsizPost、MaxBackends あたり? 梅ってやっちゃいけないんだよね、確か。
↓1000取り合戦 ┌──────────────────────―┐
│ |
│ |
│ /■\ |
│ (´∀`∩) |
│ (つ 丿 |
│ ( ヽノ |
│ し(_) |
│ |
│ Now Susukinoing... |
│ |
│ 処理中 |
│ しばらくおにぎりでお待ちください。 |
│ |
└──────────────────────―┘ このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。 レス数が1000を超えています。これ以上書き込みはできません。