2ch特化型サーバ・ロケーション構築作戦 Part20

**root▲ ★** · NG

2ch特化型サーバ・ロケーション構築作戦のスレッドです。

・２ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更まわりの関連作業・調整事項
・２ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携

等を取り扱います。

現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。

また、次世代の携帯アクセス環境をめざした「べっかんこ作戦」も稼動しはじめました。
「２ちゃんねる証券取引所」や、「Be」の機能強化等、
２ちゃんねるは今日も変化し続けています。

前スレ:
2ch特化型サーバ・ロケーション構築作戦 Part19
http://qb5.2ch.net/test/read.cgi/operate/1121886018/

**root▲ ★** · NG

**root▲ ★** · NG

近い課題
・削除関係の呪文の雪だるま対応
・live22 バックエンドの安定稼動
・matd を用いた受付の安定稼動
・mod_cache の導入によりバックエンドの負荷を下げる
・DNS ラウンドロビンから matd への移行
・heartbeat を利用した受付の冗長化

問題の解決
・電源食い杉どうしよう

重要な課題
・効率の良い金色会員維持
・家庭の保守

**root▲ ★** · NG

転載

雪だるま作戦のスレを待ち続けるスレ Part3
http://aa5.2ch.net/test/read.cgi/nanmin/1140235427/373-377

373 名前：▲ ◆cZfSunOs.U [sage] 投稿日：2006/02/21(火) 23:45:53
特化型スレが 1000 目前なので，とりあえずこちらに...... ロードバランシングが
ちゃんと機能してるらしいのはいいんですが，どのフロントに振り分けられるかによって
ETag がバラバラになっちゃいますね......

ETag: "405469-1b63-69f6b640"
ETag: "2bd861-1b63-69f6b640"
ETag: "175c61-1b63-69f6b640"

違いが出るのは inode の部分なんでしょうけど，フロントが直接持ってるファイルに
関しては ETag 生成で inode 使わないようにした方がいいのかも知れませんね．
mod_proxy (+ mod_cache) で持ってくる dat 等は今のままでいいんでしょうけど．

377 名前：▲ ◆cZfSunOs.U [sage] 投稿日：2006/02/21(火) 23:56:44
>>376 こんな感じとか......

<FilesMatch "^(フロントで|直接|持ってる|ファイル)$">
FileETag -INode

**root▲ ★** · NG

できるとうれしいこと
・バーチャルホストごとに負荷軽く統計をとれるとうれしいな

**root▲ ★** · NG

雪だるま作戦のスレを待ち続けるスレ Part3
http://aa5.2ch.net/test/read.cgi/nanmin/1140235427/353-356

353 名前：FOX[] 投稿日：2006/02/21(火) 19:05:14 ?
www.2ch.net だけスタンバイ機作りますかねー >>352

もしもの時は DNS 変更だけで仮復帰できるように

356 名前：FOX[] 投稿日：2006/02/21(火) 19:13:54 ?
あるんですけど、

んじゃ ex14 に

**root▲ ★** · NG

あと、何か課題はあるのかな。
とりあえず前スレを、再読してみるか。

で、epgの変更申請は、次のレスにて。

**root▲ ★** · NG

epg.2ch.net の新サーバへの移行申請をします。

以下のDNSサーバの設定変更をよろしくお願いします。

(現在)
+epg.2ch.net:210.135.98.243

(変更後)
+epg.2ch.net:210.135.99.7

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 02:33:35

rootたんありがたう。

