【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part15
レス数が1000を超えています。これ以上書き込みはできません。
peko作戦について語るスレです。
サーバロケーションPIEに関する話題もこちらで。
現在の主要なテーマはpeko/cobraおよびtigerサーバが
特定条件下における突然死の原因究明です。
９月にrootさんが現地へ渡米して作業するそうです。
＜関連サイト＞
レンタルサーバー maido3.com ２ちゃんねるの転送量: http://server.maido3.com/pie/
MRTGによる統計情報: http://mumumu.mu/mrtg/
２ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html
＜運営板PINKちゃんねる関係＞
【Project ama】PINKちゃんねる特化型ｻｰﾊﾞ構築作戦 Part2
http://qb5.2ch.net/test/read.cgi/operate/1082721809/l50
【PINKちゃんねる】新サーバ獲得会議☆3
http://qb5.2ch.net/test/read.cgi/operate/1080295660/l50
＜携帯電話特化型サーバ構築作戦関係＞
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
http://qb5.2ch.net/test/read.cgi/operate/1088657713/l50
＜前スレ＞
【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part14
http://qb5.2ch.net/test/read.cgi/operate/1087666806/l50 ttp://docs.FreeBSD.org/cgi/mid.cgi?200408232139.i7NLdToC094668 >>10
おぉ、、、。
Peterさん、うるうる。 live16: oonna, livenhk
%uptime
1:33AM up 18 days, 16:37, 1 user, load averages: 0.04, 0.05, 0.03
live17: ootoko, livecx
%uptime
1:33AM up 18 days, 16:27, 1 user, load averages: 0.13, 0.23, 0.20
live8: live系いろいろ
%uptime
1:34AM up 19 days, 18:10, 1 user, load averages: 1.62, 1.26, 0.81
news18: mnewsplus, trafficinfo
%uptime
1:35AM up 18 days, 16:19, 1 user, load averages: 0.38, 0.43, 0.41
どれもシングルCPU設定にしてから、オリンピック期間中一度も死ななかったと。
もう、ハードウェアの問題や電源の問題は、100%ないですね。
ということで問題は、やはりSMP/apicまわりであると。 で、どうされます？
１）５．３が出るのを待つ
２）>>10のパッチを当てる(斜め読みした限りではビンゴっぽいが)
３）その他 Dual OpteronにFreeBSD5.3-BETA2をインストール中 >>14
まずは、今回の訪問で5.3-BETA2をex7とlive8あたりに入れてみようかなと。
(>>10 相当のパッチって入ってるのかな)
>>15
お、もちろんamd64すよね。
# 今日帰宅したらCobraとTigerのBIOSとファーム更新用のフロッピーを作ろう。 >>16
スペックは
【. CPU 】Opteron 240 × 2
【 MEM 】PC3200 DDR SDRAM REG ECC 512MB × 2
【. HDD 】SCSI 15000rpm U320 36.9 GB × 2
【 SCSI 】Adaptec 39320-R
動作確認が出来たら、i.i2ch.netかi2ch.netで実験してみます。 今予定している作業予定はこんなかんじ。
・Cobra/Tiger BIOS更新 (FDD作成済)
・Cobra ネットワークカードのファームウェア更新 (FDD作成済)
・Cobra/Tiger BIOS設定確認 (マニュアル印刷済)
・banana402をプライベート側ネットワークに接続
・ex7, live8のOS更新(5.2.1R→5.3-BETA2)
・可能ならBlackGoat2等、Cobra系サーバのプライベート側を1G設定に
・Cyclades(リモートコンソール)設定確認&設定
・cobra2247のSCSIディスクの設定を確認(dual channelだが片方に両方のディスクがついている)
あと、何かあったっけか。
作業は、現地時間9月1日午後と9月2日に実施する予定。 あ、Suma(902のディスク)のファームも見ておくかな。 今入っているのよりも更新されてるですね。>>20
902に新ファームをFTPしといたです。これもやっておこう。 どこにふればいいかわからなかったのでここに書いておきます。
これってFreeBSDでも動くんだろうか（汗
ttp://www.softether.com/jp/block/ >>19
http://qb5.2ch.net/test/read.cgi/operate/1092652904/576-577
576 ：root ★ ：04/08/31 13:43 ID:???
>>575
どうも。
tiger503～510(8台), oyster901, 902, 243, cobra2244～2247(7台)が対象ですね。
結構多いな。
9月1日 14:00-19:00 PDT
9月2日 10:00-19:00 PDT
あたりか。JSTだと何時かな。
577 ：見習い▲ ★ ：04/08/31 13:45 ID:???
早朝から昼の予感 8月分まとめ完了。しかし怒涛の新板ラッシュだった。
http://mumumu.mu/old/200408.html
荷物まとめ完了。
さて、9月はいかなることになるのか。 とりあえず今日のまとめ
●Cobraサーバ
・サーバのふたを開けてマザボのリビジョンを確認する。
- Rev.Dの板にはD用、Rev.Eの板にはE用のBIOSを入れないと、金輪際立ち上がらなくなるので注意。
・起動時にF2キーでBIOSに入る。
・まずBIOSでFDDを有効にしないと、FDDからブートできない。
・準備しておいたWin98SEのFDDでサーバを起動する。
- 起動時にF5を押してHIMEMを無効にしないと、Phoenix BIOSの更新ユーティリティを実行できない。
・BIOSを更新すると重要なところの設定が一部変わってしまうので、忘れずに以下を実行すること。
- ブートの順番
* CD-ROMがHDDより後になってしまうので、前にしておく。
- パワーダウン→パワーアップ時の振る舞い
* パワーオフのままになってしまうので、パワーオンになるようにする。
* これをしないとAPCリブートが効かなくなる。
・以上終了後、Broadcomのイーサネットコントローラのファームも念のため更新しておく。
・パワーオンリセットして、起動することを確認する。
# 今日は結局Cobra2台しか作業できなかった。
# 今夜あたり、ホテルで5.3-BETA入れるのをやってみるかも(しくっても明日コンソールから作業できるので) しかけたCVSupが終わっていたので、
明日の準備にmake buildworldとbuildkernelをex7とlive8で流しておくか。 おつですー。が,
BIOSアップデートに生DOS(config.sysとかautoexec.batが入ってない奴)が必要なのは
知っていると思っていただけに以外ですた。 最近はFDイメージの中にFreeDOSが含まれてたりするけどね >>19-20 作業の進捗状況
・oyster901 902 243 cobra2244 2245 2246 2247 BIOS更新 済み
・Tigerサーバは比較的新しいBIOSであったため、更新不要
・banana402をプライベートネットワークに接続 済み
・ex7, live8のOS更新(5.2.1R-p9→5.3BETA2) 済み
・Sumaのファームウェア更新(3.41B) 済み 昨日～本日の作業で、oyster901(= live8)とtiger503(= ex7)が、
FreeBSD 5.3-BETAになりました。マルチCPUで動いています。
ということで、両板には例によって実験台になっていただくということで。 |
| 別の角度(奥)から…David さんが写っています
|
￣|/￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
.-､ _
ヽ､メ､〉 r～～ｰ-､__ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
∠イ＼) ﾑﾍ._ ﾉ |
⊥＿ ┣=ﾚﾍ､_ 了 ｜ え－－い、David氏はいいっ！
-‐''｢ ＿ ￣｀' ┐ ﾑ _..-┴へ ＜
| |r､ ￣￣｀l Uヽ レ⌒', ヽ. | root氏を映せっ！ root氏の戦い振りをっ！！
(三 |`iｰ､ | ﾄ､_ソ } ヽ |
| |｀'ｰ､_ ｀'ｰ-‐' .ｲ `､ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| | ｀ｰ､ ∠.-ヽ ',
_＿l___l＿＿＿_ l｀lｰ‐'´＿＿__l. |
￣￣￣￣￣￣￣￣￣￣|| .| |
|| |＿＿.. -‐ｲ
|| | ﾉ/ >>19
> ・cobra2247のSCSIディスクの設定を確認(dual channelだが片方に両方のディスクがついている)
は、SCSIケーブルがすぐに入手できないため、とりあえずそのまま。
今のところI/O的には飽和していないため、火急は要さないと判断。
> ・可能ならBlackGoat2等、Cobra系サーバのプライベート側を1G設定に
これをこれからトライしてみるか。
> ・Cyclades(リモートコンソール)設定確認&設定
これは別途時間がとれたら(でも、とれないかも)。 >>48
轟音と強風の中、大変乙です。
ふしあなしないと、PIEからも書けないんでしょうか？
>>49
いや、だいじょうぶすよ。
単に設定変えてないだけで。 >>39
今夜のlive8で効果が分かりそうですな
これでも重かったら板移動お願いしよう >>52
「重いのが解消される」ももちろんですが、
それよりも「落ちない」ことを祈っています、、、。 ということで、21:30をまわりました。
今日の、というか今回の作業はこれでほぼ終了。
Seanくんが待っています。ということでしつれい。
>>48 からの進捗:
・可能ならBlackGoat2等、Cobra系サーバのプライベート側を1G設定に
1000BASE-Tを接続できるGBICのアタッチメントがないみたいなので、今回は見送り。
必要ならまた別途機会を改めてこちらの中の人に頼むことになる予定。
・Cyclades(リモートコンソール)設定確認&設定
Sean君の多大なる協力により、すべてのCobra/Tigerサーバが「物理的に」接続できました。
BIOS設定は変えたので、もしだめならケーブル等の調整をこちらの中の人たちと別途調整。 ということで元気が残っていれば、寝る前にホテルから様子見てみるです。では。 >>56
たいへん乙でした！
できればリモコン接続の証拠を(ry http://sv2ch.baila6.jp/server.cgi?server=live8.2ch.net
落ちはしなかったけど、反応速度が落ちたことはあったようですね、、
(´-`).｡oO（なんとなくだけど、スレッド数が(ryだったのかなぁ、、 >>39ですが、突然死は今のところなしか。
例のパッチはあたっていそうですね。＞beta3
>>63
LAは上がらなくなったし、シングルの頃よりも負荷には強くなったけど、
もう少しパフォーマンスが出てもいいような気がするですね。
今のスケジューラは5.3-BETA2のデフォルト(SCHED_ULE)
これを従来のSCHED_4BSDにしてみるか。 で、重いときはこんなシステムメッセージが出てるですね。
これはどういうことなんだろう。
Limiting icmp unreach response from 1836 to 200 packets/sec 直訳
1836～200のパケット/秒からくるicmp範囲外の応答の制限。 おそらく、あんまりにもクライアント側から要求がくるんで
鯖ちゃんが「もう無理、ちょっち制限するよ」って根を上げているんだと思います。 /usr/src/sys/netinet/ip_icmp.cの最後のほうをみりゃ一目瞭然。 今重いですね。例のエラー出てるです。< live8
様子をチェック中。
LAが上がってないのに重いので、資源をうまく割り当てられていない雰囲気。 live8のカーネルのSCHED_ULE(5.3-BETAのデフォルト)をやめて、
従来のSCHED_4BSDにしてみた。 今リブートしたときに、BIOS出力がうまくリモートコンソールに出なかったことが判明。
やはりCycladesに標準装備のカプラじゃないと、BIOS出力がうまく出ない模様。
(現場でSean君と確認)
ttyd0からのgetty出力は正常なので、Cyclades側で何かの信号線を無視するといけるのかも。 で、live8とex7を5.3-BETA2に上げた直後に、ネットワーク関連のコードが更新されて、
ネットワークスタックがGiant freeになった模様。
http://news.gw.com/freebsd.current/%3C200409030309.i8339tCS012361@repoman.freebsd.org%3E
自分のマシンには入れてみたけど、高負荷なマシンじゃないと効果のほどはわからんなぁ。 334 ：動け動けウゴウゴ２ちゃんねる：04/09/07 21:13 ID:qFkvm/nh
カキコメナーイ
335 ：動け動けウゴウゴ２ちゃんねる：04/09/07 21:14 ID:KuGGg+dh
落ちた?
336 ：名無し募集中。。。：04/09/07 21:14 ID:zB+RAFqO
エラーが出るからおかしいと思ったら書き込めないのか
ex7だけどこのエラーって>>69と同じやつ？ 今日のメモ: 作業ログはここあたり。
携帯→2ch運用情報スレッド11
http://qb5.2ch.net/test/read.cgi/operate/1091869644/911-
・portsからのPHPのインストール方法ががらりと変わった。どうも7月下旬ごろらしい。
・APC acceleratorもportsから入れるようにしたところ、なぜか一部オプションを変える必要があった。
(というか、今までが微妙におかしかったらしい…AMD64でのたまに変になる問題も直るかも?)
・PHPのバージョンを上げたところ、MultiViewsオプションがあるとApacheがエラーを吐くようになった。
httpd.confを修正して解決。
参考:
http://qb5.2ch.net/test/read.cgi/operate/1091869644/943
943 名前：不動楽 ★[sage] 投稿日：04/09/08 00:14 ID:???
>>932
http://www.modpython.org/pipermail/mod_python/2004-June/015748.html
options +multiviews
のせいっぽいきが・・・ >>75
# cd /usr/ports/lang/php4-extensions/
# make config
で /var/db/ports/php4-extensions/optionsに記録される。
MBSTRINGを忘れない。あとは任意で。
# make install
すればDEPENDしているphp4関係のportsが入る。
>>77
どもです。基本的にその方法で入れたです。
ただ対話的にやりたくなかったんで(流れ作業にしたい)、BATCHとか使ってみたり。 ちなみにPHPを更新したc-othersのみですか？ >>80
今はそうすね。そのうちau系とdocomo系も更新予定。 PHPに、なにか必要なモジュールを入れ忘れたとか不要なものが入っているとかなのかな？ おみゃーさんらはどのような負荷が2chにとって嫌なのだ？
(´ー｀)y─┛~~ 多少のF5でもへっちゃらだべ？
昔と違うべ？どうよ？
(´ー｀)y─┛~~ >>70
少なくともlive系のサーバでは、SCHED_4BSDの方がパフォーマンス出るみたい。
>>83
無駄な負荷すね。荒らしとか広告とか。
でも、ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !! のために日々いろいろごにょごにょしてるのかなぁ、
うーんちょっとなぁ、とか、ふと思うこともあるですよ。 実は2chブラウザのOpenJaneの、自主規制をめぐっていつも揉めるんで、rootさんあたりに話を聞いてみたいな、と思ってました。
いまの本家Janeは、
subject.txtのリロードが10秒間制限
スレのリロードが5秒間制限
同時接続数は3、それ以上はキューに入れて順次処理
キューは最大6まで
開いてるスレを全部一気にリロードする機能はつけない
スレのオートリロードはつけない
て感じで来たんですが、これらの制限はユーザーの利便性をまあ犠牲にしてる面もあって、規制を解除している派生Janeが人気出たりしています。
本家も、2chの負担を極力抑えつつ、ユーザーの利便性を高めようという動きがでてきて、まあ揉めてるんです。
これらの制限について、どう思いますか？
ってかrootさんは、2chブラウザ使ってますか？使ってないと、一部の制限はイメージしづらいかもしれないですが うーん、難しい問題すね。>>88
ちなみに私はOpenJaneユーザ。 >>89
横レスすみません
root氏の使ってるjaneは本家なのでしょうか？それとも派生janeでしょうか？ これでごんす。
http://sakots.pekori.jp/OpenJane/
昔はかちゅ～しゃ+kageでしたが、新規スレ立て機能がついた時点で乗り換えたです。 live8、httpd大杉かなぁ。
むげに多くしても、書き込みのパフォーマンス出ないすね。
bbs.cgiの最大起動数をうまく制御できるとうれしいかも。 >>91
ご丁寧にどうも
スレ汚しすみませんでした >>86
> 少なくともlive系のサーバでは、SCHED_4BSDの方がパフォーマンス出るみたい。
ttp://docs.freebsd.org/cgi/mid.cgi?200409072237.i87MbiL9044294
とりあえず 5.3-RELEASE は SCHED_4BSD & PREEMPTION で行くみたいですね。
ところで>72に続いて、-currentではVMまわりもGiant freeになったけれど、
これも 5.3-RELEASE に入るのかなあ……
ttp://docs.freebsd.org/cgi/mid.cgi?200409040551.i845ptF4071382 >>92
そーいえばmod_cgidsoって進展ありました？
あれっきり音沙汰無いけど・・・・
ひょっとして聞いてはいけないテストだったりしてw ひ(ryが興味示していたからどこかで実験しているんじゃないかな？ 前スレがようやく1000逝きますた
早く立てすぎてご迷惑をおかけしますた Tiger511 , 512 到着。
メールしました > 管理人さん、rootさん >>100
今度のはFreeBSD 5.3-BETAで最初からマルチCPUなんでしょ？ >>100
受け取り&configuration正常を確認しました。
順次設定作業へと。
>>101
live8, ex7でのテスト結果は少なくとも悪くないみたいなので、様子を見ながらぼちぼちと。 Apache 2.0.51 is the best available version @09/15
ですー♪ >>100
なんで名前の▲を一つ増やしたんですか？ >>101
で、今度のはsquid用なので、5.2.1R-p9で組んでるです。
(blackgoat2同様、マルチCPU設定) で、そのうち、betaがはずれでrcにでもなれば、ぼちぼち試してみようかなと。 www.2ch.netってどうなってるのかが意味わかりません
前はbanana201でしたよね？
> www.2ch.net
Server: broadlanner
Address: 192.168.1.1
Non-authoritative answer:
Name: www.2ch.net
Address: 206.223.151.10
206.223.151.10でnslookupすると、banana201になったりbanana370になったりする
どういう仕組みになってるんですか？ >>110
こんな感じ
> 206.223.151.10
Server: broadlanner
Address: 192.168.1.1
Name: banana201.maido3.com
Address: 206.223.151.10
Aliases: 10.151.223.206.in-addr.arpa
> 206.223.151.10
Server: broadlanner
Address: 192.168.1.1
Name: banana370.maido3.com
Address: 206.223.151.10
Aliases: 10.151.223.206.in-addr.arpa banana201.maido3.comでnslookup
↓
206.223.151.10
banana370.maido3.comでnslookup
↓
206.223.150.10
banana370ってhobby5.2ch.netか おや、ホントだ。
206.223.151.10で逆引きするとたまにbanana370が出てくるねぇ。
まあ実害はなさげだけど。 最近、鰤が飛ばないのでイベント少な目ですね
rootさん！もっと景気よく鰤を飛ばしましょうですーヾ('-')ﾉ >>114
・1月 韓国F5集団来訪
・2月～4月 PIE立ち上げ
・4月～7月 突然死の原因調査
・5月 HE撤退PIE移転、各種機能&過去ログ
・6月～現在 携帯サーバ構築
・9月 夏休み(BIOS更新&OS更新)
てなわけで、8～9月はちょっとゆっくりさせてもらってるです。
でもそろそろまた（りゃ。 さて、新blackgoatとc-au3を登録いただこうかと。
以下を2ch.netのDNSに追加お願いします。
+blackgoat3.2ch.net:206.223.152.90
+blackgoat4.2ch.net:206.223.152.95
+c-au3.2ch.net:206.223.150.250 おつかれさまです('-')ﾉ
デュアルコアopteronで飛び宣言ですかー？ヾ('-')ﾉﾋﾟｭｰﾝ >>107
2ch 鯖監視係。対応しました♪
あとできれば m.2ch.net/_service/ (cobra2245.maido3.com)が欲しいですーm(_ _)m とりあえず、おれさまメモしておこう。
FreeBSD 5.3-BETA Migration Guide
http://people.freebsd.org/~bmah/pub/article.html というわけで、以下の通り2ch.netのDNSの更新をお願いします。
(設定理由)
・blackgoat, blackgoat2の廃止
・c-others2, c-docomo4の新設
・cの増設(DNSラウンドロビンの導入)
・cの2台にc1, c2という名前をつける(統計&負荷情報等のチェックのため)
(設定内容)
(以下を削除)
+blackgoat.2ch.net:206.223.150.190
(以下を追加)
+c-others2.2ch.net:206.223.150.190
+c-docomo4.2ch.net:206.223.151.200
+c.2ch.net:206.223.150.190
+c1.2ch.net:206.223.150.145
+c2.2ch.net:206.223.150.190 >>128
あ、すんません。
c.2ch.netは「2台体制」となりますので、従来のc.2ch.netも残しておいてください。
つまり、+c.2ch.netの行は以下の＊2行＊になります。
+c.2ch.net:206.223.150.145
+c.2ch.net:206.223.150.190 2台体制になったのを確認しました。その他の登録も確認しました。
あとは中の人の作業ができ次第、実戦投入で。 206.223.151.200を逆引きすると
cobra2244と言われたりbanana389と言われたりします。 >>127
あらら結局２重化ですか＞c.2ch.net
というわけでwiki書き直してきます 最近はラウンドロビンなんですねヾ('-')ﾉ
最近は見習いさんが弱くなってるしー。何が起こってるのーヾ('-';)ﾉ ついにBETA6登場
まだまだ道のりは長いか。。。
>>139
なかなかRCにならんですね。
まぁ、予定されていた時期に出ないのはいつものことだし。 live8 は逆引きってどうやって設定すればいいんですか? >>140 >>141
逆引きってのは、206.223.151.225 の逆引きってことかしら。
と思って見てみると、cobra2245とかは設定されてるですね。
Name: cobra2245.maido3.com
Address: 206.223.151.205
Aliases: 205.151.223.206.in-addr.arpa
…ということは、cobra2244以降はcobra2244.maido3.comなわけで、
oyster901.maido3.com でいいのかな。あるいはoyster901.peko.2ch.netかどっちかですね。
同じことは、oyster902 oyster243 suma-son1の3つにもいえるのかな。 正引き(oyster901.maido3.com)は、設定されていないみたいですね。
とすると、peko.2ch.netのほうがいいのかも。< 901 902 243 suma ということで私としては、他のホスト同様maido3.comでも、
peko.2ch.netでもどちらでもOKです。 あと少しですね。
うちのDUALちゃんは今BETA6で動いています。 昨晩のrootさんの操作ミスで思ったこと。
バックアップサーバがいるのでは？
# もっともlive系やI/Oがぎっちりしているものは無理か・・・ >>147
集中型のバックアップサーバですか、、、。
Jimさんにも昨日同じようなこと言われたですね。
Sumaストレージとか使ってできないかって。
今朝5時に定時バックアップ(#2 diskの内容を#1 diskに)しているわけですが、
やるとしたらどういう形がいいんだろうか。 >>148
Jimさんも似たような意見ですか。
ただ集中型だとI/Oの関係からちょっと厄介かも。
で、Sumaですか。Sumaのdf出してもらえますかね。 >>150
大変申し訳ありませんが。謹んで撤回させていただきますｗ バックアップサーバーっすか。
新しくサーバーを立てるのでしょうか？
効果が維持管理の負荷も気にならないほど
期待できるのかな？何となく思ったんですけど。 >>153
とりあえず対象は飛びやすいor飛ぶと荒れやすい鯖で、
一番負荷の低いときにnice値最低でバックアップを取るってことで。 5.3Rのリリースを間近(?)に控え、おれさまメモ。
Tigerはem、Cobraはbgeなので、だいじょうぶなはず。
bananaはvrなので、該当か。
Coming soon: default to Giant-free networking in 6.x
(was: Running the network stack without Giant -- change in default coming (fwd))
http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035718.html
- Are you using any physical network interfaces other than the
following: ath, bge, dc, em, ep, fxp, rl, sis, xl, wi. If so,
you may see a performance drop. Love affair作戦の一環として、以下のDNS追加設定をお願いします。
+c-control.2ch.net:206.223.150.145 これ、意外に泣けるかも。
20041001:
The following libraries had their version number bumped up:
/lib/libm.so.2 -> libm.so.3
/lib/libreadline.so.4 -> libreadline.so.5
/usr/lib/libhistory.so.4 -> libhistory.so.5
/usr/lib/libopie.so.2 -> libopie.so.3
/usr/lib/libpcap.so.2 -> libpcap.so.3
FreeBSD 4.10 versions of these libraries will be added to the
compat4x collection. If you expect to be able to run old 4.X
executables you will need to remove the old versions of these
libraries. However note that any 5.X executables you have built
will stop working once you remove those old libraries. You should
have all your ports/packages rebuilt before removing the old
libraries. >>158
ぐは、基本中の基本であるlibmがageですか。
それも旧バージョンのライブラリがdelなら場合によってはかなりやばい事態が予想されますね・・・・
うかつに5.3にできないのでは・・・・
で、>>152についてLAスレでもいいので説明きぼん >>160
こりゃ何かチェックするやつを作らないといかんなぁ、と思っていたら、既にこんなものが。
http://pc5.2ch.net/test/read.cgi/unix/1068658686/975
でも、自分でコンパイルして入れ込んだやつは自分でチェックしないといけないですね。 >>160 の最後の行:
>>152 のリンク先にあるように、2.0.51で縁バグしたのを直したということかと。 >>162
すいませーん、>>157ですー orz >>163
携帯の中のかたからの依頼です。
従来２ちゃんねるの外にあったc系control用サーバを、
中に持ってくる、という認識でよいのかしら。＞中のかたがた ということは
---c1/c2---c-contorol---c-{docomo|au|others}---c-{docomo|au|others}?---blackgoat[3-4]---各鯖
ってことでいいんでしょうか？ c-controlは全くの別系統です。
フロントの制御等を行なっています。 なるほど、独立した制御サーバという位置づけですか
リクエストの振り分けを調整したりとか >>166
んと、図がよくわからないのですが、
c-controlは、
各フロントエンド（c-{docomo|au|others}?）のメンテナンスを一元的に行なうサーバです。
なので他とは独立しています。 外部---（りゃ)---c-{docomo|au|others}?---(りゃ)
| | |
c-control(物理的にLAの各GWホストからは独立)
ということですかね >>171
c-others1と同居です。
それ以外は、そんな感じです。 どうもです＞こうすけさん
というわけでwikiのLAの項目を更新＆申請します 今日はたしか、RELENG_5_3が切られる日のはずだったんだけどなぁ。 あの人はここを見ていそうなので、書いておこう。
これって、某netniceなモジュールで、できるのかしら。
サーバダウン(鯖落ち)情報 Part48
http://qb5.2ch.net/test/read.cgi/operate/1095509814/668
668 名前：root▲ ★[sage] 投稿日：04/10/10 05:04:27 ID:???
あとは、ApacheのモジュールでCGIがコールされる前に検知できるのかも。
例えば、あるIPアドレスからM秒の間にN回同じCGIがコールされたら、
そのIPアドレスからはあらかじめ定められたP秒間、そのCGIはコールできなくする、
みたいなことをできるモジュールって、何かあるのかしら。
なかなか連絡できずにごめんなさい。書き込み、たまたま発見しますた。
http://www.nuclearelephant.com/projects/dosevasive/
とかでしょうかね。mod_netniceに統合しても良い機能かも知れませんね。
なお、たいへんお待たせしましたが、FB5.3beta7で動作しました。
このままbetaに追随し、release化の時点でアルファ版公開の予定でつ。
http://www.netnice.org/pukiwiki.php?FreeBSD
例の件は、いろいろアイディアを暖めましたので、また別便で...。
>>176
早速どうも。なんかよさげですね。
ちょっと見てみます。
そろそろboardingなので、またあとで。 oyster901
We have got a problem with Oyster901.
As it boots it immediatly goes to a message that says:
Invalid Partition
Invalid Partition
No /boot/loader
FreeBSD/i386 boot
boot:
Invalid Partition
No /Kernel
FreeBSD/i386 boot
Default: 0":da(0,a)/kernel
boot: _
----------------------
Please advise what coarse of action to take at this moment....
I will stand wait.
-Sean >>178
Really!?
It may be crashed the boot loader or index area in this system disk.
Please call for mumumu-san, mumumu@newsplus.jp
えー、たぶんシステムディスクが何かしらのクラッシュをおこした模様。
というわけでrootさん、fsckさせてみてだめなら交換と再インストールということになりそうです。。。 >>179
可能性高いっすね。
Invalid Partitionとは。。
Seanさんへのレスにも書いたんですがMBRかインデックスの領域、
あるいはデータ領域も逝っているかも知れません。
事態はちょっと深刻の模様です。 よくあることじゃないですかｗ
ところで、そもそもの原因は何でしたっけ？ >>183
確か旧Live8なので、そもそもの原因もシステムディスク破損。
それで、システムディスク交換済みのはずだったのに…再発？ ところでだいぶ流れちゃいましたけど>>157はどうなったですか？ あ、そうだった、live8は既に稼動していなかったんですな。
確か交換したのはデータディスクだけじゃなかったかと
システムディスクを交換していたのだったら
おそらく地雷ディスクに引っかかったものと思われ >>187
ども。ということは地雷か。
いづれにせよ、rootさんか見習いさんがこないと話にならないっすね・・・ 急ぎませんが、
http://server.maido3.com/pie/
のリンク、ここに変更よろしくお願いしますですよ。 >>191
反応が無いところを見ると、今後の用途決定＆5.3RELESEまちっぽいですね うへ、交換したばかりのシステムディスクが逝ったですか。
今夜には帰宅するので、それから徐々に対応を。 >>194
出先から乙です
確実なのはパーティション情報が飛んだだけっぽいのでまだわからんです。
逝った可能性は大ですが。 >>157
わすれとった、
すまんです
明日やる予定でーす oyster901 = live8 は、現地の都合が合えば今夜あたりにでも。 ということで、ex7にまた活躍してもらう時が来たらしい。
live8の復旧作業とともに、今夜にでもごそごそ。 ちょっとここで作戦を練りますか。
mod_dosevasiveのパラメータですが、
<IfModule mod_dosevasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
</IfModule>
がサンプルにあります。 で、それぞれ、
DOSPageCount
------------
This is the threshhold for the number of requests for the same page (or URI)
per page interval. Once the threshhold for that interval has been exceeded,
the IP address of the client will be added to the blocking list.
DOSSiteCount
------------
This is the threshhold for the total number of requests for any object by
the same client on the same listener per site interval. Once the threshhold
for that interval has been exceeded, the IP address of the client will be added
to the blocking list.
DOSPageInterval
---------------
The interval for the page count threshhold; defaults to 1 second intervals.
DOSSiteInterval
---------------
The interval for the site count threshhold; defaults to 1 second intervals.
という意味らしい。 で、ひっかかると、
DOSBlockingPeriod
-----------------
The blocking period is the amount of time (in seconds) that a client will be
blocked for if they are added to the blocking list. During this time, all
subsequent requests from the client will result in a 403 (Forbidden) and
the timer being reset (e.g. another 10 seconds). Since the timer is reset
for every subsequent request, it is not necessary to have a long blocking
period; in the event of a DoS attack, this timer will keep getting reset.
に設定した値で、ブロックされると。
さて、これらをどういうさじ加減でいじるべきか。 というわけで話題を振っておいて、これからしばらく外勤により（りゃ。
というわけで夜に、また。 >>202-203
1)
DOSPageInterval 秒の間に DOSPageCount 回を超えて、同じURLへのリクエストがあったら、
リクエスト元のIPアドレスは自動的にブロック
2)
DOSSiteInterval 秒の間に DOSSiteCount 回を超えて、同じIPアドレスからリクエストがあったら、
リクエスト元のIPアドレスは自動的にブロック
3)
ブロックされるのは、DOSBlockingPeriod 秒で定めた秒数だけ
かな。
DOSBlockingPeriodは、1時間(= 3600)あたり？
1)は、bbs.cgiの単位時間あたりの起動数でチェックするわけだけど、今は(まだ)ゆるくていいのかな。
きつくすべきは、2)か。
さて、どうすべか↓ で、補足しておくと、
md_dosevasiveでのブロックはほぼリアルタイムに行われます。
つまり、ひっかかったら速攻で止まる。 >>207
ありがとうございます。
移転準備します。 自分なりに考えてみましたが。。。
1)DosPageInterval = Samba設定秒*係数
DosPageCount = 5から10くらい？
3)DosBlockingPeriod = 3600
2)は、「あらゆるオブジェクトのリクエスト総数ですよね」
厳しくするにも感覚が掴めないから難しい。。。
<IfModule mod_dosevasive20.c>
<Files /home/ch2ﾅﾝﾀﾗｶﾝﾀﾗ/test/bbs.cgi>
あんなこととかこんなこと・・・
</Files>
</IfModule>
ってのもできるのかな？ >>213
スクリプトとはまた違うものですよね？
それが出来るとしたら画期的ですな。 mod関係のレスはあとで。
とりあえず5.3-BETA7にはできた。
%uname -a
FreeBSD tiger503.maido3.com 5.3-BETA7 FreeBSD 5.3-BETA7 #1: Tue Oct 12 03:18:56 PDT 2004 root@tiger503.maido3.com:/usr/obj/var/src/sys/GENERIC i386 OS更新は概ねOK。
古いライブラリに依存していたソフトウェアを更新中。 てなわけで、とりあえずうごいた。
サーバダウン(鯖落ち)情報 Part49
http://qb5.2ch.net/test/read.cgi/operate/1097486852/99
99 名前：root▲ ★[] 投稿日：04/10/13 05:31:10 ID:???
とりあえずPerl 5.8.5でも、 bbs.cgi は動くみたいね。
perlcc したら通らなかったんで、live系では何か技がまた必要みたいだけど。
(あきらめてPerlのまま動かすという手もある)
これで、例のモジュールを動かす準備ができたということすね。
チューニングは明日以降にぼちぼちということで。
というわけで、実地で動作確認と。
いつもおせわになるですね。なんとなく娘や競馬の中の人とは縁があるみたい。 >>213
Files で囲むのはできないみたいです。
ソースは大したことしてないみたいなので、bbs.cgi と subbbs.cgi だけカウントすることは
やろうと思えばできると思います。
>>212
どうも。今は頭がもう限界なので、明日以降に。
しかけ(モジュール)そのものはFreeBSD 5.3-BETA7で無事入ったです。
ports猿で、簡単インストール。 >>rootさん、
modの件ですが、どうもBGが規制されちゃってるみたいです。
特定のIPを除外することは可能ですか？ 昨日から大風邪ひいて、ダウン中、、、。
>>219
なるほど。
特定のIPアドレスを止めることは難しいみたいです。
本来はパラメータ調整となりますが今はだめぽなので、
とりあえずex7のmod_dosevasiveを止めました。
見てないですが、BBSな仕組みもちゃんと動いているらしいんで。
# 病院いってきます。 医者「rootさん、おめでとうございます おめでたです」 >>221
ものすごく激しくのた打ち回ってワラタ
>>220
死なないように気をつけませう
というか入院させられたりして・・・ >>220
ありがとうございます。
どうぞお身体、お大事にしてくださいです。。。 ついに、FreeBSD5.3がSTABLEになった。 予定では
・あしたRC1
・22日ビルド開始
・リリースは25日 >>227
RELENG_5は、FreeBSD5.3 stableだけど、
RELENG_5_3では、すでにRC1になってますね。
お、きたですか。
とりあえずCVSupしておこう。
# まだ寝たり起きたり。 >>230
あまり無理しないでくださいね。
今月中にはreleaseになるのかな～ やっぱり、FreeBSDの方が先に5.3をリリースすることになりそうなのか。
sargeは何時になったら安定版になるんだろう……。orz
いろいろバグフィックスされているといいですね。
oyster902 の件
/home (Sumaストレージ) を mount しないようにしてリブート。
リブート & background fsck 終了後、手で fsck 中。 なお念のため、>>234 の前に Suma ストレージをリセット。 Phase 1通った。< fsck
Phase 2実行中。 ** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
17755430 files, 317374114 used, 391390393 free (6742033 frags, 48081045 blocks, 1.0% fragmentation)
***** FILE SYSTEM MARKED CLEAN *****
無事通りました。
これから 902 を復活させます。Sumaストレージにもエラーログはない模様。 復活させました。これで様子見ということで。< 902 いやん。
Oct 18 02:48:08 <0.2> oyster902 kernel: aac0: **Monitor** NMI ISR: NMI_MEMORY_CONTROLLER_ERROR >>241
うぉ・・・
メモリーコントローラ周りがヤバメなんでしょうか？
これが原因で不安定なんでしょうかねぇ・・・
memtestあたりで故障しかけかって分からんもんなんでしょうか？
#エラーでてる時点でヤバメなんだろうけど >>242
ということは、
C P U 換 装
ですか？
# Pentium系とちがってマザボ換装しなくていいのがメリットw その後 >>241 のエラーは起こっていません。その他の挙動も今のところ異常なし。
ところで、「aac0:」が気になるわけですが。
# aac0 = システムディスクがつながっているほうのRAIDコントローラ。
# Sumaはaac0ではなく別のFCカード(isp0)に接続。 何が起きているのか。症状はこの間と同じ。
・pingには答える
・httpdは応答しない(connection refused)
・sshはつながる、しかしログインできない
ちゃんとコンソールから調べてもらった方がよさそうなので、
今日はリブート要請をせず(コンソールのメッセージがわからなくなる)、
今夜にでも現地の中の人と別途調整することにします。
# 902はSumaの制御でシリアルポートを使っているので、リモートコンソールではないのです。
なお、Sumaストレージにはリモートログインできて、異常なく動いていることは確認しました。
いまのところ 902 側のハードウェア不良の可能性が大きいか。 > ・httpdは応答しない(connection refused)
今はConnection timed outします。ううむ。 サービスがいないポート(10)はちゃんとrefused
サービスがいるポート(80)は固まる
%telnet oyster902.peko.2ch.net 10
Trying 206.223.151.230...
telnet: connect to address 206.223.151.230: Connection refused
telnet: Unable to connect to remote host
%telnet oyster902.peko.2ch.net 80
Trying 206.223.151.230...
^C
で、>>244 のシステムエラー、そしてSuma側には異常がないことからすると、
システムディスクがつながっている、AdaptecのRAIDコントローラがいまいちな予感。 さて、これで連日、3回目のダウンなので、何らかの問題が生じたことは明らかかと。
・今日の深夜に現地の中の人と連絡をとり、状況を伝える
・システムコンソールのメッセージを見てもらう
・場合によっては入院・加療か
ちなみに902のRAIDコントローラは、Adaptec 2120Sです。
OSはFreeBSD 5.2.1/amd64。
>>244 のエラーも含め、何か情報があればここに書いていただけると。 ちょっと覗かせて頂いたものです。関係あるかは分かりませんがAdaptec 2120Sといえば・・・
http://ask.adaptec.co.jp/cgi-bin/adaptec_japan.cfg/php/enduser/std_adp.php?p_sid=RumNikoh&p_lva=&p_faqid=1215&p_created=1064535857
&p_sp=cF9zcmNoPTEmcF9ncmlkc29ydD0mcF9yb3dfY250PTEmcF9zZWFyY2hfdGV4dD0xMjE1JnBfc2VhcmNoX3R5cGU9MjpmYXFzLmZhcV
9pZCZwX3Byb2RfbHZsMT02NSZwX3Byb2RfbHZsMj1_YW55fiZwX2NhdF9sdmwxPX5hbnl_JnBfc29ydF9ieT1mYXFzLmZhcV9pZDpEJnBfcGFnZT0x&p_li= >>250
どうもです。
シーゲートファーム問題すか。
いちおう、2台のディスク(RAID 1で運用)が最新ファーム(6)なことは前に確認しているです。 というわけで、今日あたり対応を。
今のところはたぶん、2120Sコントローラがいまいちになったものというのがわたしの推測。
Jimさんに連絡とって、作業のスケジューリングをぼちぼちと。 Dear Mumumu,
I will take this machine to Polywell this morning if it is ok to take it offline.
Your friend,
Jim 私の返事:
Ok, please do it.
I think Suma is completely no problem, so you can bring only 902 itself to
Polywell.
-- Mumumu というわけで、902はPolywellに入院の方向で。
こんなメール出してあるので、その筋での調査&検査入院かと。
Jim-san,
In the several days, oyster902 is encountered suddenly system downs.
And today, 902 has been down since today's evening in Japan.
We dare to suspend rebooting 902 for checking system console message.
So, if you can, please go to PIE and check system console message of
902.
I checked the details of Suma storage the day before yesterday, and
they works fine and I cannot detect any errors. So, there are no
problem on Suma.
And yesterday, I detected strange system message as seen below:
Oct 18 02:48:08 <0.2> oyster902 kernel: aac0: **Monitor** NMI ISR: NMI_MEMORY_CONTROLLER_ERROR
This means Adaptec RAID 1 controller (aac0) on board memory is wrong,
so fixing the card is needed, I think.
Anyway, please check current system console message of 902.
Yoroshiku-Onegai shimasu. >>256
英語がスラスラ書ける人ってのはカッコよく見えるんだよなァ。
rootさんかっこえぇ >>257
ですね、、、。
過去ログが入っている外付けディスクそのものは正常なので、
本体が直れば復活かと。
>>258
痛い目になんどもなんどもあって少しずつおぼえたです。
100%現場のみ。 最期がローマ字なのは何か意味があるのだろうか・・・ Jim (02:18 AM) :
this is error right now
aac0: Command 0xfffffff8ed5990 timeout after 3184 seconds
Me (02:19 AM) :
Oh, I think my guess is correct. aac0 is Adaptec 2120S RAID controller driver name of FreeBSD.
Me (02:20 AM) :
So, I think we need to fix the wrong card.
Jim (02:21 AM) :
this just happened? how can the card become wrong after it was right for many months?
Jim (02:22 AM) :
I am going to turn oyster902 off now
Me (02:23 AM) :
Hmm... Surely, this card is correct during about 8 months.
Me (02:23 AM) :
Ok, please do it. やはりシステムディスクを接続しているSCSIカードに問題が出た模様。
ということで 902 は入院となりました。
>>260
あいてがJimさんだから、そのへんは呼吸で。 Jim (02:34 AM) :
ok, I will go to polywell now. I will leave oyster902 there for the whole day.
Me (02:35 AM) :
Thank you for your work. Otsu-desu. Jim (02:36 AM) :
dai jobu mata atode friend
Me (02:36 AM) :
Ok, mata atode.
ということでJimさんは902を持ってPolywellに向かいました。
これからFreeBSD 5.3R-RC1化したlive8のセットアップの続きを少しやって、ねるとするか。 >>265
そうすね。
しかし、ディスクはRAID 1にしてあったのに、RAIDカードに問題が出るとはなぁ。
まぁ、そういうこともあるか。 >>266
ディスクコントローラがいかれるのはディスク不良が発生する確率より
若干低いとはいえ、ありえなくはないです。
ディスクコントローラに限らずチップ内の劣化断線なんてよくある話ですから
エンタープライズ級の使われ方をしてる2chの鯖なら
どこかしら不具合を起こすのも日常茶飯事かと。 順調に進めば5.3は２５日リリース予定だそうです。
ttp://distrowatch.com/?newsid=02018#0 鯖落ちスレから転載
SMP enableなんだろーか。
---
191 名前： root▲ ★ [sage] 投稿日： 04/10/21 00:22:10 ID:???
これ(注：ex7作業)でOSがFreeBSD 5.3-RC1になりました。
さて、しばらくは live8 とともに人柱になっていただくということで。
%uname -a
FreeBSD tiger503.maido3.com 5.3-RC1 FreeBSD 5.3-RC1 #0: Tue Oct 19 23:43:06 PDT 2004 root@tiger503.maido3.com:/usr/obj/var/src/sys/I386_TIGER_53 i386 >>270
当然、9月にPIEに行って5.3-BETA2にした時からSMP enableです。< ex7
その後突然のハングは一度も起こっていないので
(普通にkernelがpanicして落ちたことはある: betaだし)、
SMPなマシンでの不安定の原因はもう確定とみてよいでしょう。 ■ 新企画 Hack72 (BBQ に貯まっている串の速報) part1
http://qb5.2ch.net/test/read.cgi/operate/1093978218/200-
ということで、生誕の儀式いきます。
以下を2ch.netのDNSに追加お願いします。
+hack72.2ch.net:206.223.151.220 >>273
登録確認しました。
そろそろlive8の構築ををお願いしますと、見習いさんにおつたえくださいです。 >>271
あう、そーでしたね＞enable
ここ最近は特に記憶力の減退がひどいな・・・・ 新生live8、その実力は。
実はあの日のように、わくわくしていたりして。
あのときは確か、ロード・オブ・ザ・リングをやった日だっけか。 >>276
最初のときなんてsoftupdate disableという状態で平然だったわけですからねえ
これで瞬発力も持久力も抜群ならどうなんだろ。
ひ（りゃの意見が聞いてみたいですね コンパイルはさくっととおりました。
【実況板】 live15/16/17 鯖 Part1
http://qb5.2ch.net/test/read.cgi/operate/1097931665/116
116 名前：root▲ ★[sage] 投稿日：04/10/22 15:08:58 ID:???
live8のbbs.cgiをperlcc版に切り替えた。
Perl5.8.5ベースになったためか、バイナリの大きさが前の半分ぐらいに。
%ls -l bbs.cgi
-rwxr-xr-x 1 ch2live8 ch2 536536 Oct 21 23:06 bbs.cgi ん～やっぱり突発的な実況には耐えられないか・・・>live18
ほかはボチボチ分散しているようです。
んが、live8はいつもどおりだなｗ
なんでも実況Jが出来たの知らないのかな。
あとなんでcomic5とgame8が負荷が高いんだろう（＾＾；； >>284
あっなるほど（＾＾；；
ん～まぁそのうち復活するかな。
そういえば、oyster902はいつごろ復活するんでしょう？
もうすこしかかるのかな。 283 動け動けウゴウゴ２ちゃんねる sage New! 04/10/23 18:53:37 ID:wTQO6Odm
ん～やっぱり突発的な実況には耐えられないか・・・>live18
ほかはボチボチ分散しているようです。
んが、live8はいつもどおりだなｗ
なんでも実況Jが出来たの知らないのかな。
あとなんでcomic5とgame8が負荷が高いんだろう（＾＾；；
284 動け動けウゴウゴ２ちゃんねる sage New! 04/10/23 19:02:28 ID:ejfd13Jj
>283
アニメ中断の･･･ live8よりも、ex7でいい負荷試験ができたのかも。 どもども
代わりに banana では代用できないんですかね? >>297
PCIなFCカードがJimさんの手元にあれば意外と簡単に出来るんじゃないかのう。
Sumaとの接続はFCだで。 >>291 >>292
ようやく、か。
まずは ex7 と live8 を正式版に更新からかな。
次は live 系あたりから、順次更新していこうと。
>>297 >>298
物理的には刺さるかもしれないですが、
64bit PCIカードじゃないとI/Oが苦しい気がするので、
bananaではFCカードのパフォーマンス的に無理だと思います。
常時、相当数のアクセスがあったので。 >>299
常に二台(902,banana) を接続しておいて
902だ駄目なときはbananaが稼動っていうのじゃだめですかね?
まったく見られないよりは良いかと思いまして、 >>300
なるほど、SumaはFCだから1台にステーションを2台接続できるかもしれないですね。
FCのSCSIカードとbananaサーバ1台っていうかんじですか。
FCのカードは今の902のやつと同じもの(QLogic 2300)でいける気がします。 GENERICからoption SMPがなくなりました。
SMPを使う場合は、
make buildkernel KERNCONF=SMP
make installkernel KERNCONF=SMP
とする必要があるみたいですね。 live8でCVSup。
ex7は、、今重いからなぁ。
>>302
あ、もう書かれちゃった。
確かに、SMPがデフォルトではなくなってますね。
まあ、安全側に振ったということでしょう。
# おぐらけい、若いな。それよりゲストの若さに驚いたかも。 >>301
Strage共有にスイッチは不要でしたかの？
ちと不明なのでそのへんを訊いてみる。。
確かにSumaに穴は二つあるようじゃが、 >>305
穴(I/F)を入れられる場所は2つありますが、今は1つしか入ってないです。
FC-ALなので、リング状に接続すればいいんではないかと思っていたり。 あ、>>306 は「I/Fカードが今のSumaには1枚しか入ってない(今のSumaなら1枚しか要らないから)」
という意味です。 >>306
ちと Jim さんに接続の方法を聞いてみたりしてみます
週明けになると思いますが、
root ★さんも JIm さんを捕まえたら
手配しちゃってくださいー
技術検証、まぁちっとは役に立つかも計画ですが、 >>303
ためしに、GENERIC入れたら、やっぱり非SMPでしたｗ
いま、CPUひとつでSMPをbuildkernel中 >>308
了解です。
もしつかまったら、902のステータスも聞いてみてくださいです。
退院してくるなら、それがいちばんよいので。 うおっ
久しぶりにメールを見てみたら
10/21 にこんなメールが
Oyster902 is back on the rack.
It ran for 1 day at polywell with no errors.
It has had one extra fan installed. (Now 7 fans in it.)
and a new adaptec raid 1 card. lets see how it does for a few days.
Jim
>>311
お、状況再現せず、負荷による温度上昇かもと疑いファンを増設して、SCSIカードも換えたと。 >>306
ひょっとしてわっかにしたらわっかのどこかが落ちたりして欠けたらアレなんじゃ。。。。
>>311
おー Jimさんと連絡とれました。
今日午前中にPIEに行って(現地時間)チェックしてみるとのこと。
HWに問題がなければ、今日のうちには上がるでしょう。
Me (12:42 AM) :
Ok, wakatta. I will wait for 902 is back again.
Jim (12:42 AM) :
it will be back up today.
Me (12:43 AM) :
Ok, thank you.
Jim (12:43 AM) :
dou itashi mashite FreeBSD 219.113.242.220 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Mon Oct 25 00:14:28 JST 2004 root@219.113.242.220:/usr/obj/usr/src/sys/SMP amd64
一足お先に、5.3R導入 >>315
リングにするから、1台落ちても大丈夫なわけで。 >>318
あ、わっかといっても三角にするだけだから
どっかが落ちても経路が潰れるわけじゃないのかー oyster901 = live8 を5.3Rに更新した。
%uname -a
FreeBSD oyster901.maido3.com 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Sun Oct 24 09:22:11 PDT 2004 root@oyster901.maido3.com:/usr/obj/usr/src/sys/AMD64_COBRA_53 amd64 tiger503 = ex7 も更新した。
他のサーバの更新は明日以降。
FreeBSD tiger503.maido3.com 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Sun Oct 24 11:01:59 PDT 2004 root@tiger503.maido3.com:/usr/obj/var/src/sys/I386_TIGER_53 i386 902 動いているようで、
bananaを一台追加予定、
だめだったら tiger を考えていたり、 >>324
それは掲示板に使ってよいものですか？
memoriesのバックアップ用？ memoriesのバックアップ用 でーす
どのような方法があるのかわからないけど
902 が落ちたときに補完になれば、 >>325
仮に後者目的に使うのであればセカンダリ＝バックアップでしょーな。
ただbananaでは少々つらいかも。
>>299の懸念を902+bananaコンビのデュプレックスだけでは払拭でき無そうですし。
peko2台(1台は902)ではオーバースペックだろうし。
# 将来的には必要かもしれませんがね >>326
方法としてはc={c1/c2}同様にDNSラウンドロビンという手でいくのが妥当かと思います。
ただしこの方法だと902が落ちたときに相方のbananaに負荷が集中して結局落ちる可能性がありえます。
そんなんではバックアップの意味が無いわけで。。。。
他にいい方法ないでしょうかねぇ 902、RAID 1で構成したシステムディスクが片肺飛行状態になっているかも。
21日からネットワークに接続されていない状態で動いていた模様。
↓1行目はこないだのエラー。
Oct 18 02:48:08 <0.2> oyster902 kernel: aac0: **Monitor** NMI ISR: NMI_MEMORY_CONTROLLER_ERROR
Oct 21 03:14:03 <0.2> oyster902 kernel: aac0: **Monitor** SCSI bus reset issued on channel 0
Oct 21 03:14:30 <0.2> oyster902 kernel: aac0: **Monitor** <...repeats 1 more times>
Oct 21 03:14:30 <0.2> oyster902 kernel: aac0: **Monitor** Drive 0:0:0 online on container 0:
Oct 21 03:14:51 <0.2> oyster902 kernel: aac0: **Monitor** SCSI bus reset issued on channel 0
Oct 24 00:45:30 <0.2> oyster902 kernel: aac0: **Monitor** <...repeats 4 more times>
Oct 24 00:45:32 <0.2> oyster902 kernel: aac0: **Monitor** Drive 0:1:0 returning error
Oct 24 00:45:32 <0.2> oyster902 kernel: aac0: **Monitor** SCSI bus reset issued on channel 0
Oct 24 00:45:32 <0.2> oyster902 kernel: aac0: **Monitor** ID(0:01:0) - Cmd[0x28] failed (retries exhausted)
Oct 24 00:45:37 <0.2> oyster902 kernel: aac0: **Monitor** ID(0:01:0) - Cmd[0x2a] failed (retries exhausted)
Oct 24 00:45:37 <0.2> oyster902 kernel: aac0: **Monitor** Alarm Adapter Event -- turning Alarm On!
Oct 24 00:45:37 <0.2> oyster902 kernel: aac0: **Monitor** Mirror Container 0 Drive 0:1:0 Failure
Oct 24 00:45:37 <0.2> oyster902 kernel: aac0: **Monitor** <...repeats 2 more times>
Oct 24 00:45:37 <0.2> oyster902 kernel: aac0: **Monitor** Drive 0:0:0 online on container 0:
Oct 24 00:45:47 <0.2> oyster902 kernel: aac0: **Monitor** Mirror Failover Container 0 no failover assigned >>329
5.3にあげるつもりがあるのでしたら>>324のときに再構築したほうがいいかもですね。 httpdのスロット数は増やしたいけど、
bbs.cgiの起動数は例えば同時に100個とかまでにしたい、とかいうのって、
設定で何とかならないんだろか。 >>331
mod_cgidsoが実装されれば容易に調整できそうなものですが。 live8が上がっていたのでhttpdの起動数にリミッターを入れました。(一時的に1024に上げていた)
live8 512
ex7 384
に設定。
また風邪を引いてしまったらしく症状がひどいため、今日はたぶんあまり見られないです。すまぬ。 >>333
たぶんどころかみちゃだめです。鯖のお守りより自分のお守りをしてください。。。
とりあえず24時間寝ることを薦めます >>333
ぶっちゃけ、一週間くらい2ちゃんが落ちても、そんなに困る人は居ない。
けど、あんだが一週間寝込んだら困る人、居るでしょ？奥さんとか。ご自愛下され。 ＼ ｼｮﾎﾞｰﾝ ／（ ＾∀＾）ｹﾞﾗｹﾞﾗ
ｼｮﾎﾞｰﾝ ＼ (´･ω･`) ／
(´･ω･`) ＼∧∧∧∧／∀｀)＝◯＜´･ω･`＞◯＝（・
( つ旦O ＜ な シ ＞ ( )ｼｮﾎﾞｰﾝ
と＿)_) ＜ ｮ ＞ ∪∪
──────────＜ 悪 ボ ＞───────────
| |／( ´_ゝ`)＼＜ │ ＞ ( ´･ω･`)ﾌｰ
| |. ∩∩ ＜ 寒 ン ＞ ／ 人
|ｼｮﾎﾞｰﾝ￣￣￣￣／∨∨∨∨＼ / ＼ ＼⌒i
(´･ω･`) ／２人でｼｮﾎﾞｰﾝ ＼ | ／＼ ￣））
(∩∩)─── ／（´･ω･`)人(´･ω･`＼／ ／|￣|
／|￣￣| ｶﾀｶﾀ ／ （ ∩∩） （∩∩ ）＼／ ゝ＿_） ex7を実験台に、KeepAliveありの設定を実験中。
同じ人がリロードするのには、このほうが負荷が低いかもしれないので。 HTTP/1.1をまともに実装しているクライアントからは、
KeepAliveONのほうが、かける負荷はずっと少なくなります。
connect要求300回が、3回で済むようになる上、
apache側は、同一connectionでのリクエストは
同じプロセスそのまま再利用して処理するので。
で、クライアント側の待ち時間も、数倍違いが出ます(巡回時)。
正直なところ、個人的には全鯖KeepAliveON(タイムアウトは短くても)にして欲しいところです。
問題は、connectしたまま放置するクライアントの存在ですね。
IEは、force-no-varyに引っかかるので、必ず切断されますが
昔、比較的メジャーなクライアントの実装で
「リクエスト毎にHTTP/1.1コネクションを作成し、そのまま」
というのがあった気がします。 >>340
そうなんですよね。そんな気がして。
live8での実験の最中にKeepAliveをOffにしたわけですが、
少なくとも通常サーバでは、Onのほうがいい気がしたのです。
今はこうですね。このへんのパラメータチューンもしたほうがよさそう。
どうやるのがいいのかな。
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 10
ただ、携帯系では切ったほうがいいかも。
こんなかんじでいいんだっけか。
BrowserMatch "DoCoMo" nokeepalive
BrowserMatch "UP.Browser" nokeepalive
BrowserMatch "J-PHONE" nokeepalive
BrowserMatch "DDIPOCKET" nokeepalive >>341
http://httpd.apache.org/docs-2.0/mod/mod_setenvif.html#browsermatch
BrowserMatch regex [!]env-variable[=value] [[!]env-variable[=value]] ...
書式がかなり違うような（苦笑）
ひとまず、携帯機種には環境変数を設定して、Header を出力すると良いのかな？
BrowserMatch "DoCoMo|UP\.Browser|J-PHONE|DDIPOCKET" Mobile
Header onsuccess set Keep-Alive off Mobile
かなり自信なし（苦笑）
http://httpd.apache.org/docs-2.0/mod/mod_headers.html#header >>343
あ、クライアントに Keep-Alive: off の返事をするだけはダメですよねm(_ _)m
物理的に切断を指示するのは、VirtualHost ごとなのでかなり難解かも、、、> Keepalive ディレクティブ なんかスケジュールが巻き戻ってリリース日がかなり伸びてますねぇ
FreeBSD 5.3 Press Release 5 Nov 2004 >>331 続報
さきほどとりあえず ex7 と live8 で、
RLimitNPROC 200
にしてみた。もっと少なくてもいいのかな。 read.cgiにもこの制限当たってきちゃうわけだけど、
まぁ200なら、今のところこんなもんじゃないかなぁと。 >>350
どうもです。
システム観察的には、LA=80ぐらいになったみたい。 (http://ch2.ath.cx/load/ex7.html)
しかし、内部でとってるApacheのステータスログを見る限り、
システムはまだ余裕たっぷりだったように見えます。
なかなか、たのもしいなと。 http://sv2ch.baila6.jp/server.cgi?server=ex7.2ch.net
負荷量的には昨日のうｐ祭り @ news4vipの方が多かったと(頂上は同じぐらいか)。
つまり、女神降臨 ＞ 天皇賞 だったということかぁ。
でも、両方同時には来ないでほしいなと。 >>352
とりあえず、当面の目標は5.3Rで片肺状態の解消、でしょうなぁ
今度は巻き戻されないことを祈りませう 南無南無 ＞でも、両方同時には来ないでほしいなと。
心情的には理解できますけど、
確率的に考えてもそこは想定しない。もしあったら、潔く落ちましょう。という割り切りでいいんじゃないでしょうか？
気を楽にー、気を楽にー♪
>>354
どもです。気楽にやってるですよ。
両方来たらキタで、それもまたイベントかと。
ようやく腰下(OS)が安定になりそう = 気兼ねなく遊べそうになって、
つまり上モノ(システムやApacheの調整とか板セッティングとか)を遠慮なくいろいろといじれそうで、
相当わくわくしていたりして。 ＞両方来たらキタで、それもまたイベントかと。
さすがに慣れているというか……。(;^ ^
実社会でもそうですけど、これくらいポジティブシンキングできれば、ストレスも減らせて楽しんで活動できます。
＞ようやく腰下(OS)が安定になりそう = 気兼ねなく遊べそうになって、(ry
ネットワーク周りはPIE移転プロジェクトでほぼ解決して、今度5.3RによってOSが安定して、、、
下位のレイヤーが固まってきていますね。しばらくいじって来なかったところに、メスを入れられそうですね。
それ以前に
女神スレって削除対象でないの？( ;´Д｀) >>358
われわれが発掘できれば、立派な社会貢献かと。
live8/ex7を5.3-RC2に更新。
%uname -a
FreeBSD oyster901.maido3.com 5.3-RC2 FreeBSD 5.3-RC2 #1: Sun Oct 31 09:27:19 PST 2004 root@oyster901.maido3.com:/usr/obj/usr/src/sys/AMD64_COBRA_53 amd64
というわけでこれの効果が出ると、うれしいなと。
Merge tcp_output:1.104 from HEAD to RELENG_5_3:
date: 2004/10/30 12:02:50; author: rwatson; state: Exp; lines: +2 -2
Correct a bug in TCP SACK that could result in wedging of the TCP stack
under high load: only set function state to loop and continuing sending
if there is no data left to send.
RELENG_5_3 candidate.
Feet provided: Peter Losher <Peter underscore Losher at isc dot org>
Diagnosed by: Aniel Hartmeier <daniel at benzedrine dot cx>
Submitted by: mohan <mohans at yahoo-inc dot com>
Approved by:re (kensmith) AMD64ではlibcも更新した。
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/amd64/sys/brk.S
Revision 1.12.8.1 / (download) - annotate - [select for diffs], Sat Oct 30 00:08:46 2004 UTC (2 days, 7 hours ago) by peter
Branch: RELENG_5_3
CVS Tags: RELENG_5_3_0_RELEASE
Changes since 1.12: +1 -0 lines
Diff to previous 1.12 (colored) next main 1.13 (colored)
MFC: rev 1.13 fix brk(3) on amd64
(I believe there will be a tag slide for this)
Approved by: re (kensmith)
(中略)
Revision 1.13 / (download) - annotate - [select for diffs], Wed Oct 27 17:11:43 2004 UTC (4 days, 14 hours ago) by peter
Branch: MAIN
CVS Tags: HEAD
Changes since 1.12: +1 -0 lines
Diff to previous 1.12 (colored)
Fix brk(3). The stack was unbalanced when we jumped to cerror. Oops!
This causes nasty things like SEGV or a cpu spin when we return.
Submitted by: "James R. Van Artsalen" <james@jrv.org> root氏お疲れ様です。お体のほうはもう大丈夫なのかな？ >>364
ぼちぼちすね。
今週末からまた1週間ばかり※国方面に出張です。
この後ちょっぴり修○すると、無事に50,000ポイントということで。
# ex7はバージョンアップ早々いきなり負荷試験だったようで。 >>365
※イ＊ージでつか＞５万
そーなると5.3Rへのupは帰国後あるいは直前ぐらい？ RLimitNPROC を 200 から 150 にしてみた。< live8, ex7
超高負荷時に瀕死になる比率が下がるといいなと。 きたのかな。
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh.diff?r1=1.62.2.15.2.4&r2=1.62.2.15.2.5
===================================================================
RCS file: /usr/local/www/cvsroot/FreeBSD/src/sys/conf/newvers.sh,v
retrieving revision 1.62.2.15.2.4
retrieving revision 1.62.2.15.2.5
diff -u -p -r1.62.2.15.2.4 -r1.62.2.15.2.5
--- src/sys/conf/newvers.sh2004/10/30 22:07:061.62.2.15.2.4
+++ src/sys/conf/newvers.sh2004/11/04 18:51:301.62.2.15.2.5
@@ -28,11 +28,11 @@
# SUCH DAMAGE.
#
#@(#)newvers.sh8.1 (Berkeley) 4/20/94
-# $FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/conf/newvers.sh,v 1.62.2.15.2.4 2004/10/30 22:07:06 kensmith Exp $
+# $FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/conf/newvers.sh,v 1.62.2.15.2.5 2004/11/04 18:51:30 scottl Exp $
TYPE="FreeBSD"
REVISION="5.3"
-BRANCH="RC2"
+BRANCH="RELEASE"
RELEASE="${REVISION}-${BRANCH}"
VERSION="${TYPE} ${RELEASE}" reicha.netの#FreeBSDによると来たらしい。 live8とex7で、make buildworldとmake buildkernelぐらいしておくかな。 >>371
では早速ex7とlive8を人柱にしてみませう live8/ex7 バージョンアップ完了。
これで問題なければ、他のサーバにも徐々にってかんじで。
live8
%uname -a
FreeBSD oyster901.maido3.com 5.3-RELEASE FreeBSD 5.3-RELEASE #2: Thu Nov 4 21:52:19 PST 2004 root@oyster901.maido3.com:/usr/obj/usr/src/sys/AMD64_COBRA_53 amd64
ex7
%uname -a
FreeBSD tiger503.maido3.com 5.3-RELEASE FreeBSD 5.3-RELEASE #3: Thu Nov 4 21:51:36 PST 2004 root@tiger503.maido3.com:/usr/obj/var/src/sys/I386_TIGER_53 i386 今週末ぐらいまで問題発生しなければぼちぼちいけますかね
(ただし見習いさんあたりの号令次第で早まるかも知れんけど) 何か「どーん」と来ると、仮死状態になるですね。< live8
こんなメッセージとともに。
ex7でも前に起きた(西部警察の時)し。
5.3-BETA2にして以降出ているので、、基本的に同じ癖を持っているみたい。
Limiting icmp unreach response from 667 to 200 packets/sec
Limiting icmp unreach response from 430 to 200 packets/sec
Limiting icmp unreach response from 307 to 200 packets/sec
Limiting icmp unreach response from 485 to 200 packets/sec
Limiting icmp unreach response from 237 to 200 packets/sec
Limiting icmp unreach response from 804 to 200 packets/sec
Limiting icmp unreach response from 667 to 200 packets/sec
Limiting icmp unreach response from 483 to 200 packets/sec
Limiting icmp unreach response from 249 to 200 packets/sec
Limiting icmp unreach response from 228 to 200 packets/sec
Limiting icmp unreach response from 236 to 200 packets/sec
Limiting icmp unreach response from 655 to 200 packets/sec
Limiting icmp unreach response from 1198 to 200 packets/sec うーん。
2004/11/08 21:30:01 LA= 9:30PM up 1 day, 7:03, 0 users, load averages: 2.67, 2.73, 2.18
2004/11/08 21:40:00 LA= 9:40PM up 1 day, 7:13, 0 users, load averages: 54.95, 69.39, 37.19
2004/11/08 22:00:01 LA=10:00PM up 1 day, 7:33, 0 users, load averages: 1.12, 38.73, 58.44
2004/11/08 22:10:00 LA=10:10PM up 1 day, 7:43, 0 users, load averages: 0.93, 5.89, 29.24
2004/11/08 22:20:01 LA=10:20PM up 1 day, 7:53, 0 users, load averages: 0.61, 1.34, 14.70
2004/11/08 22:30:01 LA=10:30PM up 1 day, 8:03, 0 users, load averages: 8.22, 3.99, 8.94
2004/11/08 23:00:01 LA=11:00PM up 1 day, 8:33, 0 users, load averages: 662.45, 887.33, 840.68
2004/11/08 23:10:01 LA=11:10PM up 1 day, 8:43, 0 users, load averages: 0.66, 125.81, 423.08
2004/11/08 23:20:01 LA=11:20PM up 1 day, 8:53, 0 users, load averages: 0.39, 17.82, 211.69
2004/11/08 23:30:00 LA=11:30PM up 1 day, 9:03, 0 users, load averages: 2.36, 3.58, 104.58
2004/11/08 23:40:01 LA=11:40PM up 1 day, 9:13, 0 users, load averages: 2.52, 2.13, 52.17
2004/11/08 23:50:00 LA=11:50PM up 1 day, 9:23, 0 users, load averages: 0.48, 0.89, 26.29 LAがすごい勢いで上がる(600を超える)
システムが重くなり、無反応になる
そのまま数分～10分ぐらい、戻ってこない
という状況になりますね。
ちゃんと、
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
と出ているので、プロセス数のリミッター(150)は、効いているはずだと思うんだけど。 live18ってtigerでもcobraでもないけど 5.3Beta2・releaseとbeta1のカーネルのdiffとってみると原因がわかるかもしれないっすね
そもそもカーネルなのかあやしいけど >>384
んー、5.2.1Rの時はこういう落ち方はなかったような。
httpdの数を減らすというのももちろん手だけど、ちょっといまいちかもなぁ。
でも、やってみるかも。 live8の設定を変えてみた。
最初から用意するhttpdを増やして、最大数を減らす方向で。
<IfModule prefork.c>
StartServers 256
MinSpareServers 5
MaxSpareServers 256
ServerLimit 1536
MaxClients 1536
MaxRequestsPerChild 1000000
</IfModule>
<IfModule prefork.c>
StartServers 512
MinSpareServers 5
MaxSpareServers 512
ServerLimit 768
MaxClients 768
MaxRequestsPerChild 1000000
</IfModule>
以前あった「最初からたくさん待たせたほうがいい」を参考に、
両サーバとも再度設定変更。
# 今いいともに結構きてるみたい。
<IfModule prefork.c>
StartServers 768
MinSpareServers 5
MaxSpareServers 768
ServerLimit 768
MaxClients 768
MaxRequestsPerChild 1000000
</IfModule> >>387
競馬板だけど、readするのが少しばかり、重たくなりましたねぇ・・・ >>389
うーむ、今の込み具合なら重くなることはないはずなんだけど、、、。
(Apacheのスロットは十分あいているから)
________K_K_______K____._______KK____K___KK________K______K_____
_KK__KKC______KC_____K_K____KK________C_K.K_K._____K_______._KK_
_____________KK.K_.WW_K__W______C__CK__________K___K____W____K__
_KW____K___W___._W__K_K__.___K_K_____K__K___.___KK__________KKKK
___K__K___C_____KK__W__.KK__K______K_____K_____K____K_W.________
_K__K____K___._K__K___K.______KKW__W____K____C_____K____________
_K_____K__________.__K_______K___K_____K_______WW_______KKK____K
__WK________K_WK_.______________CK__W_W______K__W__K________K.__
__K__K_K__K__K________K.__K_______K__._____KW______________K__K_
.________KW__K.W__W_K______K_________K_KKK___W__K__________.____
___K___KK__K___K_K__K_WKK__W_KK___K_K_____K____K______K_._K__K_K
__________K_______K____K______KKC_______._K_K_WK_____._K______K_ 突然のLA上昇がOSの問題ではなく、apacheのKeepAliveの設定変更によるという可能性を探ると
考えられるのは、多数のread.cgiがpipeliedで呼び出されているのかもしれないですね。
通常の静的なコンテンツならば、pipelinedでもリクエスト順に１つずつ処理されるはずですが
cgi呼び出しを含む場合、apacheの仕組みとして
どんどん(forkしながら)子プロセスを同時実行して結果を受け取り、
返信する時にリクエスト順に返す、みたいになってるかもしれません(知りませんが)。
もしそうなら、100件のread.cgi呼び出しを含むリクエストが来た時
一瞬のうちに100個のプロセスがアクティブになってしまうので。
REQUEST_URIに.cgiが含まれるものは、NoKeepAliveにしたほうがいいかもしれないです。 携帯から。
>>391
ということは、
<Files ＊.cgi>
なんたら
KeepAlive off
</Files>
のほうがいいと？ よく知らないけど
SetEnvIf Request_URI *\.cgi* NoKeepAlive
みたいな書き方が出来たような。
それと、「read.cgiを多数呼び出すクライアント」として
先読みツールなどの他に、古くからの専用ブラウザで
read.cgiのrawモードを使う(使える)ものが考えられます。 >>391
状況証拠から考えて、ありうるかも。
機を見て、>>393 な設定を入れてみるか。
で、21:40ごろに「ぐわっ」と来た時は、スロットが満杯になって
それ以上の上昇が抑えられた模様。
どっかにも書いたけど、昨日 21:45 の状態。
で、cgi は NoKeepAlive すると、Kが減る可能性があると。
KKCKKKKKKKKKKCKKKKKKCKKKKKKKKCKKKKKKWCKKKKKKKCKKKWKCKKKKKKKKWKKK
KKKKKKKKKKKWKKKKCKKKKWKKKCKKKKKKKKKKKKKKKCCKKKKKKKKCKWKKKKKKKKKK
KKKKKWKKKCKKKKCCKCKWKKKKKKKKKCKKKWKKKKCCKKKKKKKWKKKKCKCKKKWKCKCK
KCKKKKKWKKKKKKCKKKKKKKKKKKKKKKKKWKKKKWKCCKKKKKKKKKCKKKKKKKKKKKKC
KKKWKKKCKKKKWKKWKKKWKKKKWKCKKCKKKKKCKKKKKKWCKKKKKKCKKKKCKKKKKWKK
KKKKKKCKKKKKKKCKKKKKKKKKCKKKKKKKKKKKCKKKKKKKKKKKKKKKKKKKKKKWKKKK
KKKKCKKKKKWKKKKKKCKKKKKKKKKKKKCKKKKKKCKWKKCCKKCKCKCKCKKKKWKKKKWK
KKKKKKKKKKKKKKKKKKWKKKKKKKKCKKKKCKCKKKKKKKKKKKKKKKKKKKCKKKKKKKKK
CCKKKKKKKCKKKKKKCKWKKKKKKWKKKKKWKKKCKKKKCKKKKKKKKKKCWKKKKCKKKKKK
KKCCKKKKKKKCCKWKKKKKKCKKCCKWKKKWKKKKKKKKKKKKKKKKKKKCWCKKCKKKKKCK
CWKKKKKKKKKKCKKWCKKKKKKKWKKCKKKKKKKCKKKKKKKKKKKKKKKCKKKKKKKKCKCK
KKKKKKKKKKKKWCKKCWKKWKKCKKKKKKWWKKKKKKKKKKKKKWKKCCKCKKKKKCWCKKCK live8 と ex7 にまずは以下を入れてみた。
手で telnet すると、ちゃんと read.cgi の時はセッションが切れているみたい。
#
# Thank you for http://qb5.2ch.net/test/read.cgi/operate/1093068260/391-393
#
SetEnvIf Request_URI ^/test/bbs\.cgi nokeepalive
SetEnvIf Request_URI ^/test/read\.cgi nokeepalive subbbs.cgi も追加してみた。
#
# Thank you for http://qb5.2ch.net/test/read.cgi/operate/1093068260/391-393
#
SetEnvIf Request_URI ^/test/bbs\.cgi nokeepalive
SetEnvIf Request_URI ^/test/subbbs\.cgi nokeepalive
SetEnvIf Request_URI ^/test/read\.cgi nokeepalive カーネル、ユーザランドとも無事に5.3Rに上げて、リブートテストも通り、
bumpedになったportsを更新して、再度リブートすると、、、
立ち上がってきません。< c-docomo4
謎だ、、、。
とりあえず、リブート要請してみるか。 リブートしてもらったところ、問題なく上がってきました。
チェック後、再度リブートテストを行う予定、、、。 再度リブートテストしました。今度は無事にブートアップ。
システムも異常なしの模様。
cobra2244 = c-docomo4 は FreeBSD 5.3R になりました。
今回の方法を参考に手順を整理できそうなので、
この方法で他のCobra/Tigerサーバのバージョンアップを順次実施する予定。 5.2.1R → 5.3R へのバージョンアップ手順
0) Apacheの停止(外からのアクセスを止める)
1) rm -rf /usr/obj /usr/ports
2) mv /usr/src /usr/src521 # 安全のため/usr/srcは一時的に残す
3) live8 から持ってきた作成済みの /usr/src /usr/ports /usr/obj を展開
これにより /usr/src/standard-supfile も置き換わる
4) make buildkernel KERNCONF=携帯サーバ用カーネル
5) make installkernel KERNCONF=携帯サーバ用カーネル
※4) 5)は通常マシンの場合、通常用カーネルを指定
6) /etc/sysctl.conf /boot/loader.conf を 5.3R 用に調整
(基本的にlive8のを持ってくればよいが、携帯用サーバではccdを使っているのでその設定を直す)
7) リブート
8) ブートアップ確認後、dmesg をチェック、保存
9) cd /usr/src/usr.sbin/mergemaster; make -m /usr/src/share/mk all install
10) mergemaster -p
11) make installworld
12) mv /etc/rc.d /etc/rc.d.521; mkdir /etc/rc.d
13) mergemaster -i
/etc/passwd /etc/group /etc/aliases 等をはじめとするいくつかのファイルはmergemasterで
対話的に調整する必要あり
14) リブート
15) ブートアップ確認後 rm -rf /etc/rc.d.521 /usr/src521
16) libm 等がバージョンアップしたことによる、ports の更新
# これがめんどくさい portsの消し方
c-docomo4では以下の手順が必要であった
pkg_delete analog-5.32_1,1
pkg_delete cvsup-without-gui-16.1h
pkg_delete gd-2.0.15_1,1
pkg_delete help2man-1.33.1
pkg_delete p5-gettext-1.01_4
pkg_delete gmake-3.80_2
pkg_delete bison-1.75_2
pkg_delete wget-devel-1.9.1_1
pkg_delete php4-extensions-1.0
pkg_delete php4-gettext-4.3.8_2
pkg_delete gettext-0.13.1_1
pkg_delete pear-APC-2.0.4 pear-PEAR-1.3.1 pear-XML_RPC-1.1.0 pear-Console_Getopt-1.2 pear-Archive_Tar-1.2 php4-pear-4.3.8_2 php4-zlib-4.3.8_2 pecl-zip-1.0 php4-xml-4.3.8_2 php4-tokenizer-4.3.8_2 php4-sysvshm-4.3.8_2 php4-sysvsem-4.3.8_2 php4-sysvmsg-4.3.8_2 php4-shmop-4.3.8_2 php4-session-4.3.8_2 php4-readline-4.3.8_2 php4-posix-4.3.8_2 php4-pcre-4.3.8_2 php4-overload-4.3.8_2 php4-openssl-4.3.8_2 php4-mysql-4.3.8_2 php4-mbstring-4.3.8_2 php4-iconv-4.3.8_2 php4-gd-4.3.8_2 php4-ftp-4.3.8_2 pecl-fileinfo-0.2 php4-dba-4.3.8_2 php4-curl-4.3.8_2 php4-ctype-4.3.8_2 php4-bz2-4.3.8_2 php4-bcmath-4.3.8_2 php4-4.3.8_2
pkg_delete apache-2.0.50_3
pkg_delete mysql-client-4.0.18_1
pkg_delete net-snmp-5.1.1_1
pkg_delete png-1.2.5_2
pkg_delete squid-2.5.6_6
pkg_delete t1lib-5.0.1,1
pkg_delete automake-1.5_2,1
pkg_delete autoconf-2.53_3
pkg_delete autoconf-2.59_1
pkg_delete autoconf-2.13.000227_5
pkg_delete autoconf-2.53_1
pkg_delete autoconf-2.57_1
pkg_delete p5-Net-DNS-0.42
pkg_delete p5-Digest-HMAC-1.01
pkg_delete p5-Digest-SHA1-2.06
pkg_delete p5-libwww-5.75
pkg_delete p5-Net-1.17,1
pkg_delete p5-HTML-Parser-3.34
pkg_delete p5-HTML-Tagset-3.03
pkg_delete p5-URI-1.27
pkg_delete p5-Authen-SASL-2.06
pkg_delete p5-MIME-Base64-2.21
pkg_delete p5-Digest-1.02
pkg_delete p5-Digest-MD5-2.30
pkg_delete perl-5.6.1_15
pkg_delete jpeg-6b_1
pkg_delete freetype2-2.1.5_1
pkg_delete libiconv-1.9.1_3
pkg_delete expat-1.95.7 ○ports の再導入
pkg_add -r perl
ここで /etc/make.conf を修正 (Perl のバージョンが上がったため)
pkg_add -r cvsup-without-gui
pkg_add -r p5-Digest-MD5
pkg_add -r p5-libwww
pkg_add -r p5-Net-DNS
pkg_add -r analog
pkg_add -r wget-devel
○大物パッケージをportsから入れ直し
net-snmp入れ直し
apache入れ直し
php4入れ直し
php4-extensions入れ直し
pear-APC入れ直し 17) 以上終了後、最終リブートテスト
18) ブートアップ確認後、Apache の自動起動を復活(/etc/rc.conf) 以上。
これだと、1日に1台～2台ぐらいってかんじかなぁ。
こっちは夜の10時をまわりました。
本日はここまで、、、。
手順に問題とかある場合、指摘おながいします。 んで、スタンドアロンなマシンをバージョンアップする場合は、
1) rm -rf /usr/obj /usr/ports
2) mv /usr/src /usr/src521 # 安全のため/usr/srcは一時的に残す
3) live8 から持ってきた作成済みの /usr/src /usr/ports /usr/obj を展開
が、
standard-supfile の RELENG_5_2 を RELENG_5_3 に更新
make update
make -j 適当な数字 buildworld
make -j 適当な数字 buildkernel
てな感じになるです。 >>405
pkg_deleteの山がすごすぎですなあ・・・
apt for rpmみたいに依存で一気にremoveできるといいんですけどねぇ
今回はlibcの更新があるから仕方なさそうですが・・・ 消したいのをリストアップして -f 付けて消すとか言って混乱させてみるペスト。 うひゃ～ これ全部お一人でやるんですか・・・がむばってください
温かいお茶用意して待っとります。
かしこ >>407
依存関係はそれなりなツール使えばたぶんいけると思うのですが、
今回は手でやってみたと。
で、libcはバージョン上がってないはず(上がってたらもっと大変)。
>>408
それでもたぶん問題ないような気がしますが、
何かあった時に困るし、今後中の人が増えたりした時に
情報共有するの大変だし。
だから、普通にコンパイルすれば入るものでも、
できるだけports/packages使うようにしていたり。
ということで概ね問題なさそうなので、
今度は live16 live17 あたりをやってみようかと。 >>412
>>401-404に書いてある手順通りでいいんですよね。
>>401の3)はlive8のアクセス権ないので、それ以降は大丈夫なはずです。 /usr/src/* /usr/obj/* /usr/ports/*
/etc/make.conf /etc/sysctl.conf /boot/loader.conf とかは
c-docomo4 から持ってくればいけるはずと。
ports / packages のバージョンとかは、若干違うかもと。
c-au / c-others 系もたぶんやったほうがいいと。
で、c-docomo の代表をバージョンアップする間は、
DoCoMoの携帯からはc系を利用できなくなると。
これはauやothersをやるときも同じりくつで。
で、自分的には、pkg_delete するところを shell script にでもしとこうかと。 そっか、c-docomo4から持ってくればよいのね。
>ISC
> BIND (all versions) are not affected by this vulnerability.
だから心配するな。
dnscacheについてまだ書かれていないけど、ちら見した感じだと平気そう。 libm.soとかとリンクしているportsをリストアップする奴。
前スレでも話題になったかもしれないけど。
http://www.maxlor.com/freebsd/files/findlibusers.py
portupgrade -PP -arとかするよりは無駄が無いと思う。 >>411
すいません、たしかにかわっていなかったっすね＞libc AP #3 (PHY# 7) failed!
panic y/n? [y]
がいきなり表示、、、。で、ハングアップ。
リブート、要請します。ううむ。 リブート職人さんにリブートしていただきました。
作業継続中。 i386なマシンではperlccが通らない模様。
茴 at /usr/local/lib/perl5/5.8.5/mach/B/C.pm line 476.
CHECK failed--call queue aborted.
( cd ..; tar czf bbs.cgi.tar.gz bbs.cgi )
%
とりあえず、perl版を入れておこう。 > ( cd ..; tar czf bbs.cgi.tar.gz bbs.cgi )
> %
こいつはゴミっす。上2行が不可解なエラー。 今回わかった問題:
・i386の場合、バージョンアップ途中の作業はSMPとapicなし(シングルCPUモード)の
カーネルで行わなければならない。
そうしないと立ち上がる途中でpanicを起こし、ハングアップしてしまう。
たぶん、device.hintsが5.2系と5.3系で変わるせい
(途中の段階で 5.3カーネル、5.2ファイル、という状態を経由し、それが通らない)
だと思われる(未確認)。
=> シングルCPUの5.3カーネルなら問題ないので、シングルCPUのカーネルで
バージョンアップ作業を実施し、最後にマルチCPUにすれば回避可能(既に実施済み)
・Perlのバージョンが上がるので、Perl 5.6.1ベースのbbs.cgiは当然perl 5.8.5ベースでは動かない。
read.cgi は 5.2.1 のものがそのまま動くが、ベンチマークのため ex7 のものとともに、
5.3 上で再度コンパイルを実施した。
・i386の場合、amd64で通ったbbs.cgiのperlccによるコンパイルが通らない。(>>427)
とりあえず、ex7と同じPerl版を動かすことにした。
Apacheのセッティングは、とりあえずex7と同じにしてあります。
最初に実力が試されるのは、土曜の夕方？ >>428 補足
> ・Perlのバージョンが上がるので、Perl 5.6.1ベースのbbs.cgiは当然perl 5.8.5ベースでは動かない。
「バイナリ版bbs.cgi」が正しいです。
Perlなら、5.6.1/5.8.5どちらでも問題なく動作しました。 perl5.8.5 自体をリコンパイルしなきゃかもですです、、、
でもってもしかするとportsから外して１からコンパイルした方が楽かも(^-^;;) >>430
うーむ、i386でもamd64でも同じようにpkg_add -r perl ってやったんだけどなぁ。
つまり、私はコンパイルしていません。 今日のLive17はホント強かったです。これなら土曜日の実況で落ちることも無さそうです。
問題は放送終了後のex5('A`)
http://users72.psychedance.com/logview.cgi?srv=ex5.2ch.net
地道にLive17で続けてもらう方向でがんばってみます・・・ とりあえずの課題は、超高負荷時の仮死状態対策か。
ex7/live8が上がったら、
・syslogをどこか別のマシンに飛ばすようにする
を、とりあえずやってみるか。
リミッター切ってもLA=400以上になっちゃうのは、、、。 もう live8 にはつながらない状態なのに、
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
...
が、延々と出続けてる、、、。 とりあえず、ここに記録しとこう。
仮死状態になるのは、何とかしたいなと。
【実況板】 live15/16/17 鯖 Part1
http://qb5.2ch.net/test/read.cgi/operate/1097931665/414-461 転記。
687 名前： ◆MUMUMUhnYI [sage] 投稿日：04/11/15 00:08:19
>>686
でも、defleteのせいとはちょっと思いにくいんですよね。
それより先に、syslog系を見直すとかbbs.cgiの起動制限をうまくやるとか、
そっちをやってみようかと。 syslog鯖ですか
セキュリティやログ消失問題から標準syslogdではよくなさそうでつ
syslog-ng使えるようならそっちがよろしいかと
portsでも提供されているようですし
参考：ttp://www.atmarkit.co.jp/fsecurity/rensai/unix_sec09/unix_sec01.html 465 ：▲ 某ソレ511 ：04/11/15 06:25:30 ID:Q7Whv+GJ
いちお、こっちにも書いておこーっと。
たぶん、負荷多すぎでbbs.2ch.netがちゃんと動いてなかったんだと思う、
kawasemi-m見てるとしょっしゅうありますからね。
じっさい、そのあたりで10分間くらい数字が増えてなかったりような部分がありましたし。。
たしかあれってkawasemi-m見てるんですよね、
ということもあるし、bbsはbananaだとつらすぎ？ バーボン機能を入れてアレになったのかのう。。
こないだの大根が腐ったりした原因もこれかすら？ >>442
バーボン入ってない時も同じようなこと起こってたけどね。
例えば27時間テレビの時とか、
そのレスで負荷が、って書いたけど、なんとなく
負荷が原因というより、集中してあれれ、という感じかなぁ、 game10@tiger504 の土地造成お願いしますー
>rootさん
● 質問・雑談スレ77＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1100474722/121 >>444
roger。時間とれた時点で。
で、11月26日までにFreeBSD 5.3R化必要かしら。< tiger504
# そろそろ、各サーバのバージョンアップスケジュールを出さなきゃ。
## tiger x 2ですね。< game系
## gameな人たちには以前相当ご迷惑をかけたんで、私的には罪ほろぼしの意味もある、、、かも。 >>445
そっすねぇ < 5.3R
ジンギスカン準備工事もよろしくです
tigerサーバ(掲示板用)バージョンアップスケジュール & 進捗状況 雛形
tiger503 ex7 済み
tiger504 live13→game10
tiger505 news18
tiger506 game9
tiger507 live16
tiger508 live17 済み
tiger509 news19
tiger510 hobby7 ということで、
tiger503 ex7 済み
tiger504 live13→game10 来週早々
tiger505 news18 今週中
tiger506 game9 来週中
tiger507 live16 今日明日にでも
tiger508 live17 済み
tiger509 news19 今週中
tiger510 hobby7 来週中
といったあたりかなと。 久しぶりに儀式します。
+game10.2ch.net:206.223.150.115
を、DNSに追加お願いします。 例の mod_dosevasive を、bbs.cgi 起動数リミッターに利用できないか、
ちょっと考えてみようかと。 >>453
OKです。
アカウント情報をメールしなきゃ。 >>446
ジンギスカン準備工事がまだでした。
やっておくです。 >>456
準備工事終了。
これで今やることは終了です。 単独スレによる告知
game8 の板たちは一時間くらい止まります
http://qb5.2ch.net/test/read.cgi/operate/1100511730/
>>447 のうち、こんな感じで単独スレ立てないといけなそうなのは、、、。
…基本的に全部、これでいくかな。
めったにあることじゃないし。 live16はだいじょぶだと思う。hobby7も他よりはましかなぁ。
あとは、、だめそうだなぁ。 メモリディスクがかなりぎりぎりだなぁ。
%df /md
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0 38124 31220 3856 89% /md
不安なので、1度rebootしてメモリディスクを大きくして設定変えてよかですか?
5分ぐらいでできると思われ。
いったんバックアップしてからrebootするので、
板復帰はいらないはず。 >>461
増やしたです。
%df /md
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0 76524 31328 39076 44% /md
来週はじめあたりに、OSのバージョンアップ&設定強化をしようかと。< game10 live17 と ex7 の RLimitNPROC 150 をはずした。
つまり、プロセス数のリミッターなしに。
リミッターにかかると「リミッターにかかった」ということがどばっと行くため、
システム全体がもろくなる模様。(今のlive8)
症状は、例のメッセージがコンソールに出まくりという、昨日と同じ状態。 game（PCゲーム）だけはgame8@banana226に居残りなんですね。 tiger503 ex7 済み
tiger504 live13→game10 来週早々
tiger505 news18 火曜～水曜夜あたりにでも
tiger506 game9 来週中
tiger507 live16 済み
tiger508 live17 済み
tiger509 news19 水曜～木曜あたりにでも
tiger510 hobby7 来週中 http://qb5.2ch.net/test/read.cgi/operate/1097921896/848-850n
こちらに話を振ります．>>381 のようなメッセージが出てくる状況は
まずいということですね？ では......やや変則的ですが，mod_cgi の
代わりに mod_cgid を使ってはどうでしょうか．cgid ソケットの
backlog 数がリミッタとして作用するかと思います．オリジナルの
mod_cgid ではこの数値は固定されていますが，以下のパッチにより
httpd.conf 中の ScriptsockBacklog ディレクティブで指定可能になります．
(bzip2+base64)
QlpoOTFBWSZTWUq4iQIAAdd/gGIxkEBZ////f6/+qv/v//pQBXhe6wzaHbZFAUpC
SRqCap+pPypjJqZPSegCD1PTCJppgBGjGgTI0GpkynqanqT1HpANNBowgDTJkGgA
ANNAAJEQiT1TaQ9T1P1R6TyhoAAAyGgAAAA9Q4aGTTQ0yNDTIyDIyNDIDE0ZNAGT
IxDCSIINAEmmIaKP1ID1NMgANAB6mgepk0NMiQjzm5rZK9evFM6RWIrRkcuEVLuj
aSjLnomZQ6cShDHuRZl2gvWSgoaL71CC/VWUCVlFTMr5oyiwh7EFnMQqWlViha1y
EksNLG22xttMY2NjY7wUENsbcKJPD+PfU90DMyKfD9RJmgopjxWcETZ+Rezwqzb5
85XnvT/6sp/LN7DrYzDViEM/ewx6uoZq2HNv9OiDjfsQFreEVkNuKhWE4l0QpkBI
QhapKzsAkA/UiCiw0qpiC+7oThQZBJQNBl2aD3av5yzPyjza2ZqOlgMRjLkWpUJE
I0mrGZoyEo0qulc77nc8XeHg9WXDFuoxCMdJRVvIoewrmEskXFaLRM9g1of140vz
+4cN8pMaDQyp9F3hViYQrgJag0AZIkXOw07Ku44fjU8h5vfNDpR2Rt4Mj2damkso
ZQnumC+29t4c4Avje2gZaorsYVjEgGqSviKoYaawAugxXDBg+Yin8HCcddqgRUq0
FUyEuTKbBXSUUVkohHXhMHvBQibICOD1U40AiTMmVey69Ssd/k3b4N52zOqr142y
jS6FItZVGyEOAg1QvoAcPUD8zwojh4g2urxwIOwgW4s27bcsZDqIi+OFGCpBkNxH
ryINVUWOEiSLEHeXB/KY0K0dZUiHXTJFYTQVFiRQc7yCDX1lMlhoMYYo0Q0UHcZF
YsBXmJM3OihnWi8jGaNXCUiaJXF5zI+39aywsRbA8wYX45ILkcTVIkgugHI85cix
DcKI6CBOBCWk0eA5yZ1BDUE77c6nVENQQQOjR4qCJCMnkq/OjRR5mawUHSXjKEQJ
e5g2V39AtjlfMpsmxK/UpsI4IpocmZr/QVkaB8RuIgzs32EQqGO5LeO2gy5DMVgw
GNfqM5cmQBeC+aTWE0uITFLItqlKSR95myWLB1U0MY/6qbIniVMeCNIwGE/EcRQV
a9EInCUypF9npIhVxLmAgYM4eUpBV85wiZnqgwFP+qUQibytaysLF42yK0dWDMAX
mD7Fwv2bEA4FBg2Bp1l7NlUK2CU4YrKlijjJihKocIZCKM7uRWJYyoyAuTdjs7oT
/wZzOQIvJhWjIURMJWkiUEpOKAgsy4mKPMjsDpIUJ1lRDsZ7i1AbV6YGG0MhIyW0
0Ci1cfQ0LjnIgwXM1TQ8AwxvMy1F0ugZGCLhFUlPcULXMTXei4qgQBgiz1nPEchz
mZindsCZLmcqSCCGHRaPamAiLRbipbDaksUsEFCIuphMMCr6RUWe1V32kEgrGgyX
FYmIMoFC08e7gMMNsDepnejGCiK9AaopKWwEtMvaRlQ0NknALxXDGGDNvSzpkULM
rEBDelBWjKSVDJUggN/M4ZJgxYrGDaUrRRKZB+phGchxgsbBgvRNOpOSvSoHcei6
Ii7OoVZVjkJcUNcqjrXOmQFk4zkCmQHxHUNwKnFHIReFQFrFSgnWhYoo9golKeGb
57lPxI8IeJka9COlDdr25gNnSnMOgLJJQyFXejAFQNqybe1De2Sc3k0KzSG/+LuS
KcKEglXESBA= live8 の RLimitNPROC のリミッターをはずした。
>>470
おっ。
いれてみるか。 あと、すぐに思いつくこととして、
・Apacheをch2xxxxとかの権限で動かしてSuExecをやめる
=> suexec のオーバーヘッドがなくなる
があるけど、効果あるのかしら。
これはそんなに面倒なく試せるので、そのうちどこかで。 きたく。つかれた。
これ、はっとこう。
● 質問・雑談スレ77＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1100474722/549
549 名前：FOX ★[] 投稿日：04/11/16 19:15:23 ID:???
1) ある板を別の板にリダイレクトする仕組み(手動)
2) サーバの負荷が上がったら 1) を実行する仕組み
3) 1)のある板を自動的に選択する仕組み
4) リダイレクト先を自動的に選ぶ仕組み
5) ぐちゃぐちゃにならないようにする仕組み
が全部出来れば全自動洗濯機の完成だー >>473
あっちは未読の山なのでこっちに♪
なんだかうっとこ（2ch 鯖監視係。）で実験が出来そうな悪寒だよなぁ（汗）
それとも引越すとか？ >>474
でもよーく考えてみると、その「歩いた」が Timeout(http) するようになると、なぁーんも出来なくなる悪寒（汗） tiger503 ex7 済み
tiger504 live13→game10 来週早々
tiger505 news18 済み
tiger506 game9 来週中
tiger507 live16 済み
tiger508 live17 済み
tiger509 news19 水曜～木曜あたりにでも
tiger510 hobby7 来週中 >>473
＞ある板を別の板にリダイレクトする仕組み(手動)
これは各板の.httaccessで
Redirect seeother index.html リダイレクト先URL
でいけますな。LAの値によってリダイレクト実行はひねくれた方法がいるかも。 cobra bge
tiger em
banana vr
携帯banana fxp やっぱ、どー考えても新スレ立てがサーバ負荷を急激に上げたに違いないなと。
1100695651.dat<>[フジ]高橋は神 (2)
1100695555.dat<>[フジ]お前ら何さわいでんの？ (2)
1100695549.dat<>[フジ]高橋克己の光臨を待ちわびるスレ (2)
1100695538.dat<>[フジ]生首オチ (2)
1100695529.dat<>[フジ]水10！～ﾜﾝﾅｲ→ココリコミラクルタイプ～ Part.1 (2)
1100695504.dat<>[フジ]高 橋 克 己 (2)
1100695482.dat<>[フジ]トリビアの泉 part7 ～満開激しくキボンヌ (2)
1100695468.dat<>[フジ]さくらたんのエロ画像きぼんぬ (2)
1100695454.dat<>[フジ]コマンドーがきぼんぬと発言した件について (2)
1100695417.dat<>[フジ]滝川クリステルだけど実況するスレ Part222 (2)
1100695398.dat<>[フジ]タモリ八島しらばっくれんじゃねぇ喪前らも2ち(ry (2)
1100695296.dat<>[フジ]高橋にちゃんねらー (2)
1100695283.dat<>[フジ]妹うｐマダー (2)
1100695145.dat<>[フジ]データ取得できませんでした (2)
1100695100.dat<>[フジ]データ取得できませんでした (2)
1100695178.dat<>[祭り]高橋克実、ｷﾀｰ 満開禿しくｷﾎﾞﾝﾇ (2)
1100695077.dat<>[フジ]キボンヌ！！！！！！！ (2)
1100695079.dat<>[フジ]ｷﾀｰ (2)
1100695074.dat<>[フジ]高橋克実が2ちゃんねらーである件について (2)
1100695073.dat<>[フジ]キャプチャのうｐ激しくキボンヌ (2)
1100694989.dat<>[フジ]高橋克己が「キター激しくきぼんぬ」発言した件 (2)
1100694951.dat<>[フジ]高橋がキボンヌと言った件について (2)
1100695072.dat<>[祭り]満開はげしくキボンヌ (2)
1100694942.dat<>[フジ]高橋克実は２ちゃんねらー (2)
1100694937.dat<>[フジ]満開激しくｷﾎﾞﾝﾇ (2)
1100695010.dat<>[実況]高橋克己が「キター激しくきぼんぬ」発言した件 (2)
1100694927.dat<>[フジ]満開禿しくｷﾎﾞﾝﾇ！！ (2)
1100694916.dat<>[フジ]高橋がアレな件について (2)
1100694895.dat<>[フジ]２ちゃんねらーｷﾀｰ (2)
1100694862.dat<>[フジ]毎回はげしくｷﾎﾞﾝﾇ (2) rootさん、こんばんはヾ('-')ﾉ
忙しそうですねー
ところで、2chもいずれ巨大化してこんなのに似た
分散システムになっていったりするのでしょうか・・・ﾌﾞﾙﾌﾞﾙ
ttp://internet.watch.impress.co.jp/cda/event/2004/11/16/5430.html disklessブートで、フロントエンドのApacheが立ち上がって。
データはバックエンドのMySQLに入っている。
というような仕組みになれば非現実的ではない。
でもHDDレスのブレードサーバーをJimさんに引っこ抜いてもらったりするメンテの手間はかかるな。 妄想ﾚﾍﾞﾙで想像してみた。
データを小分けにしそれを1単位として2台のPCでデータをミラーリング。
バックアップPCを何台か用意し,1台に障害が発生したらミラーマシンからバックアップの1台に
データ転送。リンクを繋ぎ変え。障害発生PCは改修後バックアップとして復帰。
こんな感じかなあ。 >>484
こんばんは。
本文より:
> ハードウェア、システムを解説したSilverstein氏は最後に、Googleにおける仕事の考え方を紹介。
> 「エキサイティングな問題に対して仕事をする」「世界中のみんなに影響を与える」
> 「可能な限りアルゴリズムで問題を解決する」「新しいことへのチャレンジを恐れない」などを列挙し、
> 「もし気に入ったなら、一緒に働きましょう」と会場へ呼びかけて講演を締めくくった。
日々エキサイティングという意味では、ここだって負けてないし。 つまり、
「もし気に入ったなら、一緒に泥沼にはまりましょう」
と。 tiger503 ex7 済み
tiger504 game10 来週早々
tiger505 news18 済み
tiger506 game9 来週中
tiger507 live16 済み
tiger508 live17 済み
tiger509 news19 済み
tiger510 hobby7 来週中
>>488
それはもう。 何気に、5.3 RELEASE-p1になっているね。
>>480対応じゃなさそうだな。。。
Edit src/UPDATING
Add delta 1.342.2.13.2.4 2004.11.18.12.03.04 cperciva
Edit src/sys/conf/newvers.sh
Add delta 1.62.2.15.2.6 2004.11.18.12.03.04 cperciva
Edit src/usr.bin/fetch/fetch.c
Add delta 1.72.2.1.2.1 2004.11.18.12.03.05 cperciva >490
FreeBSD-SA-04:16.fetch.asc参照 tigerサーバにアニメ系の板を移転するという風の噂を聞いたけど、
ひょっとしてバーチャルホストの追加作成とかの必要があるのかしら。 news18(tiger505) はジンギスカン準備工事は成されていますか? で、そのサーバがもし強化されてなかったら、
本日夜緊急にパワーアップ工事する運びになりそう。
ちなみに現状は >>489 ジンギスカン準備工事はパワーアップ時に済んでました。
news18に入れるなら、いますぐにでもOKかと。
>>496
語らずとも伝わる愛。 んで hobby7(tiger510) にも片方入れます、
もしお時間が御ありでしたら・・・
power up & RAM 工事をお願いいたします。 既存のにとりあえず寄生ってことみたいすね。
で、news18と。
ジンギスカンなしの今の状態でも、
こないだの中国敗退で微動だにしなかったんで、
負荷的にはいけるかなと。 >>499
hobby7 工事します。
一回 reboot 必要。
これは、この後でやります。
そのうえで今夜、5.3Rへの緊急パワーアップ工事も実施します。 どもです
ジンギスカン化は
今週末の様子を見てからと思っていますが、
気が変わるかも知れず・・・ ということで、 hobby7 のジンギスカン準備工事、完了。
てなわけで、ready to moveかと。 ここに転載しておこう
新設板・板移動情報・３＠運用情報
http://qb5.2ch.net/test/read.cgi/operate/1085230456/957
957 名前：FOX ★[sage] 投稿日：04/11/19 15:35:16 ID:???
アニメ系は将来サーバ名も anime.2ch.net にする予定(一年以内にはなんとか)
カテゴリも「アニメ」を作ったほうがいいと思ったりして(願望)
アニメ板(anime) の略板名(←bbsmenu上)はアニメのままでよろしくです(お願い)
なぜなら、突発的な負荷をアニメ板で受け止めるようなサーバ配置で行くからです。
アニメ板でも当然「実況はご遠慮ください」です。
>>504
ひょっとしたら最悪cobra/peko投入になるんでしょうかね・・・
アニメ系は2chリソースにとってきわめて凶悪なものといっても過言ではないわけで、
tigerでも捌ききれていない悪寒
read.cgiコールが圧倒的に多いならばcobra1台でも捌けるだろうけど(tiger1台では無理と思われ)、
bbs.cgiコールが圧倒的に多いならばtiger2台のほうがいいかもしれないと勘ぐってみる >>505
今の大敵は「スレ立て攻撃」かなと。
超短時間の間にぼこすかといっぺんにスレ立てされるのが、
一番システムのダメージが大きいみたい。
感情にまかせたレスはそういうもんだと思うことにして、
感情にまかせたスレ立て(例: >>483)って、どうにかならんもんなのかな。 >>506
サーバ毎に(or 板毎に) 最小間隔チェックでも考えますかねぇ
bbs.cgi のなるべく最初のほうでチェックするようにして、
来年になるとは思いますが、、、
ちと仕事でコードばしばし書いているので
コード書きに食傷ぎみな年の暮れ >>507
そうすね。
コードすか、、、。書けるひとのことはまじ、尊敬するです。(素)
私はセッティングとかチューニング方面の人なんで。
そういえば、動的に変えるってやつがあったんだった。
短時間で(あるいは問い合わせ内容に応じて)ダイナミックにDNS応答を変えるってのは、
意外とめんどうだったり、するかも。 >>506-507
確かにスレ立てはディスクIOの負荷が一番大きいですからね。
・datファイル生成、この重さは追記やchmod操作より重いはず
・subbackやindex等の更新
そのようなじゅうたん爆撃をされてはかなりきついのは当然でしょうね。
いっそ全板スレ立てチェックシステムがあるといいかも。仮にbbtシステムとして、
リモートIP.dat.板名.鯖名.CGI名.bbt.2ch.net
をコールして板または鯖ごとに設定された何かの数を返すようにすればいいかと サーバまたぐ必要ないし
局所的に聞けばいいんで
サーバ内(or 板毎) にファイル一個持てばokな感じ
スレ立ったら touch して スレ立て来たら stats でタイムスタンプ読んで
みたいな、 mnewsplus もジンギスカン化するので
ちょっとと止まります >>510
局所的なのはそれでもいいかもですが、
板や鯖をまたいだスレ立て爆撃に対応できますか？
もっとも既存の別システムで撥ねれば済む話かもしれませんが >>516
それはバーボンハウスでかなりいけてるんじゃないですかね。
今問題になってるのは、長短時間の間での同じサーバでのスレ立てなんで。 要するにファイル作成のコストが大きい、つまりbbs.cgi自体の起動は問題ないわけですね。
だから、bbs.cgiで、超短時間での同じサーバーでのスレタテが起きたときに「しばらくしたら立ててね」みたいなエラーメッセージを表示すればOKじゃん？ >>520
それが >>510 っていう話かなと。 スレ立てn秒規制ですか
DDoSを利用したスレ立て爆撃、みたいな未来の攻撃にも備えられますな
というか、実況板のスレ立て爆撃は事実上DDoSと同じことかｗ >>523
そうっすよね。
live系にたまに立つ単独スレのスレタイって、結構物事の核心を突いている場合が多い。 こんな感じですかね．
my ($now, $mtime) = (time(), (stat($CHECKFILE))[9] || 0);
if ($now - $mtime < $INTERVAL_TO_DENY) {
/* 廊下に立ってなさい */
}
else {
utime($now, $now, $CHECKFILE);
} >>526
そこのは全然風物詩、ってわけでもないでしょ。
むしろはっきりいってただの運営妨害だ。 あまりにもののけ姫スレが立ってるので流れ流れてここに来ました。
技術的な事はわからないけど「もののけ姫」とか同じ単語がつくスレは何スレまでとか
規制をつけると、その時あるスレを使う訳だし乱立にもならないのではとか思いました。 ここはもう実況はどうなっても構わないの心意気で、
live系のセッティングだけ甘くしておくとか…
もしくはex系だけ（ｒｙ >>留守番 ★さん、root ★さん、
＞超短時間の間にぼこすかといっぺんにスレ立てされる
確認してみたのですが、
bbs.cgiでのお茶飲め規制（LA規制）が機能してないようです、、、
これを再度機能させて様子見てみて良いですか？ >>531
お茶はFreeBSDなマシンではわざわざはずしてるんですよね、、、。
正直、あまり意味がないんで。
LAが高くても下がり目の時は大丈夫だし、
低くても「どば」が来ればだめです。
そもそもお茶が出るときはみんながいらいらしてbbs.cgiを上げるから、
いつまでたってもLA下がらないし。 今のtigerサーバにはリモートコンソール(シリアル)があるわけだから、
強制的にDDBにいけるようにしてみるというのは、手なのかも。 【実況板】 live15/16/17 鯖 Part1
http://qb5.2ch.net/test/read.cgi/operate/1097931665/666-678
ということで、live8 live16 live17 ex7 で、
net.inet.icmp.icmplim=3000
net.inet.icmp.icmplim_output=0
を /etc/sysctl.conf に追加し、sysctl で設定した。 >>535
おつです。
ぐぐってみると結構でてましたね。。。。＜icmplim
次の祭りはいつでしょうかね そのうちTV局に金渡して鯖飛ばし依頼とか出たりして hobby7にも、>>535 の設定を入れてみた。 Nov 19 13:14:09 <3.1> tiger503 savecore: reboot after panic: lockmgr: thread 0xc49b24b0, not exclusive lock holder 0xc3565640 unlocking
Nov 19 13:14:09 <3.5> tiger503 savecore: writing core to vmcore.2
だそうで。< ex7
vmcoreはちゃんととれてるっぽいんで、後で見てみます。
搭乗時間が迫ってるんで、とりあえずまた。
news18 news19 にも >>535 の設定を入れた。 >>540
(kgdb) where
#0 0xc0507ca2 in doadump ()
#1 0xc050829b in boot ()
#2 0xc05085c1 in panic ()
#3 0xc04fcd29 in lockmgr ()
#4 0xc0553b83 in vop_stdunlock ()
#5 0xc0553a33 in vop_defaultop ()
#6 0xc061dc67 in ufs_vnoperate ()
#7 0xc0616947 in ufs_inactive ()
#8 0xc061dc67 in ufs_vnoperate ()
#9 0xc055c2f0 in vrele ()
#10 0xc061a3cb in ufs_close ()
#11 0xc061dc67 in ufs_vnoperate ()
#12 0xc05666b0 in vn_close ()
#13 0xc05675a2 in vn_closefile ()
#14 0xc04ea014 in fdrop_locked ()
#15 0xc04e8e61 in fdrop ()
#16 0xc04e8e17 in closef ()
#17 0xc04e861f in fdfree ()
#18 0xc04f01c8 in exit1 ()
#19 0xc04efcf4 in sys_exit ()
#20 0xc066b9ff in syscall ()
#21 0xc06593af in Xint0x80_syscall () うーん、難しいなぁ。
mod_perl化って、言われているほど簡単じゃなさそうだ。 なるほど、mod_perlすると最初のディレクトリが / になるんか、、、。 悪戦苦闘中、、、。
ほとんどの障害はクリアできそうなんですが、
親元のcgi側で、
require "本体.cgi";
ってやって、
そっちで exit; ってやると(ごぞんじのようにbbs.cgiはそうやっている)、
[Sun Nov 21 10:17:31 2004] [error] ModPerl::Util::exit: (120000) exit was called at 本体.cgi line exitがある行Compilation failed in
require at 親元.cgi line requireの行.\n
ってなって、500 Internal Server Error になるです。
最近のmod_perlは、exit; を使ってもいいように改良されているのですが、
requireした先で exit するのは許してないのかも。
あるいは mod_perl そのもののバグなのかどっちなのかは、現在調査中です。 つまり、>>546 を簡単にいうと、
A.cgi
--------------
#! /usr/bin/perl
...
require "B.cgi";
--------------
B.cgi
--------------
exit;
--------------
ってのが、ちゃんとうごかんわけです。 個人的には、mod_perlのバグのような気がするなぁ。 いままでにクリアした障害:
1)SuExecと相性が悪い
UserとGroupをch2ex7/ch2に設定
2)カレントディレクトリがcgiを置いてあるディレクトリにならない
とりあえず明示的に最初のほうでchdir()する
3)bbs.cgi以外のcgiに影響をおよぼして欲しくない
<Files bbs.cgi>
</Files>
で囲む 試しに require をやめて、親元の下に本体をくっつけてみると、mod_perl配下でちゃんと動きました。
うーーーむ、、、。 exit;
を
Apache::exit;
にしてみるとか。 >>551
それはもうやったんすよ。
ちなみに、Apache2だからmod_perl2なんで、
Apache::exit; じゃなくて ModPerl::Util::exit; にしないとだめです。 で、結果は同じでした。
ちゃんとModPerl::Util::exitはexit;だけで呼ばれるみたい。 bbs.cgi をとりあえず動く状態 (>>550) にして少し動かし続けたところ、突然反応がなくなりました。
pingはかかる、、、。
メモリリークとかが起こった予感。 ex7はリブート要請しました。
みんなが何年もの間言っていたほど簡単には、mod_perl化はできないとわかった、、、。 いっそbbs.cgiを1から書き直すとか……。
誰がやるんだとか言う突っ込みはなしの方向で一つ。 俺も一から書き直したが早い気がする。
言い出しっぺの法則で>>558が（りゃ ここでテストしてましたが、mod_perl配下だとTZ環境変数もおかしくなるみたい。
鯖が不安定なんだけど
http://ex7.2ch.net/test/read.cgi/morningcoffee/1101034399/
少なくとも今日のところは、撤退せざるを得ないなと。
で、SuExecをやめたぶん、ほんのちょっぴりパフォーマンスがよくなったのかも。
これについては、要経過観察で。 今後やるとしても、まずは、基礎研究とじっくりとした調査が必要そうですね。
環境変数とか、動作の違いとか。
で、世の中の解説やWebにあるページとかを見ても、
mod_perlの2系(with Apache2)は、実はあまり多く解説されていないように見えます。
つまり、練りが足りないということがじゅうぶん考えられる。
もちろん、じっけん！じっけん！(AA略 して、
ここで練るというのもありですが、
そうするにしてもまずは事前準備をじっくりやって、勝ち目が出てきてからってことになるかなと。
ということで今日のところは、負け&撤退ということで。 寝る前に、試みた設定をダンプしておこう。
何か、設定に間違いがあったのかもしれない。
・mod_perlはportsからインストール(www/mod_perl2)
・httpd.conf
LoadModule perl_module libexec/apache2/mod_perl.so
<IfModule mod_perl.c>
PerlModule Apache2
</IfModule>
(略)
<Directory "/home/ch2ex7/public_html">
(略)
<IfModule mod_perl.c>
<Files bbs.cgi>
SetHandler perl-script
PerlResponseHandler ModPerl::PerlRun
PerlOptions +ParseHeaders
</Files>
</IfModule>
</Directory>
# 以下は動作確認の際のみ入れた設定
# mod_perl status
<IfModule mod_perl.c>
<Location /perl-status>
SetHandler perl-script
PerlResponseHandler Apache::Status
</Location>
</IfModule> これで、有効にした後でエラーなくカキコできたことは確認。(>>561 のスレの最後のほう2つ)
しかしその後、リモートログイン窓の反応なくなる。
リモードコンソールのlogin:も出なくなった(エコーバックはあった)
メモリがめいっぱいになった時と同様の動作であったため、
メモリリーク? が起こったのかもしれない。
ただしsyslogには、そのようなメッセージはなし。 <Files *.cgi>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
</Files>
Perlrequire "～/startup.pl"
===startup.pl================================
use Apache2 ();
use subs qw(exit);
*exit = \&ModPerl::Util::exit;
1;
============================================
#!/usr/local/bin/perl
use strict;
use warnings;
if (exists $ENV{MOD_PERL}) {
my $path = $ENV{SCRIPT_FILENAME};
$path =~ s|/[^/]*$||;
chdir($path);
}
>>565
自分の環境でやってみました。
>>546 なパターンのプログラムの場合、同じ結果ですね。
で、ModPerl::Util::exit に変えても同じ。
[error] ModPerl::Util::exit: (120000) exit was called at ./test2.cgi line 1Compilation failed in require at /home/hoge/public_html/test/mod_perl/mod_perl_test.cgi line 33.\n
つまり、requireした先でModPerl::Util::exit; は呼んではいけないらしい。 use Apache::compat; を startup.pl に入れてみたけど、結果は同じ。
この問題が解決できないと、メンテナンス性という意味でつらいかも。
ということで、とりあえずここまで。
しばらく本業します。 bbs.cgiをPerl5.8.5以降専用に大幅にリファクタリング。
mod_perl2でバグるところは書き方がしくじっている可能性が高い。 土曜の日テレの「ｷﾀｰ」と、
さっきのCXの「ドーン」を無事にクリアできたということは、
やはり >>535 が効果を発揮したのか。 21:00からのTVタックル@liveanbでどうなるか やっぱPerlのような物に拘るのはもう限界じゃない？
preg_hogehoge()も付いてるあれの方がまだ安全というか、なんというか。 >>571
ひ(ryがいぢれないものはだめなのでわ？ で、その夜○さんとやらはmod_perl2用のPerlが弄れるのか？ たぶん たぶん
2001年8月の２ちゃんねるの規模は、、、
現 tiger 2台とみた、 それは・・・（びっくり
そりゃあ色々変わっていくのが自然だよなぁとオモタ。 >>576
今一番働いているtiger = tiger503 = ex7の最大転送量が、
圧縮して14～15Mbpsぐらい。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/ex7traf.html
2台だと、圧縮して30Mbpsぐらいはさばけると。
この頃って、もう圧縮してた(mod_gzip)はずだから、
http://web.archive.org/web/20011127064159/http://www.yakin.cc/
tiger4台分ぐらいなんじゃないかしら。 てことはなにかい。
4 x (morningcoffee + news4vip + entrance + keiba + base) = 2001年8月の２ちゃんねる
っていうことなのか。 >>581
そっすね。
圧縮前の転送量ベースなら、ほぼぴったりか。 >>580
狼とVIPの書き込みの多さはただごとじゃないからのう
野球と競馬もROMが半端なく多いからのう つまり、圧縮して30Mbpsくらいだったのかぁ。
2001年8月の２ちゃんねる
= 2 x ex7鯖
= ex7鯖 + news18鯖 + news19鯖 x 2
= morningcoffee + news4vip + entrance + keiba + base + anime + mnewsplus + newsplus x 2
(trafiicinfoは各種データがmnewsplusの2%くらいなのではずした)
(ﾉ∀`)ｱﾁｬｰ もしかして、bbs.cgi内で開いたファイルで
明示的にcloseしてないのがあって
それがmod_perlで動作させようとしたときに影響してる、
なんてことはないですかね。
いや、mod_perlでexitした時の動作とか全然知らないし
メモリ不足が原因なら、全然関係ないんですが。 exitの代わりにreturnで戻すのはだめ？
常駐してんだから終了させんじゃなくapacheに戻してやる。
exitするとデータがクリアしたのに、他のプロセスで同じモジュールが動き続けて馬鹿になってゾンビが出る。
dieは？こいつも同じ原因を作る。 mod_perlからはとりあえず一時撤退するとして、
SpeedyCGIを使ってみるというのは、どうなんだろう。 Perl側を変えないとすると、こうかな。
# まだ入れてない。
LoadModule speedycgi_module libexec/apache2/mod_speedycgi.so
# まずは安全のため、機を見てコメントアウトとか数字を増やすとか
<IfModule mod_speedycgi.c>
MaxRuns 0
</IfModule>
# bbs.cgiだけSpeedyCGIにしてみる
<IfModule mod_speedycgi.c>
<Files bbs.cgi>
SetHandler speedycgi-script
</Files>
</IfModule> きたく。ねむい。
>>589は、明日昼間あたりに入れてみるか。 これは何がどうなってどうなると予想されるものなんですか?
現状の２ちゃんねるにおいての話しとして、 >>591
これが、一番まとまっていると思います(原文の翻訳かな)
http://perldoc.jp/docs/modules/CGI-SpeedyCGI-2.21/SpeedyCGI.pod
つまりうまくいけば、Perl CGIの実行パフォーマンスが数倍になると。
で、こいつはmod_perlよりお手軽で、
mod_perlほど元プログラムをいじらなくても導入できる見込みがあると。
かつ、suexecとも仲が悪くないらしいし、
root権限なくても動かせるというのも、魅力的すね。 mod_perlにしてもそうですが、
基本路線としては、c系(PHP)を高速化した路線と大同小異です。
つまり、毎回でっかいPerlインタプリタを起動するコストを下げたいと。 LA を下げるのに寄与するって考えればいいのかな?
処理が比較して短い時間で終るからどんどん捌けるという路線? てなわけで、
if 成功
bbs.cgi のすばらしい高速化が実現し、負荷耐性が上がるかもしれない
else
歓迎せざる、予期せぬ結果を招くかもしれない
endif
ということになります。
いろいろ調べていて、それなりに高速化の成功例も報告されているようなので、
まずは実験してみようかなと。 >>594
そですね。短い時間というか、
1つのbbs.cgi起動・実行をより少ない資源で済むようにすると。
仕込みはしてあるので、
万一「あっちゃー」が起こった時にリブートしていただけるんでしたら、
今やってもいいかなぁ、とか思っていたりして。して。 _ ∩
( ﾟ∀ﾟ)彡 じっけん！じっけん！
⊂彡 入れた。まずは、
<IfModule mod_speedycgi.c>
MaxRuns 0
</IfModule>
入り。 #<IfModule mod_speedycgi.c>
#MaxRuns 0
#</IfModule>
をコメントアウトした。 ひょっとすると、設定間違ってて、
bbs.cgiの1行目を直さないといけない、、のかも。 bbs.cgiの1行目を、
#!/usr/local/bin/speedy
に変更した。 >>606 はだめすね。
/usr/bin/perl に戻しました。
効いてない、、、。のかも。 うまく効いてないかな？
500 エラーになるすね。>>606 この状態でしばらく動かしてみるです。
>>608
LAは、この時間のex7だといつもこんなかんじすね。 つまり、LA=30とか50とかでは、どってことないってころです。< この時間のex7 >>606 の直後にどんどん上昇し始めて
>>607 の直後から元にもどり始めた
ということです。
mod_perl化のための一歩
・exit()をApache::exit()でオーバーライド
ですね。500エラーの原因をつかむ必要がありそう。 今Apache起動しなおしました。LAが一時的に上がるです。 ふむ、やはり500エラーになるですね。
(>>606を>>600入りでやってみた) [Thu Nov 25 07:14:22 2004] [error] [client 219.197.196.67] Premature end of script headers: bbs.cgi, referer: http://ex7.2ch.net/test/read.cgi/morningcoffee/1101308600/l50
って言うなぁ。< speedyに食わせると >>617
use CGI::Carp qw(fatalsToBrowser);
を入れると、エラーの実態が表示されるので参考になるかと。
ただし、その部分のソースコードも表示されるのでｺﾞﾆｮｺﾞﾆｮ >>621
とりあえず、正しいhttpdレスポンスを吐き出していないかと思いますです（苦笑）＞ぷりめちゃーなんたら #!/usr/bin/speedy -r10000
use strict;
use warnings;
use sigtrap;
... <IfModule mod_speedycgi.c>
<IfModule>
で囲んじゃ、だめとわかたです。
囲まなければ、1行目を変えなくてもspeedyで起動する(で、500エラー)。 MaxRuns 0
ではなくて、
SpeedyMaxRuns 0
だったとわかったです。
ちなみに上記でも500エラー。
あとは、500エラーの原因は何か、と。 んぢゃ、cp bbs.cgi ナンタラbbs.cgi で複製を作って、 use CGI::Carp qw(fatalsToBrowser); 入れちゃうとか(^-^;)
でもってそろそろ眠m(_ _)m で、さらに、
<IfModule mod_speedycgi.c>
ではなくて、
<IfModule mod_speedycgi2.c>
だとわかった。
あとは、500エラーの原因さえわかれば。 順番にやっていけばいいかと
前提：perlccによる実行形式を削除
1) １行目を変えるのみ＆MaxRunsを1にする（-- -r1）
2) MaxRunsを指定しない
3) mod_speedycgiを使ってみる 今の設定
LoadModule speedycgi_module libexec/apache2/mod_speedycgi.so
<IfModule mod_speedycgi2.c>
SpeedyMaxRuns 1
</IfModule>
で、
<IfModule mod_speedycgi2.c>
<Files bbs.cgi>
SetHandler speedycgi-script
</Files>
</IfModule>
に設定。
これで、元bbs.cgiをいじることなく、bbs.cgiだけspeedycgi配下に。 うそみたいに軽くなった。
これで、しばらくようすをみてみよう。 でもこれだと、毎回起動はしてる、、、だよなぁ、たぶん。
どのくらい効果があるかは、しばらく観察ということで、
ごはんたべてきます。
从o＾ー＾从御飯喰
http://ex7.2ch.net/test/read.cgi/morningcoffee/1101210350/ たとえ-r1だとしても、バイトコンパイルのキャッシュが効くとか？ もしかして$ENV{'QUERY_STRING'}でパラメータを渡しているところが初期化ルーチンの最初だけとかじゃ無い？
環境変数を渡すタイミングが初期化時だけだとハマりどころかも。 あとexit前に
%Hoge = ();
みたいな感じで消去しとかないと-r1じゃないと動かないスクリプトになるという肝。 >>638-639
たぶん、備後の予感。
しかしわたしわ、Perlかけないし。 speedy_backendのゴミプロセスが残っていたようなので、それらをkillして、
SpeedyTimeout 60
を追加して、httpdを立ち上げなおした。 emの問題の続き
stable(RELENG_5)には、対応するするbugfix入りました。
Tue Nov 23 22:28:40 2004 UTC (2 days, 5 hours ago) by rwatson
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/em/if_em.c?rev=1.44.2.4&content-type=text/x-cvsweb-markup
今度の RELENG_5_3 candidate は反映されるのかな。 >>632 の設定する場合、
いうまでもなく、SuExecをやめないとだめでした。
つまり、
User ch2live16
Group ch2
とかにしないとだめ。
# いきなり(たぶん)ファイルロックかからなくって、ぐわわと重くなり、リブート、、、。 で、1行目を変える方法(#!/usr/bin/perl → #!/usr/local/bin/speedy -- -r1 -t60)なら、
SuExec配下になるので、従来どおりで問題ないと。 あ、もちろんその場合は、
#SuexecUserGroup ch2live16 ch2
は、上記のようにコメントアウトで。 ex7見ると、、、。
56485 ch2ex7 131 0 4320K 3680K RUN 0 69:32 68.70% 68.70% speedy_back
96829 ch2ex7 131 0 4316K 3680K RUN 2 184:26 67.48% 67.48% speedy_back
59449 ch2ex7 131 0 4320K 3684K RUN 0 64:19 66.99% 66.99% speedy_back
なんか、ぼそってるすね。例のbbs.cgiぼそり現象がそのままきてるのか。
うーん。
そっか、RLimitCPUとか、moduleにすると効かなくなるのね。
Apache側でlimitかけてやらんと、だめなわけね。
設定しよう。
しかし、実際に動かしてみないと、わからんことばかり。 apache2limits_enable="YES"
apache2limits_args="-e -t 60"
を/etc/rc.confに入れて、Apache再起動でいいのかな。
とりあえず、ex7にて。 >>650 を ex7 live16 live17 に入れた。 やっぱ、ぼそるすね。
16551 ch2ex7 127 0 4320K 3688K CPU2 1 9:37 96.14% 96.14% speedy_back
しかたないすね、、、。/etc/login.conf をいじろう。 >>653
だめすね。login(1) でしか参照しないのか。 /etc/login.confに、
# for limiting www user
www:\
<TAB>:cputime=60:\
<TAB>:tc=default:
を足して、
cap_mkdb /etc/login.conf
を実行し、
apache2limits_enable="YES"
apache2limits_args="-e -C www"
を/etc/rc.confに設定して、apacheをrestartした。 うーむ。>>655 でも再発。
で、/etc/master.passwd のクラスのところに www と書いてもだめ。
さて、どうすべか。 rc.confとかって再起動しないと有効にならないとか？ portsからapahce2を入れていれば
/usr/local/etc/rc.d/apache2.shを読めばわかるが、
上記スクリプトapahce2.shからrc.confを舐めることになっている。
PORTNAME= apache
PORTVERSION= 2.0.52
PORTREVISION= 3 リミッターが効かないことでex7の怪我が大きくなったので、
リミッターが効く方法(CGI経由での呼び出し)にスイッチ。
具体的には、ex7のbbs.cgiの1行目を、
#!/usr/bin/perl
から、
#!/usr/local/bin/speedy -- -r1 -t60
に変更。 live16/live17 も >>659 と同様の変更を実施。 live8は、SuExecをやめる工事だけ実施。
bbs.cgiは、perlccもの。 tiger503 ex7 済み
tiger504 game10 済み
tiger505 news18 済み
tiger506 game9 済み
tiger507 live16 済み
tiger508 live17 済み
tiger509 news19 済み
tiger510 hobby7 済み
というわけで、掲示板のあるtigerはすべてバージョンアップ完了しました。
あとはぼちぼち、blackgoatをやるかな。
すいてる時間にかたっぽずつやれば、たぶんサービス止めないでいけるかと。 ex7 の様子を見る限りでは、>>659-660 の方法でも、それなりに効果あるのかも。
今日はちょっと夜11時前に事件があったんで、明日にはわかるのかなと。 いいお湯でしたか！少しは疲れがとれましたか？
いつもお疲れ様です。
孤独な作業、そして皆が2ちゃんを気持ち良く利用できるように日々努力していただき、ありがとうございます。
がんばってください。
何も出来ないけど、応援しています。 >>665
>>664は、root▲ ★さんへの励ましでした。誤解させてすみません。 >>665
でも、FOX ★さんのあちらこちらでの縦横無尽のご活躍も凄いって思っています。
無理なさらないでください。
皆さんのこうした努力があって、この2ちゃんが快適に楽しめるんですね。
ありがとうございます。 FOXさんは、私の何倍も、何十倍も、すごい人ですから。（す） >>672 root▲ ★さん
そうなんですか、知りませんでした。
それと、大切な専用メモを荒らしちゃったみたいですみません。
黙って見ています。ありがとうございました。 root▲さんの俺様メモを見ていると昔EWSの管理者だった頃の事を思い出す。。。
campas noteを何冊埋めたことか・・・ ここをROMってlogとって、経過を読むと実地の鯖運用記録として使えます。
本にならないかなぁ。
FOX＆root▲ ★の、動け動けウゴウゴServer構築運営管理ガイド。
萌え萌えUnixネットワーク管理ガイド風に、お二方をキャラ化して、David氏が黒いメガネ…
>>675
(･∀･)ｲｲ!
おもしろそ。実現ｷﾎﾞﾝﾇ >>676
ダメダメ
ここで実現ｷﾎﾞﾝﾇなんて言ってもダメだ
実装ｷﾎﾞﾝﾇ rootくんが2chの鯖管理で培って来た技術を本にして皆に広めてもらいたい
1年毎くらいで毎年発行とかで >>678
今まで2ch本なんか買わなかったけど、この本なら多少高くても買うぜ！
3000円ぐらいでお願い。
形式は電車男みたいな感じにすれば、校正の手間とかも掛からないのでは。 なんで買ってもないのに、電車男の形式という発言が出てくるんだ？ ほとんどそのまま、まとめサイトをそのまま紙面に移しただけ、
ですもんね。＞電車男 いや、それは知っていたけど、実物見ずに発言したということか。
スレ汚しすまそですた。 こいつあやしいなっていう解説本が出るかもしれないし、
出ないかもしれないってだけのことだろ。 >>682
ネットでただで手に入るがインストールCDも売っているFreeBSDと同じなわけかw 厳密には、ネットだと通信費かかるけどな～。
今は定額制が主流になってきたので、あまり意識しなくなったけど。 本すか。
流れのままに、って感じすかね。
何らかの方法で何かを残したいな、とは思ったりするです。
しかし、実際に出すとなるとなかなか大変だったり。
# ジャパンカップダート @ ex7は微風だった模様。 すべてのtigerサーバに、
ex7/live16/live17と同じ呪文を入れた。
・SuExecを無効化し、直接ch2XXXXユーザでhttpdを起動 => CGI起動を少しでも軽く
・bbs.cgiをSpeedyCGI化 現状のまとめ
cobra (oyster901 = live8)
・SuExecなし、httpdを掲示板オーナのUIDで直接起動
・perlcc版bbs.cgi
・httpd数896
・httpdはアイドル時も全数待機
tiger (tiger503 - tiger510 = ex7 game10 news18 game9 live16 live17 news19 hobby7)
・SuExecなし、httpdを掲示板オーナのUIDで直接起動
・SpeedyCGI版bbs.cgi
・SpeedyCGIは#!/usr/local/bin/speedy -- -r1 -t60 で起動
・httpd数784
・httpdはアイドル時も全数待機 質問です
1) SpeedyCGIはPerlを高速化するものですか?
2) bbs.cgi or bbs.cgi がrequire しているファイルが更新されたとき
何かしなければいけませんか? 1)Perlのプロセス起動をへらすので結果的に
2)再読み込みが必要なのでapachectl graceful >>691
ちと長くなるので、別々に答えます。
まず結論から。
1) Yes
動作原理は後述します。
2) 現在の2chの運用形態なら、bbs.cgiの配布・保守形態は現在のままでよい
2-1)親bbs.cgiがrequireしているファイル、
例えばbbs.cgi主処理部(頻繁に変更される方)が
更新された場合は、特に何もする必要はありません。
なぜかというと、現在の２ちゃんねるでのSpeedyCGIの運用形態が
「バックエンドエンジン毎回起動モード(-r1)」だからです。
理由は後述します。
2-2)親bbs.cgiそのものが更新された場合は、>>659にあるように、
bbs.cgiの1行目を#!/usr/bin/perlから
#!/usr/local/bin/speedy -- -r1 -t60に変更する必要があります。
ただし、急いで変更しなくてもSpeedyCGIのパフォーマンスにならないだけで、
従来のPerlのパフォーマンスで動き続けるため、運用にすぐに支障が出るわけではありません。
現状、親bbs.cgiにはめったに更新がかからないため、
親bbs.cgiに変更がかかったのを私が知ったら、その都度作業するというポリシーで、
当面はいけると考えています。
# というか、想定質問っす(w。
## 後述は、めしくってから書きます。
ちなみに、bbs.cgi主処理部が更新された場合に
ちゃんとそれが即座に反映されることは、実地に確認してありますです。はい。 bbs.cgi がこれによってかなり美味い具合になってきたとすると、
もう一つほとんど更新されないcgiがあるわけですが、
そっちはどのような方針がいいんですかね?
1) Perl にして同様にSpeedy化する。
2) C のまま、Apache のモジュール化する。
2) の方が効果があると思ってはいますが、
実は 1) でも 2) の90% くらいの効果が望めるので 2) にするとか?
read.cgi ですが、
今既にCで書いてあるもので、かつコンパクトなプログラムなので、
私は 2) がよいと考えていますです。
めざす方向は、mod_readがいいなと。
1)にして効果を上げる(SpeedyCGIの本来のパワーを発揮させる)ためには、
それなりにきちんと(Per作法l的に)プログラミングする必要があるようです。
今のbbs.cgiはいわば「SpeedyCGIを使ううまみの1割も使っていない」状況です。
それも、あわせて後述を。 んじゃ 若さの暴走ということで
mod_read に挑戦してみますかー
と、 以下はにわか勉強なので、間違い・不足な点はご指摘いただけるとたすかります ]
・SpeedyCGIの動作原理
SpeedyCGIは、フロントエンド部とバックエンドエンジンに分かれています。
フロントエンドは、ApacheモジュールまたはCGIプログラム(/usr/local/bin/speedy)として呼ばれます。
フロントエンドはバックエンドエンジンがいなければ起動し、Perlプログラムをプロセス間通信で
バックエンドエンジンに渡します。
バックエンドエンジンはPerlプログラムを＊実行前に＊コンパイルし、できた中間コードをメモリ上に展開し、
それを実行します。
つまり、Perlをインタプリタで実行せず、コンパイル後のバイナリを実行するようになるため、
その分実行が高速になります(効果1)。
その後、デフォルトではバックエンドエンジン側の処理が終わっても、
コンパイル後のバイナリコードは開放されることなくバックエンドプロセスのメモリ上に残り、
次に同じプログラムのリクエストをフロントエンドから受けた場合、
cgiプログラムが更新されていなければ
(ここで本体cgiの時間をチェックし、更新されていれば自動的に再読み込み&再コンパイル)、
同じバイナリコードを、そのまま再利用します。
つまりデフォルトでは、2回目以降はバックエンドエンジンの再起動なし、
再コンパイルなしでそのままバイナリコードが動きます。
ということで、動作がとても高速になります(効果2)。
しかし、この場合Perl側でコードの再利用(主に変数関連)を考慮した、
行儀の良いコードを書く必要があるため、
場合によっては、Perlプログラム側を行儀の良い形に書き直す必要が出てきます。
で、bbs.cgiは残念ながらこれに該当したため、デフォルトの状態では動かなかった。
(続く) (続き)
これを避けるために、SpeedyCGIのオプションとして、
バックエンドエンジンの再起動インターバルを指定することができるようになっています。
これが、#!/usr/local/bin/speedy -- -r1 -t60 の -r1 のところです。
ここで1を指定してあるため、1回ごと(つまりフロントエンドが起動されるたびに、毎回)、
バックエンドエンジンを起動しなおすことになります。
つまり、上記の(効果2)を捨てることになるわけです。 といったところが、SpeedyCGIの私の理解です。
で、量産型bananaにもSpeedyCGIを入れていただけると、
全部のマシンのbbs.cgiを
#!/usr/local/bin/speedy -- -r1 -t60
にできるので、bbs.cgiの管理が楽になったりするです。
>>697
おおっっ。 なお、デフォルトのモードの場合、requireしているほうの子供Perlプログラムが更新された場合には、
自動的には更新を検知できないため、
その場合には >>692 にあるようにApacheをリセットするか、
親cgiをtouchする必要があります。
# ２ちゃんねるの場合「毎回起動モード」なので、たまたましなくてもいいと。 >>701
ですよ(ο･д･)(･д･`ο)ﾈｰ
bbs.cgiを、具体的にはどう改良すればいいんだろうか。
>>638-639 あたりが答えの一部? >>704
てなわけで、今日はなんだか記念日みたいです。 bbs.cgi の speedy化の効果２をねらう改造の為に
サブドメインが必要な気がしまーす
read.cgi も一緒にやるか、
やっぱ明日、tiger に一個サブドメイン増やそうぜ >>706
了解です。
今日は、いい気分で寝られそうな気がするですよ。 電子雑誌だったらできそうな悪寒＞ここのスレのログっぽいの ＞697 ：FOX ★ sage ：04/11/29 01:00:06 ID:???
＞んじゃ 若さの暴走ということで
＞mod_read に挑戦してみますかー
↑これ、笑うところ？ 質問・雑談スレ81＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1101642955/79-82 を前に、
live8 の bbs.cgi を perlcc 版から SpeedyCGI 版に変えてみた。
昨日の座頭市の時のLAの上がり方から考えて、
毎回起動モードでも、SpeedyCGIの方がいい気がするんで。 live8 だけ、read.cgi の時も KeepAlive を有効にした。
今の設定:
#
# Thank you for http://qb5.2ch.net/test/read.cgi/operate/1093068260/391-393
#
SetEnvIf Request_URI ^/test/bbs\.cgi nokeepalive
SetEnvIf Request_URI ^/test/subbbs\.cgi nokeepalive
#SetEnvIf Request_URI ^/test/read\.cgi nokeepalive <= ここをコメントアウト ついでに鯖争奪戦論争も電子ブック化して（ry
サブタイトル募集ちう サーバ争奪戦は04/08/15（tiger509,510）からはやってないですな 争奪戦なんかちゃねらーの一部しか読まないだろ・・・ >>659 SpeedyCGI導入以降のex7のLAのようす:
http://mumumu.mu/mrtglog/2004/11/30/load/ex7load.html
WeeklyとMonthlyを見る限り、効果はかなりあるみたい。 >>719 金曜日深夜域を見ると一目瞭然で砂。
勝ち組宣言楽しみにしてます(素 bbs.cgi改造するなら、そろそろ古い機能はとっぱらっても良いような。
>>の数チェックとかはもういらないような。 むしろ、>>nnでリンクする機能を、.datに直接書き込むのではなく
read.cgi/r.i及び、bbs.cgiでhtml/*.htmlを作成時に変更したら良いのでは。
以前実際の各種板の全.datから計算したら、
通常の板でおよそ10%程度、AA系の板で3%程度、.datのサイズが小さくなるはず。
実況系はその間くらいかな。
専用ブラウザの対応は問題ないはず。
というのは、外部実況板などで>>nnのリンクは.datに入ってないところも多々あるから。 少しでもdatを小さくしようと、あえて>を１個にしてる人もいるよね。
2chブラウザなら全く問題ないし。
# 2chブラウザへの移行を促す効果も（Webブラウザだと不便に）
# いわゆるh抜きも同様の効果があるかな、と。 >>724
最小は＞724らしい。
>は実体参照に書き換えられて格納されるとか。
流れ的にスレ違いだぞ
read.cgiかbbs.cgiのスレでやれ >>724
＞# 2chブラウザへの移行を促す効果も（Webブラウザだと不便に）
＞# いわゆるh抜きも同様の効果があるかな、と。
ここにレスするのも何だけど、そういうのはProxomitronで簡単にフォローできるから
初心者以外は促せないかなぁ… cgiの開発･実験用のバーチャルホストですが、さてどこに作りますかね。
特に問題なければ、game9 = tiger506 あたりにしようかなと。
名前は dso.2ch.net でいいのかな。 では作業行ってきます。
出来次第、儀式→掲示板システム入れ込みへと。 すんませーん、SpeedyCGIを入れたところはLoad Averageが低くなるけど、
LAがサーバーの実際の負荷と比べて恐ろしく低く表示されるから、
LAが低くても安心できないって事ですか？ >>733
書き込み(bbs.cgi起動)の同時起動が抑制されるので、負荷が低くなる、ってことです。
つまり、bbs.cgiを産児制限することになるから、本当に負荷が低くなると。
# 特にlive系などは、負荷の8割が書き込みだと思われ。
つまり、システム的には落ちなくなるけど、
もう少し書き込みパフォーマンスが出せるようにしたいなと。 では、儀式行きます。
+dso.2ch.net:206.223.152.30
を、DNSに追加お願いします。 これから、mod_cgidsoを入れる工事に入ります。
(DNSには登録いただいてOKです) UA が上がりっぱなしの時はどうすればいいのか・・・ >>736 の仕込み終わりました。
dsoのユーザのread.cgiと.so拡張子が、DSOの対象となります。
SpeedyCGIは既に導入済み。 dso.2ch.net に板を作るべくいろいろ転送中。。。 直ったはず。
同一ホストに2個以上バーチャルホストを切ると、
UIDの都合によりそのままではSuExecなしにはできないみたい。
ということで、game9もSuExecありにしました(運用上は問題ないです)。 >>747
こっちは、SuExecじゃないモード(httpdのオーナー)で動きますんで。 というかこれで、i386/amd64の両方で動くことが確認できたと。
まずはめでたいです。>>747 -M32は結局流れを阻害するので、やめ。
-b1048576 (CGIからのPOSTの時のバッファをデフォルトの8倍にする)したら、ex7がとっても好調に。
しばらく見て調子いいようなら、これにしてみよう。
ただしlive8の変更は、本日が落ち着いてから。 SpeedyCGI環境では、ある「壁」までは、割と軽く動くみたい。
その壁にぶち当たると、だめと。 今のhttpdの並列数は、768～896あたりがせいぜい。
1024だともう苦しくて、それより大きいと「どーん」に耐えられないと。
大きくしても、bbs.cgiが詰まるだけ。 りょうかいですー
read.cgi(DSO味) の実験は live8 に触らなくてもよくなってからにします、
来年にでもまた、 >>765
そですね。
live8のbbs.cgiは今の(8.01+)でいきますか。
で、仕込みをdso.2ch.netでしっかりやる方向で。 915 名前：root▲ ★[sage] 投稿日：04/12/01 23:15:49 ID:???
ex7は、httpdの並列数を896に戻した。
これ以上増やすと(少なくとも1280とかにすると)、
bbs.cgi(speedy_backend)が増殖しまくって、さっきみたいに結局意識不明に。
ex7も、入れたら768に戻しておこう。
カキコ遅くても、今のままだとこれ以上は、無理な模様。
>>767
おっ。見てみるか。 いきなり
> お粗末なプログラミングで、お粗末なパフォーマンス
きびしいのう。
といってもこれは、私だけで何とかできる問題でもないわけで。
dsoのbbs.cgiスレに期待しよう。 ざっと読むと、泣けるなぁ。書いてあることはわかります。
直感ですが、とっても、該当しているような気が。
dsoのbbs.cgiスレかここのbbs.cgiスレあたりで、話題振ってみていただけると。 さて、
・httpd起動数はもうこれ以上は増やせない (tiger: 768, cobra: 896)。
・「スロットいっぱい」「bbs.cgi詰まり」が観測された。
kqueueステータスだったので、DNSまわりの結果待ちな予感。
=> DNSサーバの再チューニングが必要か。
=> 特にBBS/BBQ/DNSキャッシュサーバ。
・mod_cgidsoは、パフォーマンスを確実に底上げしている。
read.cgiは、この路線で進むのが当面、正解と思われる。
・やっぱりbbs.cgi、こいつを何とかしなきゃ。
他に何があるかな。 BBQは(少なくともDNS側は)、変じゃなかったのか。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/bbqbbx/bbq.html
BBQはCobra(oyster243)だからなぁ。 BBSのDNS側ログをチェック中。
明らかにBBSシステムのDNS側、変でしたね。
この間、ひとつも処理できていない。
(時間はPST)
2004-12-01 05:06:03.757482500 cedf94fa:201d:2913 + 0001 1101906363.4977.60.40.234.32.0.40.1092895397.loveho.sakura02.bbspink.com.bbs.bbs.2ch.net
2004-12-01 05:45:57.994422500 cedf9837:c3f7:d610 + 0001 1101906363.66646.220.102.118.141.0.19.1101897431.dancesite.live17.2ch.net.bbs.bbs.2ch.net
日付変わったら、live8のbbs.cgiを他と同じものにしよう。 >>771
で、「スロットいっぱい」は、「bbs.cgi詰まり」により、惹起された模様です。
つまり、BBS処理がふんづまりになることによってbbs.cgiが滞り、
それによって詰まってしまった。
BBQは詰まっても大丈夫なように若者が対応したはずだけど(実験もした)、
BBSはどうなんだろう。 banana238 = BBS/BBY/BBX のdjbdnsを強化版(make WITH_PERSISTENT_MMAP=yes)に更新した。
おかしかったら、指摘よろしくです。 oyster243 = BBQ(niku) のdjbdnsも、強化版に更新。 cobra2245 = BBM のdjbdnsを同様に更新。
これで、更新はひととおりできたはず。
BBSがbananaではもたない、、、ということは、あるのか、ないのか。 さて、めし、くってくるです。腹が減ってはなんとやら。
落ち着いたらもいっかい今日いじった掲示板cobra/tigerサーバ群の設定を見直しておこう。
設定もれとかがあると、いまいち。 >>781
ふむ。わたしもそう思っています。< BBS
BBQがbananaではもたなかったのは、DBがでっかかったから(これは明確)。
今のBBSはDBを持ってないので(データがないことしか返していない)ので、
もちろん、もつはずという前提です。
その前提で、サービスが停止した原因を考える必要があるとおもわれ。
# めしめし。 ちなみに今のBBQデータ。でかっ。
%ls -l data
-rw-r--r-- 1 ch2bbq ch2 73286705 Dec 1 07:20 data
%wc -l data
5158061 data BBQ/dnscacheのログ
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/bbqtraf.html
該当時間、INが少ないですね。
つまり、一般の軽かったサーバも含めて、
問い合わせがDNSキャッシュに十分に行っていなかった、ってことなのか。
BBSのぶんがなかった、というのと一致するわけか。
さて、理由は。 bbs.cgi での各処理の順番はどうだったかな、、
BBQ -> BBX -> BBS -> BBY だったかな >>777
>BBQは詰まっても大丈夫なように若者が対応したはずだけど(実験もした)、
>BBSはどうなんだろう。
ここでのお題目は、その「つまり」を起こさないことかな。
起った場合の逃げコードはサザン ★君が暇になったら
ぼちぼちやってもらうという事にして、
BBQ -> BBX -> (BBY) -> BBS だった。
Load Average @ stats.2ch.net
2004/12/01 21:00:00 LA= 9:00PM up 186 days, 22:19, 0 users, load averages: 0.00, 0.06, 0.11
2004/12/01 21:10:00 LA= 9:10PM up 186 days, 22:29, 0 users, load averages: 0.08, 0.10, 0.08
2004/12/01 21:20:00 LA= 9:20PM up 186 days, 22:39, 0 users, load averages: 0.20, 0.18, 0.12
2004/12/01 21:30:00 LA= 9:30PM up 186 days, 22:49, 0 users, load averages: 0.06, 0.12, 0.11
2004/12/01 21:40:00 LA= 9:40PM up 186 days, 22:59, 0 users, load averages: 0.17, 0.10, 0.08
2004/12/01 21:50:00 LA= 9:50PM up 186 days, 23:09, 0 users, load averages: 0.25, 0.15, 0.10
2004/12/01 22:00:00 LA=10:00PM up 186 days, 23:19, 0 users, load averages: 0.06, 0.12, 0.10
2004/12/01 22:10:00 LA=10:10PM up 186 days, 23:29, 0 users, load averages: 0.07, 0.10, 0.08
2004/12/01 22:20:00 LA=10:20PM up 186 days, 23:39, 0 users, load averages: 0.05, 0.11, 0.08
2004/12/01 22:30:00 LA=10:30PM up 186 days, 23:49, 0 users, load averages: 0.02, 0.05, 0.06
2004/12/01 22:40:00 LA=10:40PM up 186 days, 23:59, 0 users, load averages: 0.04, 0.09, 0.08
2004/12/01 22:50:00 LA=10:50PM up 187 days, 9 mins, 0 users, load averages: 0.29, 0.32, 0.20
LA 見る限りは、特に負荷が上昇しちまったようには見えず、 上がるとしたら、負荷じゃないですね。
BBQがだめぽになった時も、LAがあがらなかったです。
プロセスが増えるわけじゃないから。
BBQの時はI/Oがつらくなって、処理がふんづまりました。
LAは低いままで、DNS問い合わせに答えられなくなったと記憶。
てなわけで、今送信側(news18とかnews19)のDNS問い合わせログをチェック中。 1行目の「負荷」は、LAと読み換えてくださいです。>>791 ということは、
DNS問い合わせのたびに呼ばれるプログラムは特に問題ないということかな?
どんどん呼ばれてもどんどんはけて行く or 一個しか起動しない。 >>793
そっち側が変になっても、DNS側がブロックしないように組んであるはずです。
# いちおう、確認してみます。 >>778 の順番に処理しているんで
呼ばれる回数は BBQ > BBS ( >>> BBX >>>>>>>>>> BBY) です
news18の問い合わせログを見ました。
2004-12-01 05:06:06.098103500 tx 0 1 1101906365.98088.0.0.0.0.0.57.1101628087.anime.news18.2ch.net.bbs.bbs.2ch.net.maido3.com. maido3.com. cedf93fe cedf94fe
2004-12-01 05:06:06.102803500 nxdomain cedf93fe 2560 1101906365.98088.0.0.0.0.0.57.1101628087.anime.news18.2ch.net.bbs.bbs.2ch.net.maido3.com.
これは「ないよ(nxdomain)」の応答があるのに、
2004-12-01 05:06:13.843026500 query 2292275 7f000001:4d75:fe65 1 1101906373.98241.0.0.0.0.0.94.1101743825.mnewsplus.news18.2ch.net.bbs.bbs.2ch.net.
この問い合わせに対する、BBSのDNS側からの応答(nxdomain行)がありません。
で、このあと、BBSについてその状態がずっと続く。
つまり、
・問い合わせ側システムは正常
・でも、BBSのDNS側からの返事がなかった
ということになります。
同じサーバ(banana238)で動かしている別のDNS(BBX/BBY)は、
該当時間、どうだったのかな。 訂正
>>788 の順番に処理しているんで
呼ばれる回数は BBQ > BBS ( >>> BBX >>>>>>>>>> BBY) です
>>796
BBXとBBYはその時間無事動いていたことを確認しました。
また、BBQも同様に確認しました。
おかしかったのは、BBSだけか。 んんん?
それはいったいどういうことじゃ?
なぞだ、 しかも、live8やex7が変だった時間と、一致するような予感。
というよりひょっとすると、BBSが変になったことで、live8やex7もつられて落ちた、
というのが、正しいような気もする。 ちなみに
BBS呼び出し側(bbs.cgi)には、タイムアウトを検出する処理はいってます
マツケンサンバが始まったのが22:05:00 ころですね。
その直後にlive8は落ちました。ex7はもうちょっとあとかも。
>>800
その可能性は、なんかあるかも、、
BBSが動いてない時間に、どの鯖でもbbs.cgiが微妙に動作が遅かったですね、、 入ってましたか。つまりブロックは数秒(何秒でしたっけ)ですむと。
つまり、他のサーバは「あれ？」ぐらいで、済むわけか。
「数秒のブロック」が雪ダルマ式に影響が出るのは、
その時カキコが激しかったサーバということだとすると、
ex7とlive8だけ壊滅するのは、ありうることかも。
live8とex7のシステムログを、緻密にあたってみます。 >>802
とすると、、、。
ex7/live8からものすごいDNSアクセスがBBS側のDNSに来て、
BBS側が不調になり、
bbs.cgiの滞留が起こりはじめ、
それが顕著に起こったex7/live8が、ブロックプロセス過多で壊滅した
というシナリオは、ありうるわけだ。 その部分のコード
{
my $BYTES = length($FORM{'MESSAGE'});
my $BHOST = "$NOWTIME.$$.$ENV{'REMOTE_ADDR'}.$NEWTHREAD.$BYTES.$FORM{'key'}.$FORM{'bbs'}.$ENV{'SERVER_NAME'}.bbs.bbs.2ch.net";
eval{
alarm(3);
my $YACHO = gethostbyname($BHOST);
alarm(0);
};
alarm(0);
if($@ =~ /timeout/){
last;
}
} ちゃんと動いていると思うんですが
BBS だけ止めてみるなんてこと出来ますか? タイムアウト処理が正しく動いているか検証してみよう。 時間決めて、しばらく止めてみろということですか。
では、1:45から2分、BBSだけ止めてみます。 書き込みが多いサーバ(ex7)の様子をチェックしてきます。
まだ、BBSは止めています。 ですね、
これと同じことが当該時間帯に別のサーバで起ったという記憶があります すごいことになってる。
LA上がってないけど、ブロックばかり。
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
631 dnscache 98 0 32868K 32172K select 0 104:59 5.81% 5.81% dnscache
11196 ch2ex7 4 0 7112K 6336K kqread 2 0:01 5.08% 2.00% speedy_back
11051 ch2ex7 4 0 7092K 6320K kqread 0 0:00 3.24% 1.86% speedy_back
11045 ch2ex7 4 0 7080K 6376K kqread 0 0:00 3.15% 1.81% speedy_back
11037 ch2ex7 4 0 7088K 6316K kqread 0 0:00 2.96% 1.76% speedy_back
11301 ch2ex7 4 0 7096K 6324K kqread 0 0:00 12.26% 1.71% speedy_back
11330 ch2ex7 4 0 7068K 6304K kqread 3 0:00 35.00% 1.71% speedy_back
11302 ch2ex7 4 0 7092K 6320K kqread 2 0:00 11.56% 1.61% speedy_back
11310 ch2ex7 4 0 7088K 6320K kqread 1 0:00 11.56% 1.61% speedy_back
11041 ch2ex7 4 0 7092K 6320K kqread 0 0:00 2.71% 1.61% speedy_back
11043 ch2ex7 4 0 7092K 6320K kqread 0 0:00 2.71% 1.61% speedy_back
11046 ch2ex7 4 0 7060K 6292K kqread 0 0:00 2.81% 1.61% speedy_back
11263 ch2ex7 4 0 7100K 6316K kqread 3 0:00 6.02% 1.56% speedy_back
11319 ch2ex7 4 0 7060K 6292K kqread 0 0:00 15.89% 1.51% speedy_back
11253 ch2ex7 4 0 7068K 6300K kqread 0 0:00 5.65% 1.46% speedy_back
11039 ch2ex7 4 0 7092K 6320K kqread 0 0:00 2.47% 1.46% speedy_back
11316 ch2ex7 4 0 7092K 6320K kqread 0 0:00 10.50% 1.46% speedy_back
11296 ch2ex7 4 0 7092K 6324K kqread 3 0:00 7.53% 1.37% speedy_back
11292 ch2ex7 4 0 7096K 6324K kqread 0 0:00 7.26% 1.32% speedy_back
11067 ch2ex7 4 0 7064K 6296K kqread 1 0:00 2.30% 1.27% speedy_back
11217 ch2ex7 4 0 7064K 6296K kqread 0 0:00 3.50% 1.27% speedy_back
11062 ch2ex7 4 0 7064K 6360K kqread 2 0:00 2.22% 1.27% speedy_back
11305 ch2ex7 4 0 7092K 6320K kqread 0 0:00 9.10% 1.27% speedy_back
11073 ch2ex7 4 0 7080K 6312K kqread 1 0:00 2.22% 1.22% speedy_back
11247 ch2ex7 4 0 7060K 6296K kqread 2 0:00 4.13% 1.22% speedy_back
11171 ch2ex7 4 0 7080K 6316K kqread 1 0:00 2.65% 1.12% speedy_back
11152 ch2ex7 4 0 7080K 6380K kqread 3 0:00 2.49% 1.12% speedy_back なんか重いと思ったらまた遊んでやがんなｗ
ま、原因がわかったらはよ直してね BBSあげました。
ex7のブロックは解消しました。 体感では、さきほどBBSが止まってた時と
ほとんど同じくらい(2～3秒)の引っかかり感がありますね。 BBSの戻りは一切チェックしなくてもいいので、
bbs.cgi側のディレイを「なし」にできると、うれしいかも。 alarm(3);
を
alarm(0); とかにすればいいのか?
それとも alarm(1); が最小なのか?
＞ 指定した秒数(実際は 1 を引いたもの)が経過した後、 SIGALRM をプロセスに伝える。
＞ つまり、 `alarm(15)' はそれから 14 秒以上経ったある時点で SIGALRM を起こす。
らしいので、alarm(1); でディレイ0になるんじゃないかな。 あ、そういえば、
bbs.cgi 配布サイトに、live16 と live17 も加えておいてくださいです。
これらは FreeBSD 5.3R への更新に伴い、
perlcc バージョンの使用をやめました。
今後も、perlccバージョンにする予定は当面ないです。
live8 もさきほど perlcc をやめましたが、
私の判断で、perlcc版とスイッチするかもしれないので、
当面従来どおり配布ホストには、入れなくてよいです。 alarm(1);のbbs.cgi に全サーバ置き換えた
>>823
live16,live17 りょうかいです bbsにはあいかわらず、query来ています。
このカキコの後で、BBSを再度止めてみます。 ちょっと引っかかる感じはありますが、さっきよりいい感じですね。 live16 , 17 も元々配られているようです >>829
了解です。
ex7の様子を確認してきます。 ブロックは、してるみたい。< ex7
631 dnscache 97 0 32868K 32172K select 1 105:17 6.10% 6.10% dnscache
25373 ch2ex7 4 0 7072K 6280K kqread 0 0:01 14.80% 2.69% speedy_back
25418 ch2ex7 4 0 7068K 6308K kqread 2 0:00 21.01% 2.00% speedy_back
25323 ch2ex7 4 0 7060K 6268K kqread 2 0:00 5.62% 1.66% speedy_back
25393 ch2ex7 4 0 7068K 6284K kqread 0 0:00 11.91% 1.66% speedy_back
25412 ch2ex7 4 0 7060K 6292K kqread 3 0:00 17.43% 1.66% speedy_back
25388 ch2ex7 4 0 7060K 6272K kqread 3 0:00 11.56% 1.61% speedy_back
25398 ch2ex7 4 0 7060K 6268K kqread 0 0:00 11.56% 1.61% speedy_back
25372 ch2ex7 4 0 7060K 6272K kqread 0 0:00 8.34% 1.51% speedy_back
25317 ch2ex7 4 0 7060K 6340K kqread 0 0:00 4.96% 1.46% speedy_back
25333 ch2ex7 4 0 7060K 6272K kqread 0 0:00 5.46% 1.42% speedy_back
25311 ch2ex7 4 0 7060K 6276K kqread 1 0:00 4.79% 1.42% speedy_back
25379 ch2ex7 4 0 7060K 6344K kqread 0 0:00 7.80% 1.42% speedy_back
25383 ch2ex7 4 0 7060K 6268K kqread 1 0:00 7.80% 1.42% speedy_back
25394 ch2ex7 4 0 7060K 6340K kqread 0 0:00 9.45% 1.32% speedy_back
25400 ch2ex7 4 0 7064K 6268K kqread 1 0:00 8.75% 1.22% speedy_back
25262 ch2ex7 4 0 7060K 6272K kqread 0 0:00 2.98% 1.17% speedy_back
25260 ch2ex7 4 0 7064K 6344K kqread 1 0:00 2.85% 1.12% speedy_back
25054 ch2ex7 4 0 7096K 6292K kqread 3 0:01 1.57% 1.07% speedy_back
25264 ch2ex7 4 0 7060K 6268K kqread 0 0:00 2.73% 1.07% speedy_back
25340 ch2ex7 4 0 7064K 6268K kqread 2 0:00 4.14% 1.07% speedy_back
25435 ch2ex7 4 0 7060K 6296K kqread 1 0:00 22.00% 1.07% speedy_back
25348 ch2ex7 4 0 7060K 6272K kqread 0 0:00 4.19% 0.93% speedy_back
25297 ch2ex7 4 0 7064K 6276K kqread 0 0:00 2.66% 0.88% speedy_back
25280 ch2ex7 4 0 7060K 6268K kqread 0 0:00 2.42% 0.88% speedy_back
25350 ch2ex7 4 0 7060K 6272K kqread 2 0:00 3.97% 0.88% speedy_back
25271 ch2ex7 4 0 7060K 6272K kqread 0 0:00 2.29% 0.83% speedy_back >>821
これ、perl alarmで検索して一番上のところにそう書いてあったんだけど、
ほかのところはどこ見てもそう書いてないなぁ、、だいじょぶだべか、 BBSを再度動かしました。
ex7のブロックは解消しました。
遅延なしにはできてないみたいですが、さっきよりは、改善されたです。 live8 , ex7 が落ちたのは
直接的には BBS の返事がないから処理が貯まりに貯まって落ちたと、
元々 live8 , ex7 は物凄い書き込み数だと言うことが原因の一端であると、
しかし、根本的には何が起ったかというと
BBSがなぜか応答しなくなったと
なのに不思議なのは、同じサーバにある別のもの BBY 等は問題なく動いていたと
質問
同じサーバ内で BBS だけがぽしゃる事なんてあるんですか? 投げっぱなしで応答をまったく期待しない場合の
コーディング方法募集中です (Perl >>805) >>835
BBS担当、BBY担当、BBX担当のDNSサーバは全部別プロセスなので、
ありえますね。というか、全部がぽしゃらないようにしてあるともいえます。 >>836
具体的には gethostbyname() の結果がDNSから来なくても、
次に進んでほしいということですね。 >>837
なるほど、
ということは、サーバの負荷というよりも BBS(DNS)の限界?
>>839
それを疑っています。
その時間だけBBSのログがないのです。まったく「すぽーん」と。
まるで、サーバそのものがいなかったかのように。
しかし、djbdns+daemontoolsで作ってあるので、
プロセスがいなくなっても立ち上がるし、
サービスダウンには、とりわけ強いはずなんですよ。
すくなくともこんなふうにサービスがいなくなることは、これまで一度もなかった。
banan238の他のシステムログもあさっていますが、
今のところ不審なものは、発見できていませんです。 BBS はどれくらいコールされているかというと、、、
一日で 150万～180万
ピーク時で一分間に・・・
どれくらいでしたっけ?
1,000 くらい? ぐおっ 2,400/min
つまり 24ms毎にリクエストがあると、(平均ですが)
ぱっと見、それくらいいけそうな数字ではあるんですけど、 1分ごとだと3000～3500かな？
夏～秋ごろに、1分ごとのデータをグラフにしてたことがあるんですけど、
その時も記憶に残ってる限り最高で3500くらいでした。 >>843
普段はいけてますね。(>>842 のグラフ参照)
今回は、、、。 ん?
計算変かな?
35000/min だとすると 17ms 毎くらいか もう二桁くらい小さい値で動くと思うんですけどね < DNS
(単なる勘です) で、いけない数字とは思えないんですよ。
DNSコンテンツサーバ側って、数千query/secぐらいは、さばけるはずなんです。
あと、今日やったMMAPの手術(>>778-780)で、
さらに30%らいは強化されているはず。 こちらで別の機会に実験した値でも、
DNSのコンテンツサーバ側は数千queries/secまでは問題なく動く、
という結果が出ています。>>847 初めての経験ですからねぇ
「たまたまだった」という結論にでもしますかねぇ
二度目があったら・・・そんときに再度考える? BBSが動いていない現象自体はしょっちゅうありますけどね、、
確かにこんな長い時間動かなかったのはめずらしいけど 今日のところは、そうしておきたいかも。>>850
DNSサーバ側を緊急強化したので、これで様子を見たいかなと。
今月は、機会が連日連夜あるに違いないわけで。
# うへー、明日朝早いんだよなぁ。 げっ
そういえばそうか?
たまたまじゃないのか?
DNS 自体は返事していて、単に数え漏れが発生しているということではない?
>>851 >>851
しょっちゅうあるのは、いまいち、、、かも。
DNS側がブロックしないように、ちゃんとなってるかちょっと見てみます。 >>853
んまぁ、、確かに他の止まってる時とは明らかに動作が違ってたですからねぇ。
いつもは数え漏れなのかもしれませんねぇ。
そうかも。いや、そうだべ。うん、きっとそうだ！ 個人的には、ネットワークのチューニング問題な気がとってもするです、、、。 >>860
ではなく、banana238のです。
# netstat -s -p udp
udp:
361330042 datagrams received
0 with incomplete header
0 with bad data length field
8 with bad checksum
327 with no checksum
152972 dropped due to no socket
125983 broadcast/multicast datagrams dropped due to no socket
9072993 dropped due to full socket buffers
0 not for hashed pcb
351978086 delivered
352298516 datagrams output
今BBS止めてたんで、この値そのまま信用できないところがありますけど。 今netstat -z でカウンタをリセットしたんで、
この後様子を見てみます。
ドロップパケットとかが出てるようだと、
ネットワーク系を何かチューニングしないと、いかんかなと。
udp:
212 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
0 with no checksum
0 dropped due to no socket
0 broadcast/multicast datagrams dropped due to no socket
0 dropped due to full socket buffers
0 not for hashed pcb
212 delivered
212 datagrams output DNSはUDPなんで、具体的には、
# netstat -s -p udp
udp:
1996 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
0 with no checksum
0 dropped due to no socket
0 broadcast/multicast datagrams dropped due to no socket
0 dropped due to full socket buffers
0 not for hashed pcb
1996 delivered
1996 datagrams output
の、droppedなんちゃらのところがカウントアップされるようだと、
いまいちですね 各個のサーバを強化し
台数も増やすと、、、
土台が小さく感じ始めるということかしら、
当然なんですけどもね、 >>863
それを _serviceに吐き出しておくとか、
皆で観察 ! >>864
それは、多分にあるかなと。
今、２ちゃんねるで動いているDNS系の仕組みはこんなかんじです。
おおむね、上から負荷が大きい順。
・dnscache
量産型bananaからのDNS問い合わせを処理
cobra (oyster243)
・BBQ
BBQチェック、投稿毎に呼び出し、巨大DB参照
cobra (oyster243)
・BBS
野鳥の会、投稿毎に呼び出し、DB参照なし
banana (banana238)
・BBM
携帯版BBQ、携帯からの投稿で呼び出し、DB参照
cobra (cobra2245)
・BBX
Rock54、広告っぽい投稿毎に呼び出し、DB参照
banana (banana238)
・BBY
ヘッドライン&スレ立てチェック、スレ立て毎に呼び出し
banana (banana238) もっと書き込めるようにスレ保持数さげて(ex7)
現象が顕著に現れるようにしてみよう。 Dropped Due to No Socket
受け取った UDP データグラムのうち、宛先ソケット・ポートが開かれなかった数。
結果として、「ICMP Destination Unreachable - Port Unreachable」という
メッセージが送信されます。ただし、 受け取った UDP データグラムがブロード
キャスト・データグラムである場合は、ICMP エラーが生成されません。
この値が大きい場合は、アプリケーションがソケットをどのように処理しているかを調べてください。
port unreach か。
いまいちな予感。
処理が追いついてないのか、、、。
BBQはでっかいDBをrbldnsでmmap()してるからなぁ。
mmap() の頻度をもっとまばらにしてみるです。 ちょっと狼のスレ数減らさないでよ
大体ハロプロって50人くらいメンバーいるから
それぞれのカップリングスレだけでも50×50で2500は必要なんだし
各メンバーのファンスレ数種類にアンチスレ数種類もひつようだし
最低3000は必要だよ BBQのdjbdnsは強化型になっていなかった(portsが古かった)ことが判明。
再度手術するです。 人が多い所はスレ保持数2000くらいでまわせるような感じにして欲しい >>878 をやりました。
これからbbqのnetstatのカウンタをリセットします。
で、すみませんがスレッド保持数の話は、別のところでおながいします、、、。 狼をどうぞ沢山増やしてあげてください
VIPは300くらいでいいです
落ちても誰ひとりとして気にしません VIPER一同より
我々はFOX ★がどんなに理不尽な仕様にしようとも受け入れて生きていきます >>880
とりあえず、これで、しばらく様子見ですかね。 >>887
そっすね、、、。
BBQ側のカウンタが微妙にいやんな感じなのが、ちと気になるです。
でもさすがに今日はもう寝ないといかんので。 tigerサーバ/cobraサーバのspeedycgiを、バッファ拡張版にした。
( #!/usr/local/bin/speedy -- -r1 -t60 -b1048576 )
今日は、ここまでかなと。 流れそうだから、もっかいおれさまメモ。(>>767)
意識なくなってきたんで、おやすみなさい。 2004/12/02 04:05:00
udp:
155591 datagrams received
-略-
1 with no checksum
204 dropped due to no socket
-略-
155387 delivered
156167 datagrams output
まぁ、今のところのstatsがdelivered以外0なのに比べると
確かに微妙にいやんかも、、
おやすみなさい。 FreeBSD 5.3R-p2
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-04:17.procfs.asc
workaroundは、procfsを使わないことか。 思い出したときに書いておこう。
今の902だと、/homeにAMD64なバイナリ(read.cgi/offlaw.cgi)が入っているから、
次のを作るときも、AMD64アーキテクチャじゃないと大変めんどいですね。
/homeを共有することになるわけだから。
Cobraクラスにするかもっと安いのにするか(組みようにより、安いamd64も組めます)は、
別途考えることになるのかなと。 下記がもしほんとだとしたら、、、。
DNSサーバ系も絶対5.3Rにしよう、そうしよう。
blackgoat4: FreeBSD 5.2.1R
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
684 squid 96 0 347M 341M select 0 212.3H 19.48% 19.48% squid <= CPUを20%食ってる
623 root 96 0 42420K 5416K select 0 4:59 0.00% 0.00% httpd
561 root 96 0 1608K 928K select 2 2:04 0.00% 0.00% ntpd
658 root 8 0 1232K 484K nanslp 0 1:50 0.00% 0.00% svscan
297 root 8 0 3108K 2508K nanslp 1 1:42 0.00% 0.00% ipmon
586 root 96 0 3512K 2012K select 1 1:08 0.00% 0.00% sendma
686 root 96 0 2224K 1440K select 0 0:30 0.00% 0.00% proftp
603 root 8 0 1340K 824K nanslp 3 0:19 0.00% 0.00% cron
427 root 96 0 1312K 704K select 3 0:10 0.00% 0.00% syslog
blackgoat3: FreeBSD 5.3R
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
626 squid 20 0 282M 278M kserel 1 10:18 0.20% 0.20% squid <= CPUを0.2%しか食っていない
582 root 96 0 42012K 7776K select 0 0:01 0.00% 0.00% httpd
1449 service 96 0 2616K 1912K CPU1 0 0:01 0.00% 0.00% top
1007 service 96 0 6092K 2996K select 3 0:00 0.00% 0.00% sshd
598 root 96 0 5048K 4244K select 2 0:00 0.00% 0.00% snmpd
653 dnscache 96 0 32820K 32220K select 1 0:00 0.00% 0.00% dnscac
525 root 96 0 2880K 1776K select 2 0:00 0.00% 0.00% ntpd
306 root 8 0 1804K 1392K nanslp 3 0:00 0.00% 0.00% ipmon
628 root 8 0 1236K 664K nanslp 3 0:00 0.00% 0.00% svscan ネットワーク周りのGIANTLOCKが解消されたからでは？ #!/usr/local/bin/speedy -- -b1048576
バージョンのbbs.cgiをex7に投入しましたー
bbs.cgi再開発プロジェクト４
http://qb5.2ch.net/test/read.cgi/operate/1101984763/74-75
昨日のピーク時 350投稿/min くらいで、沈没 → DNSの強化でなおったばす
今日のピーク時 350投稿/min しらいで平和
さて明日は? SpeedyCGI フルスペック版bbs.cgi がどう動くのか
1) 軽くなって 400投稿/min でもへっちゃら
2) やっぱ意味無しで 350投稿/min で沈没
3) かえるの歌でも歌ってみる
質問だす
#!/usr/local/bin/speedy -- -b1048576
で bbs.cgiが起動され speedy_back プロセスが走り出すと思うのですが
このときの speedy_back の pid を 74745 とすると
プロセス 74745 が殺される(or自滅する)タイミングって何時ですか? 昨日は本業で疲れ果て、そのまま寝てしまいました。
さて、今週はシステム系サーバの工事。
↓
システム系サーバ工事に伴う書き込み不安定・一部サービスダウンのお知らせ[12/3]
http://qb5.2ch.net/test/read.cgi/operate/1102042361/
>>897
おおっ。bbs.cgiスレが激しく進んでいると思ったら、いよいよすか。
>>904
-rと-tのデフォルト値に依存してるですね。
http://perldoc.jp/docs/modules/CGI-SpeedyCGI-2.21/SpeedyCGI.pod
によると、
・bbs.cgiが500回実行される(-r500)
・1時間、何のリクエストも来ない(-t3600)
と、バックエンドプロセスが切り替わるようです(両方とも変更可能) MaxRuns( -r オプション、デフォルトが500 ）判定で再execされても
古いバックエンドが kill されないように見えるということですか？ うわっ、調べてる間に詳しいレスついてた、ハズい・・・・ ex7の1プロセスあたりのCPU時間を30秒から120秒に増やしました。
(speedy_backendが500回分ずつ処理するので、1プロセス的に消費時間が増えるため) ふんふん
つまり Speedy は時限装置が組み込まれていると、
そしてサーバは殺しに行かないようにしたと、
こういう感じ? >>909
そういうことになります。120秒が短いなら、またのばそうかなと。
bbs.cgiには暴走癖がありますが、それは120秒制限で遅かれ早かれ死ぬはず。
でex7ですが、今のところ平和なかんじですね。
300投稿/minを超えるあたりからが、見ものか。 でも冷静に考えてごらんよ。
このまま進むと確かにそう遠くない将来(Febころ?)
tigerで 500投稿/min をこなすようになるですねぇ
なったらどうなるかというと・・・・・
道路を作れば渋滞が解消するという幻想を
抱いている方々と同じ境遇というか、、
車減らさなきゃ渋滞解消しないのに、
道を快適にすればそれ以上に車に乗る人が増えるのに、
>>911
しょうがないすね。
それはもう、「宿命」とか「業」とかのレベルかなと。
DNSサーバ構築で巻き込まれはじめ、
uma作戦以降どっぷりと漬かってからというもの、
サーバの資源不足が解消するなんて、はじめから思ってないっす。
とりあえず、きゅうり踊りだけはちょっとだけうまくなったのかもしれないけど。 いや必ずどっちかが限界に達する
それか質的にかわるか >>914
dnscache止めてた = bananaサーバからの書き込みができなかったはずなので、
本当に書き込み数が減っていたはず。 oyster243を観察中。
ネットワークはじめ、全体的にとても軽くなった気がしますね。
やっぱ、ネットワーク周りのgiant lock解消が効いてるのかなと。 >>915
そうでしたかぁー。
いや、kawase-m見る限り狼も数字動いてなかったもんで、、 >>922
狼= ex7は別の要因と思います。(bbs.cgiが違う)
BBQのalerm()な処理が入ってないんだと思う。 そうでしたか。微妙にそんな気はしたけど、、
おつかれさまですー。。 >>923
あっ
もしかして、使ってなさそうな処理をばっさり削ったのが原因かも。。。
alerm() は入っているけど、 シグナルなんとかってのはばっさり削ったのだ
はっはっは
きっとそのせいだ、、 <br> 関係もコピペの問題なんだろうなぁ。。。
もしのソースからもう一度慎重に持ってくれば直る予感。 FOXさーん、
bbs.cgi をいじって、return 0;を入れませんでしたか? qb6のだけ、いじったです。
で、これを配布すればいいのかな。 return 0; も 1 も沢山入れたからわからないなぁ、
いつごろのことですか? あっ 入れた気がする !!
うへへぇー
間違ってくばっちった、 >>932
6時間ぐらい前だと思います。
で、Proxyチェックのところをパスするにようなっていたことが判明したので、
そこを元に戻したものを配布しておきました。
これで、BBQは再度有効になったはず。 てなわけで、たぶんBBQの問題は解決したはずです。 なるほど、「避難訓練実施中」バージョンの時ですね。>>933
了解です。
で、今後はもうBBQは止めないので、これで問題ないでしょう。 >>936
試したら、BBQ戻ってますね。
乙ですー BBQのquery数、戻りましたね。
でも相変わらずoyster243は軽いので、
5.3Rへのバージョンアップの効果は大きいみたい。 おい！！いつになったら書き込めるようになるんだ
早く直せ糞野郎 >>943
とりあえず書き込めない板とスレを出さないと解決にならないと思われ 提案です
ex7 も read.cgi(DSO風味)やっちゃいませんかー? > root ★さん >>952
やりますか。
んじゃ、ごそごそしてきます。 ほほーい
read.cgi@ex7 一回止めて
.so 版 構築します 500 error になるっすね、、、
なんか間違ったかなぁ んー、なんか変だなぁ。
[Fri Dec 03 07:10:40 2004] [error] [client むにゃ] /home/ch2ex7/public_html/test/read.cgi: /home/ch2ex7/public_html/test/read.cgi: mmap returned wrong address: wanted 0x8048000, got 0x2873b000, referer: http://ex7.2ch.net/morningcoffee/ >>958
アナルを小指で軽く触ってみるといい。マジで。 ちょっと、ex7のApacheの設定いじります。
dsoと同じにしてみよう。 どれが最新だか解らなくなったので
dso.2ch.net からバイナリをコピーしました
うごいた 動いたと思う。
んー、SuExecしないといけないのか。いまいちだなぁ。
後で、もう1回設定見直してみるです。 >>966
んじゃ、もう1回SuExecなしにしてみます。 SuExecなしにした。
動いた。ということで、>>966 が備後の模様。 そうやって一時の気紛れでチョコチョコやったり
また戻したり
蓄積という言葉を知らないと
器のデカイ大人に成れねえよ
他はどうでもいいけど戦闘力と!baseと!774!force!3は戻してほしいな >>974-975
今やってるのはどう見ても気まぐれじゃないって。
ｽﾏｿ、出しゃばりすぎですね。 【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part16
http://qb5.2ch.net/test/read.cgi/operate/1102087698/
>>985
どもです。
bbspink、携帯電話特化型はとりあえずはずしました。
また必要なら、自然に入るかと。 systat -pとかsystat -vとかすると、いろいろとわかるです。 >>996
ですね。
>>1 が8月21日か。
このスレでの作業は、とても有意義だったなぁと。 いつもおつかれさまです。
これからもいっしょに（？）遊ばせてもらいますー
FOXの実験には大爆笑する
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼
それがＶＩＰクオリティ
http://ex7.2ch.net/news4vip/
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。 レス数が1000を超えています。これ以上書き込みはできません。
