2ch特化型サーバ・ロケーション構築作戦 Part40
■ このスレッドは過去ログ倉庫に格納されています
2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
前スレ:2ch特化型サーバ・ロケーション構築作戦 Part39
http://qb5.2ch.net/test/read.cgi/operate/1274259928/ 今見たら、bg24.2ch.net は上がっていた。
ログインもできた。 >>230-231
はい、定期お掃除(f22)で古いのは消えていくます。
>>233
そうですね。
lagg(4) は FreeBSD 7.0Rでもサポートしているので、
トライする価値はありそうですね。
man lagg すると設定例が書いてあります。 >>194は無事終了してますた。
>>243
返事がきますた。
<要約>
・詳細調査の結果、bg24 = banana3203 はハードウェア不良ではなく、
スイッチ側の問題であり、スイッチの再起動により復旧
・詳細調査の際に banana3203 のハードウェアには異常が
見つからなかったため、bg24 は banana3203 で継続して動作させる
・フロントサーバの起動作業は5月29日午前10時ごろから開始し、
動作チェック等で問題が無ければ午後1時には完了する予定
体力の限界につき、私はそろそろ負け組へと。 お疲れ様です
>>246を携帯スレに貼らせて頂きます >>246
夜遅くまでお疲れ様でした(`・ω・´)ゞビシッ!!
>>248
ではオレは某所へと・・・ gimpo は2〜3日前に酷く引っ掛かる現象があったな〜(笑) 逆に言えば交換時期がわかるというのはとてつもないメリットにも思える 交換時期がわかったとして、CPの面で実用的なのかは別の話。 gimpoぐらい枚数があると全部ジンギスカンってわけにもいかんだろうから… 複数の鯖を一台に集約出来る事を考えたらCPも悪くないんじゃない? 睡眠不足は血糖を下げる作業の妨げとなります
充分に寝ましょう(@全ての40歳以上の方) E9自体はデータを書き込んだ総量を記録してるだけだから当てになるも糞もない
保証書き込み総量を1バイトでも越えたらすぐ壊れるのかって議論ならわかるけど 間違った 書き込んだ総量から補償書き込み総量を差し引いた残りか >>246
> 午前11時30分にc.2ch.netの全てのサーバが復旧しました。
とのこと。 >>261
rootさん、お疲れ様です(`・ω・´)ゞビシッ!!
リブート要請スレに転載しました まだまだyutori7やtsushimaは余裕ありそうだし、
他の鯖からでかいところを持ってきても大丈夫だと思うんだ
例えば、morningcoffee,ogameをyutori7、ghardをtsushimaに持ってってyutoriの負荷を減らすとか(夜間のyutoriは結構重い) >>264
素直に、5号機をyutori無印に投入だろ。でも、5号機はバナナか。 E9他の値検証も含めてのまさに人柱だからなあ。
E9が0になった暁に一体何が起きるのかとか、巷で言われているようなデータ化け
とか含めた実証試験と思えばw
その上で蓄積したデータを基にして、その後の方針をまたワイガヤすれば良いだけだし。 そういやyutori7鯖の修理中のやつってどうなったの? まだどういう壊れ方するか判らないし
初期導入コスト対ランニングコストの分岐点も見極めなきゃ
板詰め合わせの話はずっと先でしょ。 しかし約1日でE9-1ってのは下手すりゃ3ヶ月持たない可能性もあるのかしら?
でーた化けが表に出てすぐ分かるものならいい実験なんでしょうけど。
帰宅したらグラフ自動調整するように組まないとなぁ、このまま行くとはみ出るわw とりあえずgimpoの/home側をnoatime化が急務なのか? >>269
観測開始地点から、1か月前から、一週間前からの3パターンあると美味しいかもね >>269
縦軸の目盛りを一番下が0・一番上が100に固定するだけでもいいんじゃね? 色んなの作れるけど22〜23日分のでーた消失しちゃったからなぁ・・・
誰か持ってないかしら? ある事はあるけど、途中までしか記録してない。
それにsystem側のデータも取得してない。 >>273
とりあえず今からの分だけでも表示できるようにすればいいと思うんだ >>261
いや
言わせて貰うけど
そんなもん復旧してもほとんど規制されてて書けないから
それ もうROM専用さ〜ヴぁにしてくれよ(笑) >>272
いや、縦はいいんだ。でーた差がない場合表示の上限が100、下限が0、
でーた差がある場合はmax、minをとってそれを表示の上限、下限にしてる。
問題は横で7日分の日毎のでーた全部使ってるので、このままだと伸びたり縮んだりするのだ。
帰ったら直すよ、一日24でーたあるから、8日分位まとめてケツから7*24でーた取りゃいいはず。
でも1ヶ月っているかな?週間と累積位でいいんじゃなかろか? >>279
この感じだと2〜4か月で終焉が見えるから一カ月はいらなかったかも・・・
累計は100-0(%)で一週間は平均から±5〜10%あたりを表示するとか 7号機 帯域を 1Gbps に変更完了 セットアップ完了
6号機 帯域を 1Gbps に変更完了 セットアップ完了
一言:6号機・7号機 1Gbps に帯域変更完了
いつだ >>284
> ちなみに、なぜオンラインにするのに時間がかかったかと言いますと、
> 1Gbps スイッチへのサーバーの移動をお願いした PIE のスタッフが
> 「1Gbps サーバー」=「プライベートネットワークを組む」
> との勘違したらしく、サーバーの2番目のNICと1Gbpsのスイッチを
> ケーブルでつないでいました。
PIE orz 帰宅したら規制されていた件
>>280
なるなる、危なそうってのが分かればいいもんですしねぇー、じゃあ週間でいいかなぁ
表示の細かい調整は使っていきながらやってみますか、Image::Magickで描いてるのでなんぼでも変えれますん
とりあえず一週間分168でーたを表示するようにしてみたこれではみ出ることは無いだろう
多分( ゚∀゚)y─┛~~ >>287
キャップあると規制回避されるんじゃないのか?
キャップなしで書き込んで気付いたんだろ 交換する際はSLCに変えてコスパ見るのも一興。
耐性に10倍もの差があるなら初期コストが倍とか三倍でもペイ出来るし。
問題はgimpoに入っている第一世代のSSDとyutori7以降に入れた第二世代の差がどれだけあるかということだ >>216
SSD以外はT-Banana2009だし、hideyoshiとjfkをリフレッシュを兼ねてひとまとめにするんじゃ?
それかatlantaに投入とか 耐久テストでE9が1のまま一日変化がなかったらしい
ttp://botchyworld.iinaa.net/ssd.htm#try3 鯖ではなく回線どんづまりになったのでは
yutori7は100Mbps線だし 一時的にへこんでますね。
http://traffic.maido3.com/DxxB/dIbc/ramJ/
サーバの状況見てなかったです。
で、すぐに反発して80Mbpsか。
WC本番ではほんとに100Mbpsあふれるかも。 >>297
それも考えられますが、
その場合は、グラフが上までいくんじゃないかなと。 >>300
様子見てなかったですね、、、。
見てればよかったな。
今はきわめて健康。 考えられるのは、
・httpdの最初の待機数が少なくて、
「どばっ」と突然来た時に、受け入れ可能になるまで時間がかかった
・SSDのプチフリ症状疑い (>>300)
あたりか。
いずれにしても、
リアルタイムで見てなかったから、今となってはちょっとわからないかも。 >なかのひと
もし可能であれば、yutori7 = tiger3521 の httpd.conf 中の、
StartServers 768
MinSpareServers 32
MaxSpareServers 768
ServerLimit 768
MaxClients 768
MaxRequestsPerChild 10000
MaxMemFree 2000
の部分の現在の設定内容をお教えいただけると助かります。
ちなみに上記は現在のroot権限ありA-tigerの標準設定です。
(最初から最大数(768)で待機、途中で増やしたり減らしたりしない) プチフリだったらあんな中途半端なヘコミはしないような。 おっと間違った。
>>304 は一世代前の設定だった。今はこれか。
StartServers 704
MinSpareServers 32
MaxSpareServers 704
ServerLimit 704
MaxClients 704
MaxRequestsPerChild 10000
MaxMemFree 2000
704個。
「最初から最大数で待機、途中で増やしたり減らしたりしない」
というコンセプトは同じ。
(httpd のメモリ使用量から計算して 88個 / 1G で、
8G メモリだから 704 個) 確かにそうかも、どっかの処理が間に合わなくてという感じか・・・ >>308
オウンゴールで落ちたのだから、
つ3試合とも0-0 >>311
そういう試合は、最後PKになるからいやだな、、、。
前半15分に日本先制
後半5分に日本2点目
後半25分に日本3点目
日本のゴールキーパーの奇跡的なセービング連発もなく、
そもそも日本のゴールが脅かされることがなく、
審判の疑惑の判定もなく、
柄の悪い観客もいなくて、
相手選手に性質の悪いチャージをされることもないような、
平和な試合がいいです。 【ネット】 「その人がどんなサイトを見て、どんな言葉を検索したか、全て記録・分析して広告提供」…の技術に、総務省がゴーサイン★5
http://tsushima.2ch.net/test/read.cgi/newsplus/1275220030/
Googleはhttpsに対応したけど ( https://www.google.com )、サーバー負荷どれだけ増えてるんだろう。
2chも今までのサーバーだとhttpsへの対応は難しかったりするのかな? IOがネックだったからそうでも無い? そういう処理をハードウエアでやってしまうSSLアクセラレータを挟むもんです。
大概の場合 >>313
> 後半25分に日本3点目
後半25分に日本3点目、そのまま勝利
です。ねんのため。 サッカー2010FIFAワールドカップ最終強化試合
日本×コートジボワール
6/4(金) 19:00 〜 21:20 TBS >>314
+でプチ祭りになってるみたいですが、
もうちょっと冷静な情報収集をしたいかも。
テクニカルには https: になるとどうなるか、
なわけですが、例によって、なりそうになったら考える、
ってかんじでしょうか。 >>315
専用ハードウェアは高いし、別のサーバーにSSLリバースプロキシを入れるだけで十分な気がするけどどうなんだろう。 >>318
>テクニカルには https: になるとどうなるか
リクエストもレスポンスも非対称鍵暗号で暗号化される。
専ブラの対応が必須。
SSL証明書の取得にお金がかかる。
携帯でどういう扱いになるのかは良く知りません。 携帯は各メニューとのやり取りだから関係ないんじゃない?
各メニュー→2chもあやしいISPを通さないなら傍受されないのでhttpでOKだし。
httpでも提供されるのだから非対応でも問題ないでしょ。
httpsが良いなら専ブラ変えれば良いし。 携帯だとhttpではゲートウェイでリクエストヘッダを加工する訳で。httpsだと通常はそれができないわけで。
ググったところ罠だらけですね。ソフトバンクはソフトバンク側で盗聴できる形ですし。
ttp://blog.mynet.co.jp/hirashima/2008/06/mobile_https.html 失礼します
ご存じと思いますが、ワールドカップの一次リーグ3試合は同点でも延長・PKはないので
決勝リーグの始まる6月26日からが心配されると思います
お節介を失礼致しました
皆様、お体にはくれぐれも気を付けて下さい。。。 まず各メニューがhttpsに対応するかどうかって言うのも。
httpsになっても盗聴可能なキャリアならわざわざhttpsにする必要もないね。
キャリアの問題もあるけど、2chとしてはhttpsを使うかhttpを使うかはユーザが選べば?って感じ。
けど携帯キャリアだけは>>314に手を出さないでほしいなぁ でも、今までのyutori7の落ち方とはちょっと違ったね
以前は1度httpdがおかしくなったら自力で復帰できなかったことが多いけど、今回はすぐ持ち直して80M超えたし(以前のyutori7では76Mbpsが限界)
プチフリ以外なら、ドバっと来る→httpdが足りず(ここで接続できない人が発生)→httpdが急遽増員されて持ち直したと考えるのが自然かも atlantaをSSD実験機にして、実ぷらかvipのどちらかをに移転してしまえば結構解決するんじゃね? そういえば、昨日の23時にyutori7でF22が動いてなかったみたい
2010/05/30 22:50:00 LA=10:50PM up 10 days, 11:22, 0 users, load averages: 1.81, 3.51, 3.22
2010/05/30 23:10:01 LA=11:10PM up 10 days, 11:42, 0 users, load averages: 4.49, 3.92, 3.13
これってなんか関係あるのかな >>324
携帯sideこそこの収集モデルが欲しい予感 ふと、SSD鯖のディスクビジー率を10分毎に_serviceディレクトリに出力してみたらいいかもと思った 1G接続のSSDサーバが用意できている、
liveって次何番だったっけ? アカウント設置してもらう いまlive24まであるんだっけ?じゃぁ次はlive25かな。 と思ったらlive25,live26,live27はDNSが引ける。
live28,live29,live30は引けなかったからこの辺かな。 live23 → live28
live24 → live28
ということで、live23 / live24 で移転作業始める際には、
こちらで「live23 はじめますー」のような形で宣言をいただけると助かりますです。
・bbsd停止(これでsubject.txtのロックが外れる)
・各フロントサーバのbbs.cgi停止
などの必要な準備作業を、わたしのほうで同期してやります。
あと、F22やらボボンやらbbs.cgiやら、
live23 や live24 という名前を特別扱いしているかもしれないものがあるので、
それらの調整も別途(移転後?)にでも必要になりますです。
で、live28.2ch.net が割り当てられたサーバの本名、
というかIPアドレスが確定したら、ここでお教えいただけると助かります。
stats 登録を先まわりして実施します。
で、F15/F22/F35 実行のタイミングを「F22 動かしてくださいー」のように、
指令くださいませ。
・・・まずは、というぐらいか、、、、。
あとは思い出したら、その都度。 りょうかい、
リフレッシュ工事込みなんで
live28はまっさらからスタートする予定でーす ちなみにちきちーたさんの作業は、
live23b と live24b ですることになるかなと。
で、雪だるまサーバ群を完全に捨てる場合、
www2 を別途作る必要があるです。
背景のレンガとか、そのへんのコンテンツが入っています。 >>340
りょうかいです。< まっさら
live23 と live24 は、花子(仔花子かも)に入れる方向ですかね。 live28 は tiger3524.maido3.com です (SSD実験6号機) >>341
海のものとも山のものともつかないので
とうぶん雪だるまはそのまま待機にしようと思っています。
目的が雪だるまの破棄じゃないんで
結果的にそこまですすめたらそれはそれで素晴らしいということで、 ■ このスレッドは過去ログ倉庫に格納されています