･電源食い杉どうしよう
増やすしかない。まぁいらん鯖はほかのラックにうつしたほうがいい。
データセンターでソーラーないし二重化電源を思い切って…(ry

**root▲ ★** · 2006/02/22(水) 02:53:16

2ch特化型サーバ・ロケーション構築作戦 Part19
http://qb5.2ch.net/test/read.cgi/operate/1121886018/35

35 名前：root▲ ★[sage] 投稿日：2005/07/22(金) 03:37:58 ID:???0
転載

786 名前： ◆MUMUMUhnYI [sage] 投稿日：2005/07/21(木) 23:53:49 ID:B2JZ82ht
>>784
キーボード(とマウス?)なんですよね。
PIEで使っているKVMスイッチはデイジーチェインでつなぐブツなのです。
で、ACPIとの相性が悪くて、旧tiger(tiger5xx)だけ、FreeBSDの立ち上げ時に
パニックして止まってしまうという。

で、ACPI切ると上がるのですが、
そうすると別のところでハングアップして、止まってしまうです。

キーボードとマウスをつけていてもシステムBIOS画面は、問題なくKVM経由操作できるです。
FreeBSD＊だけ＊が、だめ。

で、キーボードとマウスをはずすと、ちゃんと上がる。
OSが上がっている時に、途中から刺しても大丈夫。

bananaと新tigerでは問題は起こってないので、
問題はかなり根深い気がします。

PIEに行ったら、旧tigerのBIOSを最新版に上げてみようかなと、
思っていたり。

787 名前： ◆MUMUMUhnYI [sage] 投稿日：2005/07/21(木) 23:56:55 ID:B2JZ82ht
症状は、これとかこれと同じです。
XeonでSMPの時で、しかもブート時に、
特定の種類のマザーボードでしか、起こらない模様。

AP #1 (PHY# 1) failed
http://lists.freebsd.org/pipermail/freebsd-smp/2003-June/000185.html
AP #1 (PHY#1) failed! Panic (y/n)?
http://lists.freebsd.org/pipermail/freebsd-stable/2005-February/012216.html

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 03:04:19

ここも20スレ目ですか｡｡｡PIEへ移住しようとしてた頃が懐かしい｡｡｡

＞重要な課題
＞・効率の良い金色会員維持
＞・家庭の保守
超重要ですね｡｡｡

◆Reffiz2Zh. · 2006/02/22(水) 03:09:23

電源対策ですか。。。
手軽に出来るのは電源関連の強化だけどこればっかりは出来ることと出来ない
事に分かれるので難しいところですねぇ
あとは前に漏れが書いてた省電力型bananaへのリプレースとかですね。

**root▲ ★** · NG

**root▲ ★** · NG

**root▲ ★** · NG

**root▲ ★** · NG

**root▲ ★** · NG

このぐらいですかね。

進行はゆっくりでしたが、いろいろと実り多いスレだったのかな。
ほとんど、おれさまメモだという話もあったり。

**root▲ ★** · NG

>>11
…ですね。

もう、2年になるですか。
コンパクトな番組表を、よく投稿していただいたものでした。

月日のたつのが、ほんとに速いなと感じるです。

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 03:54:19

なんかしんみりしますね・・・ｗ

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 08:04:54

今思うんだが、暇なサーバー(挑戦ら辺)にhttpdのログを回収させて(内部メールでもよいでよ)で回して管理センターにするのもいいかと。スクリプトは書くのﾏﾝﾄﾞｸｾなんでtestにWebアナアライザー？を投入

#たまにはBSD触ろうかな。fedoraとCentOSしか触ったことしかないし。

**ピロリ** · NG

>>8

done

**root▲ ★** · 2006/02/22(水) 14:24:52

>>20
いいアイディアな気がするので、そのうちやるかも。

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 15:16:04

matdってなんですか

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 15:51:46

二輪車乗員を模擬した衝突試験用人体模型
「MATDダミ：Motorcyclist Anthropometric Test Device Dummy」
とか言ってみる。ｗ

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 15:54:06

雪だるま計画の鍵となるファイルの一つじゃないの？

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 15:59:20

えっ､中の人が騒音防止マット敷くの面倒臭いからデーモン召還したんじゃないの？

**root▲ ★** · NG

>>24 管理人とメールと同じセンスだ、、、。

管理人も、MAT のアルゴリズムに興味を持っているようです。
NAT というのはもう一般的ですが、MAT は耳新しいかも。

# というか、私も雪だるま作戦するまでよくわかってなかったです。

MAT は MAC Address Translation と言われていて、MAC アドレスの
変換をするものです。

で、何のためにするかというと、帰りをロードバランサー経由ではなくて、
フロントエンドから直接戻るようにしたいからです。

Googleに聞くと、わかりやすい図面例がありました。
http://www.znw.co.jp/product/piolink/02.html

**root▲ ★** · NG

>>27
× >>24 管理人とメール
○ >>24 管理人のメール

**root▲ ★** · NG

あとは、これとか。
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/sw/cat60/csicg/chapter02/02_netwcsm.shtml#91466

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 17:28:30

>>27
なるほど、NATのMACアドレス版というわけですか。

**root▲ ★** · NG

おいそがしいところすみませんが、、、。

新 www/menu になる予定のサーバの設定をすすめているのですが、
今気がついたのですが、メモリがちょっと少ない
(というかそんなわけないので、正しく認識していないということだと思われる)
ようです。

今までのbanana (例: banana613)
real memory = 528416768 (503 MB)
avail memory = 511455232 (487 MB)

今回受け取ったbanana (banana2848)
real memory = 469696512 (447 MB)
avail memory = 449945600 (429 MB)

システムメッセージによると、
これまでの banana とマザーボードが異なっているようなので、
そのあたりにも何か原因があるのかもしれません。

すみませんが、調査の手配をよろしくお願いいたします。
パスワードは、これからいったん、いただいた時のものに戻しておきます。

**root▲ ★** · NG

で、>>31 の補足ですが、
OS を FreeBSD 6.0R に上げた時点で気がついたので、
今は 6.0R になっていますが、もらった直後からメモリ容量の値が小さかったことは
改めて確認しました。
(もらった時の最初のシステムブートメッセージは、いつも最初に保存しています)

ということですみませんが、状況の調査をよろしくお願いします。

**ピロリ** · NG

はいー

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 21:00:38

システムが占領しているかもね。ビデオメモリの最低が増えたとか。

データ配置どうにかならんかな？

Mcellなら同じデータを呼び出すなら速いけどdatは頻繁に書き換えられるし、なかなか上手く行きそうにない。

やはりi-RAM使うかな。
やはり現状維持？

誰かソフトウェアでのアプローチきぼん

**ピロリ** · 2006/02/22(水) 21:13:46

判明しました。
banana2848のメモリが少なく表示されていますが、
マザーボード上のグラフィック部分のチップセットが
今までのbananaサーバと異なり、BIOS部分で占有
するメモリが増えた為です。

banana613 ： P4M266
banana2848 ： P4M80P

む P221119009244.ppp.prin.ne.jp · 2006/02/22(水) 21:39:24

>>35
了解です。>>34でビンゴということですか。

セットアップ作業続けるです。
FSB800かな。今後このロットはbananaマークIIと呼ぶことにしよう。

▲ ◆SANUKI/VII · NG

bananaMkIIですか

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 21:42:13

ZBananaじゃないんですか・・・

**ひろゆき** · NG

LVSってMATとはちがうんすか？

む P221119009244.ppp.prin.ne.jp · 2006/02/22(水) 22:18:02

MATのLinux上の実装のひとつが、LVSということですね。
matdは、SolarisとFreeBSD上のMATの実装のひとつと。

**ひろゆき** · NG

おぉ、そういうことなんすかぁ。理解理解。

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 23:27:51

怪獣攻撃隊じゃなかったのか・・・・

**動け動けウゴウゴ２ちゃんねる** · 2006/02/22(水) 23:30:18

過去ログはシンボリックリンク張って別に移してほしいけど●のなかいじらないといけない。やっぱり難しいか。
(●くらいdigest認証で良いような。名前の●もダイアログがそのたび出れば良いわけで。でも.htpasswdがでかくなりすぎるし管理が面倒臭いか。)

雪だるまの削除の呪文は
(1)まず削除するとこの案内嬢に削除するものを示すデータベースに削除命令を掲示。

(2)バックが削除命令を実行。受付嬢に完了を知らせる。

(3)バックが(2)をもう一度するがそんなの無いとエラーを吐くこれを確認して削除命令の掲示を削除。

雪だるまいがいでもできそう。かな。

**動け動けウゴウゴ２ちゃんねる** · NG

>>36
FSB800には対応しておるが
PM880ならメモリヅアル対応
PM800ならメモリ片肺（よってFSB800意味なし）

そしてS-ATA対応
しかしVT8237RはS-ATAII非互換なので要注意
VT8237R+なら心配はいらぬ

socketT仕様なら状況に応じて廉価なPenDを使用出来るかもしれない
（CPU性能のみを求めてXeonを使う必然性は薄くなる）
socket478ならほぼ従来通り

以下、参照のこと
http://kakaku.aol.co.jp/aol/akiba/040930_1.html
いい具合に枯れております

**root▲ ★** · 2006/02/23(木) 00:27:27

>>44
どもです。

メッセージを見る限りP4M80Pになったこと以外、ほとんど変化がないようです。
CPU・HDD・ネットワークカード、全部前と同じ。

Ζとか新とかいう感じではないですね。マークIIということで。

**root▲ ★** · NG

wwwとmenu、まずは仮住まいから本住まいに再移転します。
次の段階で、冗長化とか分散化にとりかかるかんじで。

以下のDNS設定変更をお願いします。

(現在)
+2ch.net:207.29.224.75:300
+www.2ch.net:207.29.224.75:300
+menu.2ch.net:207.29.224.75:300

(変更後)
+2ch.net:206.223.157.122:300
+www.2ch.net:206.223.157.122:300
+menu.2ch.net:206.223.157.122:300

株価【950】 ▲ ◆cZfSunOs.U · 2006/02/23(木) 03:37:39

>>16
>mod_disk_cache (微妙にまだ挙動不審)
>http://qb5.2ch.net/test/read.cgi/operate/1121886018/916-923

Age ヘッダが Squid に悪さをすると仮定して......

1. c の Squid で Age ヘッダを無効にしてみる．

header_access Age deny all

2. 1. がダメなら live22x の httpd で Age ヘッダを出さないようにしてみる．

ResponseHeader unset Age

株価【950】 ▲ ◆cZfSunOs.U · 2006/02/23(木) 03:40:16

>>47 我ながらボケてますね......ｗ
-ResponseHeader unset Age
+Header unset Age

**root▲ ★** · NG

>>47-48
2. がよさげかな(キャッシュの様子がわかりにくくなるという欠点はあるけど)。

明日以降にでも。

**ピロリ** · 2006/02/23(木) 10:27:40

>>46
DONE

**root▲ ★** · NG

ということで、yakin.ccの内容を戻しました。
以下の変更をよろしくお願いします。

(現在)
+yakin:cc:206.223.151.10
+www.yakin.cc:206.223.151.10

(変更後)
+yakin.cc:206.223.157.122
+www.yakin.cc:206.223.157.122

パスワードが再設定されましたので、情報をメールしておきます。

**root▲ ★** · NG

あう、タイプミス。
これでお願いします。

(現在)
+yakin.cc:206.223.151.10
+www.yakin.cc:206.223.151.10

(変更後)
+yakin.cc:206.223.157.122
+www.yakin.cc:206.223.157.122

**動け動けウゴウゴ２ちゃんねる** · 2006/02/23(木) 12:49:53

>36

納入のときBIOSいじれないのかな。
正直設定できたら８Ｍでもいいと思いますが。

**ピロリ** · NG

http://qb5.2ch.net/test/read.cgi/operate/1121886018/951-
>>>
>>> いただいたbanana613ですが、今までのIPアドレスレンジと違うわけですが、
>>> (それ自体はめでたくて、PIEが成長したということだと思います)、
>>> DNSの逆引きの設定がおかしいようです。
>

なおったはずー

**root▲ ★** · NG

>>53
そうですね。512Mのうち56M減ってしまうのは、
ちょっと大きいかなと。

>>54
了解です。
でも、ちゃんとした逆引きの設定もあるといいかもです。(206.223.のところのように)

**root▲ ★** · NG

再稼動したtiger503/tiger507関係のDNS設定更新依頼を出します。
ということで、よろしくお願いします。

(設定追加)
+live22y.2ch.net:206.223.150.110:300
+live22y.2ch.net:206.223.150.42:300
+www2f4.2ch.net:206.223.150.110:300
+www2f5.2ch.net:206.223.150.42:300

**root▲ ★** · 2006/02/23(木) 22:41:00

>>56
これ、キャンセルします。
理由は言わずもがなで。

**root▲ ★** · NG

banana403 が復活したので、
www2f4/www2f5をmatdの仲間から外した。

**root▲ ★** · NG

Jim-san, Sean-san,
Cc: Hiroyuki-san, Yakin-san, (中の人)-san,

This is Mumumu.

First, I say thank you for your trouble recovery work,
and I heard from Sean-san today an another power circuit has been added.

But, I cannot trust you in the current situation.

So, you say the power circuit has been added two times. But I have not
heard from you an _accurate_ measurement result of the _peak_ of the
power usage yet.

I think we need the accurate measurement for the peak power usage at
22:00-24:00 JST. It is the peak access time in Japan.
This is a basic and an important issue.

Please do not forget about it.
It is very important issue about the trust between you and 2ch.

**root▲ ★** · NG

(続き)

And I have an idea to solve the problem. As you may heard from
Yakin-san, some of servers in XO rack can be moved out to another
location.

Follow servers can be moved to another location. They are not needed
neither 1Gbps connection not the private network connectivity.

tiger504, tiger509, tiger510
cobra2245, banana402

But they are now served for 2ch BBS, so, we need step-by-step moving
process. For example, scheduling, notify to 2ch users before moving,
etc.

So, we need a steady process and mind for success the project.
Please do not short-cut.

And all 2ch users are watching us. Please do not forget this again.

Regards,

**root▲ ★** · NG

ひどい英語だ。

まぁ、とりあえず言いたいことは伝わっただろうと。

**root▲ ★** · NG

> neither 1Gbps connection not the private network connectivity.
not => nor のtypoですね。

ねるねる。

**動け動けウゴウゴ２ちゃんねる** · 2006/02/24(金) 03:08:13

なるほど

**動け動けウゴウゴ２ちゃんねる** · 2006/02/24(金) 05:03:14

rootたん、乙。
All 2ch users are watching you.

株価【950】 ▲ ◆cZfSunOs.U · 2006/02/24(金) 07:46:52

http://aa5.2ch.net/test/read.cgi/nanmin/1140235427/875
これは httpd が abort したりしてお亡くなりになるってやつかな？
バック側の httpd がお亡くなりになるのは mod_cache を使えるようになれば
かなりリスクは軽減できそうだけど，フロント側はさて......

ついでに，また 1000 越えも発生してしまったようで......
http://live14.2ch.net/test/read.cgi/liveplus/1139846761/648
http://qb5.2ch.net/test/read.cgi/operate/1140349345/750
これは httpd がお亡くなりになると副作用で道連れになってしまうのか......？

む P061198250106.ppp.prin.ne.jp · 2006/02/24(金) 12:03:09

まだ中身を見てませんが、live22x1だけDB用のbbsdが動いていて、他のフロントより忙しいんですよね。
そのへんに手がかりがあるのかも。

**動け動けウゴウゴ２ちゃんねる** · 2006/02/24(金) 12:11:32

>>66
起きて大丈夫なん？
たまには２ｃｈを忘れて、しっかり休んだ方がいいと思うです。

**root▲ ★** · 2006/02/24(金) 13:28:15

>>65
live22x1 ログインして様子見ましたが、
LAの超急上昇とかシステムログの変なメッセージといった異常はないようです。
live22がおかしくなったための巻き添えの可能性が大きい模様。

live22は例の現象が。

Feb 23 12:20:10 <0.2> tiger2522 kernel: calcru: runtime went backwards from 136858476 usec to 136858421 usec for pid 80472 (httpd)
Feb 23 12:20:37 <0.2> tiger2522 kernel: calcru: runtime went backwards from 137933957 usec to 137933660 usec for pid 80553 (httpd)
Feb 23 12:23:56 <0.2> tiger2522 kernel: calcru: runtime went backwards from 1855272 usec to 1855048 usec for pid 7955 (httpd)
Feb 23 12:24:48 <0.2> tiger2522 kernel: calcru: runtime went backwards from 3957023 usec to 3956924 usec for pid 7974 (httpd)
Feb 23 12:25:18 <0.2> tiger2522 kernel: calcru: runtime went backwards from 5120010 usec to 5119944 usec for pid 7961 (httpd)
Feb 23 12:26:09 <0.2> tiger2522 kernel: calcru: runtime went backwards from 1637417 usec to 1637382 usec for pid 8299 (httpd)
Feb 23 13:29:30 <0.2> tiger2522 kernel: calcru: runtime went backwards from 2328454 usec to 2328443 usec for pid 22270 (httpd)

**root▲ ★** · 2006/02/24(金) 13:33:33

>>67
かもすね。

今朝のグラフうｐしたら、今日はオフライン気味で。

**root▲ ★** · NG

mbmonによる監視、動かし始めてみた。
http://live22.2ch.net/_service/mbmon-20060224.txt

とりあえずの比較対象:
http://ex11.2ch.net/_service/mbmon-20060224.txt

**root▲ ★** · NG

新設板・板移動情報・5.5＠運用情報
http://qb5.2ch.net/test/read.cgi/operate/1132068329/193

FFFTPで表示ができない問題:

http://blog.goo.ne.jp/hetare-neko/e/a4a1603fe38ea17397bb97af12baeed8
にある、

# cd /usr/ports/distfiles
# fetch http://www.hayasoft.com/haya/linux/proftpd-nlst-patch/proftpd-1.3.0rc3-nlst-ffftp.patch
# vi /usr/ports/ftp/proftpd/Makefile.local

---
PATCHFILES += proftpd-1.3.0rc3-nlst-ffftp.patch
PATCH_DIST_STRIP = -p1
NO_CHECKSUM = yes
---

# portupgrade -rf proftpd

とかいうかんじで。

**root▲ ★** · 2006/02/24(金) 22:57:16

Jim-san,

Thank you for your effort. I understand the current situation.

But as you know, these servers in XO racks have so many users and very
important data, so, we should progress the project more carefully.

So, I seem to have to be cool-down a little, too. ;-)
Now we are discussing about the current situation and our next steps,
and I am sure that we can make ideas and strategies for our next steps.

Now we are now in progress a project named "Project Snowman" at XO
servers. It is composed of load balancer software, frontend clusters,
and backend servers. If it is completed, this is sure to become stronger,
high-ability BBS system from the current stand-alone server, for next
generation.

Thank you for your support of everyday.

Regards,

-- Mumumu <mumumu@newsplus.jp>
as 2ch engineer

**root▲ ★** · NG

>>72
Dear Mumumu,

Things will be ok, we are doing our best to support you. I have been sick
this week and am taking strong medicine.

Please relax and lets have a nice dinner together next time we are in the
same city.

Your friend,

Jim

とりあえず(お互いに)、落ち着きを取り戻せたようです。
メールにあるようにリラックスして、じっくり作戦を練る感じで。

# まずは二人とも、体を回復させなきゃってことで。

**動け動けウゴウゴ２ちゃんねる** · 2006/02/25(土) 15:12:12

Apache2.2.0のロードバランサーで
30,40,40くらいに負荷分散したらいいとおもた。
by 携帯よりの使者

**root▲ ★** · NG

matd環境を冗長化すべく、作業をぼちぼちやろうと。

1) banana403 が死んでも、banana404 が代理で作業する、復活したら元に戻る
2) tiger2523-2525 のどれかが死んだら自動で切り離され、復活したら元に戻る

**root▲ ★** · NG

あと、banana806 (臨時に使ったwww/menu)ですが、
特に問題がないようならデータ同期の仕組みを入れて、
banana2848 (今のwww/menu)のスタンバイ機に仕立てるかんじがいいのかもとか。

**root▲ ★** · NG

>>75
> 1) banana403 が死んでも、banana404 が代理で作業する、復活したら元に戻る

これの設定をしたつもり。
これから banana404 に切り替えてみる。

**root▲ ★** · NG

うまくいっている模様。
ということで戻してみる。

**root▲ ★** · NG

うまく戻った模様。
今回は banana403 が上がったら、常に banana403 になるように設定。
(ha.cfでauto_failback on)

matd の上げ下げはこんなかんじのを、/usr/local/etc/ha.d/resources.d/zzz-matd に置き、
/usr/local/etc/ha.d/haresources で以下のように設定。
banana403.maido3.com 206.223.150.96/32 zzz-matd

#!/bin/sh

_LIP="127.0.0.1"
_VIP="206.223.150.96"
_CFFILE="/usr/local/etc/matd.cf"
_CFFILE_SKEL="/usr/local/etc/matd.cf.skel"

case "$1" in

start)
echo -n 'Activating matd '
sed -e "s/%%IPADDR%%/${_VIP}/" < $_CFFILE_SKEL > $_CFFILE
svc -h /var/service/matd
echo 'done.'
;;
stop)
echo -n 'Standbying matd '
sed -e "s/%%IPADDR%%/${_LIP}/" < $_CFFILE_SKEL > $_CFFILE
svc -h /var/service/matd
echo 'done.'
;;
*)
echo "$0 start | stop"
;;
esac

**root▲ ★** · NG

フロントの切り離しと接続は、ldirectord を使うのかな。
ぼちぼちと。

**root▲ ★** · NG

実現性はともかくアイディアとしては面白いので、
リンクだけしておこうかと。

http://qb5.2ch.net/test/read.cgi/operate/1140349345/986

**動け動けウゴウゴ２ちゃんねる** · 2006/02/26(日) 03:36:27

>>81
こういう話もあったり

ttp://d.hatena.ne.jp/hoshikuzu/20060210#P20060210EROGRIDCOMPUTING

**ピロリ** · NG

banana806　は当初の目的に使わないならば
引き上げるですー

**root▲ ★** · 2006/02/26(日) 15:46:52

>>83
了解。

であればやはり、うまく雪だるま等に収容する方向で。

◆OSfanJsSVc · 2006/02/26(日) 21:13:51

>>20desu.
http://www.mrunix.net/webalizer/
desu.
http://awstats.sourceforge.net/
tokamoarmashita.

**root▲ ★** · NG

c.2ch.net 系を Apache 2.2 + PHP5 + eacceleratorにバージョンアップ。
いろいろはまったので。以下。

まず、worker MPM では httpd がどんどん暴走状態になり、だめ。
prefork MPM では問題なく動作。

prefork MPM なので、mod_cgid じゃなくて mod_cgi じゃないとだめ。

Options MultiViews は＊徹底的に＊除去しないと、
思わぬところのものが有効になり、どつぼにはまる。
MultiViews を httpd.conf から全消ししたら動いた。これは後で精査必要。

なぜかどうやっても、.htaccess で Options +MultiViews と書けない。
理由は不明。これも後で精査必要。
結局、httpd.conf に移動して解決。

.htaccess にある、
addhandler php-script p
を、
addhandler php5-script p
に変えないと動かない。

**root▲ ★** · NG

; added by mumumu, 2005/9/6
;eaccelerator.shm_only=1

をコメントにして、

; added by mumumu, 2006/2/28
eaccelerator.cache_dir=/md/tmp

にしてみた。
メモリディスク上にPHPのキャッシュを作る。

**root▲ ★** · NG

で、MultiViews 問題は、

<Directory /home/*/public_html>

のところからも、MultiView をはずさないといけなかったと判明。

**root▲ ★** · NG

MultiView じゃなくて、MultiViews ですね。>>88

**root▲ ★** · NG

httpd.conf を見比べているけど、
>>88 は Apache 2.0 と 2.2 で仕様が変わった、、、ように見える。ううむ。

あと、
[Mon Feb 27 11:45:19 2006] [alert] [client 210.136.161.193] /home/ch2c-docomo/public_html/.htaccess: Option execcgi not allowed here

となるのは、未解決。
ううむなぜだ。

**root▲ ★** · NG

Options=MultiViews とか書くと、ExecCGI がうんちゃらって言うってことは、
ただOptionsと書いたんじゃ、だめなのかな。ううむ。

**root▲ ★** · NG

Options=All,MultiViews

が正解でした。

うーん、勉強になりましたぁ。

**root▲ ★** · NG

すべての問題が解決しました。

**動け動けウゴウゴ２ちゃんねる** · 2006/02/28(火) 05:20:49

うんと、どっかでAllにMultiViewsは含まれないってあったけど、
それを引きずるってことですか。

**root▲ ★** · NG

いやー、Googleには書いてないし、どこ見ても載ってないし、
いろいろはまったし、ということは後発の人は
ここを見て解決できることもあるんじゃないかなぁとか、
久しぶりに思った1日でした。

やっぱ、リハビリにはシステム設定がよさげね。

ドコモの方々には大変ご迷惑をおかけいたしました。
おやすみなさいです。

**root▲ ★** · NG

>>94
Options All では MultiViews は含まれないっていう仕様が前からあったわけですが、
Apache 2.2 からは新たに、AllowOverride Options ではだめで、
AllowOverride Options=All.MultiViews とここ＊にも＊書かないといけなくなった、
ということだと思います。

**root▲ ★** · NG

>>96
おっと、
- AllowOverride Options=All.MultiViews とここ＊にも＊書かないといけなくなった、
+ AllowOverride Options=All,MultiViews とここ＊にも＊書かないといけなくなった、

**root▲ ★** · NG

ということで、>>91-92 は AllowOverride の話でした。

AllowOverride FileInfo AuthConfig Limit Options=All,MultiViews Indexes

おやすみさい。

**動け動けウゴウゴ２ちゃんねる** · 2006/02/28(火) 05:33:53

おつかれさまでしたー。

**動け動けウゴウゴ２ちゃんねる** · 2006/02/28(火) 07:09:26

ありがとうございます。お疲れ様です。

**root▲ ★** · NG

eaccelerator.debug=0

をphp.iniに入れないと、延々とデバッグメッセージが出てちょっと遅くなるみたい。

**root▲ ★** · NG

>>98 はもちろん、
AllowOverride All

でもだめなので注意。

AllowOverride All Options=All,MultiViews と、
なんと All を2回も書いたうえで、かつ MultiViews を明示的に有効にしないといけない。

**root▲ ★** · 2006/02/28(火) 16:46:09

c.2ch不具合報告総合スレ5
http://qb5.2ch.net/test/read.cgi/operate/1138289353/347-360

Apache 2.2 + mod_proxy + mod_cache で
squid の代わりをしようと思ったのですが、
トラフィックを乗せたとたんに過負荷で爆死。

squid はとてもよくできていることと、
Apache 2.2 ではその代わりは務まらないことを痛烈に認識。しくり。

**root▲ ★** · 2006/02/28(火) 16:50:52

いきなりLAが急上昇し、
プロセスを止めることもできず、そのまま無反応状態へと。>>103

squid はこのへん、きわめてよくできているんだなと。

**root▲ ★** · 2006/02/28(火) 16:58:27

あと試す余地があるのは、5.4R時代に一度試して
高パフォーマンスだったけどカーネルパニックで落ちた-lthrぐらいか。

今日明日はもうやらなくて(c-docomo系の結果を見ようかと)、
その後にでもまたぼちぼちと。

株価【750】 ▲ ◆cZfSunOs.U · 2006/02/28(火) 21:27:03

>>86 乙です．

>まず、worker MPM では httpd がどんどん暴走状態になり、だめ。
>prefork MPM では問題なく動作。

OS が 5.4R なのが問題なのか，それとも PHP5 (or eaccelerator) の
thread safety problem なのか......

あと，MultiViews も何か曲者みたいですね．まぁ元々，パフォーマンス面を考えても，
毎回 readdir(_r) することになるんで使わずに済ませられるならそうした方がいいんですけどね．

>>103-104 まぁ prefork MPM ならそんなもんかと......event MPM に
async read / write も実装した段階では Squid なみになるかも知れませんが．

>>105 Solaris でも 7 までは M:N モデルだったのが，8 では代替スレッドライブラリとして
1:1 モデルも用意されるようになり，9 からは 1:1 モデルに全面移行しましたからね．
理屈上のことはともかく，現実的には多くの場合シンプルな 1:1 モデルの方が
パフォーマンスがいいというのがその背景ということのようで．

**root▲ ★** · 2006/02/28(火) 23:33:04

http://lists.freebsd.org/pipermail/freebsd-current/2006-February/060833.html

いままさに、やってるわけか。

**root▲ ★** · 2006/02/28(火) 23:34:00

phk: い、今の-currentなら、、、(以下略
http://lists.freebsd.org/pipermail/freebsd-current/2006-February/060836.html

**root▲ ★** · 2006/02/28(火) 23:34:51

あ、そうだ。

ハードウェアの状態、どうだっただろう。

**root▲ ★** · 2006/02/28(火) 23:35:45

http://live22.2ch.net/_service/mbmon-20060228.txt

おかしかったのは、、、何時ごろだっけ。

**root▲ ★** · 2006/02/28(火) 23:40:38

http://people.freebsd.org/~phk/

がんがってほしい、、、。

**root▲ ★** · 2006/02/28(火) 23:49:18

さて、

>>106
MultiViews なしのほうが、パフォーマンス上がるということですか。
どのくらい差があるんだろう。

> まぁ prefork MPM ならそんなもんかと

…ですか。worker MPMでしたが、やはりだめでした。
aync read/write がでかいみたいです。

-lthr は、明日夜あたりに時間とれればぼちぼちというかんじで。

株価【750】 ▲ ◆cZfSunOs.U · 2006/02/28(火) 23:51:30

乙です．毎度おなじみのパターンですか......まぁ現状で打てる手はやはり mod_cache でしょうね．

http://qb5.2ch.net/test/read.cgi/operate/1140699969/814-817n
814 ：root▲ ★ ：2006/02/28(火) 23:28:57 ID:???0
　　すぐにはハードウェアの追加は見込めないから、
　　何とかしないといけないなぁ。

　　まずは、フロントに mod_cache ですね。
　　今日作業しよう。

817 ：root▲ ★ ：2006/02/28(火) 23:30:08 ID:???0
　　calcru: runtime went backwards from 1186744 usec to 1186538 usec for pid 905 (httpd)
　　pid 17287 (httpd), uid 2001: exited on signal 10
　　pid 17309 (httpd), uid 2001: exited on signal 10
　　pid 17273 (httpd), uid 2001: exited on signal 10
　　pid 17274 (httpd), uid 2001: exited on signal 10
　　pid 17279 (httpd), uid 2001: exited on signal 10
　　pid 17318 (httpd), uid 2001: exited on signal 10
　　pid 17306 (httpd), uid 2001: exited on signal 10
　　pid 17305 (httpd), uid 2001: exited on signal 10
　　pid 908 (httpd), uid 2001: exited on signal 10
　　pid 17272 (httpd), uid 2001: exited on signal 10
　　pid 1595 (httpd), uid 2001: exited on signal 10
　　pid 1597 (httpd), uid 2001: exited on signal 10

　　いつものやつか、、、。ううむ。

**root▲ ★** · 2006/02/28(火) 23:53:52

>>113
…ですね、、、。

コンソールをいつでも問題なく触ることが出来て、
時間をもっととれるなら、phk に付き合って最新の -current で人柱する、
というのもありなのかもですが、現状の私では残念ながら、無理な模様。

**root▲ ★** · 2006/03/01(水) 00:31:52

c-docomo5 の様子を観察中。

LA=4強ぐらい。
混んでいた時のnews19ぐらいですね。
一定の効果はあったのかなってかんじで。

問題は、明日以降なわけですが。

**root▲ ★** · 2006/03/01(水) 01:16:59

live22x[123] を、Apache 2.2.0 環境に更新中。

Apache 2.0.x なサーバと、read.cgi バイナリに互換性がなくなるので、
dso の配布リストから削除。
live22x1 から配布で。

**root▲ ★** · 2006/03/01(水) 01:25:24

で、kako/ はキャッシュしなくていいのかな。
Expires: と Age: を殺そうかと。

**root▲ ★** · 2006/03/01(水) 02:37:22

>>117
kako はローカルには持ってないんだった。
とりあえず設定には入れず。

で、mod_cache 化は完了のはず。
設定内容は次以降で。

**root▲ ★** · 2006/03/01(水) 02:41:20

869 名前：root▲ ★[sage] 投稿日：2006/03/01(水) 02:40:35 ID:???0
○ mod_cache 関連

/usr/local/sbin/htcacheclean -d5 -p/md/cache -l64m

を、/md 作成時に起動するようにrcファイルに追加。

<IfModule cache_module>
# configure cache directory
CacheRoot /md/cache
# configure cache expiration time
#CacheDefaultExpire 60
#CacheMaxExpire 60
# unset unneed headers
Header unset Age
Header unset Expires
</IfModule>

というファイルを作って、2ch-cache.conf という名前で Include に放り込み。

Age: と Expires: がないとそもそもキャッシュだとわからないので
(昼間BG4でしくったときに実験した)、外からみた振る舞いに変化はないはず。

**root▲ ★** · 2006/03/01(水) 02:44:45

で、肝心のキャッシュは、

CacheDisable /dome/SETTING.TXT
CacheEnable disk /dome/
CacheDisable /dancesite/SETTING.TXT
CacheEnable disk /dancesite/
CacheDisable /endless/SETTING.TXT
CacheEnable disk /endless/
CacheDisable /eq/SETTING.TXT
CacheEnable disk /eq/
CacheDisable /eqplus/SETTING.TXT
...

という、単純なもの。

**root▲ ★** · 2006/03/01(水) 02:46:02

あ、これだと、read.cgi の出力もキャッシュされるのかな。
このへんは、微妙なチューニングが必要かも。

**root▲ ★** · 2006/03/01(水) 02:47:19

で、昔やった予備実験の結果からすると、
20%～25%ぐらい、バックエンドへのアクセス数が減少するはず。

**root▲ ★** · 2006/03/01(水) 02:47:44

アクセス数というか、実際の転送回数かな。

**root▲ ★** · 2006/03/01(水) 02:50:31

http://mumumu.mu/bremen/live22.html

それなりに減ったかな。
一定の効果は出ているっぽい。

live22のログを見てみるか。
3xx なレスポンスが多くなれば、うまくいっているということかしら。

**root▲ ★** · 2006/03/01(水) 02:52:16

2xx 3xx 4xx 5xx URL
221 13 0 0*/liveanb/dat/1141148550.dat
216 13 0 0 /livevenus/dat/1141144653.dat
57 0 0 0 /liventv/dat/1141142442.dat
50 4 0 0 /news/dat/1141142585.dat
27 0 0 0 /livetbs/dat/1141142582.dat
26 7 0 0 /liveetv/dat/1141130962.dat
26 0 0 0 /news/subject.txt
23 9 0 0 /livenhk/dat/1141148068.dat
22 4 0 0 /livewkwest/dat/1141148317.dat
19 0 0 0 /livewkwest/dat/1140972656.dat
16 2 0 0 /liveskyp/dat/1141140286.dat
12 10 0 0 /liveradio/dat/1141140643.dat
11 0 0 0 /liveanb/subject.txt
11 20 0 0 /liveanb/dat/1141147805.dat

悪くなさげ。

**root▲ ★** · 2006/03/01(水) 03:22:01

携帯系(というかSquid)への副作用が発生。対応中。

**root▲ ★** · 2006/03/01(水) 03:24:05

>>119 を修正。

<IfModule cache_module>
# configure cache directory
CacheRoot /md/cache
# configure cache expiration time
#CacheDefaultExpire 60
#CacheMaxExpire 60
# unset unneed headers
Header unset Age
Header unset Expires
Header unset Cache-Control
</IfModule>

株価【750】 ▲ ◆cZfSunOs.U · 2006/03/01(水) 03:41:22

>>114-127 乙です．Squid への副作用がなぜなのかいまいちわからないですね．
ただ......各フロントごとにキャッシュの内容が新旧入り交じっていて，
Squid から取得するたびに新しいのに当たったり古いのに当たったり
バラバラだったりすると，ひょっとしておかしくなるのかな，とも......

**root▲ ★** · 2006/03/01(水) 04:31:43

>>128
なるほど。それはあるかも。

いずれにせよ、squidの振る舞いをきっちりチェックする必要ありですね。

#LoadModule cache_module libexec/apache22/mod_cache.so
#LoadModule disk_cache_module libexec/apache22/mod_disk_cache.so
#LoadModule mem_cache_module libexec/apache22/mod_mem_cache.so

にして、今日はいったん撤退。

c.2ch不具合報告総合スレ5
http://qb5.2ch.net/test/read.cgi/operate/1138289353/374
>
> squidの振る舞いについては、じっくりした調査研究が必要そう。
> たぶん、squid側から何か言われても無視するようにすればよさげな気もしますが、
> そのへんはおいおい調べるということで。

**root▲ ★** · 2006/03/01(水) 04:35:28

で、今見たら120MBytesの/mdを64MBytesまでしか使わないはずなので、
既に90MBytesちかくになっていて、どきどきしたので、

/usr/local/sbin/htcacheclean -d1 -p/md/cache -l64m

に変えた。(インターバル1分)

**root▲ ★** · 2006/03/01(水) 04:46:27

前にもsquidのキャッシュの取り扱いではちょっと悩んだことがあるので、
現在の設定をダンプしておこう。

# added override-lastmod by mumumu, 2004/7/29
#refresh_pattern . 2 0% 2 override-lastmod reload-into-ims
# shorten delay time to 1 minutes by mumumu, 2004/8/17
#refresh_pattern . 1 0% 1 override-lastmod reload-into-ims
# extend max value by mumumu, 2005/3/25
refresh_pattern . 1 0% 60 override-lastmod reload-into-ims

このスレまだ生きてた。
http://pc8.2ch.net/test/read.cgi/linux/997328024/182-183

**root▲ ★** · 2006/03/01(水) 04:49:59

http://qb5.2ch.net/operate/kako/1107/11073/1107376477.html
の、453 か。

この 60 ってのが、とってもとってもあやしいような気がしてきたのです。

ということで、今日はここまで。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/01(水) 04:58:02

Yahoo! Developer Network - PHP Developer Center
ttp://developer.yahoo.net/php/

なんてものができてたらしい

◆Reffiz2Zh. · 2006/03/01(水) 07:18:04

ttp://lists.freebsd.org/pipermail/freebsd-current/2006-February/061134.html

**root▲ ★** · NG

>>133
お、これは。

>>134
パッチですか。
ちょっと、リスト読んでみるです。

**root▲ ★** · NG

http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061137.html

> Thanks. After applying your patch, I never get calcru messages on
> 6-STABLE. It seems fine. Thanks again!

効果あるのか。

**root▲ ★** · NG

>>134
> I've been getting calcru messages on 6-STABLE when stress-testing an
> application linked with libpthread. As far as my experience goes,
> these messages are only for ones linked with libpthread. If the same
> application is linked with libthr, these messages go away.

うわってかんじなんですが。

もうちょっと調べて、たぶん試してみようかと。

**root▲ ★** · NG

>>134
http://people.freebsd.org/~davidxu/patch/calcru_r61_060227.patch

に、ゆきあたった。

**root▲ ★** · NG

>>138 を適用した。

しばらくしたら、live22 リブートの予定。

**root▲ ★** · NG

リブートした(無事上がった)。

これで、どうなるのか。

**root▲ ★** · NG

以前適用した、

#kern.timecounter.hardware=TSC

をやめた。(デフォルトのACPI-fastに戻した)

**動け動けウゴウゴ２ちゃんねる** · 2006/03/01(水) 17:45:10

http://takabsd.jp/d/?date=20070121

**動け動けウゴウゴ２ちゃんねる** · 2006/03/01(水) 17:46:46

>>142 書き込んでしまいました失礼

http://takabsd.jp/d/?date=20070121
http://dev.ariel-networks.com/blog/index.php?itemid=706
ここらの話はどうでしょう、もうやってたらすみません

**root▲ ★** · NG

>>142-143
ざっと読みました。
これはとても興味深いですね。

worker MPMはいまや使いまくりなので、相当のパフォーマンスアップが期待できると。

> ところで、APR がすでにインストールされていると、configureオプションを変えて
> 再インストールしようとしても、すでにインストールされている APR を使おうとするため、
> APR をリビルドすることができないようです。

これに気をつけないと、いかんという話もあるのか。

ちょっと、調べてみるです。

**root▲ ★** · NG

.if defined(WITH_THREADS)
CONFIGURE_ARGS+= --enable-threads
. if ${OSVERSION} > 500023
. if ${ARCH} == i386
CONFIGURE_ARGS+= --enable-nonportable-atomics
. endif
. endif
.endif

となっているのか。< portsのMakefile

問題は、これが有効になっているかだが、、、。

**root▲ ★** · NG

. if ${WITH_MPM} != "prefork"
PKGNAMESUFFIX= -${WITH_MPM:L}
WITH_THREADS= yes
WITH_THREADS_MODULES= yes
WITHOUT_MODULES+= cgi
...

なのか。< Makefile.modules

**root▲ ★** · NG

%nm /usr/local/lib/libapr-1.so.2 | grep atomic
0000ddf0 T apr_atomic_add32
0000dddc T apr_atomic_cas32
0000deb0 T apr_atomic_casptr
0000de10 T apr_atomic_dec32
0000de24 T apr_atomic_inc32
0000de58 T apr_atomic_init
0000df20 T apr_atomic_read32
0000de38 T apr_atomic_set32
0000de00 T apr_atomic_sub32
0000de48 T apr_atomic_xchg32

入っている模様。

で、mod_mem_cache はこれで動いている模様。

httpd は、、、。

**root▲ ★** · NG

…入っているようです。
(都合上、適宜折り返し)

configured by ./configure, generated by GNU Autoconf 2.59,
with options \"'--enable-layout=FreeBSD' '--with-perl=/usr/local/bin/perl5.8.7
' '--with-port=80' '--with-expat=/usr/local' '--with-iconv=/usr/local' '--enable
-http' '--enable-v4-mapped' '--with-dbm=sdbm' '--with-ssl=/usr' '--enable-thread
s' '--enable-nonportable-atomics' '--with-mpm=worker' 'i386-portbld-freebsd6.0'
(以下略)

…ということで、ports猿マンセー状態だったということか。

**root▲ ★** · NG

しかし、勉強になりました。

ということはちゃんと動くんなら、worker MPM(や将来はevent MPM)のほうが、
パフォーマンスアップするということですね。

www.2ch.net/menu.2ch.net がサーバ更新後に異様に軽くなった理由が、
相当わかった気がします。worker MPMの力だけかと思っていたけど、そういう理由だとは。

**root▲ ★** · NG

>>149 補足

もちろん、www2.2ch.net が仲間から抜けたことも相当大きいですが。

**root▲ ★** · NG

で、このコードって >>145 っていうぐらいで、i386 の時しか有効にならないのね。
cobra2247 をバックエンドに仕立てる次期計画を考えると、
amd64 でも動いてほしいなとか思ったり。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/02(木) 00:52:21

[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:09.openssh
http://lists.freebsd.org/pipermail/freebsd-announce/2006-March/001049.html

対象はFreeBSD5.3と5.4のOpenSSHだそうで．

**動け動けウゴウゴ２ちゃんねる** · 2006/03/02(木) 02:32:09

FreeBSD-SA-06:10.nfs もきたね。
[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:10.nfs
http://lists.freebsd.org/pipermail/freebsd-announce/2006-March/001050.html

こっちはAll FreeBSD releases.が対象、だけど、nfsつかっているんだっけ？

**動け動けウゴウゴ２ちゃんねる** · 2006/03/02(木) 04:19:56

結構workerで動くもんなのだね。。

/* むやみに6.0にしたくなったけどMySQLの都合で出来ずorz */

bbs.cgiのSpeedyCGIはmod_speedycgiじゃないよね？
毎回プロセス起動のほう？

株価【650】 ▲ ◆cZfSunOs.U · 2006/03/02(木) 07:46:50

>>139-140 これで "calcru: runtime went backwards......" が出なくなれば，一つ山を越えることになると......

>>151 apr_atomic.c で↓のようになってるんで，AMD x86-64 でも行けるかなと．

#if (defined(__i386__) || defined(__x86_64__)) \

>>154 http://qb5.2ch.net/test/read.cgi/operate/1105909861/477-479n

話は変わりますが，mod_load_average なんてものがあるようで．
http://svn.force-elite.com/svn/mod_load_average/trunk/src/mod_load_average.c
http://www.mail-archive.com/dev@httpd.apache.org/msg31056.html
This way you could disable CGI when your LA is above 10,
and then disable everything when your LA is above 100:
LoadAvgMaxByHandler cgi-script 10
LoadAvgMax 100

**root▲ ★** · 2006/03/02(木) 11:15:35

おはよござます。

>>152
PAMとのconflictでうんぬんですか。
昔なら「FreeBSD only」っぽい(この項目いつの間にかなくなったっぽい?)やつかも。
状況からして、当てる必要ありで。

>>153
2ch/BBSPINKではNFSは使っていないので、
こっちは急ぐ必要ないですね。

**root▲ ★** · NG

>>154
私自身、結構驚いていたり。
前スレにも書きましたが worker MPM については、

5.2.1R 論外
5.3R だめだめ
5.4R 一応動くけど挙動不審
6.0R 今のところ大きな問題なし

という感じのようです。

> bbs.cgiのSpeedyCGIはmod_speedycgiじゃないよね？
> 毎回プロセス起動のほう？

毎回プロセス起動のほうです。
mod_ のほうは、worker MPM では動かないはず。

あと２ちゃんねるみたいな使い方(= CGIはばりばりいじられる、
全サーバのroot権限があるわけではない)だと、
プロセス起動にしておいたほうが、いろいろな意味で安全ですね。

mod_ な環境でCGI が暴走すると httpd を kill しなきゃならないので、
root 権限なかったりすると面倒です。
プロセス起動なら、speedy_backend を kill すればよいわけで。

**root▲ ★** · NG

>>155
> >>139-140 これで "calcru: runtime went backwards......" が出なくなれば，
> 一つ山を越えることになると......

そう願いたいですね。
今週は日曜夜に巨大なトラフィックがある模様。

> >>151 apr_atomic.c で↓のようになってるんで，AMD x86-64 でも行けるかなと．
> #if (defined(__i386__) || defined(__x86_64__)) \

なるほど、使えるですか。

> 話は変わりますが，mod_load_average なんてものがあるようで．

ちょっとそのスレッド読んでみました。
より細やかな制御ができると。

今は read.cgi / bbs.cgi とも LA チェック入っているので急務ではないですが、
使う機会は別にあるのかもなと。

**154** · 2006/03/02(木) 14:45:17

>>157
うーん、やはり6.0はあなどれないな。。
5.2以前のネイティブスレッドは一つのスレッドのI/Oが大きいと
他のスレッドがたちまち遅くなるっていう致命を持った貧弱さだから。。

でも5.3でもだめなんだ。うーん、うちんとこは5.4だからここはpreforkのままでいくしかないな。。

一度workerMPMで動かしたことがあって、あのプロセス数:最大接続数の多さを見たときには感激したけど、
C++で書いたCGI+mod_cgidsoのどっかの動作でMT-safeでなかったらしくApacheが暴れたことがあり(preforkならOK)orz

MT-safeな書き方を学ぼうと思ってついに2006年の春を迎えてしまった。

Thread-safeってすごく便利だけど、やっぱり対応が未だ少ないのがネックか('д`)

**root▲ ★** · 2006/03/02(木) 15:18:11

>>159
> でも5.3でもだめなんだ。

…でした。
ちょっと前に news19 で試したんですが、SIGBUSで落ちまくりで
5分ぐらい掲示板が超挙動不審になってしまい、livemarket1 の住民さんに
「昼間のザラ場の時間にメンテなんて何考えてるんだ !!」って、
ものすごい勢いでおこられました。

デイトレーダーの人たちはどうやらものすごい勢いで、
この掲示板に強く依存しているようです。

MT-safe は、たぶん何かすごくこつがあるんでしょうね。
errno が普通の方法では参照できないとかいうので目からうろこが落ちてるようじゃ、
たぶん、全然だめなんだろうなと。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/02(木) 15:47:11

>>160

> 5分ぐらい掲示板が超挙動不審になってしまい、livemarket1 の住民さんに
> 「昼間のザラ場の時間にメンテなんて何考えてるんだ !!」って、
> ものすごい勢いでおこられました。

そんな時間に株系の板で実験ですか
予告してやったんでしょうか？
でなきゃ{起こ|怒}るのも当たり前でしょう・・・・

> デイトレーダーの人たちはどうやらものすごい勢いで、
> この掲示板に強く依存しているようです。

ワロス

**FAX ★** · 2006/03/02(木) 16:27:11

怒り爆発

**root▲ ★** · NG

>>162
む、、、。何か、私まずいことしたのかしら。

**FAX ★** · 2006/03/02(木) 16:54:13

いえいえ

**動け動けウゴウゴ２ちゃんねる** · 2006/03/02(木) 22:09:19

困るrootたん萌えってことで
むぎゅって言って(*´Д｀)

**root▲ ★** · NG

Saru: Active-Active
http://ultramonkey.jp/papers/active_active/active_active.shtml

これがFreeBSD+matdでもできるようになると、とてもいいなぁとおもた。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/03(金) 04:06:52

なんとなく、pf(4)を駆使すれば似たようなことができるような気がする。
NATでだけど。
http://www.openbsd.org/faq/pf/
http://www.openbsd.org/faq/pf/pools.html

**root▲ ★** · NG

サーバダウン(鯖落ち）情報　part94
http://qb5.2ch.net/test/read.cgi/operate/1140710423/325
の件、、、。

live22x[123] の matd 化に向けて、httping(*1)で応答時間を監視していて、
(*1: http://www.vanheusden.com/httping/ )
10パケットに1パケット程度、数秒のディレイが起きていることに気づきました。

で、banana403でdevice_polling(4)を試そうと決め、
もしリブートでしくってもheartbeatによりbanana404にフェイルオーバーするはずだと、
リブートをかけました。

しかし、いつもとリブートの感じが違いました。
いつもはputtyの窓がちゃんと閉じるのですが、今回は閉じずに
ただ反応だけがなくなりました。

で、banana404へのフェイルオーバーは起きたのですが、
「俺のIPアドレスを別のやつ(banana403)も名乗っているぞ」というエラーが404で出始めました。

(続く)

**root▲ ★** · NG

で、「これはおかしいぞ」と思い、
一度 banana404 のリブートもかけてみようと思い立ちました。
(今思うとこれがまずかったと思われ)

で、banana404 は設定を変えずに、単に reboot コマンドでリブートしました。
しかしなぜか、さきほどの banana403 と同じ状態になりました。
つまり窓が閉じずに、反応だけがなくなる状態になりました。
ここで本能的に「まずい」と思いました。

案の定、両方のサーバともサービスがない状態になり、
www2.2ch.net は止まった状態になりました。
で、現在に至ります。

(続く)

**root▲ ★** · NG

今調べてみると、

banana403 実IPアドレス … ping かかる
banana403 実IPアドレス … ping かかる
サービス用 IP アドレス(www2.2ch.net) … ping かかる

という状態にあるようです。
しかし、どのサービスも応答しない状態になっています。

推測ですが、これはリブートではなく、シャットダウンの途中で止まっている
ように思えます。つまり、何らかの理由でシャットダウンできていない。
いつもは閉じる窓が閉じなかった(つまり向こうからTCPのセッションを切ってこなかった)
ことから、ほぼ間違いないと思います。

しかし、設定を変えたbanana403はともかく、
設定を全く変えていないbanana404でも同じことが起きたのは、
かなり不可解です。

heartbeatが悪さをしたのか、
あるいは、remote KVMとかが悪さをしたのか、
あるいは他の原因か、、、。

いずれにせよ現在、remote KVMにアクセスできない状態なので、
(さきほどやってみましたがだめでした。これはSeanさんにさきほど問い合わせしました)
コンソールの状況を確認できないです。

以上が現在の状況です。ううむ、、、。

**root▲ ★** · NG

> (さきほどやってみましたがだめでした。これはSeanさんにさきほど問い合わせしました)

Seanさんから返事が来て、無事にKVMにアクセスできました。

やはりbanana403/404とも、シャットダウンの途中でしくっていました。
というか、Rebooted by ... というシステムログが出て、
プロセスは切られているのに、そこから先に進まない状態。

直感ですが、matd がというか、
たぶんヘビーなパケット処理により、カーネルが何らかの形で止まっているっぽいです。

**root▲ ★** · NG

…ちとまじで限界なので、
ここから先はリブートの中の人に403/404の両サーバをリブートいただいた後に、
別途リブート入れて検証してみることにするです。ううむ。

株価【650】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 07:09:39

>>166-167 フェイルオーバしつつロードバランスもするって感じなんでしょうか．興味深いですね．

>>168-172 う～む......matd の挙動も要観察ですかね．パケットのドロップが発生してるのかどうかとか......

株価【650】 ◆OSfanJsSVc · 2006/03/03(金) 07:57:16

Apache2.2.0の機能でプロセスが終わらないとサービスが切れない機能？があるらしいです。

無理矢理切ってエラー発生して結局システム真紀子み止まった。

てな感じかと｡｡｡

**動け動けウゴウゴ２ちゃんねる** · 2006/03/03(金) 10:31:49

> デイトレーダーの人たちはどうやらものすごい勢いで、
> この掲示板に強く依存しているようです。

デイトレーダーの人はモリタポ買ってね！
と言っても良さそうな気がして来た。

**root▲ ★** · NG

無事(device_pollingしたほうも)上がりました。

>>173
ちと、じっくり調べてみるです。

>>174
今回のサーバではApache 2.0系で、CGI動かしてないです。

**root▲ ★** · NG

WARNING: / was not properly dismounted

両サーバとも、やはり正しく落ちなかった模様。

**root▲ ★** · NG

354 名前：root▲ ★[sage] 投稿日：2006/03/03(金) 11:43:48 ID:???0 ?#
ふうむ、device polling ありだと、うまくないのね。
なし(前の状態)にしたら、つながりました。

まだよくわかりませんが、
device polling はいまやなしのほうが、よさげなのかも。

**root▲ ★** · NG

で、いろいろ変えてみる前に、
まずは今の設定での効率を調べて、状況をきちんと把握する

ことから始めようと。

ということで、httping -c 100 -g http://www2.2ch.net/ の結果(cvsup.peko.2ch.netから)

connected to www2.2ch.net:80, seq=73 time=18.44 ms
connected to www2.2ch.net:80, seq=74 time=3014.49 ms
(略)
connected to www2.2ch.net:80, seq=75 time=21.35 ms
timeout receiving reply from host
connected to www2.2ch.net:80, seq=77 time=16.91 ms
connected to www2.2ch.net:80, seq=78 time=14.07 ms
(略)
connected to www2.2ch.net:80, seq=87 time=17.59 ms
connected to www2.2ch.net:80, seq=88 time=11.90 ms
connected to www2.2ch.net:80, seq=89 time=3017.84 ms
connected to www2.2ch.net:80, seq=90 time=3015.85 ms
(略)
connected to www2.2ch.net:80, seq=96 time=471.73 ms
connected to www2.2ch.net:80, seq=97 time=6219.80 ms
connected to www2.2ch.net:80, seq=98 time=15.69 ms
connected to www2.2ch.net:80, seq=99 time=19.33 ms
--- http://www2.2ch.net/ ping statistics ---
100 connects, 99 ok, 1.00% failed
round-trip min/avg/max = 11.7/449.1/6219.8 ms

**root▲ ★** · NG

同じく、www.2ch.net

connected to www.2ch.net:80, seq=94 time=2.66 ms
connected to www.2ch.net:80, seq=95 time=2.71 ms
connected to www.2ch.net:80, seq=96 time=2.67 ms
connected to www.2ch.net:80, seq=97 time=2.72 ms
connected to www.2ch.net:80, seq=98 time=2.69 ms
connected to www.2ch.net:80, seq=99 time=2.84 ms
...
--- http://www.2ch.net/ ping statistics ---
100 connects, 100 ok, 0.00% failed
round-trip min/avg/max = 2.6/2.8/4.6 ms

**root▲ ★** · NG

同じく、live22x.2ch.net

connected to live22x.2ch.net:80, seq=95 time=3.17 ms
connected to live22x.2ch.net:80, seq=96 time=3.26 ms
connected to live22x.2ch.net:80, seq=97 time=3.54 ms
connected to live22x.2ch.net:80, seq=98 time=3.13 ms
connected to live22x.2ch.net:80, seq=99 time=2.97 ms
--- http://live22x.2ch.net/ ping statistics ---
100 connects, 100 ok, 0.00% failed
round-trip min/avg/max = 3.0/3.2/6.3 ms

**root▲ ★** · NG

で、感想ですが、

matd はユーザランドで動いているせいか、15ms～18ms 程度
遅延が生じるようです。(これは想定内)

しかし、たまにがくっと遅くなることがあります。(想定外です)
>>179 では100カウントやって、1つタイムアウトになりました。
これの原因が知りたいところです。

banana403 や banana404 からやってみればいいのかな。

このへんで、まずはめしを。

株価【650】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 12:58:33

>>182
>matd はユーザランドで動いているせいか、15ms～18ms 程度
>遅延が生じるようです。(これは想定内)

ユーザランドということもあるかも知れませんが，
http://qb5.2ch.net/test/read.cgi/operate/1121886018/901
　　>アプリとして動くみたいなので、カーネルとの切り替えがばかにならないのかなと。
　　>(パケット1個単位で切り替えですよね。)

　　FreeBSD では BPF，Solaris では bufmod によるバッファリングが効いて
　　パケット取り込みはある程度まとめて行われると思いますが，
　　パケットの取りこぼしとか発生しないかどうかってのは，正直わかりません......

のようにバッファリングしてるわけですが，その際の待ち時間が最大 10ms に
なっているので，それもあるかも知れません．

>しかし、たまにがくっと遅くなることがあります。(想定外です)
> >>179 では100カウントやって、1つタイムアウトになりました。
>これの原因が知りたいところです。

何らかの原因でパケットの取りこぼしが発生していることも考えられますが，
そうだとするとなぜ取りこぼすのか（処理が追い付かないのか，それとも別の要因か）ってのが問題ですね．

**root▲ ★** · NG

>>183
> のようにバッファリングしてるわけですが，その際の待ち時間が最大 10ms に
> なっているので，それもあるかも知れません．

なるほど、なるほど。

> 何らかの原因でパケットの取りこぼしが発生していることも考えられますが，
> そうだとするとなぜ取りこぼすのか（処理が追い付かないのか，それとも別の要因か）
> ってのが問題ですね．

そうですね。まさにこれを調べたいということで。

**root▲ ★** · NG

そもそも、普通のpingがいまいちであるらしいことに気がついた。

...
64 bytes from 206.223.150.74: icmp_seq=4 ttl=64 time=0.175 ms
64 bytes from 206.223.150.74: icmp_seq=5 ttl=64 time=0.264 ms
64 bytes from 206.223.150.74: icmp_seq=6 ttl=64 time=0.242 ms
64 bytes from 206.223.150.74: icmp_seq=7 ttl=64 time=0.205 ms
64 bytes from 206.223.150.74: icmp_seq=9 ttl=64 time=0.273 ms
64 bytes from 206.223.150.74: icmp_seq=10 ttl=64 time=0.234 ms
64 bytes from 206.223.150.74: icmp_seq=11 ttl=64 time=0.214 ms
64 bytes from 206.223.150.74: icmp_seq=12 ttl=64 time=0.195 ms
64 bytes from 206.223.150.74: icmp_seq=13 ttl=64 time=0.155 ms
64 bytes from 206.223.150.74: icmp_seq=14 ttl=64 time=0.259 ms
...
--- live22y.2ch.net ping statistics ---
30 packets transmitted, 28 packets received, 6% packet loss
round-trip min/avg/max/stddev = 0.155/0.222/0.287/0.036 ms

株価【650】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 13:37:06

tcpdump とかで，httping かけてる時の banana403 / banana404 上でのパケットの流れ見てみるとか
......と言おうと思ったら

>>185 う～む，これはネットワークとかの問題でしょうか？

**root▲ ★** · NG

>>186
XOの高性能スイッチに繋がっているサーバの間の通信について、
パケットがきちんと通っているか、精査してみます。

**root▲ ★** · NG

おさらい: XOの２ちゃんねるラックにあって、高性能スイッチに繋がっているサーバ

サーバ名ホスト名接続I/F一覧
○雪だるま系 206.223.150.0/24 192.168.100.0/24
tiger503 live22x4 em0/em1
tiger507 live22x5 em0/em1
tiger2522 live22 em0/em1
tiger2523 live22x1 em0/em1
tiger2524 live22x2 em0/em1
tiger2525 live22x3 em0/em1
banana403 live22b1/www2 fxp0 fxp1
banana404 live22b2/www2 fxp0 fxp1

○携帯系 206.223.150.0/24 192.168.0.0/24
tiger511 blackgoat3 em0/em1
tiger512 blackgoat4 em0/em1
tiger2507 c-au4 em0/em1
tiger2508 c-au5 em0/em1
tiger2509 c-au6 em0/em1
tiger2510 c-docomo5 em0/em1
tiger2511 c-docomo6 em0/em1
tiger2512 c-docomo7 em0/em1
banana405 c-others1/c1 fxp0 fxp1
banana406 c-others2/c2 fxp0 fxp1

○どちらでもない系
tiger504 game10 em0
tiger509 news19 em0
tiger510 hobby7 em1
cobra2245 bbq bge0
(banana402 stock fxp0) 移動済みのはずだが、こないだの全停電でなぜか通信が途絶えた

**root▲ ★** · NG

まずは雪だるま系のパブリック側。
ping -c 30 サーバ名を実行

tiger2522 から、
tiger2523 ○
tiger2524 ○
tiger2525 ○
tiger503 ×
--- tiger503.maido3.com ping statistics ---
30 packets transmitted, 26 packets received, 13% packet loss
round-trip min/avg/max/stddev = 0.123/0.206/0.274/0.051 ms
tiger507 ○
banana403 ×
--- banana403.maido3.com ping statistics ---
30 packets transmitted, 27 packets received, 10% packet loss
round-trip min/avg/max/stddev = 0.135/0.192/0.298/0.031 ms
banana404 ×
--- banana404.maido3.com ping statistics ---
30 packets transmitted, 24 packets received, 20% packet loss
round-trip min/avg/max/stddev = 0.135/0.229/0.309/0.044 ms

**root▲ ★** · NG

>>188 修正

サーバ名ホスト名接続I/F一覧
○雪だるま系 206.223.150.0/24 192.168.100.0/24
tiger503 live22x4 em0/em1
tiger507 live22x5 em0/em1
tiger2522 live22 em0/em1
tiger2523 live22x1 em0/em1
tiger2524 live22x2 em0/em1
tiger2525 live22x3 em0/em1
cobra2247 未割り当て bge0/bge1
banana403 live22b1/www2 fxp0 fxp1
banana404 live22b2/www2 fxp0 fxp1

○携帯系 206.223.150.0/24 192.168.0.0/24
tiger511 blackgoat3 em0/em1
tiger512 blackgoat4 em0/em1
tiger2507 c-au4 em0/em1
tiger2508 c-au5 em0/em1
tiger2509 c-au6 em0/em1
tiger2510 c-docomo5 em0/em1
tiger2511 c-docomo6 em0/em1
tiger2512 c-docomo7 em0/em1
banana405 c-others1/c1 fxp0 fxp1
banana406 c-others2/c2 fxp0 fxp1

○どちらでもない系
tiger504 game10 em0
tiger509 news19 em0
tiger510 hobby7 em1
cobra2245 bbq bge0
(banana402 stock fxp0) 移動済みのはずだが、こないだの全停電でなぜか通信が途絶えた

**root▲ ★** · NG

>>189 に追加。

cobra2247 ○

**root▲ ★** · NG

banana403 から、
banana404 ○
tiger503 ○
tiger507 ×
--- tiger507.maido3.com ping statistics ---
30 packets transmitted, 24 packets received, 20% packet loss
round-trip min/avg/max/stddev = 0.135/0.214/0.270/0.038 ms
tiger2522 ×
--- tiger2522.maido3.com ping statistics ---
30 packets transmitted, 28 packets received, 6% packet loss
round-trip min/avg/max/stddev = 0.135/0.197/0.259/0.037 ms
tiger2523 ×
--- tiger2523.maido3.com ping statistics ---
30 packets transmitted, 27 packets received, 10% packet loss
round-trip min/avg/max/stddev = 0.148/0.207/0.316/0.042 ms
tiger2524 ×
--- tiger2524.maido3.com ping statistics ---
30 packets transmitted, 26 packets received, 13% packet loss
round-trip min/avg/max/stddev = 0.136/0.206/0.375/0.048 ms
tiger2525 ×
--- tiger2525.maido3.com ping statistics ---
30 packets transmitted, 26 packets received, 13% packet loss
round-trip min/avg/max/stddev = 0.132/0.204/0.386/0.053 ms
cobra2247 ×
--- cobra2247.maido3.com ping statistics ---
30 packets transmitted, 27 packets received, 10% packet loss
round-trip min/avg/max/stddev = 0.117/0.208/0.423/0.063 ms

**root▲ ★** · NG

これは、、、。

2つの「うまく通信できるグループ」があって、
その間のパケットはぼろぼろロストしてるってことなのか?

グループA tiger507 tiger2522 tiger2523 tiger2524 tiger2525 cobra2247
グループB tiger503 banana403 banana404

株価【850】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 15:03:06

>>187-193 乙です．となると......スイッチがおかしいとか？

**root▲ ★** · NG

原因切り分けのため、
まったく関係ないところ(XOの外: PIE内部)からやってみた。

banana273 [206.223.147.225] から、

tiger2522 ○
tiger503 ×
--- tiger503.maido3.com ping statistics ---
30 packets transmitted, 25 packets received, 16% packet loss
round-trip min/avg/max/stddev = 1.280/1.428/1.766/0.116 ms
banana403 ×
--- banana403.maido3.com ping statistics ---
30 packets transmitted, 28 packets received, 6% packet loss
round-trip min/avg/max/stddev = 0.658/0.899/2.144/0.365 ms
banana404 ×
--- banana404.maido3.com ping statistics ---
30 packets transmitted, 28 packets received, 6% packet loss
round-trip min/avg/max/stddev = 0.675/0.764/1.148/0.091 ms

tiger503, banana403, banana404 だけがおかしい、で正解ですね。
でも、相互の通信はうまくいくと。

スイッチの設定上の問題の予感がします。
もう少し調べてから、状況(問題発生)をSeanさんにエスカレーションする方向で。

で、ここまでやっておじさんが
「stock (= banana402) と be (= ブラジル)との間の通信が微妙」と言っていたのを
思い出しました。

banana402は移動したと言っていますが、この間の電源トラブルのときに
巻き添えで落ちたので、同じスイッチに(あいかわらず)繋がっているのかもしれません。
これもあわせて、調べてみます。

**root▲ ★** · NG

> banana402は移動したと言っていますが、この間の電源トラブルのときに
> 巻き添えで落ちたので、同じスイッチに(あいかわらず)繋がっているのかもしれません。
> これもあわせて、調べてみます。

わーい、だめだこりゃ。

--- banana402.maido3.com ping statistics ---
30 packets transmitted, 23 packets received, 23% packet loss
round-trip min/avg/max/stddev = 0.665/0.734/0.801/0.041 ms

**root▲ ★** · NG

ちょっとひどそうなので、
>>190 のやつ全部、調べなおす方向で。

で、XOだけならいいんだけどということで、age。

● ◆ANGLERlqvM · NG

なるほど、今までの不思議に思っていたことが
何か見えてくるかもしれませんね。

株価【450】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 15:20:32

matd の挙動調査から思わぬ展開に......
でもまぁこういう問題を発見できたのはよかったと．

● ◆ANGLERlqvM · NG

>>199
そうですね。
こういうのは、何かきっかけが無いと分かりにくいですから。
問題が発見できたのは良かったと思います。