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

この機会にex11のメモリディスクを、

md /md mfs rw,nosuid,noatime,-s128m,-i2048 0 0

と/etc/fstabに書く形から、

/sbin/mdmfs -S -M -s 128m -i 2048 -o noatime,async md /md

とスタートアップ時に設定する形に変えてみた。

・swapではなくて実記憶を直接mallocで与える
・softupdateの処理をしない
・書き込みを非同期モードに

これで、/md のパフォーマンスアップができればいいなと。

>これで、/md のパフォーマンスアップができればいいなと。

何がいけにえになるんですかねぇ?

>>326
メモリディスクに、実記憶を割り当てるということです。

FreeBSDのメモリディスク(md)には、4つモードがあります。

man mdによると、

malloc Backing store is allocated using malloc(9). Only one malloc-
bucket is used, which means that all md devices with malloc
backing must share the malloc-per-bucket-quota. The exact size
of this quota varies, in particular with the amount of RAM in
the system. The exact value can be determined with vmstat(8).

preload A file loaded by loader(8) with type `md_image' is used for
backing store. For backwards compatibility the type `mfs_root'
is also recognized. If the kernel is created with option
MD_ROOT the first preloaded image found will become the root
file system.

vnode A regular file is used as backing store. This allows for mount-
ing ISO images without the tedious detour over actual physical
media.

swap Backing store is allocated from swap space.

で、一番下がこれまでのジンギスカンで使っているもので、
今回それを一番上にしたということです。

で、簡単にいうと、swap方式だと、システムの状況によっては
HDD(スワップ領域)を触る可能性があるということです。

malloc方式だと、それは起こりません。

ということで、メモリが2Gあってそのうちの128Mとか160Mとか割り当てる形なら、
こちらの方がパフォーマンスが出るのではないかという考えです。

あとの設定変更2つは、基本的にはHDDでやっているデータ破損防止処理を
メモリディスクではオフにしよう(意味ないし)ということです。
これはたぶん、今のジンギスカンにもすぐに応用できるはず。

ということで、実記憶というかカーネルのmalloc領域を直接使うので、
メモリが貧しいサーバだと設定内容によってはどきどきするかも、というのが、
いけにえってことになるですね。

512Mに32Mとかなら、bananaでもやってみる価値はあるかも。

mdでsoftupdateをasyncにするってのは確かにありかも。
でもmdだと「光の速度1/10だったのが1/9.5に成りました」という領域に近い気配。

サーバダウン(鯖落ち）情報　part81
http://qb5.2ch.net/test/read.cgi/operate/1129187861/55

> The FreeBSD Projectは、いくつかの抜本的開発を進めるために
> FreeBSD 5系の開発に長い時間をかけてきた。FreeBSD 5系で
> 目標としてきた実装にある程度目処が立ちシステムが安定してきたことから、
> The FreeBSD Projectは早めにFreeBSD 5系をFreeBSD 6系に移行させ、
> currentをFreeBSD 7系、stableをFreeBSD 6系という本来の開発体制に
> 戻したい意向だ。これまではFreeBSD 4系とFreeBSD 5系を同時に対処するなど、
> 開発チームに高い負荷がかかっていた。

やはり、5系を早くやめて、安定(運用)系は6系に移行させたいってことで。
そううまくいくかは、6.0Rの出来にかかっているのかなと。

>>331
そう思っていたんですが、特にファイルシステムがGiant lockで動くシステムだと、
結構影響はあるみたい。

一度、ベンチかBG系あたりでテストでもってかんじで。

Apache 2.0.55 Released

重い重い重い重い重い重い重い×34＠運用情報
http://qb5.2ch.net/test/read.cgi/operate/1127144824/218-

設定変更後、好調に動いていたex11のメモリディスクのmallocモードですが、
今日突然、メモリディスクが劇重に。

で、従来のswapモードに戻したところ、軽くなった。
うーむ。ひょっとしてまた虫を踏んでしまったのか。

いやー

そんなにうまい話はないんでないかい。
何かを得るにはなにか生贄が必要なのは太古から変わっていないかと、

と、おじぃさんがいってました。

ex11のメモリディスク、
softupdate off + async を
softupdate on に戻したら、軽くなった。

この条件で使う限り、softupdate のほうが、
async よりも圧倒的にコストが低いということになります。
書き込み(bbs.cgi)のCPU使い具合やはけ具合が、全然違う。

しかし、なんでだろう。

そうやって使うことが前提だからとか単純な理由だったりしたらﾜﾛｽ

buffer -> sync(softupdates) -> md
は単に速いHDDとして使えるけど。
buffer -> async -> md
はsoftupdatesでやっているキューの整理が入らないからか？

HDDの書き込みという桁違いのボトルネックがあればasyncは速いけど、mdだと整理していない分遅いとかか。

>>338
連続したメモリ領域のアクセスのほうが効率がいいとか、
そういう話なのかしら。

>>339
ですかねー

>>338でもいっているようにソートしてあればmdは絶大な威力を発揮、
てんでんばらばらな追記だとファイルシーク（という言い方があっているか微妙）に
(通常のメモリアドレス検索より)激しく時間を食うのでそのぶん重くなりやすいってことなんですかね

Hello Sean-san,
Cc: 2ch guys,

Since about several hours ago, outgoing network performance of tiger505
has been bad (it is reported by many 2ch users).

I checked the network performance of tiger505, and I verified it is
certainly occurred.

I did the performance test by using ftp, and I detected outgoing
network performance has been bad, as follows:

- other servers => tiger505 is good. (it is about 100Mbps)
- tiger505 => other servers is bad. (it is about 50Mbps)

I verified the network setting of tiger505 is still set to 100Mbps
full-duplex (Of course, I don't change the network setting on tiger505).
And I feel the suspicious network delay when I am working on tiger505
via remote login

I checked the network performance by ping from other servers at PIE, and I
detected suspicious delays are occured the response packet as follows:

64 bytes from 206.223.150.120: icmp_seq=104 ttl=63 time=1.105 ms
64 bytes from 206.223.150.120: icmp_seq=105 ttl=63 time=0.569 ms
64 bytes from 206.223.150.120: icmp_seq=106 ttl=63 time=0.642 ms
64 bytes from 206.223.150.120: icmp_seq=107 ttl=63 time=0.567 ms
64 bytes from 206.223.150.120: icmp_seq=108 ttl=63 time=31.387 ms <=
64 bytes from 206.223.150.120: icmp_seq=109 ttl=63 time=0.719 ms
64 bytes from 206.223.150.120: icmp_seq=110 ttl=63 time=0.616 ms

Probably, it is the cause of the trouble I think.
Please check and fix it.

Regards,

life7からnews19をpingした結果

--- news18.2ch.net ping statistics ---
1049 packets transmitted, 1049 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.449/2.629/153.439/13.277 ms

やはり、変なパケット遅延がありますね。
これが全体の足を引っ張っています。

スイッチの問題のようかん。

news19じゃなくてnews18の間違い。>>342 1行目

Sean-san,

Thank you. I detected some other PIE servers have the same trouble.
I detected the same situation on banana601 and banana388.
But banana201 is probably normal.

I will also check the network performance on 2ch servers and I will
report to you the result sooner or later.

And I have an information. These banana601, 388 and tiger505 servers
have the same condition.

- network I/F configures 100Mbps full duplex
- 'incoming' traffic is no problem.
- 'outgoing' traffic is low performance now.

I think it may help you.

Regards,

life7 <=> memories は、双方向とも問題なしでした。
memoriesから、計測してみるか。

oyster901 901 243 異常なし
cobra2244 2245 2246 2247 異常なし

tiger503 504 506 507 508 509 510 511 512 異常なし
tiger505 おかしい

tiger2507 2508 2509 2510 2511 2512 2513 2522 2523 2524 2525 異常なし

banana201 238 異常なし

さて、bananaは多いですね。

おかしいサーバ

qa
etc3
live14
tmp5
comic6
food6
society3

他の掲示板banana(2ch/bbspink)は、とりあえず正常。
banana的正式名称は、、、。

qa = 386
etc3 = 601
live14 = 386
tmp5 = 390
comic6 = 388
food6 = 389
society3 = 382

http://sv2ch.baila6.jp/sv2ch02.html　より

>>352
ありがとうです。

Sean-san,
Cc: 2ch guys,

> I will also check the network performance on 2ch servers and I will
> report to you the result sooner or later.
>
> And I have an information. These banana601, 388 and tiger505 servers
> have the same condition.

I checked all servers for 2ch and following seven servers' network
performance is bad.

cobra: (There are no bad servers)
tiger: tiger505
banana: banana382 banana386 banana388 banana389 banana390 banana601

The situation of above servers are the same, the outgoing network
performance is bad.

Probably, I think their servers are connected the same edge switch.
Please investigate and fix it.

Regards,

Ok, I will do.
-- Mumumu

> Please check them again. I think all will be ok now.
> -Sean

tiger505 修正確認。
他はこれから調査。

>>352 の全サーバのパフォーマンスが元通りになったことを確認。
障害は修正されたと思います。

経過観察で。

最近、この類の障害が続いてますね。。

Sean-san,

I briefly checked all following servers are OK.
Thank you for you work.

And I want to know how do you solve the problem.
Do you change the edge switch?

-- Mumumu <[email protected]>

>>358
Seanさん、結構忙しいみたい。

で、私はこれから仕事で外出なので、またあとで。

はい、お疲れ様でした。

784 ：root▲ ★ [sage] ：2005/10/25(火) 20:18:20 ID:???0
障害はSeanさんにより修復されました。
今は、正常のはず。

http://qb5.2ch.net/test/read.cgi/operate/1127144824/784

6.0-RC2を出す気でいるらしい。

Build 6.0-RC2 TBD
-- Begin building the second release candidate build for all Tier-1 platforms.
Release 6.0-RC2 TBD
-- 6.0-RC2 tier-1 platform images released, and uploaded to ftp-master.FreeBSD.org.

http://www.freebsd.org/releases/6.0R/schedule.html

はやーなー。

え？RC-2出すんですか。。。

http://lists.freebsd.org/pipermail/freebsd-stable/2005-October/019056.html

(AA略。

で、

これと、
http://lists.freebsd.org/pipermail/freebsd-stable/2005-October/019060.html

これに、ちょっとわろた。
http://lists.freebsd.org/pipermail/freebsd-stable/2005-October/019064.html

リリースするぞぇ。
はい直した。
はい直した。



わろす。

CVSwebのデザインも(トップページと同じっぽく)変わった。

http://cvsweb.freebsd.org/

なかなかカッコイイですね。
ports の cvsweb もデフォでこれにしてもらいたい

<チラシのうら>
A Comparison of Solaris, Linux, and FreeBSD Kernels at OpenSolaris.org
http://www.opensolaris.org/os/article/2005-10-14_a_comparison_of_solaris__linux__and_freebsd_kernels/

bsdforums.org - FreeBSD, OpenBSD, NetBSD, MacOS X, Darwin, Linux, BSD Unix forums, message boards, discussions and news. - Destination FreeBSD: Interview with Release Engineer Scott Long
http://www.bsdforums.org/forums/showthread.php?t=35212
</チラシのうら>

とりあえず、報告

php 4.1.1
変更点
ttp://www.php.net/ChangeLog-4.php#4.4.1

(･∀･)ﾆﾔﾆﾔ

一足先にRELENG_6が-STABLEブランチになりました。
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh.diff?r1=1.69.2.8&r2=1.69.2.9

-BRANCH="RC1"
+BRANCH="STABLE"

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh.diff?r1=1.69.2.8&r2=1.69.2.8.2.1

-BRANCH="RC1"
+BRANCH="RELEASE"

━(AA略。

もう出すのか
しかし、todo list見ると積み残し多数なんだけど大丈夫なのか（汗

>>377
毎回そうだったりするのですが(なんだかねぇ)、Webの更新が間に合っていなかったりする様子。

来ましたか。

RC2が消えてるような…

>>366 にあるように、
> we've decided to skip RC2 and go straight to 6.0-RELEASE.

ということだそうで。>>380

>>381
(ﾟдﾟ)ｱﾗﾔﾀﾞｽﾏｿ

最近5.4をごにょごにょしだしたものですが、

ということはまもなくリリース？

>>383
…そのはずです。

6.0Rは私の脳内では5.5R++ぐらいの変化なので
(5.2.1R→5.3Rぐらいか、あるいはもっとか)、
今5.4Rをごにょごにょしだしたんなら、6.0Rにするいい機会かもなと。

6.0R make world 中

>>384
もう遅いです、各種環境構築に走ってしまいましたw

毎日 make worldして喜びに浸ってほしい。

私はちょっとだけ、様子見かな。。

差し戻しとゆうか、newvers.shが変わってもいくつかコミットされることもあるので、
まずは cvsup.peko.2ch.net あたりで試して、アナウンスが出次第
ex10 epg 雪だるまサーバ という運びで。

ということで、とりあえず cvsup.peko.2ch.net を 6.0R に。

%uname -a
FreeBSD banana273.maido3.com 6.0-RELEASE FreeBSD 6.0-RELEASE #1: Wed Nov 2 02:59:37 PST 2005 [email protected]:/var/src/sys/i386/compile/I386_BANANA_60 i386

まだISOは出ないか。

isoの件はミラーに行き渡ってから騒ぎましょう。

http://itpro.nikkeibp.co.jp/article/NEWS/20051102/223939/

ありゃりゃ

>393
う〜む
かなりまずい穴なので全鯖に適用する必要がって4.4.1入れても大丈夫なのかなぁ
（なんか4.4.0で大幅な仕様変更があったらしい）

>>393
ていうかいま入っているヴァージョンいくつにもよりますな
4.4.11以降であれば無問題ですが

>>395
1が一つ多かった・・・orz

>>393
ふむ。こりゃまずそうですね。

対策するか。

> 対策は，PHPの場合4.4.1以上にアップグレードすること。

これでいきます。

tiger/cobra/root権限ありbananaと、
epgでは、PHP5は使用していません。

おれは昨日の内に対処して、4.4.1にしたけど、
gd 周りでハマりますた。

>>399
なるほど、いかにもはまりそうな箇所ですね。

今の2chでは、使っていないはず。
AASは使っているかもね。

ついに6.0RELEASE上がり初めますた
まだ一部だけど今日明日中にはアナウンス出ると思います。

amd64ついにｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
これは赤飯炊いて（ｒｙ

[FreeBSD-Announce] FreeBSD 6.0 Released
http://lists.freebsd.org/pipermail/freebsd-announce/2005-November/001023.html

とりあえず置いておきます〜

>403
トップにも正式アナウンス出ました。
6.0入れ替え大会もそう遠くない日にありそうですね。

>>403
自宅サーバの6.0化をしなくちゃと思いつつ、そのうちやろうで放置中だったり……
5.4でもそう不自由がないから無理して6.0化しなくてもいいんだけど。
そのうちやろっと。

>>404
出ましたね。

今日は5000行ぐらいのPerl読んで頭がうにうになんで、
ぼちぼち、やっていくかなと。

というわけで、

>>403
> ~ Significant performance improvements to the filesystem and direct disk
> access layers of the OS. The filesystem is now multithreaded and can
> take full advantage of multiple CPU systems.

が、もっとも大きな売りなわけです。
tiger/cobraでの、さらなるパフォーマンスアップを期待。

うちのサーバも1台だけ6.0Rにしたけど、残りどうしようかな。

前にもどっかに書きましたが、デュアルCPUとかSCSIのサーバなら、かなり意味がありますね。
5.3R以降になっていてシングルCPUでIDEのサーバなら、無理することはないってかんじで。

6.0RにしたのがシングルCPUでIDEのサーバで、5.4RのままがデュアルCPUでSCSIなサーバｗ

ぼちぼち、リリースノートを読み始め。
以下はamd64のリリースノートから、カーネル系。

・HZのデフォルト値が変わった。割り込み系とか時間の粒度とか、よりよくなるかも。
The default HZ parameter (which controls various kernel timers) has been increased
from 100 to 1000 on the i386 and ia64. It has been reduced from 1024 to 1000
on the amd64 to reduce synchronization effects with other system clocks.

・panic/強制リブート時の立ち直りを早くする工夫。
Recomputing the summary information for “dirty” UFS and UFS2 file systems is
no longer done at mount time, but is now done by background fsck(8). This change
improves the startup speed when mounting large file systems after a crash.
The prior behavior can be restored by setting the vfs.ffs.compute_summary_at_mount
sysctl variable to a non-zero value. [MERGED]

・NFSサーバの虫がとれたらしい。
A kernel panic in the NFS server has been fixed. More details can be found in errata
note FreeBSD-EN-05:01.nfs. [MERGED]

ユーザランド系。

・このへんを高速化しているそうで。
Machine-specific optimized versions of bcmp(3), bcopy(3), bzero(3), memcmp(3), memcpy(3),
memmove(3), memset(3), strcat(3) and strcpy(3) have been implemented.
Several mathematics functions such as ceill(3) and sqrtf(3) are also replaced with
the optimized versions.

・pgrep/pkill 大幅強化。
The pgrep(1) command now supports a -S option which allows matching
system processes (kernel threads).
The pgrep(1) and pkill(1) commands now support a -F option, which matches
a process whose PID is stored in a file.
The pgrep(1) and pkill(1) commands now support a -i option to ignore case
in the process match.
The pgrep(1) and pkill(1) commands now support a -j option that matches processes
based on their jail(2) ID.
The pgrep(1) and pkill(1) commands now support a -o option which matches only
the oldest (least recently started) of the matching processes.

・portssnapコマンド新設。
The portsnap(8) utility for downloading, updating, and extracting compressed snapshots
of the FreeBSD ports tree has been added.

・tail -fが複数のファイルを処理できるようになった。
The -f option of tail(1) utility now supports more than one file at a time. [MERGED]

・tcpdropコマンドがOpenBSDから輸入された。
The tcpdrop(8) command, which closes a selected TCP connection, has been added.
It was obtained from OpenBSD. [MERGED]

ざっと読んでみて、サーバ系でめぼしいところは、このぐらいか。

無線LANサポートとか、LapTopサポートがかなり入ったとか、
CPUクロックの制御まわりがいろいろ入ったとか、
DHCP関係がISCのものからOpenBSDのものに変わったとか、
そのへんもあるですね。

こまごまとしたところが、良くなったり変わったりしている様子。

で、
Source upgrades to FreeBSD 6.0-RELEASE are only supported from
FreeBSD 5.3-RELEASE or later. Users of older systems wanting to
upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first,
then to FreeBSD 6.0-RELEASE.

とあるように、従来のバージョンからアップグレードする時は、
いったん5.3R以降に更新してから、6.0Rにするようにと。

ファイルシステムの粒度が良くなったので、Disk I/Oが苦しいサーバーには結構効くんじゃないかな。

>>414
そですね。それが(サーバ用途では)いちばん効くところかなと。

>>411
>・NFSサーバの虫がとれたらしい。
>A kernel panic in the NFS server has been fixed. More details can be found in errata
>note FreeBSD-EN-05:01.nfs. [MERGED]

虫を踏んでいたであろう条件の再現実験方法が
http://aa5.2ch.net/test/read.cgi/nanmin/1121344281/663-667n
のような感じなんで，これを試して Ok そうなら NFS いけるかもしれませんね．

もっとも，カーネルごと落ちることがなくなっても，通常エラーとしての
ESTALE などは発生するかも知れませんが......たまにしか発生しないなら
「その時はリロードして下さい」ってのもありかも知れませんが......

>>416
…ですね。

NFSはやっぱりどきどきするので、
やはり、今の路線(bbsdとのインタラクションでいく)で、当面すすめようかなと。

あ、書き忘れ。

BG3/BG4がそろそろアレなので、
個人的にはlibthrを試してみたかったりするかも。

保存のため、こっちにも貼っておくか。

【ex10】FreeBSD 6.0R性能評価実験に伴うサーバダウンについて
http://qb5.2ch.net/test/read.cgi/operate/1129310805/138

138 名前：root▲ ★[sage] 投稿日：2005/11/06(日) 01:42:39 ID:???0
で、いくつかのサーバを6.0-RC1や6.0Rに上げたので、使用感を。

ログインしていくつかコマンド打ってディスク触ってまず、「軽い」と感じますね。
特にファイルシステム周りというか、ディスクをがりがり触る系のオペレーションでは、
明らかにそう感じます。

例えば、makeしながら他のことする時とかの、「ひっかかり感」が
明らかに軽減されたような気がするです。

ex10が問題なく動くようなら、次は思い切ってBG3/BG4をやってみるかな。

おつでしたー

日本語で読みたい、FreeBSDに興味のある人向けに。

システム旅譚 - FreeBSD 6.0-RELEASEの新機能と変更点を見る
http://pcweb.mycom.co.jp/articles/2005/11/07/freebsd/

>>421
> mpsafevfs

ご存知、目玉商品。
シングルプロセッサでも、恩恵があると。

> portsnap(8)・bsdiff(1)・bspatch(1)の追加

標準に入ったってことですね。
CVSupがなくてもいくなったと(何かと使うから入れるけど)。

> SCHED_ULE

昔 5.3-BETA 時代に ex7 で少し試したけど、LA が上がらないのに
パフォーマンスがまったく出ず、散々でした(落ちはしなかったけど)。

live20あたりで試してみる価値はあるかも。

> 注意：ロケール ファイルのフォーマット変更 - compat5xの導入

5.xのバイナリでsetlocale() を使っているやつは、気をつけろと。

たぶんあまり関係ないと思うけど。

RingServer Projectにおける、FreeBSD, FreeBSD-jp及びFreeBSD-PC98のミラーの廃止について（廃止予定日：2005/12/01）
ttp://www.ring.gr.jp/ring/freebsd.html.ja

>422
>CVSupがなくてもいくなったと(何かと使うから入れるけど)。
/usr/objをどっかで代表してbuildworldして、コピーしてmake installworldすれば/usr/srcのcvsupも使わなくて済むかも。

ULE実戦再投入くる〜

>>422
>> 注意：ロケール ファイルのフォーマット変更 - compat5xの導入
>
>5.xのバイナリでsetlocale() を使っているやつは、気をつけろと。

bbsd では setlocale() 使ってますが，問題なのは 5.x 用バイナリをそのまま
6.x で使う場合のようで，リコンパイルすれば平気な模様ですね．

portupgrade -aFすりゃcompat5x要らない

>>426
そういうことですね。

>>427
2chのサーバは、6.0Rにした時にはportsを総入れ替えしているです。
ひらたくいえば、全部きれいさっぱりpkg_deleteしていると。

ひとつ、重要な注意を。

/md (メモリディスク)を /etc/fstab で mount している場合は、
6.0Rへのバージョンアップにあたり、コメントアウトしないとだめです。

途中、カーネルが6.0R、ユーザランドが5.xRとかの時に、
/md の mount が失敗し、シングルユーザに落ちてしまいます。

live20は/etc/fstabでやっていないので、助かりました。
今後、気をつけるべしで。

>途中、カーネルが6.0R、ユーザランドが5.xRとかの時に、
>/md の mount が失敗し、シングルユーザに落ちてしまいます。

気合いと根性でmake installkernel && mergemaster -p && make installworld && mergemasterしてしまうのはどうか。

>>430
さすがに、6000マイル先のサーバでそれするのは、、、。
ごく一部のサーバしか、私はリモートコンソールへのアクセスできないし。

5.3R→6.0Rにしたlive20のdmesgから。

-em0: <Intel(R) PRO/1000 Network Connection, Version - 1.7.35> port 0x3000-0x303f mem 0xfc200000-0xfc21ffff irq 28 at device 2.0 on pci3
+em0: <Intel(R) PRO/1000 Network Connection, Version - 2.1.7> port 0x3000-0x303f mem 0xfc200000-0xfc21ffff irq 28 at device 2.0 on pci3

emのバージョンが上がるのね。
BG3/4には有効か。

-Timecounters tick every 10.000 msec
+Timecounters tick every 1.000 msec

そういえばHZが1000になるんだった。

(live20)
%sysctl kern.clockrate
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
(live16)
%sysctl -a kern.clockrate
kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 }

忙しい系のサーバには、有効かも。

あれ。
5.3Rなのはdevice emのバグ回避だったの？

>>433
単に、バージョンアップしてなかただけです。

SuExec 一時的に復活 @ ex10

これから、ex14 の土地作りと依頼を。

以下を2ch.netのDNSサーバに追加お願いします。

+ex14.2ch.net:206.223.151.225

done

>>435
予定地みえますた

みえた

>>435-436
OKです。

OCNBフレッツファミリー100からもみえたでよ。

>>436
アカウント情報メール済みです。
建物建てていただいてOKかと。

http://ex14.2ch.net/
http://206.223.151.225/~ch2ex14/
maido3.comのどの鯖かが、分からない。

ex10とおなじかと。

>>443
リニューアル工事な訳ですね。

そんな訳で、久々に。

http://ex14.2ch.net/
IPアドレス： http://206.223.151.225/~ch2ex14/
バーチャルホスト変換前： http://oyster901.peko.2ch.net/~ch2ex14/

http://that4.2ch.net/
IPアドレス： http://206.223.150.100/~ch2that4/
バーチャルホスト変換前： http://banana229.maido3.com/~ch2that4/

>>445
that4間違い。

http://that4.2ch.net/
IPアドレス： http://206.223.147.235/~ch2that4/
バーチャルホスト変換前： http://banana275.maido3.com/~ch2that4/

いや、that4は、nslookupしてみたかぎりでは、banana275ってやつらしいです。
いままで出てこなかったから、新鯖かも。

http://that4.2ch.net/
IPアドレス： http://206.223.147.235/~ch2that4/
バーチャルホスト変換前： http://banana275.maido3.com/~ch2that4/

ちなみにex10は、システムを調整したりしてみる？らしいので、
いったんログを退避させるために移転したようです。

>>446
おっと、、しつれいしましたです。。

(ﾟ∀ﾟ)ﾗｳﾞｨ!!

ex10, that3 memories への収容が完了しました。

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

(現在)
+ex10.2ch.net:206.223.151.225
+that3.2ch.net:206.223.150.100

(設定後)
+ex10.2ch.net:206.223.151.230
+that3.2ch.net:206.223.151.230

done

>>451
確認しました。
1日待って、HDD掃除へと。< 旧ex10

で、こんなのあるのね。チラシの裏。
http://search.cpan.org/~gaas/libwww-perl/lib/LWP/Simple.pm

旧ex10のフルダンプ(今日の早朝バージョン)をmemoriesに転送中。

>>453 done.

下記、準備したです。> ※な人ほか

http://cook81.2ch.net/_service/

>>454
done.

http://live22x1.2ch.net/_service/
http://live22x2.2ch.net/_service/
http://live22x3.2ch.net/_service/

準備したです。

これらは、個別に見るようにしていただけると助かります。< PV/LA等

http://live22x.2ch.net/_service/
も、なぜか拾っちゃった♪

つ [php5.1.0]

>>457
それは、3つのうちのどれかにアクセスするようになるから、あんまり意味ないんすよ。

PHP 5.1.0 って、虫っていないのかしら。

>>458
・Over 400 various bug fixes.
なぁんて書いてあったりしました（苦笑）
http://www.php.net/ChangeLog-5.php#5.1.0

>>459
ひゃー400個、、、。

epgが微妙に不安定なんで、あとでやってみるか。

p2.2ch.net不具合報告スレ Part7
http://qb5.2ch.net/test/read.cgi/operate/1132583026/199-209

【しゃけ】雪だるま作戦に思いを馳せながら雑談するスレッド Part27
http://aa5.2ch.net/test/read.cgi/nanmin/1132754646/633

#
# setting for Snowman -- 11/28/2005 by mumumu
#
<IfModule mod_rpaf-2.0.c>
RPAFenable On
#RPAFsethostname On
RPAFproxy_ips 192.168.100.2 192.168.100.3 192.168.100.4
</IfModule>

これで、REMOTE_ADDR が live22xN => live22 に透過させられるので、
それ系をチェックしているプログラムもちゃんと動くよ、という話。

早っ
もう5.1.1出すって事はよっぽど致命的な虫でもいたのかなぁ


ttp://www.php.net/ChangeLog-5.php#5.1.1

5.0系は正直、ぼろかったので、
5.1系はどうなのかしら。

cook81.2ch.net の引越し準備が整いました。

以下の手順で、引越しをよろしくお願いします。

1) 今のcook81の中身を、新cook81に移す

新cook81はbanana402.maido3.comです。
ログイン名・パスワード・Webサーバの設定は今のcook81と同じです。
cronの設定は、済んでいます。

2) DNSの設定を変更する

1)の作業後、以下の設定変更をお願いします。

(現在)
+cook81.2ch.net:206.223.150.140

(設定後)
+cook81.2ch.net:206.223.150.250

(続く)

(続き)

3)DNSキャッシュサーバの再起動(qb5が参照しているもの)

qb5が参照しているDNSキャッシュサーバのプロセスを再起動します。
これで、臭いをかぐ方のDNS対応が更新されます。

4)DNSキャッシュサーバの再起動(ex14が参照しているもの)

3)まで終わったら、お知らせください。
私が実施します。
これで、臭いをつける方のDNS対応が更新されます。

以上です。よろしくお願いします。

>>464

1) 完了

建設予定地見えました。

>>464

1) 完了
2) 完了

了解です。>>469

臭いつけるほう(ex14)のDNSキャッシュを、リスタートしてきます。

banana402のほうに、においがつきはじめたのを確認。

>>464

1) 完了
2) 完了
3) 完了

>>472
operate2で確認してくるです。

問題ないようです。
VIP931をqb5以外のサーバで設定していない場合、これで作業完了ということで。

◆　密かにスタート　運用情報(金) Part3
http://qb6.2ch.net/test/read.cgi/operate2/1131481715/486

404 も再インストールするんでしたっけ?

>>475
条件を同じにする(余計なところで問題が起きないようにする)ため、
402 403 と同じ同条件での再インストールよろしくお願いします。

はいー

あ、念のため。
banana404 には他に何も入っていないため、
既に再インストール可能な状態になっているです。

…一応、アクセスログ確認してくるです。< banana404

385 名前：root▲ ★[sage] 投稿日：2005/12/01(木) 14:08:05 ID:???0
banana723.maido3.com から、アクセスがあるようです。
どこか、臭いかいでいる板があるのかも。

banana723.maido3.com のDNSキャッシュも、リスタートいただけますか。
他には、2ch内部からのアクセスはないようです。

…ということで。

>>480
完了

>>481
アクセスがなくなったことを確認しました。
これで、banana404は本当に再インストールが可能な状態になりました。

おさわがせしました。

めでたし　めでたし

再インストールしますー

引越しして
掃除して
お風呂か

再インストール完了。

>>485
はやっ。

で、http://aa5.2ch.net/test/read.cgi/nanmin/1132754646/924 ですが、
なにか、おぼえありますか。

ログイン情報受け取りました。>>485

チェック後、作業入ります。

ハードウェア交換後の banana403 の情報を受け取りました。
チェック後、作業入ります。

それで、banana403/404のプライベート側ネットワークの通信の件ですが、
中の人(仮名)と、あとでちょっと調整してみるです。

とはいえ、今日は会議と締め切り仕事がめじろおし。
とりあえずはbanana404のほうの作業を、すすめているです。

banana403, banana404のプライベート側ネットワークが
問題ないことを確認しました。おつでした。

よかったー

誰も書いてないようなので書いてみる

Apache 2.2.0 Released http://www.apache.org/dist/httpd/Announcement2.2.html

↓コメント

>>492
おー。ついに。

proxy/cache方面が大幅改良とか、なんとか。
雪だるま方面で試してみたいけど、まずは動かしてからか。

などと言いながら、つい見てみる。
http://httpd.apache.org/docs/2.2/new_features_2_2.html

いろいろ、よさげ、よさげ。

banana404 の基本設定が、できつつあります。
banana403 も、週末にはおおむね。

で、あとは、

トータル設計→構築→基本テスト→第2回最速1000大会開催→本移転→年末年始も安泰→ｳﾏｰ

というかんじで。

正式版出ました。


Apache 2.2.0 Released
ttp://httpd.apache.org/

banana403、banana404の2台、基本部分のセットアップほぼ完了。

>>496
↓
>>492-494

いろいろ調べて、方針を決めてみた。

1) banana403 banana404 では HDD をさわる I/O は一切させない
2) banana403 banana404 では heartbeat を動かして互いに監視する
3) banana403 banana404 ではIPアドレスAを共有する(heartbeatの機能)
4) 初期状態では、Aへのリクエストにはbanana403が応答する
5) banana404はbanana403の「スタンバイノード」となる
6) banana403に異常が発生したり、メンテナンスの時は
banana404がすぐにbanana403にとってかわる
7) その時、ユーザに見える共有IPアドレスAは変わらない
そのため、サービスは継続される
8) banana403 では負荷分散(ロードバランシング)プログラムが動き、
Aへのリクエストをlive22x1/x2/x3に振り分ける
9) ロードバランシングプログラムはlive22x1/x2/x3の監視も同時に行い、
正常に応答しなくなったら、振り分けの仲間から自動的に外れ、
回復したら、自動的に仲間に戻る(バランシングプログラムの機能)

これで、

a) 外に見せる代表IPアドレスはA一つにでき、
b) Aを受けている振り分けサーバが落ちても、サービスは停止せず、
c) 振り分けサーバの後ろにいるlive22x1/x2/x3が部分的に落ちても、サービスは停止しない

ようにできます。

(続く)

で、いろいろ調べてみたのですが、banana403とbanana404をワークとスタンバイではなく
「冗長化を完全に実現した上で、両方同時にワークにする」ようにするのは、
現状のheartbeatでは難しいようです。

しかし、ディスクI/Oをさせないのと、ネットワークI/Fチップがタフなことから、
この用途で使うのであれば、帯域幅が100Mbpsがめいっぱいにならない間は、
いけるような気がします。

これにより、教科書どおりのサーバクラスタ構成にできるはず。
明日以降、この方針で構築をはじめようと思います。

で、この方針だと、ネットワークをより有効に働かせるために、
banana403と404のプライベート側ネットワークのVLAN設定を、
再度微妙に変えてもらう可能性があります。

その際には、また必要事項を連絡します。

ということで、今日はこのへんで。

rootたんっていつ寝てるのかしら。乙です

>>499
> で、この方針だと、ネットワークをより有効に働かせるために、
> banana403と404のプライベート側ネットワークのVLAN設定を、
> 再度微妙に変えてもらう可能性があります。

再度脳内で検討した結果、
変えなくてもいけそうだとわかりました。

ということで、おやすみなさい。

banana403 / banana404 の外部からの状況監視・
LAのチェック等のためにのみ使用する httpd を上げました。

以下のDNS登録をお願いします。
b = balancer で。

backend とちょっと紛らわしいですが、これでいこうかと。
なお live22b という代表名は使用しないため、つけません。

+live22b1.2ch.net:206.223.150.95
+live22b2.2ch.net:206.223.150.140

>>502
done

http://live22b1.2ch.net/_service/
http://live22b2.2ch.net/_service/

見えたら、登録おながいしますです。 > ※の方ほか

>504
両方とも見えました。

>>498
読んでみて、それで問題ないかと思います。

>>504
見えます。

課題: バランサーに何を使うか

候補はこのぐらいか

1) pound
2) balance
3) Apacheリバースプロキシ
4) squidリバースプロキシ

よくあるのは 1) だけど、昔の 1.7 はたまに不安定になった。
今の 1.9 はどうかなと。

>>507
　 _ 　∩
(　ﾟ∀ﾟ)彡　実験！実験！
　⊂彡

http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html

これってどうなんでしょうねぇ

で、>>507 は、まずは LVS を使ってみる方向で。

【きりたんぽ】雪だるま作戦に思いを馳せながら雑談するスレッド Part28
http://aa5.2ch.net/test/read.cgi/nanmin/1133468879/93-

で、>>509 のはそれはそれで面白そうなんで、生かせる局面があればそこで。

1) banana403 につけている代表アドレスを、

live22x1
live22x2
live22x3

の、lo0 に alias でつける

2) Apacheでは、そのアドレスもListenする

で、いけた。

banana403をリブートしても、自動的に3つ組みになるようにできた。
/usr/local/etc/rc.d/zzz-ipvs.sh

#!/bin/sh

_VIP="206.223.150.96:80"
_REALS="192.168.100.2 192.168.100.3 192.168.100.4"
_REAL=""

case "$1" in

start)
echo -n 'Starting ipvs '
kldload ipvs.ko
kldload ip_vs_rr.ko
/usr/local/sbin/ipvsadm -A -t ${_VIP} -s rr
for _REAL in ${_REALS}; do
/usr/local/sbin/ipvsadm -a -t ${_VIP} -r ${_REAL} -g
done
echo 'done.'
;;
stop)
echo -n 'Stoping ipvs '
/usr/local/sbin/ipvsadm -C
kldunload ip_vs_rr.ko
kldunload ipvs.ko
echo 'done.'
;;
*)
echo "$0 start | stop"
;;
esac

>>513 の設定で動かすと、サービスダウンを検出しないのね。
ipvsadm のマニュアルを読んでみるか。

…どうも、三姉妹が落ちた時にうまくそれだけを切り離す、というのは、
ないかもしれないですね。

これは、将来の課題にしよう。

で、>>513 をちと改良。スケジューラを選べるようにした。
rr だとラウンドロビンになって、wlc にするとちょっと重み付けしたうえで、
一番コネクション数が少ないやつに回されるらしい(他にもあるみたい)。

#!/bin/sh

_VIP="206.223.150.96:80"
_REALS="192.168.100.2 192.168.100.3 192.168.100.4"
_REAL=""
_SCHED="wlc"

case "$1" in

start)
echo -n 'Starting ipvs '
kldload ipvs.ko
kldload ip_vs_${_SCHED}.ko
/usr/local/sbin/ipvsadm -A -t ${_VIP} -s ${_SCHED}
for _REAL in ${_REALS}; do
/usr/local/sbin/ipvsadm -a -t ${_VIP} -r ${_REAL} -g
done
#/usr/local/sbin/ipvsadm --set 5 5 5
echo 'done.'
;;
stop)
echo -n 'Stoping ipvs '
/usr/local/sbin/ipvsadm -C
kldunload ip_vs_${_SCHED}.ko
kldunload ipvs.ko
echo 'done.'
;;
*)
echo "$0 start | stop"
;;
esac

>515
そういえば３姉妹の名前まだ決まってないですか？
実況鯖だと命名はちょっと難しいかも
フジならすぐ決まりそうだけどｗ
（命名案はこっちではなく雪だるまスレの方へ）

○heartbeatの設定

- ha.cf, haresources, authkeys を設定
- LVS を上げている部分をheartbeat傘下に移動

設定内容は、サーバが上がったら。

というわけで、DNS変更申請いきます。

いよいよ、live22xのアドレスを本番環境にします。
見え方は今と変わりません。ということで「みえましたー」はないです(今既に見える)。

(現在)
+live22x.2ch.net:206.223.150.64

(変更後)
+live22x.2ch.net:206.223.150.96

で、LA情報をlive22xからとっておられる各位にお願いです。

live22x.2ch.net はこの設定の後は「代表受付」になります。
つまり、ここからLAとっても個々のサーバのどれにいくかわからないので、意味がないです。
ということでLAについては、live22x1, live22x2, live22x3 のものを
それぞれ個別にとっていただけると、助かります。

DOT 少ない?

あっ　私の目の問題か、、
どんどん見えなくなっていくのよね

で、このIPアドレスは、live22b1とlive22b2のうちの「どっちか」についています。
通常はlive22b1についてますが、落ちると30秒程度でlive22b2に切り替わります。

で、live22b1が上がってもそのままで、live22b2が落ちると、
live22b1にまた変わります。

ということで、いわゆるひとつのフェイルオーバーっていうやつで。

x の次に . があると、確かに見えにくいすね。>>519-520

>>517 続き

- /usr/local/etc/ha.d/ha.cf

bcast fxp1
keepalive 2
warntime 10
deadtime 30
initdead 60
#udpport 694
auto_failback off
respawn hacluster /usr/local/lib/heartbeat/ipfail
node banana403.maido3.com
node banana404.maido3.com
ping 206.223.150.1

- /usr/local/etc/ha.d/haresources

banana403.maido3.com 206.223.150.96/32 zzz-ipvs

- /usr/local/etc/ha.d/authkeys

auth 1
1 sha1 "むぎゅー"

>>523 は banana403, 404 共通

haresources に書いた内容により、banana403が最初は活動し、
banana404がスタンバイノードになる。

auto_failback off で、banana403が上がった時の自動戻しは発生しなくなる。

authkeys に共通鍵を書いて、互いに認証する。

で、>>515 のスクリプト (zzz-ipvs.sh) を、
/usr/local/etc/rc.d から /usr/local/etc/ha.d/resources.d に mv し、
heartbeat 配下にする。
で、最後の .sh を取る。(/usr/local/etc/rc.d/resources.d/zzz-ipvs という名前で入れる)

それから、IPアドレスはheartbeatがつけたりはずしたりするようになるので、
/etc/rc.conf の以下の行をコメントアウトする。

#ifconfig_fxp0_alias0="inet 206.223.150.96 netmask 255.255.255.255"

ここまでできたらbanana403/banana404をリブートして、設定完了。

残っている問題:

・read.cgi をフロントエンドで動かす。
(既にSunOSさんから案あり)

・bbs.cgi トラックバック部分を改良する。
(既にSunOSさんから例あり)

・live22x[123]のどれかが落ちても、切り離されない。
(検知して切り離すコマンドを入れるところを作る必要あり)

・削除関連の各種呪文が雪だるまに対応していない。
(これは、ぼちぼちというかんじか)

案 => 提案 >>526

板移転時の注意:

live22x側での設定(httpd.conf、ゆっくり同期スクリプト)もあわせて必要なので、
移転の際には、同期して作業する必要あり。

>>518
done

banana403 / 404の様子が、微妙におかしくなっていた。
で、banana404 をリモートコンソールからリブートかけたところ、
ハングアップした。

で、banana404のリブート依頼を出した。
ううむ。

どうも、公道での通信がしくったっぽい。
で、落ちたと思ってしまって、両方に同じIPアドレスが振られたっぽい。

ううむ。

このへんは、設定で逃れられるかどうかを検討する、というかんじか。

あるいは、heartbeatやLVSそのものの安定性かもしれないけど。

> 落ちたと思ってしまって、両方に同じIPアドレスが振られたっぽい。

なんてこった。。。
＊落ちたと思ってしまって＊の部分が非常に気になる。。

お互いに、heartbeatのパケットを送って監視しているわけです。

で、それは「専用の通信路を使え」と書いてあるです。
例えばシリアルで直結するか、Ethernetのクロスケーブルで直結しろと。

で、今はそうなってないということですね。

なるほど、まだケーブルは繋がってないのですね。
でも、おいちゃんは、『private LAN に全部つないだ』と言ってたような。

>>535
えっと、今こうなっているのです。< banana403/404

fxp0 … 外部通信用
fxp1 … 内部通信用(live22x1/x2/x3と通信)

で、heartbeat通信用に、fxp0でもfxp1でもない占有の通信路を確保すべきと
heartbeatのドキュメントに書いてあるわけです。

で、今あいているvr0(マザボについているもの)を使おうかと思って、
雪だるまスレで相談したのですが、「それを使うことは想定してなかった」という返事で、
今はかわりにfxp1を使って、heartbeatの通信もしていると。

>>536
あー、そういう事ですか。
理解しました。

Ethernetのブロードキャストでのやりとりをやめて、
普通のUDPパケットでheartbeat通信をやりとりするようにしてみた。

修正後のha.cf

#bcast fxp1
ucast fxp1 192.168.100.66 (banana404ではここが192.168.100.65)
keepalive 2
warntime 10
deadtime 30
initdead 60
#udpport 694
auto_failback off
respawn hacluster /usr/local/lib/heartbeat/ipfail
#respawn hacluster /usr/local/lib/heartbeat/ccm
node banana403.maido3.com
node banana404.maido3.com
ping 206.223.150.1

http://www.linux-ha.org/ha_2ecf

> The bcast directive does not work on FreeBSD because of the fragmentation issue described in
> W. Richard Stevens - Unix Network Programming - Vol 1 - 3rd Edition: The Sockets Networking API

やられたのか。
フラグメント起こすといけないから、FreeBSDではbcastは使っちゃだめぽと。

これで、安定するといいなと。

これで、リブートテストをしてみる。

まずはbanana403をリブート。
banana404に切り替わったのを確認。

403は無事立ち上がり、スタンバイになったのを確認。
404をリブート。403に切り替わったのを確認。

404は無事立ち上がり、スタンバイになったのを確認。

切り替わりも、ややスムーズになった模様。
これで、動かしてみるじゃ。

あらら、j の隣に k があったのね。>>542

いずれにせよ、これで。

>>526
> ・bbs.cgi トラックバック部分を改良する。

done. by bbs.cgi 2005/12/05

> ・bbs.cgi トラックバック部分を改良する。

助けを求めてみた。
read.cgi再開発スレ Part2
http://qb5.2ch.net/test/read.cgi/operate/1105909861/415

> ・live22x[123]のどれかが落ちても、切り離されない。

if 自分が振り分けをサービスしている {
三姉妹の状況を調べて、状況に応じてつなげたり切ったりする
}

というかんじのを、banana403/404でcronか何かで動かせばいいのかなと。

> ・削除関連の各種呪文が雪だるまに対応していない。

とりあえず唯一知っているやつ(スレスト)で、試してみるか。
あとは、、、できる人に期待で。

>>544
二つ目は以下の間違い。

> ・read.cgi をフロントエンドで動かす。

>>538 をさらに修正。
heartbeatの通信を占有チャンネルに変更。

#bcast fxp1
#ucast fxp1 192.168.100.66
ucast vr0 10.0.0.2 (banana404ではここが10.0.0.1)
keepalive 2
warntime 10
deadtime 30
initdead 60
#udpport 694
auto_failback off
respawn hacluster /usr/local/lib/heartbeat/ipfail
#respawn hacluster /usr/local/lib/heartbeat/ccm
node banana403.maido3.com
node banana404.maido3.com
ping 206.223.150.1

>>545
> ・read.cgi をフロントエンドで動かす。

は、できた。
基本はOKなので、バイナリの共通化をはかる。
神に感謝で。

・キャッシュが微妙におかしい場合があるっぽい

Apache関連か。
ひどいようならキャッシュ設定を無効に。将来的にはApache 2.2化か。

・root権限がなくても作業できるようにする

しくみは作れそうな感じ。

めもめも。Apache のキャッシュ問題。

【きりたんぽ】雪だるま作戦に思いを馳せながら雑談するスレッド Part28
http://aa5.2ch.net/test/read.cgi/nanmin/1133468879/540

vrかー
http://www.seichan.org/Other/nic.html

>>549
vrは負荷には強くないですね。

携帯サーバでやった時も、NICがvrなやつが先に微妙になりました(メモリも少なかったが)。
トラフィックよりも、フレーム数が多い場合に微妙になるようです。

今回vrはheartbeatのやりとりにしか使っていないので、
フレームが落ちることがなければ、なんとかなるんではないかと。
(外部や他サーバとの通信は全部fxpかem)

config -g なんてあるのね、しらんかった。
http://www.nendai.nagoya-u.ac.jp/~kato/FreeBSD/debug/kgdb.html

メモ。
【実況】 live22x 鯖 Part2
http://qb5.2ch.net/test/read.cgi/operate/1134050051/375

read.cgi再開発スレ Part2
http://qb5.2ch.net/test/read.cgi/operate/1105909861/484-485

これを受けて、worker MPMに挑戦しようと思っていたりするわけですが、
問題なのは、サーバ数のところの調整です。

今、typicalなtigerサーバでは、

<IfModule prefork.c>
StartServers 768
MinSpareServers 128
MaxSpareServers 768
ServerLimit 1024
MaxClients 1024
MaxRequestsPerChild 1000000
MaxMemFree 2000
</IfModule>

といったかんじなんですが(上記はnews19)、

これを <IfModule worker.c> のところに、どう反映させるのがいいのかなと。

こんな感じ？あんまり自信ないけど


<IfModule worker.c>
StartServers 6
Serverlimit 8
ThreadLimit 128
ThreadPerChild 128

MinSpareThreads 128
MaxSpareThreads 768

MaxClients 1024
MaxRequestsPerChild 1000000
MaxMemFree 2000
</IfModule>

>>554
どもです。
1プロセスに、128個のスレッドということですか。

まあ、1プロセスに何スレッドにするのかは難しいですねえ

おぉ，worker MPM 行きますか．
# 2.2 なら event MPM も行ってみたいところですが．

で，可能ならプロセス数を絞って1プロセスあたりのスレッド数を多くしてみたいところですが，
bbsd もスレッド数を増やした状態だと挙動が不安定な模様だったので，ちょっと心配ですね．
どこまで行けるかは「じっけん！じっけん！」ってところですか．
で，MaxMemFree はスレッド数に応じて増やした方がいいかも知れません．

あと，AcceptMutex pthread でもちゃんと動くなら，FreeBSD でのデフォルトの
flock より効率はいいんですが...... pthread_mutexattr_setrobust_np()
がないプラットフォームだと httpd がコケた時がコワいのか......

live22xの受付が落ちた時の避難口用に、
live22y.2ch.net を作ることにしました。

こちらは従来のDNSラウンドロビン方式なので、手堅いです。
ただし、フロントが1台落ちると、いまいちになります。

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

(以下の3つを新規追加)
+live22y.2ch.net:206.223.150.64
+live22y.2ch.net:206.223.150.74
+live22y.2ch.net:206.223.150.84

【きりぼし】雪だるま作戦に思いを馳せながら雑談するスレッド Part29
http://aa5.2ch.net/test/read.cgi/nanmin/1133983623/750

ということで、>>558 に加えて、以下の設定変更もあわせてお願いします。

これで、live22x は live22y の別名となり、かつ設定を変えた場合は5分程度で
それが浸透するようになるはず。

(現在の設定)
+live22x.2ch.net:206.223.150.96

(上記を削除し、下記を追加)
Clive22x.2ch.net:live22y.2ch.net:300

>>554 >>556-557
live22x2 で、worker MPM を試してみました。

read.cgi / bbs.cgi ともに、うまくいくみたいです。
いけるかも。
(mod_cgiのかわりにmod_cgidを使用する)

とりあえず、1プロセスに32個のスレッドにしてみたです。

live22x2では、これに対して、

<IfModule prefork.c>
StartServers 1536
MinSpareServers 256
MaxSpareServers 1536
ServerLimit 2304
MaxClients 2304
MaxRequestsPerChild 1000000
MaxMemFree 2000
</IfModule>

こう設定したです。

<IfModule worker.c>
StartServers 48
Serverlimit 72
ThreadLimit 32
ThreadsPerChild 32
MinSpareThreads 256
MaxSpareThreads 1536
MaxClients 2304
MaxRequestsPerChild 1000000
MaxMemFree 64000
</IfModule>

server-status で見る限り、受付の見かけ上の人数は同じに見えます。
で、read.cgi / bbs.cgi とも、動いたっぽい。

…これをlive22x[13]にも投入したいけど、
今日は、やめておこう。

楽しみは明日以降にということで。

で、言うまでもないですが、
このworker MPMがちゃんと動くようになると、
一人のhttpdが多数のセッションを同時にさばけるようになるので、
メモリが空くとか、設定によってはより多くのセッションを
さばけるようになるとか、そういう話なわけです。

ThreadsPerChild 32なら、MaxRequestsPerChildを32倍したほうが良い気がする

>>564
なるほど。これはプロセス単位で数えるですか。

こうしてみた。

<IfModule worker.c>
StartServers 48
Serverlimit 72
ThreadLimit 32
ThreadsPerChild 32
MinSpareThreads 256
MaxSpareThreads 1536
MaxClients 2304
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

普通の板でも、実験してみるかな。
明日あたり、ex11 = 狼の方々にご協力いただこうかと。

>>566 を、live22 (バックエンド)に入れてみた。
read.cgi も bbs.cgi も動かないので、まずは慣らし運転ということで。

>>561 >>566 をまとめると、

prefork => worker への「等価」変換

StartServers = StartServers(p) / ThreadsPerChild
MinSpareThreads = MinSpareServers(p)
MaxSpareThreads = MaxSpareServers(p)
ServerLimit = ServerLimit(p) / ThreadsPerChild
ThreadLimit = ServerLimit(p)
ThreadsPerChild = 1プロセスでいくつのスレッドを処理するか(これから試行)
MaxClients = MaxClients(p)
MaxRequestsPerChild = MaxRequestsPerChild(p) * ThreadsPerChild
MaxMemFree = MaxMemFree(p) * ThreadsPerChild

>>569 修正

prefork => worker への「等価」変換

StartServers = StartServers(p) / ThreadsPerChild
MinSpareThreads = MinSpareServers(p)
MaxSpareThreads = MaxSpareServers(p)
ServerLimit = ServerLimit(p) / ThreadsPerChild
ThreadLimit = ThreadsPerChild
ThreadsPerChild = 1プロセスでいくつのスレッドを処理するか(これから試行)
MaxClients = MaxClients(p)
MaxRequestsPerChild = MaxRequestsPerChild(p) * ThreadsPerChild
MaxMemFree = MaxMemFree(p) * ThreadsPerChild

>>570 さらに修正

StartServers = StartServers(p) / ThreadsPerChild
MinSpareThreads = MinSpareServers(p)
MaxSpareThreads = MaxSpareServers(p)
ServerLimit = ServerLimit(p) / ThreadsPerChild
ThreadLimit = ThreadsPerChildより多くする、当面同じで
ThreadsPerChild = 1プロセスでいくつのスレッドを処理するか(これから試行)
MaxClients = MaxClients(p)
MaxRequestsPerChild = MaxRequestsPerChild(p) * ThreadsPerChild
MaxMemFree = MaxMemFree(p) * ThreadsPerChild

ex11の設定 (>>553から)

<IfModule worker.c>
StartServers 24
MinSpareThreads 128
MaxSpareThreads 768
ServerLimit 32
ThreadLimit 32
ThreadsPerChild 32
MaxClients 1024
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

httpdの大きさはこのぐらいか。
これで1プロセス32セッションになるなら、相当いい感じ。

news19
16848 ch2news19 96 0 9572K 5196K select 0 0:43 0.05% 0.05% httpd

ex11
84519 ch2ex11 96 0 21712K 15304K select 1 0:17 0.00% 0.00% httpd

以下のサーバのパスワード変更済み。

oyster901 902 243
cobra2244 2245 2246 2247
tiger503 504 505 506 507 508 509 510 511 512
tiger2513 2514
tiger2522 2523 2524 2525

携帯系tigerとroot権限ありbananaは、これから作業へと。

済み。

tiger2507 2508 2509 2510 2511 2512

済み。

banana201 227 238 273 307 402 403 404 405 406

済み。

cherry903

banana637 tiger2526 済み。

これで、担当分は全部済みのはず。
漏れがあったら、ご指摘をば。

JimさんとSeanさんに、作業完了と新パスワードを伝えた。

で、news19では、worker MPM化は失敗の模様。

FreeBSD 5.3R だめ
FreeBSD 5.4R, 6.0R 大丈夫

ということみたい。

若者に愛の手紙を送った。

これで、全作業完了のはず。

>>558-559
done

>>583
確認しました。

%dig +short -t a live22x.2ch.net
live22y.2ch.net.
206.223.150.64
206.223.150.74
206.223.150.84

これで、DNSラウンドロビンモードに徐々に移行するはず。

TTL は　300 だった気するけど
所詮　わたしの記憶力

正しく300になっていたです。

%dig +norec -t cname live22x.2ch.net @ns1.maido3.com
(中略)
;; ANSWER SECTION:
live22x.2ch.net. 300 IN CNAME live22y.2ch.net.

%dig +norec -t a live22y.2ch.net @ns1.maido3.com
(中略)
;; ANSWER SECTION:
live22y.2ch.net. 300 IN A 206.223.150.64
live22y.2ch.net. 300 IN A 206.223.150.74
live22y.2ch.net. 300 IN A 206.223.150.84

焼かれているのか?

>>587
そ、そんな永久規制なところをわざわざ使わんでも。

本日(12/12)速そうな番組
20:00〜 TBS「水戸黄門」
松下の一社提供番組なので、全CMが例のおわびに差し換わる模様

>>589
どもです。

でも、こっちがいいかも。
↓
【かぼちゃ】負荷監視所_20051123
http://live14.2ch.net/test/read.cgi/liveplus/1132747514/

>>588
ちょｗｗｗｗｗｗﾋﾄﾞｽｗｗｗｗｗｗｗｗｗ

workerを利用して、
バックエンド(live22)の処理受付可能数を、>>566 の倍にしてみたつもり。

<IfModule worker.c>
StartServers 96
MinSpareThreads 512
MaxSpareThreads 3072
Serverlimit 144
ThreadLimit 32
ThreadsPerChild 32
MaxClients 4608
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

FreeBSD5.3Rでworkerがうまく動かないのってこれじゃないんですか？

■新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!? Part1
http://qb5.2ch.net/operate/kako/1105/11050/1105035540.html

188 ◆cZfSunOs.U [sage] 05/03/10 20:55:04 ID:geHPxiLU0
http://www.mail-archive.com/[email protected]/msg24903.html
* FreeBSD, threads, and worker MPM. All seems to work fine
if you only have one worker process with many threads. Add
a second worker process and the accept lock seems to be
lost. This might be an APR issue with how it deals with
the child_init hook (i.e. the fcntl lock needs to be resynced).
More examination and analysis is required.
Status: Works with FreeBSD 5.3. Does not work in previous versions.
This has also been reported on Cygwin.

189 動け動けウゴウゴ２ちゃんねる [sage] 05/03/10 21:13:47 ID:KUErTDVR0
ほう。
つまり、1プロセスならば問題なさそう、という事ですね。
むしろ願ったりな状況なのかも。

>>593
かもしんないすね。

で、live22x2のworker MPMは何ら問題なかったようなので、
live22x[13]も、worker MPMにしてくるです。

done. >>594

news19, ex14, live22系でworker MPM(with -lpthread)を動かしてみた結果:

Apacheはどれも2.0.55を使用。

news19 (FreeBSD 5.3R):
・httpd落ちまくり、最終的には外部からのアクセス不能に、あわてて戻す

ex11 (FreeBSD 5.4R):
・概ね問題なし、ただしhttpdの数が減らない設定にしているはずなのに減っていく現象が発生
・アクセスが多くなればちゃんと増える

live22系 (FreeBSD 6.0R)
・現時点まで全く問題なし

ということでread.cgiのようなプログラムもさることながら、
OSそのものやスレッドライブラリの出来の違いも、大きいみたい。

昨日管理人から「worker MPMが普通にちゃんと動いたっていうの、初めて聞きましたー」
って言われたです。確かに、そうかも。

>>596
たぶん、これか。

FreeBSD/i386 5.4-RELEASE Release Notes
http://www.freebsd.org/releases/5.4R/relnotes-i386.html

> A number of bugfixes for libpthread have been merged from HEAD.

>> 586
今年はもう受付嬢の実験はないようですが、
CNAMEをlive22y.peko.2ch.netにしておけば、
maido3の中のひとがいなくても、rootさんだけで
実験できるかも。

worker MPM は，とりあえず順調なようですね．

>>571
>ThreadLimit = ThreadsPerChildより多くする、当面同じで

worker MPM では1プロセスあたりのスレッド数は固定なので，
ThreadLimit > ThreadsPerChild の状態にしてもメリットはなく，
むしろスレッド管理データ領域を必要以上に確保してメモリの無駄遣いになっちゃいます......

FreeBSD 6.0R Apache2.2 + worker MPM
という人柱も海外にはチラホラ出現しているね。

>>598
確かに。
でも、ゾーン外CNAMEを使うとDNSキャッシュサーバがその分仕事しなければいけないんで、
あんまり、使いたくない部分があるです。

>>599
なるほどです。

で、明日はかなり来るということなので、負荷テストを兼ねて
live22の設定を以下にしてみました。
これで、live22xNの3倍の接続を受け付けるので、
全フロントエンドがフルスロットになるまでは、いくはず。
(先日の中山のくじできびしくなったのは、たぶんここが足りなかった、というか
増やしにくかった)

>>600
今の2段階ぐらい先のフェーズで、やってみたいかなと。

>>601
<IfModule worker.c>
StartServers 144
MinSpareThreads 768
MaxSpareThreads 4608
Serverlimit 216
ThreadLimit 32
ThreadsPerChild 32
MaxClients 6912
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

ex14(FreeBSD 6.0R/amd64)もworker MPMに移行した。
問題ない模様。

http://live22.2ch.net/_service/bbsd-20051217.txt
で、2回ばかり、
> total worker threads = 4, idle worker threads = 1

があったので、
-n 32 => -n 48 にしてみた。@ bbsd

>>604 PC 故障中乙です......

まぁ，現在の bbsd はスレッド数可変式なので足りなくなったら増えますけどね．
-n32 なら 4-32，-n48 なら 6-48 の範囲でスレッド数は変化します．

>>605
なんと、そういう動きですか。

んじゃ、32のままでもいいかもですが、
実害はあまりないかなと。

来年の予定。

HEADS UP: Release schedule for 2006
http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020744.html

Jan 30: Freeze RELENG_5 and RELENG_6
Mar 20: Release FreeBSD 6.1
Apr 3: Release FreeBSD 5.5
Jun 12: Freeze RELENG_6
Jul 31: Release FreeBSD 6.2
Oct 23: Freeze RELENG_6
Dec 11: Release FreeBSD 6.3

5系は5.5Rでおしまい。
6系をがんがって3回出すと言っているけど、さて、どうなることやら。

>>607
さっそく、FreeBSB 6.0R-p1になりました。

20051219: p1 FreeBSD-EN-05:04.nfs
Correct a locking issue in nfs_lookup() where a call to vrele()
might be made while holding the vnode mutex, which resulted
in kernel panics under certain load patterns.

>>608
…ですね。
今日からstiger10[0-5]をもみ始めましたが、
その時に気がついたです。

NFSの虫取りですか。
vreleっていうぐらいで、mpsafevfsまわりでもあるのかな。

NFSちゃんと動けば、サーバのdat共用が出来てうれしいんだけど、まだ無理なんだろうな。

先週、6.0R-p0の状態で、NFS試したけど駄目だったｗ

*BSDのNFSでまともに動くのって、経験したことがないです。
2chでも大敗だったのは、記憶に新しいところ。

NFSをまじめに使いたいなら、Solarisしかないかなと。
rpc.lockdとか、ぼろいみたい。

>*BSDのNFSでまともに動くのって、経験したことがないです。
Linuxはさらにダメぽ。

つまりroot★氏のいうとおりSolarisだけか……

Linux の NFS は論外として、*BSD の NFS はそこそこ
というか、かなりよくなってきてると思うけど、
どの辺がダメぽなの？

>>613
確かに昔よりは、相当いいかんじですね。それは認めるです。
NFS越しにfindを繰り返すとそのまま逝ってしまうとかいうことは、
なくなってきました。

・雪だるまで使った時は、ヘビーに読むと(read only mount)
I/O待ちになったまま、カーネル内でささる状況を観測
(psで見るとDの状態のままになる)
(FreeBSD 5.4R)

あと何より、

・NFS越しのロック機構(rpc.lockd)が相当しょぼい

これに尽きるかなと。

Solarisですら、rpc.lockdのパッチは相当出ていたように記憶しているです。

めもめも。

HEADS UP: MFC of local_startup changes to rc.d complete
http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020931.html

べっかんこ作戦関連のDNS登録依頼をします。
既に登録があるようなので、変更依頼になるはずです。

以下の設定変更をお願いします。
ログインアカウント情報等は、別途出します。

(現在)
+u.la:206.223.151.180
+www.u.la:206.223.151.180

(変更後)
+u.la:206.223.157.7
+www.u.la:206.223.157.7

続いて、第二弾のDNS登録依頼いきます。

(新規追加)
+same.u.la:206.223.157.12
+chirasi.u.la:206.223.157.17
+bbm.u.la:206.223.157.32

>>616 done
>>617 done

逆引きはｾﾃｰｲされていないのですね。＠*.u.la

ありゃりゃ?

誰が設定すれば良いのでしたっけ?

>>621
ns[12].maido3.com で設定すればいいはずですね。

%dig -t ns 0.157.223.206.in-addr.arpa.

; <<>> DiG 9.3.1 <<>> -t ns 0.157.223.206.in-addr.arpa.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55384
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;0.157.223.206.in-addr.arpa. IN NS

;; ANSWER SECTION:
0.157.223.206.in-addr.arpa. 769 IN NS ns2.maido3.com.
0.157.223.206.in-addr.arpa. 769 IN NS ns1.maido3.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Dec 24 02:22:28 2005
;; MSG SIZE rcvd: 90

はいー

206.223.157.7 u.la
206.223.157.12 same.u.la
206.223.157.17 chirasi.u.la
206.223.157.32 bbm.u.la

DNS逆引き設定を登録しました。

>>624
確認しました。
stigerXXX.maido3.comではなく、u.laな名前で登録したですか。

bbs.cgi とかで hostname によって処理を振り分けてる部分とかなかったでしたっけ．
load avg. に応じた処理変更とか．もっとも，DNS の逆引きがどうあれ gethostname() が
stigerXXX.maido3.com を返すのなら大丈夫でしょうけど．

修正の方向で、

>>626
> もっとも，DNS の逆引きがどうあれ gethostname() が
> stigerXXX.maido3.com を返すのなら大丈夫でしょうけど．

のはずですね。
サーバごとの臨界LAを定めているところがありますが、
あそこはSys::Hostname を使っていたはず。

>>627
了解です。

虫を踏んだか。
類似例とか、あるのかしら。

【ブリ大根】負荷監視所_20051214
http://live14.2ch.net/test/read.cgi/liveplus/1134552855/523

523 名前： ◆MUMUMUhnYI [sage] 投稿日：2005/12/25(日) 02:51:36 ID:tGhMF0WE0 ?
クラッシュダンプを収容中。(savecore)

vm_thread_new: kstack allocation failed

スタックを、使い切ったっぽい。

http://www.monkey.org/freebsd/archive/freebsd-current/200505/msg00063.html
スレッド数が猛烈に増えるとカーネルメモリを食い尽くすってことですかね．
worker MPM で接続可能クライアント数を増やしたのもありますし(>>601-602)．
そのカーネルメモリ領域を増やすとかできないんですかね......

>>631
in sys/vm/vm_glue.c:

/*
* Get a kernel virtual address for this thread's kstack.
*/
ks = kmem_alloc_nofault(kernel_map,
(pages + KSTACK_GUARD_PAGES) * PAGE_SIZE);
if (ks == 0)
panic("vm_thread_new: kstack allocation failed");
if (KSTACK_GUARD_PAGES != 0) {
pmap_qremove(ks, KSTACK_GUARD_PAGES);
ks += KSTACK_GUARD_PAGES * PAGE_SIZE;
}
td->td_kstack = ks;

となっているのか。

で、in vm/vm_kern.c:

/*
* kmem_alloc_nofault:
*
* Allocate a virtual address range with no underlying object and
* no initial mapping to physical memory. Any mapping from this
* range to physical memory must be explicitly created prior to
* its use, typically with pmap_qenter(). Any attempt to create
* a mapping on demand through vm_fault() will result in a panic.
*/
vm_offset_t
kmem_alloc_nofault(map, size)
vm_map_t map;
vm_size_t size;
{
vm_offset_t addr;
int result;

size = round_page(size);
addr = vm_map_min(map);
result = vm_map_find(map, NULL, 0,
&addr, size, TRUE, VM_PROT_ALL, VM_PROT_ALL, MAP_NOFAULT);
if (result != KERN_SUCCESS) {
return (0);
}
return (addr);
}

#ifndef KSTACK_MAX_PAGES
#define KSTACK_MAX_PAGES 32
#endif

って、なってるですね。(in vm/vm_glue.c)

で、

/*
* Create the kernel stack (including pcb for i386) for a new thread.
* This routine directly affects the fork perf for a process and
* create performance for a thread.
*/
void
vm_thread_new(struct thread *td, int pages)

となっているですね。うむむ。

Googleしてみると、こんな記述が。
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/performance/2005-08/0004.html

Hrm... I'll suggest one tunable:

options KSTACK_MAX_PAGES=32 # Maximum pages to give the kernel stack

Don't crank it up too far, but 64 seems to be a decent number in my
experience. I'd pimp more settings, but given that tuning is still
closer to an art than a science (it wouldn't be if someone catalogued
settings for various applications and hardware combinations, but I
digress), I'll suggest having you take a peak at the various NOTES
files and some of the headers, such as: src/sys/amd64/include/param.h.
I've divulged more in the archives, too. -sc

…でかくしてもよさそうな気がするけど、
よく調べてからでないと、ちと、こわいかも。

さらに。

int kstack_pages = KSTACK_PAGES;
SYSCTL_INT(_kern, OID_AUTO, kstack_pages, CTLFLAG_RD, &kstack_pages, 0, "");

sysctl tunableか。
i386では2、amd64では4の模様。

(live22)
%sysctl -a | grep kstack
kern.kstack_pages: 2

(ex14)
%sysctl -a | grep kstack
kern.kstack_pages: 4

で、さらっとカーネルソースに目を通してみたところでは、
>>636 は、どうも埋め込みのようかん。
つまり、カーネルの再構築が必要と。

とりあえず今日は、こんなところで。

あと、bbsd ですが、そんなわけで -n 24 に減らしましたが、
もっと小さな値でも、いいのかも、かも。

>>637
KSTACK_MAX_PAGESはkernel stack一つ当たりのサイズを
制限するものだから、今回のようなkernel stackの数が増え過ぎのときに
増やすのは逆効果では?

>>641
…とすると、httpdの数とか(今のところまだ相当余裕あり)を
もっと減らした方がいいかもしれんと。

全プロセストータルでのスレッド数が増えすぎないようにということでは，
MaxClients の引き下げとかいうあたりですかね．

# こういうのは，カーネルパニックじゃなくシステムコールのエラーリターンのように
# もっと graceful なやり方にできんものか，とも思ったりもしますが......

>>643
<IfModule worker.c>
StartServers 144
MinSpareThreads 768
MaxSpareThreads 4608
Serverlimit 216
ThreadLimit 32
ThreadsPerChild 32
MaxClients 6912
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>
↓
<IfModule worker.c>
StartServers 96
MinSpareThreads 512
MaxSpareThreads 3072
Serverlimit 144
ThreadLimit 32
ThreadsPerChild 32
MaxClients 4608
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

に変更してみた。@ live22

【ブリ大根】負荷監視所_20051214
http://live14.2ch.net/test/read.cgi/liveplus/1134552855/709

カーネルパニックする前に救い出した。
bbsdが凍り付いて、LAがどんどん上がっている状態だった。

とりあえず、-n 24 を -n 8 にして、
httpdとbbsdをリスタートして、再開。

>>630
よく考えたら、panicの直接の原因はkstack allocation failedだけど、
別の何かが大量にメモリを掴んでいることが真の問題とかいうことも考えられますよね。
# vmstat -mz -M /var/crash/vmcore.1
とかして、何か変わったところとかはありますか?

>>646
http://live22.2ch.net/_service/vmstat-20051225.txt

で、実行時に、
vmstat: not implemented

と、出るです。

>>625
done

>>648
逆引きが stiger10[012345].maido3.com になったのを確認しました。

>>645
>カーネルパニックする前に救い出した。
>bbsdが凍り付いて、LAがどんどん上がっている状態だった。

う〜む......その凍り付いてる時にどんな状態だかがわかればってとこですが......＜bbsd
しかし

http://aa5.2ch.net/test/read.cgi/nanmin/1135352063/164
>[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]

なんですよね...... でも，

http://live14.2ch.net/test/read.cgi/liveplus/1134552855/709
>(killでも死なない、kill -9で死んだ)。

ってことはメインスレッドも凍ってたってことでしょうから，
メインスレッドの状態だけでもわかれば手がかりになるかも......

rootさん、こんばんはーヾ('-')ﾉ

>>650
次回再発したら、精査してみるです。

# /proc を mount しておかないと。

>>651
おひさしぶりです。

むさんいつぞやはお世話になりましたー。
本業も一息つきそうなので、手伝えることがないか
このスレに参加させてもらいますー。

pthread_cond_signal(), pthread_cond_broadcast(), pthread_cond_wait()
pthread_mutex_lock(), pthread_mutex_unlock()
pthread_rwlock_rdlock(), pthread_rwlock_wrlock(), pthread_rwlock_unlock()

これらがエラーになったら abort() するようにしてみますた＜bbsd, matd
通常ならこれらがエラーになるのは考えられないんですが，
その考えられないことが発生してるかも知れないので......
で，abort() すると /tmp に core dump します（setuid プロセスになったりしていなければ）．

>>655
おぉ、入れ替えます。

daemontools的にsetuidgidしていますが、coreは吐くはず、、、。
で、abortしたらdaemontoolsが自動的に立ち上げ直すことになると。

最近は鯖さんが氏んでも即復帰する体制作りやってるんですか？ヾ('-')ﾉ

>>654
こことか、nanminを「雪だるま」で検索してみるとか。

>>657
いろいろですね。
そのへんも、微妙にやっていたり。

「絶対繋がる２ちゃんねる」への道

(´-`).｡ｏＯ(毎分ping撃って、10回連続して返事がなかったらリモートコンソールをリモートで動かしてｺﾞﾆｮｺﾞﾆｮ)

…ということで、DNS登録依頼をするです。
雪だるまシステム開発用になります。

以下の登録をよろしくお願いします。

(新規登録)
+snow.2ch.net:206.223.152.30

>>661
done

snow.2ch.net建設予定地見えました。

やほーでsnow.2ch.net見えますた

>>662
いつもはえーですな

>>rootﾀﾝ
何のことかよくわかりませんが、いつもお世話になっております
これからも頑張ってください

そして、実験用新板が生まれた…
http://snow.2ch.net/alaska/

>>936
ttp://qb5.2ch.net/test/read.cgi/operate/1121886018/255-256
ってことで対応してるみたい。

>>668
これ、まだやってないわけですが、さて。

やらないままに突入すると、どうなるのか。

UNIX timeは別に関係ないから(だって所詮は単なる数値)、
dateコマンドとかローカルタイムにする(zoneinfo読む系)ところで、1秒ずれるのかな。
で、ずっとずれ続けると。

FreeBSDだと、
確か5.4R以降じゃないと2006年の閏秒は入ってないから、
そういうやつ(ほとんどのbanana、かなりのtiger)は、何かしないといけないのかな。

ちょっと調べてまとめて、必要ならmaido3.comの中の人にも作業お願いしようっと。

いろいろ調べ中。

結論からいうと、

FreeBSDでは、デフォルトでは閏秒はシステムに入っていない状態なので、
「デフォルト状態で」「NTPでUTCに対して時間を合わせている限り」、
今回の閏秒挿入に関して、何らかのアクションを起こす必要はない。
つまり、我々は何もする必要がない。

になります。

TAIに合わせている場合(例えばclockspeedとかを使っている場合など)は、
FreeBSDでは最初にそもそも対応が必要だったはずで、
その対応と同じことを、ファイルを更新したうえで、再度やる必要がある。

ことになるはず。

重要なFAQ:

ネットワ−クによる時刻情報提供サービス（NTPサ−ビス）のうるう秒対応
http://jjy.nict.go.jp/news/leaps.html#l4

NTPの取り扱う時刻は1900年１月１日を起点とした時系ですが、
過去のうるう秒を積算していません。積算秒数をお知らせします。
日本標準時で1月1日8時59分60秒(UTCでは12月31日23時59分60秒)と
9時0分0秒（UTCでは1月１日0時0分0秒）は9時0分0秒に相当する
同じ積算秒数をカウントします。

すなわち、60秒と0秒は、同じ時刻を２度カウントすることになります。

こんなページが。djbか。
ほんとに、同じ時刻を2度カウントするのね。すごいな。

http://cr.yp.to/proto/utctai.html

1997-06-30 23:59:59.7 UTC -> 867715199.7 xntpd
1997-06-30 23:59:59.8 UTC -> 867715199.8 xntpd
1997-06-30 23:59:59.9 UTC -> 867715199.9 xntpd
1997-06-30 23:59:60.0 UTC -> 867715200.0 xntpd
1997-06-30 23:59:60.1 UTC -> 867715200.1 xntpd
1997-06-30 23:59:60.2 UTC -> 867715200.2 xntpd
1997-06-30 23:59:60.3 UTC -> 867715200.3 xntpd
1997-06-30 23:59:60.4 UTC -> 867715200.4 xntpd
1997-06-30 23:59:60.5 UTC -> 867715200.5 xntpd
1997-06-30 23:59:60.6 UTC -> 867715200.6 xntpd
1997-06-30 23:59:60.7 UTC -> 867715200.7 xntpd
1997-06-30 23:59:60.8 UTC -> 867715200.8 xntpd
1997-06-30 23:59:60.9 UTC -> 867715200.9 xntpd
1997-07-01 00:00:00.0 UTC -> 867715200.0 xntpd
1997-07-01 00:00:00.1 UTC -> 867715200.1 xntpd
1997-07-01 00:00:00.2 UTC -> 867715200.2 xntpd

ということで、今回の件をまとめると、

0) NTPで時刻あわせをしているシステムでは、
今回何の対応もしなくてよい。
つまり、私もmaido3.comの中の人も、何も作業しなくてよい。

1) ntpdは増える閏秒が発生した場合、
同じ秒を2回繰り返すことにより、つじつま合わせをしている。

2) 結果として今回、1136073600 というUNIX timeな時間が、
２ちゃんねる内において1秒間ではなく、2秒間存在することになる。

3) その際のlocaltime()ライブラリによる時間表示は、
Sun Jan 1 09:00:00 JST 2006 となる。

4) つまり、2006/01/01(日) 08:59:60 という表示が
２ちゃんねるにおいて 投稿日： のところに現れることはなく、
2006/01/01(日) 09:00:00 という表示が、2秒間発生することになる。

ということになるのかなと。

つまり、記念カキコしても無駄ですよと
それはそれで寂しいな

if( time == 1136073600 and $$ % 10 == 0){ $FOX->{なんたら} =~ s/\b09:00:00/08:59:60/ }
wktk

1/1はX:YY:XX.aaにしてみるとか

無駄かな？

ログが2個できて壊れる可能性があると？特にVIP

>>676
どひー。

>>677
面白いかも。

>>678
ある瞬間の1秒が2秒に伸びるだけのはずなので、
それは起こらないはず。

qb6には、Time::HiRes が入ってないのね。

必要なのは一部サーバだけだろうから、
live22xとex14あたりだけ入れてみるとかかなと。

あっち行ったりこっち行ったり大変そうですが頑張ってください。

>>680
http://search.cpan.org/~jhi/BSD-Resource-1.24/Resource.pm
こっちの方が何かと使えたりするかも？

>>682
あ、使えないか、、、λ.....

http://www.bsddiary.net/doc/ntpd-leapseconds.html
># cd /usr/src/share/zoneinfo/
># vi leapseconds
>Leap 1998 の行の下に、以下の行を挿入する。
>Leap 2005 Dec 31 23:59:60 + S
>
># make clean
># make LEAPSECONDS=yes install
># cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

これで「60秒」が出現するのかな......

祭りたいのか？祭りたいんだなｗ

>>684
FreeBSD 5.4R以降では、最初から2005年12月31日のエントリが入っているです。

で、時刻合わせをTAIでやってやれば、できなくはないのかな。
clockspeedとか使ってみるかんじか。

1/100秒対応:

通らないところで、use したものがない場合エラーになるようなので、
syscallで代用。

# 一部サーバではマイクロ秒もとる
if($ENV{SERVER_NAME} =~ /snow|ex14|live22/)
{
# 本当はこっちの方が普通だが、、、
#use Time::HiRes qw( gettimeofday );
#
#($GBX->{NOWTIME}, $GBX->{NOWMICROTIME}) = gettimeofday;
#
# FreeBSD 5.2.1Rなbananaサーバのperlには
# Time::HiResが入っていないので、
# 替わりにsyscallを使うことにする

my $tv = pack("L!L!", ()); # 2つのpackしたlong型変数

require 'sys/syscall.ph';
syscall(&main::SYS_gettimeofday, $tv, undef);

($GBX->{NOWTIME}, $GBX->{NOWMICROTIME}) = unpack("L!L!", $tv);
}
else
{
$GBX->{NOWTIME} = time ; #現在時刻
}

ほいで、

# マイクロ秒の情報がある場合、1/100秒まで表示する
if(defined($GB->{NOWMICROTIME}))
{
my $csec = sprintf("%02d", int($GB->{NOWMICROTIME} / 10000));
$GB->{DATE} .= '.' . $csec;
}

ex11も入れてみたりしない？

eval "use Time::HiRes";
if ($@) {
# Time::HiResが無かったときの処理
$GBX->{NOWMICROTIME} = 1;
}
else {
# Time::HiResがあったときの処理
$GBX->{NOWMICROTIME} = undef;
}
# $GBX->{NOWMICROTIME} = $@ ? 1 : undef; # 1行にしてみるテスト
でもって、、、

$GBX->{NOWTIME} = &getNowTime(鯖名、板名、とかとか♪);
こんな式にしておいて・・・

sub getNowTime{
# 一部サーバではマイクロ秒もとる
return time unless $ENV{SERVER_NAME} =~ /^snow|^ex14|^live22/;
ﾅﾝﾀﾗｶﾝﾀﾗ･･･
}
で値を返してあげるとかとか♪

>>689
入れてみるですかね。

>>690
おぉ、evalすればいいと。

だめっぽいような。

#! /usr/local/bin/perl -w

use strict;
use warnings;

my $seconds = 0;
my $microseconds = 0;
my $centiseconds = 0;

#use Time::HiRes;
eval "use Time::HiRes";

if(!@$)
{
($seconds, $microseconds) = Time::HiRes::gettimeofday;
$centiseconds = sprintf("%02d", int($microseconds / 10000));
};

print $centiseconds;

exit;

で、これを実行すると、

./xx.pl
Bareword "Time::HiRes::gettimeofday" not allowed while "strict subs" in use at ./xx.pl line 15.
Execution of ./xx.pl aborted due to compilation errors.

こうなるですね。

# のところを普通のuseにすれば、動くみたい。

>>693 Time::HiRes::gettimeofday も eval 中に入れたらどうでしょうか．
というか......Time::HiRes が入ってない鯖ではホームディレクトリに
Time::HiRes を入れておいて use lib するとか......

ヒント：$@

ですね

>>694
なるほどです。

>>695
おはずかしい、、、。

うぅむ、、、
こうなったら全鯖perl5.8.xにしてもらおう！

ええと、ひとつ質問です、、、。

いわゆるprefork(シングルスレッド・複数プロセス)な状態でbbsdを動かすことって、
できるんでしたっけか。

さすがに -n 8 は微妙な感じなので、
-n 12 にしてみた。< live22

>>698 シングルスレッド・シングルプロセスなら可能ですが，複数プロセスは
残念ですが対応してません......複数プロセスだと排他制御が大変になるし
（インタープロセスな mutex だとどれかプロセスが死んだ場合の考慮を
しなければならないが，それに必要な pthread_mutexattr_setrobust_np()
が FreeBSD にはない模様，一方 flock() などでやるとなると昔の bbs.cgi と同じ），
subject バッファも共有メモリを使うとかいうことになって，それも大変なので......

まぁ，安全策ならシングルスレッド・シングルプロセス（-DUSE_THREADS なしでビルド）で
動かす形になりますかね．その場合，UDP ソケットのキューイング機能によって処理が
シリアライズされることになります．コンカレンシーはなくなりますが，実際上待ち行列に
入ってもそれほど長時間待たされるということもないかと思いますし......

>>700
> シングルスレッド・シングルプロセスなら可能ですが，複数プロセスは
> 残念ですが対応してません......

やはりそうですか。
理由も含めて納得したです。

> まぁ，安全策ならシングルスレッド・シングルプロセス（-DUSE_THREADS なしでビルド）で
> 動かす形になりますかね．

そですね。
それでどこまでいけるか、ってかんじですか。

そういえば、例のおかしくなっていた時のApache statusって、
L (ログファイル書き込み中)、ばっかりだったんですよね。
普段はほとんど見かけないのですが。

ひょっとしてひょっとすると、mpsafevfs周りに微妙に虫がいるのかも。

calcru: runcalcru: runtime went backwards from 1435168 usec to 1434623 usec for pid 10326 (httpd)
time went backwards from 1380652 usec to 1380546 usec for pid 10327 (httpd)
pid 98776 (httpd), uid 2001: exited on signal 10
pid 10286 (httpd), uid 2001: exited on signal 10
pid 98685 (httpd), uid 2001: exited on signal 10
pid 75181 (httpd), uid 2001: exited on signal 10
pid 10326 (httpd), uid 2001: exited on signal 10
pid 75156 (httpd), uid 2001: exited on signal 10
pid 75165 (httpd), uid 2001: exited on signal 10

さっきと同じか。< 症状
で、LAが急上昇。

もう少し「リアルタイムで」現場を見ないと何とも言えないけど、
直感では、mpsafevfsまわりの虫くさいような気がしないでもない。

書き込み側だけじゃなく読み込み側もドバっと来ると虫がうごめき出すようですね．
mod_cache でバック側からの読み出しを減らせれば虫が冬眠から目覚めにくくなるかも......？

>>705
やはり、Apache 2.2化が急務ですか。

>>706 まぁ OS 側の虫駆除ができればそれはそれでいいんでしょうけど，
それのめどが立たなければ打てる手はそのあたりかと......

# XXX
debug.mpsafevfs=0

/boot/loader.confに追加してリブートした。

さっきはhttpdとかperl(F15)とかが全部、ufsと言って止まっていた。
かなり高い確率で、mpsafevfsの虫だと思われ。

>>708 を入れる前と、様子が変わったですね。
bbsdがCPUを速いタイミングから、食うようになったです。

前は、半日も動かしてないとbbsdがtopの上位プロセスに出てこなかったのが、
早くから出てくるようになった。

ファイルシステムががGiant lockで動く(5.xまでと同じ)から、
そういうもんなのかなと。

>>709 なるほど......

bbsd のログ見てたら，20:50から20:51の間に落ちて再立ち上げされてたようですね．
abort() なのか SIGSEGV かそのあたりか......となると core 吐いてるかな......？

Sat Dec 31 20:50:00 JST 2005
user CPU time = 0:32:21.009, system CPU time = 0:50:51.806
elapsed time = 126:21:01.139, CPU load = 1.10%

Sat Dec 31 20:51:00 JST 2005
user CPU time = 0:00:00.290, system CPU time = 0:00:00.397
elapsed time = 0:00:17.162, CPU load = 4.00%

この目で見たです。
原因はhttpdか。

>>710
手でやったかも。
/tmp 見てきます。

>>712
一応聞いときますが,楽しいですカー？

live22のhttpdをpreforkに戻した。
今日はこれで動かす予定。

>>713
いやぁ、リンクが遅くて。

セッティング出している時が、一番楽しいですよ。
例えそれが、虫との戦いであっても。

>>715
なればおｋ
体も家庭も無理せんようにねーﾉｼ

mpsafevfs は原因切り分けのため、明日の昼間にでも元に戻そうかなと。

しかし、超ヘビーにアクセスがあるとworker MPMがおかしくなるというのは、
ありそうな話では、あるのかも。

まぁ，worker MPM の 32 threads / process ってのは bbsd でいえば
-n256 (32-256) と同じようなもんですからね．livejupiter で最速1000
やってた時も，そのぐらいのスレッド数だと bbsd もおかしくなってましたし......

preforkにするにあたり、php4のモジュールを切ってメモリを空け、
httpdの応答数を前と同じ(フロントの2倍まで受けつけ)にした。< live22

とりあえず、なんとかなるかなと。

>>718
ありえるですね。

1プロセス4スレッドとか、8スレッドとかぐらいがいいのかなぁ(それでも有用ではある)。

このへん、あんまり情報がないんですよね。
探し方が悪いだけなのかもしれないですが。

でもまずは、とりあえずpreforkで動かして、他が安定したら再度考えるです。
mpsafevfsとかを元に戻して、しばらく動かしてみてからで。

morningcoffeeの設定を戻して、、、。
あとは、live22のmpsafevfsを戻すのか。

これは、落ち着いてからやるか。

PHPを止められないとわかったので(p2/２ちゃんねるプロバイダからの過去ログ参照で使用)、
復活させて、そのぶんサーバ数を減らした。

現在の設定。 @ live22

<IfModule prefork.c>
StartServers 2048
MinSpareServers 256
MaxSpareServers 2048
ServerLimit 4608
MaxClients 4608
MaxRequestsPerChild 1000000
MaxMemFree 2000
</IfModule>

>>722
…って書いた直後に、既にこれはフロント参照にしてあって、
私のかんちがいだったことが判明。
(だって、offlawと一緒じゃん。スロー同期でOK)。

明日、mpsafevfsと一緒に、元に戻そう(PHPはずそう)。

ということで、明日これに変える予定。 @ live22

2304 = フロントひとつ分の最大値
4608 はその倍ということで。

<IfModule prefork.c>
StartServers 2304
MinSpareServers 256
MaxSpareServers 2304
ServerLimit 4608
MaxClients 4608
MaxRequestsPerChild 1000000
MaxMemFree 2000
</IfModule>

そねそね
バックは何もしなくていいはず、、、

>>725
過去ログを読む部分は、既に完全にフロント化できたです。
(そういうわけで、上記はかんちがいでした)

bbs.cgiやread.cgiはフロント化でき、
Samba24とかtimecount/timecloseも別サーバに移動でき、
あとは、ライブなdatを触るとか、subject.txtをごにょごにょするとか、
そのへんですね。

ようは、各種呪文系と。

で、SETTING.TXTをいじるとか、キャップを編集するとかは、
バックに対して唱えることになるです。
あと、過去ログ削除の呪文とかも、そういうことになるのかな。

このへんの整理整頓ができたら、
呪文を唱えた時点で、「こっちで唱えてください」みたいなのを、
表示するかんじにまとめて、呪文そのものは同じやつを配布すればOKにしようなと、
思っていたりするです。

芋ほりは単に =~ s/live22x/live22/ したっす。
先のことは考えていないコードですけど、

>>727
掘るのは、たぶんそれでいけるはずです。

キャップいじるのとかSETTING.TXT変えるのとかも、
唱えるところをかえるだけでいい = 変更不要かなと。

やはり、削除系の各種呪文の対応ですね。これは避けて通れない。
bbsd側の道具はそろえてもらえたので、
おぞうにたべながら、I/Fスレあたりでぼちぼちやっていくかんじで。

初ごにょごにょは、live16, live18, live20, live21のmemoriesへの収容から。

現在、移動中。
live20、なかなか多い。

移動完了。
バイナリread.cgi、offlaw.cgiを入れ替え。
各種配布リスト更新。
f22は既に停止。

DNS更新依頼を出しておくです。
実際の更新は、しばらく後かなと。

ということで、以下のDNS更新依頼をば。

(現在)
+live16:206.223.152.50
+live18:206.223.152.150
+live20:206.223.150.110
+live21:206.223.154.235

(変更後)
+live16:206.223.151.230
+live18:206.223.151.230
+live20:206.223.151.230
+live21:206.223.151.230

どーん

>>732
おぉ、どもです。はやいすね。

変更確認しました。
live18, live20, live21 の TTL が 300 になっているようですが、
live16 同様、86400 でよいと思いますです。

ということで、bbsdもシングルスレッドに。

【伊達巻】負荷監視所_20060101
http://live14.2ch.net/test/read.cgi/liveplus/1136044526/403

シングルスレッドにした後も処理はさばけていたので、
とりあえず、この設定で様子見か。

ということで、虫(?)との戦いは続くと。

あとは、これか。

【伊達巻】負荷監視所_20060101
http://live14.2ch.net/test/read.cgi/liveplus/1136044526/420

こうならないことを祈りたい。

あとはApache 2.2にして、フロントのキャッシュを有効に活用できるようになるかどうかで。
空いた旧live16/20/21のどれかで、新しいhttpdのセッティングを作ってみるか。

【実況】 live22x 鯖 Part7
http://qb5.2ch.net/test/read.cgi/operate/1136038806/443

pid 80132 (httpd), uid 2001: exited on signal 6
pid 80107 (httpd), uid 2001: exited on signal 6
pid 80194 (httpd), uid 2001: exited on signal 6
pid 80026 (httpd), uid 2001: exited on signal 6
pid 80183 (httpd), uid 2001: exited on signal 6
pid 80074 (httpd), uid 2001: exited on signal 6
pid 80214 (httpd), uid 2001: exited on signal 6
...

ううむ、daily処理でhttpdの子供が一斉に。
# 親は死ななかったので、普通に立ち上がったけど。

昨日の挙動不審の影響か。

で、全面的にシングルスレッドにしたことでもしlive22が落ち着いたら、
次はいよいよ、matdを試す時期か。

>>703
>calcru: runcalcru: runtime went backwards from 1435168 usec to 1434623 usec for pid 10326 (httpd)
>time went backwards from 1380652 usec to 1380546 usec for pid 10327 (httpd)

このあたりもちょっと気になるんですが，

http://qb5.2ch.net/test/read.cgi/operate/1129310805/119-121n

ってのもあったようですね．このあたりがキーポイントかも......？


>>737
>次はいよいよ、matdを試す時期か。

いよいよですか．

Security Advisory 何通来るんだろ

>>739
これと言って緊急に対応しなければならなさそうなのは無い？ようなので
大丈夫じゃないっすかねぇ．

と思ったら，[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:04.ipfw
なるものがありますなぁ．
http://lists.freebsd.org/pipermail/freebsd-announce/2006-January/001037.html

私のところにもぼこすか。
とりあえず、8通じゃなくて4通の模様。

Dear freebsd-announce subscribers,

Due to a scripting bug, the four recent security advisories
(FreeBSD-SA-06:01.texindex, FreeBSD-SA-06:02.ee, FreeBSD-SA-06:03.cpio,
and FreeBSD-SA-06:04.ipfw) were accidentally sent out twice each, first
with the correct subject line of "FreeBSD Security Advisory ..." and
second with the incorrect subject line "FreeBSD Errata Advisory ...".
Don't worry, there are only 4 advisories, not 8.

Sorry for accidentally filling your inboxes,

Colin Percival
FreeBSD Security Officer

>>740
6.0系だけのようですね。
いまいちなので、あとでまとめて作業をば。

=============================================================================
FreeBSD-SA-06:04.ipfw Security Advisory
The FreeBSD Project

Topic: ipfw IP fragment denial of service

Category: core
Module: ipfw
Announced: 2006-01-11
Credits: Oleg Bulyzhin
Affects: FreeBSD 6.0-RELEASE
Corrected: 2006-01-11 08:02:16 UTC (RELENG_6, 6.0-STABLE)
2006-01-11 08:03:18 UTC (RELENG_6_0, 6.0-RELEASE-p2)
CVE Name: CVE-2006-0054

>>741
本家のfreebsd-announceと，日本のannounce-jpへ登録してた
もんだから倍の16通に（＾＾；；
ちょっと困ったもんだ．

ipfw.ko はとりあえず使ってないので、
リブートは不要だと判明(cook81はやってしまいましたが)。

他のはユーザランドなので、たんたんと入れ替えで。

Seanさんからリモートコンソール復活の知らせが入ったので、
bbq = cobra2245 のRAIDのチェック(どうも1台HDDがいまいちらしい)を、
明日昼間にでもやることにしようかと。

bbs.cgi再開発プロジェクト7
http://qb5.2ch.net/test/read.cgi/operate/1130918407/439-440

このスレの >>325-340 あたりを参照ですね。
そんなわけで、なんか面白い結果が出たということで。

>>745
Seanさんに状況の報告と、作業のお願いをしました。
bbqサーバで作業する前に、連絡が入る手はず。

一応、報告

PHP 5.1.2
ttp://www.php.net/ChangeLog-5.php

どのURIをアクセスしても、工事中表示にする設定
リダイレクトだとURIが変わってしまうので、mod_rewriteにて

# XXX kouji
RewriteCond %{REQUEST_URI} /kouji.html
RewriteRule ^(.*) $1 [L]
RewriteRule ^(.*) /kouji.html [L]

>>749 は最後の1行だけについしたくなるんですが、
それだとあえなく500エラーで。

>>749-750
RewriteRule !/?kouji\.html$ /kouji.html [L]

かな......

>>751
うわ、駄目出し入っちゃいました(w。

…ですね。kouji.htmlを含んだり別のところにあったりすると、
アレであると。

>>752 いや，ダメ出しってことでもないんですが，1行にまとめるとこんな感じかなぁと......

>>753
なるほど、、、。
まだまだ、しゅぎょうが必要そうすね。

mod_rewriteって、なんかその昔の(でもないか)sendmail.cfっぽいなと思ったり。

>754
mod_rewriteの解説文には複雑さをsendmailで例えていたような

>>754-755 ですね......
http://httpd.apache.org/docs/2.2/rewrite/
``The great thing about mod_rewrite is it gives you all the configurability and flexibility of Sendmail.
　The downside to mod_rewrite is that it gives you all the configurability and flexibility of Sendmail.''

1/19/2006 0:40 JST ごろ、XOロケーションのサーバに障害発生。
一時的に全サーバへの接続性が失われる。

いくつかのサーバは、電源断が入った模様。
調査結果は追ってここに。

XOにある、電源強制断が入ったサーバ:

tiger503 tiger504 tiger511 tiger512
cobra2245
tiger2508 tiger2510 tiger2511 tiger2512

XOにあるけど、電源強制断が入らなかったサーバ:

tiger509 tiger510
banana402 banana403 banana404 banana405 banana406
banana307
tiger2522 tiger2523 tiger2524 tiger2525
tiger2507 tiger2509

とりあえず現在は、全サーバとも動作している模様。

原因によっては、何らかの根本的対策が必要な予感。

ここで作業します。
緊急事態につき、野次馬カキコ禁止。

live22の板は、全部復帰できたはず。

tiger504 つながらず。
tiger509 電源断入った。復帰必要のはず。

tiger510 電源断入った。 復帰必要のはず。

tiger511 電源断再度入った。

状況から考えて、電源不安でほぼ間違いないですね。
XOロケーション全体で起こっている模様。

アクセスがピーク過ぎるまでは、起こり続ける予感。

で、対応できる現地の人が誰一人オフラインではないので、
根本対応は、日本時間の昼あたりになりそうな予感。

連絡がとれる人は全員ICQ的にオフラインのようです。
つまり、こちらではどうしようもない状況。

とりあえず、JimさんとSeanさんに状況をメール打っておきます。

とりあえず、小康状態か。

tiger504 = game10 ダウンしたままの模様。

Seanさんと連絡とれました。
状況を伝達中。

Sean (02:14 AM) :
Which servers are not online????
Me (02:14 AM) :
Now tiger504 is offline. Please check.
Sean (02:15 AM) :
Please wait while I check it.

d1donly (02:28 AM) :
tiger504 is back up now...
mumumu (02:28 AM) :
Ok, I will check now.

Me (02:53 AM) :
And I found tiger511 is now out of service.
Ping is OK, but other servers are down.
Please reboot it now.
Sean (02:54 AM) :
ok...I will.

障害は2台のサーバを追加したことによる、電源のオーバーロード。
つまり、現地のミス(誰がやったかは不明)。

Seanさんが緊急に電源を繋ぎ変え、障害の原因そのものは修復された模様。

Me (02:44 AM) :
And I have one more question. Do you complete the power rearrangement?
I mean, is the cause of the trouble solved now?
Sean (02:45 AM) :
yes....it has been solved. I sent a completed mail msg just a few minutes ago.

tiger511上がりました。

ファイルシステムが一部損傷しているようなので(datのキャッシュのところ)、
一時的にサービス止めて、リモートコンソールで作業します。

キャッシュ部分が破損していて、squidがおかしくなるようなので、
いったんキャッシュをゼロクリアして、squidを上げなおしました。< tiger511

Me (03:24 AM) :
I received reports from 2ch users all servers of 2ch are normal and back online.
I think the trouble is solved now. Thank you for your work.

But I think this is human error. So, please be careful for your operation.
we serve most biggest BBS service in Japan, so, we are watched by millions
users of Japan always... Please do not forget it, it is very important for us.
Sean (03:28 AM) :
ok....I will remember

Me (03:30 AM) :
Yes. But it is proud for us.
It is very funtastic project that 2ch makes bigger and bigger.
Let's enjoy it together.
Sean (03:31 AM) :
Yes... I agree.
Sean (03:31 AM) :
I am excited for it too....
Me (03:32 AM) :
Ok, I was relieved to see it. Please don't let you down.
But server management is very important work for us, please be careful again.
Me (03:35 AM) :
And now time is 3 AM in Japan, so I feel a little bit sleepy.
I will check the servers for a while and will go to bed.

Thanks again for your quick recovery.

…ということで今日のところは、このぐらいで。

ここには書いてないけど、
もうちょっときついこと(電源オーバーロードは2回目でしょ、とか)もゆったです。
むぎゅー。

c.2ch不具合報告総合スレ4
http://qb5.2ch.net/test/read.cgi/operate/1122639354/959

Jimさんに状況確認したところ、返事が。
昨日の続きだった模様。

全ラックを止める(先日の二の舞)の替わりに、一部サーバの電源系を移動したと。

The mobile phone user power maxed out and our new technician
made a decision to move power immediately or have the entire rack
disconnected from blown circuit breaker.
This was the correct decision to make.
I am very sorry for any inconvenience that you incurred.
Please note that power usage on the servers increases as they become busy
and this is monitored
by pie.

公式p2のサーバ引越しに伴い、
以下のDNSの変更をお願いします。

(変更前)
+p2.2ch.net:210.135.97.178

(変更後)
+p2.2ch.net:210.135.99.5

ぶひー

>>779
変更完了を確認しました。

TTL=86400(通常モード)なので、
浸透には変更後最大1日かかる予定。

http://p2.2ch.net/_service/

というわけで、よろしくです。 < いろんな中の方々

[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:06.kmem
http://lists.freebsd.org/pipermail/freebsd-announce/2006-January/001043.html
[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:07.pf
http://lists.freebsd.org/pipermail/freebsd-announce/2006-January/001044.html

でてました．

2ch.se / www.2ch.se 用の土地を作りました。

まだNSが向いていないようですが、
とりあえず従来の形で。

+2ch.se:206.223.150.250
+www.2ch.se:206.223.150.250

つまり、2ch.se と www.2ch.se を、
206.223.150.250 に向けていただければ OK です。
アカウント情報は、これからメールするです。

>>783
done

<チラシの裏>

WilTel Communications Looking Glass
http://lookingglass.wcg.net/
Cogent - Looking Glass
http://www.cogentco.com/htdocs/glass.php

</チラシの裏>

>>785
某3DGUIプロジェクトと名前が紛らわしいですなー

あ、むこうのほうが紛らわしいのかw

http://tmp6.2ch.net/
IPアドレス： http://206.223.149.90/~ch2tmp6/
バーチャルホスト変換前： http://banana340.maido3.com/~ch2tmp6/

stock.2ch.net 用の土地を作成しました。

(新規追加)
+stock.2ch.net:206.223.150.250

よろしくです。

チラシの裏。VJってゆうぐらいで。
http://www.lemis.com/grog/Documentation/vj/

Linuxの例みたいだけど、どうもいろいろ面白そうらしい。

ということで、tmp5.2ch.netをmemoriesに収容。
よろしくです。

(現在)
+tmp5.2ch.net:206.223.150.205

(変更後)
+tmp5.2ch.net:206.223.151.230

>>790
done

>>788 も done. なのを確認。

そうだった、、

done です

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh.diff?r1=1.69.2.9&r2=1.69.2.10

6.1-PRERELEASE で、 RELENG_6_1 はまだ切られてないと。

Note that we've entered code freeze and the 6.1-RELEASE cycle has
begun but we're not ready to branch yet so we call it PRERELEASE
between now and when we're ready to branch.

select問題。うむむ。

【チョコ】雪だるま作戦に思いを馳せながら雑談するスレッド Part36
http://aa5.2ch.net/test/read.cgi/nanmin/1138964618/427

> --- sys_generic.c.ORG Thu Jul 7 11:17:55 2005
> +++ sys_generic.c Mon Feb 6 11:28:07 2006
> @@ -678,7 +678,11 @@
> * FD_SETSIZE infds, outfds and exceptfds with the old FD_SETSIZE
> * of 256.
> */
> +#if 1
> + fd_mask s_selbits[howmany(8192, NFDBITS)];
> +#else
> fd_mask s_selbits[howmany(2048, NFDBITS)];
> +#endif
> fd_mask *ibits[3], *obits[3], *selbits, *sbp;
> struct timeval atv, rtv, ttv;
> int error, timo;
> にしたつもり。

【チョコ】雪だるま作戦に思いを馳せながら雑談するスレッド Part36
http://aa5.2ch.net/test/read.cgi/nanmin/1138964618/441-452

ということで、
CFLAGS+= -DFD_SETSIZE=8192
を /etc/make.conf に追加。

これがうまくいくようなら、通常サーバ(tiger/cobra)にも反映が吉か。

>>795 のカーネルソースにあるコメントも含めて考えると、
通常サーバでは CFLAGS+= -DFD_SETSIZE=2048 あたりか。

【チョコ】雪だるま作戦に思いを馳せながら雑談するスレッド Part36
http://aa5.2ch.net/test/read.cgi/nanmin/1138964618/457-469

ということで、

COPTFLAGS+= -DFD_SETSIZE=8192
を /etc/make.conf に追加。
で、カーネル入れ替え。

>>797
これじゃだめで、
/usr/include/sys/select.h をいじるのもだめで、
(/usr/src/sys/sys/select.h があるから)、
結局、

# for increasing FD_SETSIZE
makeoptions CONF_CFLAGS="-DFD_SETSIZE=8192U"

と、カーネルコンフィギュレーションファイルに書いて作り直さないと、
だめらしい。

しかも、いったんクリーンナップして作らないと、バイナリを作り直さない場合が
あるかもしれないらしい。

ということで、

/etc/make.conf:

CFLAGS+=-DFD_SETSIZE=8192U
これを追加。

COPTFLAGS に同様に追加すると、カーネル生成時に副作用があるので、
追加してはいけない(COPTFLAGSmake.conf的には何もしない)。

Apache等は正しく作れたが、これを見ないportsがあるかもしれないので
要注意。

bbsd のように直接makeする場合は、コンパイル時に-DFD_SETSIZE=8192U を
明示的に追加すること。

カーネルmake時の注意は、>>798 のとおり。

>>799
> ということで、
> COPTFLAGS に同様に追加すると、カーネル生成時に副作用があるので、
> 追加してはいけない(COPTFLAGSmake.conf的には何もしない)。

追加してはいけない(COPTFLAGSはmake.conf的には何もしないのがよい)。

rootさんこんばんはーヾ('-')ﾉ

ファイルディスクリプタのチューニングってYahooのApacheでもしてそうだな。

http://public.yahoo.com/~radwin/talks/yapache-apachecon2005.htm

>>802
おぉ、面白い資料をありがとうです。あとで読んでみます。

>>801
こんばんはです。

ttp://blog.bz2.jp/archives/2006/01/yahoo_apache.html
一応これも。

>>804
今読んでいるです。
「うんうん、そうなんだよね」なところ、「おぉー、そうか」なところ、
「そうか、そうやってるのか」なところ、などなど、すんごく参考になるですね。

> 起動と同時に最大数のプロセスを生成する
> プロセスがアイドル状態になっても終了しない

とかはまさに、死ぬほどうなづく、うんうんなところ。

>>806 について補足すると、２ちゃんねるの場合、
そうもいかないところもあるですね。

書き込み主体か読み出し主体かによっても違うし、
いろんな要因があったりするんで。

そのへんは、おいおいまたどっかに書こうかなとは思っていたりするわけですが、
思うに終始しているという話もあったりして。

・FD_SETSIZE=8192 対応カーネル
・FD_SETSIZE=8192 対応Apache2、bbsd
・Apache2 マルチスレッド復活
・bbsd マルチスレッド復活(-n 8)

@ live22

>>808
kern/sys_generic.c パッチバージョン

radwinさんの他のスライドもおもしろいよ

>>810
http://public.yahoo.com/~radwin/

んーむ。面白そうなものばかりだ。
私も、がんがらなきゃ。

rootﾀﾝファイト！

rootﾀﾝ尊敬してます。ファイト!

pid 55164 (httpd), uid 2001: exited on signal 10
pid 55160 (httpd), uid 2001: exited on signal 10
calcru: runtime went backwards from 871422 usec to 871357 usec for pid 55170 (httpd)
pid 55196 (httpd), uid 2001: exited on signal 10
pid 55218 (httpd), uid 2001: exited on signal 10
pid 55157 (httpd), uid 2001: exited on signal 10
pid 55182 (httpd), uid 2001: exited on signal 10
pid 55156 (httpd), uid 2001: exited on signal 10
pid 55184 (httpd), uid 2001: exited on signal 10
pid 55221 (httpd), uid 2001: exited on signal 10
pid 55162 (httpd), uid 2001: exited on signal 10
pid 55167 (httpd), uid 2001: exited on signal 10

虫を踏んだ時のログ。
Apacheリスタートで復活。

calcru: っていうぐらいで、カーネルの虫か?

Apacheかカーネルかライブラリか。

いずれにせよ、あとでいったんシングルスレッドに戻そう。< httpd

やはり、マルチスレッド＊も＊、あやしい模様。

【実況】 live22x 鯖 Part9
http://qb5.2ch.net/test/read.cgi/operate/1139287006/824

824 名前：動け動けウゴウゴ２ちゃんねる：2006/02/11(土) 20:42:41 ID:BYTRitRl0 ?
フジのスレが1008までいった
めちゃいけ　part6
http://live22x.2ch.net/test/read.cgi/livecx/1139657295/
1005 名無しでいいとも！ New! 2006/02/11(土) 20:40:07.79 ID:Go7yoz7N
昔紗理奈もやられてたな
1006 名無しでいいとも！ sage New! 2006/02/11(土) 20:40:08.12 ID:sFKhtQWa
遺留品ｗｗｗｗｗｗｗｗ
1007 名無しでいいとも！ New! 2006/02/11(土) 20:40:08.73 ID:IEqIP2kY
１０００！！
1008 １００１ New! Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

これ、vmwareの話だけど、

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-06/0457.html

%sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

うーむ、やってみるか。

# suspicious "calcru: runtime went backwards" wordaround
# see http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-06/0457.html
kern.timecounter.hardware=TSC

を /etc/sysctl.conf に入れて、

sysctl kern.timecounter.hardware=TSC

を実行。@ live22

>>819 を実施したので、再度様子見。
再発するようなら、MT 再度オフで。

LA=15超えたら、Apacheをリスタートするしくみを入れてみた。
daily処理の時とリスタート後120秒以内は、発動しないようにしたつもり。

# for increasing -DFD_SETSIZE=8192U
.if ${.CURDIR} != "/var/src/libexec/rlogind"
CFLAGS+=-DFD_SETSIZE=8192U
.endif

なんてやらないといかんかった。せめて#undefしてほしいかも。 < rlogind

rlogind.c に、こんなことが直書き。

#define FD_SETSIZE 16 /* don't need many bits for select */

%grep ACPI- /var/run/dmesg.boot
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000

%sysctl -a | grep hz
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }

というぐらいで、6.0RでHZが1000になったのが、
微妙に影響していたりするかも、かも。

# とりあえず変えないけど。

で、
%sysctl -a | grep TSC
kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-1000000)
kern.timecounter.hardware: TSC

ここが -100 (品質だめ = 選ばれない)になっていることに気づき、
/usr/src/sys/i386/i386/tsc.c を読むと、

#ifdef SMP
static int smp_tsc;
SYSCTL_INT(_kern_timecounter, OID_AUTO, smp_tsc, CTLFLAG_RDTUN, &smp_tsc, 0,
"Indicates whether the TSC is safe to use in SMP mode");
TUNABLE_INT("kern.timecounter.smp_tsc", &smp_tsc);
#endif

となっていて、

#ifdef SMP
/*
* We can not use the TSC in SMP mode unless the TSCs on all CPUs
* are somehow synchronized. Some hardware configurations do
* this, but we have no way of determining whether this is the
* case, so we do not use the TSC in multi-processor systems
* unless the user indicated (by setting kern.timecounter.smp_tsc
* to 1) that he believes that his TSCs are synchronized.
*/
if (mp_ncpus > 1 && !smp_tsc)
tsc_timecounter.tc_quality = -100;
#endif

ということらしく、

でも、TSCにしてちゃんと動いているということは、
このマザボはたまたま "Some hardware configurations do this"
なやつらしく、

%sysctl -a | grep smp_tsc
kern.timecounter.smp_tsc: 0

のように、デフォルトではオフになっていて、

%sysctl kern.timecounter.smp_tsc=1
sysctl: oid 'kern.timecounter.smp_tsc' is a read only tunable
sysctl: Tunable values are set in /boot/loader.conf

ということなので、sysctl.conf で指定する必要があると。

>>826
× ということなので、sysctl.conf で指定する必要があると。
○ ということなので、/boot/loader.conf で指定する必要があると。

でもどうせ、TSCのクオリティは、

static struct timecounter tsc_timecounter = {
tsc_get_timecount, /* get_timecount */
0, /* no poll_pps */
~0u, /* counter_mask */
0, /* frequency */
"TSC", /* name */
800, /* quality (adjusted in code) */
};

のように、800と決められているようなので、
ACPI-fast(1000)には負ける模様(未確認)。

なので、/boot/loader.conf への追加はどうもしなくてよくて、
/etc/sysctl.conf に TSC を強制選択すると書いておけば、いい模様。

TSCまわりだと、こんなパッチが出てる模様。
http://docs.freebsd.org/cgi/mid.cgi?1835.1139524338
6-stableにマージされるのが楽しみ。

>>829
おぉ、 phk ですか。
わくてかってかんじで。

>>829 のパッチを読んでいますが、
これって calcru をまるっきり置き換えなんすね。
まさに、○○だねみたいな。

# for Torino olympic games
0 17 * * * /usr/local/bin/home-backup.sh /home

@ live22

もともとは 14:00 PST/PDT >>832

今日健康でもLA=10超えたので、
>>821 を LA=20 で発動に変更。

>>819
> # suspicious "calcru: runtime went backwards" wordaround

word => work

# おはずかしい。

>>832
月曜の朝10時にフルダンプするのもいまいちなんで、
あとで、2時間ぐらい早めておこう。

いまさらだけど>>811のradwinさんのスライド読みました。
これはすごいですねーー。
kill -HUP しなくてログローテーションとかどうやるんだろう。
inode変るはずなのに。

>>837
それ用のモジュールあたりかしら。

Apache 2.2系で環境を作るべく、調べ中。
以下、FreeBSDのports的観点でまずは。

・Apache 2.2系では最初からkqueue(2)をサポートしている模様。
- ports作る時のWITH_KQUEUE_SUPPORTは、不要(意味なし)になった。
・configとかが/usr/local/etc/apache22の下に変わる
・同様にモジュールの場所も/usr/local/libexec/apache22の下に変わる

2ch的には、
・mod_cgidsoは再インストールが必要

あたりか。

/usr/local/etc/rc.d/apache22.sh

これも名前が変わる。

#
# Add the following lines to /etc/rc.conf to enable apache22:
# apache22_enable (bool): Set to "NO" by default.
# Set it to "YES" to enable apache22
# apache22_profiles (str): Set to "" by default.
# Define your profiles here.
# apache22limits_enable (bool):Set to "NO" by default.
# Set it to yes to run `limits $limits_args`
# just before apache starts.
# apache22_flags (str): Set to "" by default.
# Extra flags passed to start command.
# apache22limits_args (str): Default to "-e -C daemon"
# Arguments of pre-start limits run.
# apache22_http_accept_enable (bool): Set to "NO" by default.
# Set to yes to check for accf_http kernel
# module on start up and load if not loaded.

のように、accf_http(9)のオン・オフをrc.confに書くようになった。
デフォルトでは入らないので注意。

/usr/ports/CHANGES:

20051108:
AUTHOR: [email protected]
The following changes were introduced:
...
* Add bsd.apache.mk
USE_APACHE knob enhancements

/usr/ports/Mk/bsd.apache.mk:

# Variables definition
# USE_APACHE: Call this script. Values can be:
# <version>: 1.3/13/2.0/20/2.1/2.2/1.3+/2.0+/2.1+/2.2+
# common*: common13, common20, common21 and common22

ということは、/etc/make.conf に、

# added by mumumu, for Apahce 2.2 -- 2006/2/13
USE_APACHE=common22

を追加でいいのかな。

<IfModule dir_module>
DirectoryIndex index.html
</IfModule>

IfModuleの文法が変わったですか。
(多分前のもいけるんでしょうけど)

>>839
>Apache 2.2系で環境を作るべく、調べ中。

いよいよですか．2.2 なら Event MPM も挑戦する価値あるかも．

>・mod_cgidsoは再インストールが必要

それを用いるプログラム (read.cgi 等) もですね．

>>843
> それを用いるプログラム (read.cgi 等) もですね．

おぉ、なるほど。

で、さっきまた症状再発。

アイドルタイムがぐぐぐとなくなり、でもtop的にはプロセスがRUNにならないのに、
ロードアベレージが上がり続けるという、いかにもカーネルのバグっぽい、
謎な状態になる模様。

症状はこれまでと全く同じ。

%grep backward /var/log/messages
Feb 13 10:27:24 <0.2> tiger2522 kernel: calcru: runtime went backwards from 235116018 usec to 235115799 usec for pid 28466 (httpd)
Feb 13 10:28:06 <0.2> tiger2522 kernel: calcru: runtime went backwards from 557817 usec to 557807 usec for pid 17019 (httpd)
Feb 13 10:28:06 <0.2> tiger2522 kernel: calcru: runtime went backwards from 547476 usec to 547431 usec for pid 16997 (httpd)
Feb 13 10:28:21 <0.2> tiger2522 kernel: calcru: runtime went backwards from 1734019 usec to 1733938 usec for pid 16944 (httpd)

2006-02-14 03:26:37.805228500 MaxLA = 20, LA = 2.13818359375
2006-02-14 03:27:07.806554500 MaxLA = 20, LA = 14.9033203125
2006-02-14 03:27:37.808498500 MaxLA = 20, LA = 98.05224609375
2006-02-14 03:27:37.809198500 delta = 1139855257
2006-02-14 03:27:37.809226500 Restarting apache...
2006-02-14 03:27:37.893737500 Performing sanity check on apache2 configuration:
2006-02-14 03:27:38.135912500 Syntax OK
2006-02-14 03:27:38.193105500 Stopping apache2.
2006-02-14 03:27:38.208165500 Waiting for PIDS: 55140, 55140, 55140, 55140, 55140, 55140.
2006-02-14 03:27:50.395771500 Starting apache2.
2006-02-14 03:28:21.037681500 MaxLA = 20, LA = 82.00390625
2006-02-14 03:28:21.037954500 delta = 30
2006-02-14 03:28:21.037975500 delta = 30, not restarting
2006-02-14 03:28:51.038550500 MaxLA = 20, LA = 79.72509765625
2006-02-14 03:28:51.038668500 delta = 60
2006-02-14 03:28:51.038692500 delta = 60, not restarting
2006-02-14 03:29:21.039819500 MaxLA = 20, LA = 49.25634765625
2006-02-14 03:29:21.039891500 delta = 90
2006-02-14 03:29:21.039907500 delta = 90, not restarting
2006-02-14 03:29:51.041112500 MaxLA = 20, LA = 30.40380859375
2006-02-14 03:29:51.041344500 delta = 120
(続く)

2006-02-14 03:29:51.041389500 Restarting apache...
2006-02-14 03:29:51.056401500 Performing sanity check on apache2 configuration:
2006-02-14 03:29:51.104448500 Syntax OK
2006-02-14 03:29:51.121918500 Stopping apache2.
2006-02-14 03:29:51.186926500 Waiting for PIDS: 16927, 16927, 16927.
2006-02-14 03:29:57.209463500 Starting apache2.
2006-02-14 03:30:28.033177500 MaxLA = 20, LA = 53.62548828125
2006-02-14 03:30:28.033181500 delta = 30
2006-02-14 03:30:28.033183500 delta = 30, not restarting
2006-02-14 03:30:58.033944500 MaxLA = 20, LA = 35.7099609375
2006-02-14 03:30:58.034165500 delta = 60
2006-02-14 03:30:58.034201500 delta = 60, not restarting
2006-02-14 03:31:28.035250500 MaxLA = 20, LA = 22.26318359375
2006-02-14 03:31:28.035586500 delta = 90
2006-02-14 03:31:28.035631500 delta = 90, not restarting
2006-02-14 03:31:58.036485500 MaxLA = 20, LA = 12.85009765625
2006-02-14 03:32:28.037717500 MaxLA = 20, LA = 8.75927734375
2006-02-14 03:32:58.038980500 MaxLA = 20, LA = 5.54248046875
2006-02-14 03:33:28.040237500 MaxLA = 20, LA = 3.64404296875
2006-02-14 03:33:58.041496500 MaxLA = 20, LA = 2.49658203125
2006-02-14 03:34:28.042745500 MaxLA = 20, LA = 1.51171875
(以下略)

[Mon Feb 13 10:27:24 2006] [notice] child pid 28437 exit signal Bus error (10)
[Mon Feb 13 10:27:41 2006] [warn] child process 28391 still did not exit, sending a SIGTERM
[Mon Feb 13 10:27:41 2006] [warn] child process 28392 still did not exit, sending a SIGTERM
[Mon Feb 13 10:27:41 2006] [warn] child process 28393 still did not exit, sending a SIGTERM
[Mon Feb 13 10:27:41 2006] [warn] child process 28394 still did not exit, sending a SIGTERM
...
[Mon Feb 13 10:27:47 2006] [error] child process 28391 still did not exit, sending a SIGKILL
[Mon Feb 13 10:27:47 2006] [error] child process 28392 still did not exit, sending a SIGKILL
[Mon Feb 13 10:27:47 2006] [error] child process 28393 still did not exit, sending a SIGKILL
[Mon Feb 13 10:27:47 2006] [error] child process 28394 still did not exit, sending a SIGKILL
...
[Mon Feb 13 10:27:49 2006] [notice] caught SIGTERM, shutting down
[Mon Feb 13 10:27:50 2006] [notice] suEXEC mechanism enabled (wrapper: /usr/local/sbin/suexec)
[Mon Feb 13 10:27:51 2006] [notice] mod_cgidso enabled
[Mon Feb 13 10:27:56 2006] [notice] Apache/2.0.55 configured -- resuming normal operations
[Mon Feb 13 10:28:02 2006] [notice] child pid 16999 exit signal Bus error (10)
[Mon Feb 13 10:28:03 2006] [notice] child pid 16994 exit signal Bus error (10)
[Mon Feb 13 10:28:03 2006] [notice] child pid 16980 exit signal Bus error (10)
[Mon Feb 13 10:28:04 2006] [notice] child pid 17000 exit signal Bus error (10)
...
[Mon Feb 13 10:29:54 2006] [warn] child process 16944 still did not exit, sending a SIGTERM
[Mon Feb 13 10:29:54 2006] [warn] child process 16946 still did not exit, sending a SIGTERM
[Mon Feb 13 10:29:54 2006] [warn] child process 16947 still did not exit, sending a SIGTERM
[Mon Feb 13 10:29:54 2006] [warn] child process 16948 still did not exit, sending a SIGTERM
...
(続く)

ひょっとしてこれが解決策になるかも


ttp://d.hatena.ne.jp/hiro-ueda/20060118

[Mon Feb 13 10:29:56 2006] [notice] caught SIGTERM, shutting down
[Mon Feb 13 10:29:57 2006] [notice] suEXEC mechanism enabled (wrapper: /usr/local/sbin/suexec)
[Mon Feb 13 10:29:58 2006] [notice] mod_cgidso enabled
[Mon Feb 13 10:30:00 2006] [notice] Apache/2.0.55 configured -- resuming normal operations
(ここまで)

>>849
↓
>>817-819

・装置は2回発動
・2回とも死ぬ前に SIGBUS 発生
・1回目はSIGTERMでは死なず、SIGKILLで死んだ
・2回目はSIGTERMで死んだ

今日作ったインストールキット使って、Apache 2.2を入れてみるか。

ついに2.2投入ですか
早朝実況組もいますがざっくり入れちゃっても問題はないと思います。
（どの時間帯に実施しても騒ぎになること必定ですし）

ううーむ。
http://www.atm.tut.fi/list-archive/freebsd-stable-2005/msg08332.html

>>854
カーネルバグっぽいので、ちょっと躊躇していたり。
で、>>855 の件を調べちゅう。

うーむ。
http://www.atm.tut.fi/list-archive/freebsd-stable-2005/msg08344.html

症状は、これなんですよね。
http://www.freebsd.org/cgi/query-pr.cgi?pr=72338

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_resource.c

Revision 1.151 / (download) - annotate - [select for diffs], Mon Jan 23 19:15:13 2006 UTC (3 weeks ago) by ups
Branch: MAIN
Changes since 1.150: +1 -1 lines
Diff to previous 1.150 (colored)

Hopefully fix the "calcru: runtime went backwards from ..." problem by
keeping the resource values locked (where needed) while we use them
for calculations.

MFC after:3 days

…で、これはまだMFCされていない模様。

>>859 は、
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_resource.c.diff?r1=1.150&r2=1.151

===================================================================
RCS file: /usr/local/www/cvsroot/FreeBSD/src/sys/kern/kern_resource.c,v
retrieving revision 1.150
retrieving revision 1.151
diff -u -p -r1.150 -r1.151
--- src/sys/kern/kern_resource.c2005/11/02 21:18:071.150
+++ src/sys/kern/kern_resource.c2006/01/23 19:15:131.151
@@ -35,7 +35,7 @@
*/

#include <sys/cdefs.h>
-__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/kern/kern_resource.c,v 1.150 2005/11/02 21:18:07 ps Exp $");
+__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/kern/kern_resource.c,v 1.151 2006/01/23 19:15:13 ups Exp $");

#include "opt_compat.h"

@@ -733,8 +733,8 @@ calcru(p, up, sp)
&pcpu_find(td->td_oncpu)->pc_switchtime);
}
}
-mtx_unlock_spin(&sched_lock);
calcru1(p, &rux, up, sp);
+mtx_unlock_spin(&sched_lock);
p->p_rux.rux_uu = rux.rux_uu;
p->p_rux.rux_su = rux.rux_su;
p->p_rux.rux_iu = rux.rux_iu;

…でもこれ、1.154で「ばっさりこん」なんですよね。
>>829 のやつのもより。

うーむうーむ。

>>859
がびーん。

Revision 1.152 / (download) - annotate - [select for diffs], Wed Jan 25 02:05:47 2006 UTC (2 weeks, 5 days ago) by ups
Branch: MAIN
Changes since 1.151: +1 -1 lines
Diff to previous 1.151 (colored)

Back out changes made in rev. 1.151.
They were bogus.

Cluebat applied by: jhb@

いずれにせよ、、、カーネルの虫ってことっぽいのかな。

Apacheを変えるのはそれはそれで意味ありそうなんで、
そっちは、たんたんとやるかんじかなと。

ということで、Apache 2.2.0 を投入。@ live22

TransferLog の動きが、2.0 と違うみたい。

TransferLog "| /usr/local/sbin/logbuffer"

とかやっているのですが、Apache 2.xでは直接起動してくれたlogbufferが、

%ps ax | grep logbuffer
74136 ?? I 0:00.01 /bin/sh -c /usr/local/sbin/logbuffer
74137 ?? S 0:01.30 /usr/local/sbin/logbuffer
74568 p1 S+ 0:00.00 grep logbuffer

のように、sh経由になり、
しかもApacheをリスタートすると、暴走状態で残ってしまうようです。
(kill -TERMで死にはする)

おぉ、Apache 2.2 系列では
今の read.cgi は、そのままではコンパイルできないっぽい。

gcc -c read.c -I`apxs -q INCLUDEDIR` -O2 -Wall -funsigned-char -fPIC -DSNOWMAN -o read.o
In file included from read.c:1:
read.h:11:22: apr_date.h: No such file or directory
read.h:12:25: apr_file_io.h: No such file or directory
read.h:13:21: apr_lib.h: No such file or directory
read.h:14:25: apr_strings.h: No such file or directory
read.h:15:24: apr_tables.h: No such file or directory
read.h:16:22: apr_time.h: No such file or directory
read.h:20:22: apr_want.h: No such file or directory

>864
これですか？

ttp://httpd.apache.org/docs/2.2/ja/mod/mod_log_config.html#logformat

>>866
そうです。で、

TransferLog "| exec /usr/local/sbin/logbuffer"

とすることで、前と同じ動きになりました。
リスタートしても大丈夫でした。

色々、微妙みたい。

>>865
/usr/local/include/apr-1 に入るのかぁ。
ってことは、Makefile 更新しないとってことかい。

-I`apxs -q INCLUDEDIR` -I/usr/local/include/apr-1

とかやって、read.cgi はできる模様。

あとは、例の装置のリスタート部分を2.2対応にすればOKかな。
やっておこう。

で、今日はそろそろみせじまいで。

2.2 稼働ですか，乙です．あとは mod_cache がちゃんと使えるようになれば
バック側の httpd がかなり楽になりますね．

>>869 は、

%apr-1-config --includes
-I/usr/local/include/apr-1

これ使ったほうがよさげ。

で、>>871 (live22x[123]をApache 2.2にする)をそのうち。

(´-`).｡ｏＯ(2.3になると、deny allow がなくなるそうな)

>>873
まじすか。
つまり2.4を使う頃には、あれのしくみ変えないといけないと。

これですね
まだ2.3すら出てないし、これからどうなるか知らないですけど

http://svn.apache.org/repos/asf/httpd/httpd/trunk/CHANGES

*) Authz: Mark the directives 'Order', 'Allow', 'Deny' and 'Satisfy' as
deprecated and move them into the new module mod_access_compat which
can be loaded to provide backwards compatibility for these directives.
[Brad Nicholes]

>>875
mod_access_compat 入れれば、一応互換性は保てることにすると。
たぶん、もっといいしくみにしようってことなのかしら。

このあたりかな......
http://www.mail-archive.com/[email protected]/msg30304.html

フロント2台追加の第一段階(基本セットアップ)ができました。
以下のDNSへの追加をお願いします。

これをDNSに追加することにより、第二段階(掲示板システムに必要なファイル入れたり、
F22をセットアップしたり等)が、できるようになります。

で、それができた後で、ラウンドロビンへの投入
(= DNSに再度追加し、live22x の仲間に入れる)という手順を踏むことになります。

以上、よろしくです。

(新規追加)
+live22x4.2ch.net:206.223.150.110:300
+live22x5.2ch.net:206.223.150.42:300

で、これら2台はApache 2.2 + worker MPMです。

キャッシュ関係はオフです。
どうも、Apache 2.0 で入れていた以下の設定は、そのままではエラーになる模様。
CacheSize なんて知らないよ、って言われたです。

# include cache config file
<IfModule cache_module>
# config cache directory and size
CacheRoot /md/cache
CacheSize 65536
</IfModule>

>>879
そこも設定かわっているみたいですな。

ttp://httpd.apache.org/docs/2.2/ja/mod/mod_disk_cache.html
を参考にすると

<IfModule mod_disk_cache>
# config cache directory and size
CacheRoot /md/cache
CacheMinFileSize 64 #(デフォは1)
CacheMaxFileSize 1000000 #(デフォは1000000)
</IfModule>

などと書くのが正しいようですね。

>>878-879 乙です．
>で、これら2台はApache 2.2 + worker MPMです。

どうせなら，どちらか片方を event MPM にしてみるとか......
http://httpd.apache.org/docs/2.2/mod/event.html

あと，キャッシュ保持時間とかのチューニングの手段は，と......

フロント側 mod_cache のディレクティブ:
    CacheLastModifiedFactor
    CacheMaxExpire

バック側 mod_headers で Cache-Control ヘッダ付加:
    # キャッシュ保持時間が n 秒未満なら再評価なしにキャッシュをそのまま使用
    # その後は conditional GET で再評価する
    Header set Cache-Control s-maxage=n

>>878
そろそろ受付嬢の再投入は？

live22x4,live22x5のIPアドレスを直接ラウンドロビンに
いれるのではなく、受付嬢での振り分け先をlive22x4,live22x5に
して、受付嬢の代表IPアドレスを登録する。

とりあえず、1/4の負荷からはどうでしょう。
おちても、3/4の確率でつながるので、以前ほどはひどくないかと。

>>878
done

>>880 以降へのレスは別途まとめて。

まずは、くーるすれっずにちょっとﾜｸﾃｶしておこうと。

Sun、『UltraSPARC T1』プロセッサの仕様を公開
http://japan.internet.com/webtech/20060215/12.html

>>880 >>882
どもです。
ディスクキャッシュの時は、htcacheclean ってのを動かすかんじなのか。
いろいろ読み中。

>>881
Event MPM
The event MPM uses a seperate thread to handle Keep Alive requests and
accepting connections. Keep Alive requests have traditionally required httpd
to dedicate a worker to handle it. This dedicated worker could not be used
again until the Keep Alive timeout was reached.

おぉ、なんかよさげですね。
入れてみるかな。

>>883
魅力的ですが、一歩一歩やっていこうかなと。
普通にラウンドロビンして、次にmatdか。

で、

フロントは負荷的には足りているような気がするのに、なぜ2つ追加投入するのか

の件ですが(私も疑問を持ちました)、
それは「雪だるまシステム」そのもののテスト、という意味合いがあるとのことです。

ようは、スロー同期とか今の形で構築したシステムが、フロントが増えていっても
ちゃんと動くようになっているかとかを、いまのうちにきちんと試しておきたいと。

どうせ、フロントは増える方向だし、このシステムは将来にわたり使うに違いないので、
いまのうちにきちんとしたものを作っておくほうが、いいんじゃないかなということで。

…ということで、私も納得したと。

で、cobra2247は「コブラをバックエンドにしたらどんなかんじなのか」を試すということで、
バックエンドに仕立てると。

live22x[45] を作る場合の手順:

・器を作る
・フロントパック(フロントにするためのもの一式)を入れる
・スロー同期のための設定をする (live22x[45], live22)
・スロー同期スクリプトを手で動かす
=> それまでの過去ログがどばーっと転送される (要注意)
・cronの設定をする(定時スロー同期開始)
・BBx 等にIPアドレスを登録する

・DNSに live22x[45] を登録する
・投稿のテストをする
・F22/丁稚どん/配布リストに live22x[45] を登録する

・DNSに live22y として追加登録する => 将来は live22b[12] の matd に追加、になる
・ｳﾏｰ

>>887
雪だるまスレのほうがよいのかもしれないけど。
なんとなく、フロントで過去ログをもっているのが厳しいかも。

バックを複数もつとフロントは掛算で過去ログを持ちますよね。
そこが大変そう。

ディスクは十分大きいから大丈夫かもしれないし、
自動的にコピーができるから、バックアップする必要がないという
うれしい点があるかもしれないけど。

メンテを考えると、過去ログは、bbsdを動かすバックエンドとは
別のバックエンドに突っ込むほうがよいのかなと思う。
(dat落ちのタイミングでコピーかな。)

ここらへんも実験！実験！なんでしょうが。

ふむふむ。

そうすれば各フロントが過去ログをバックにとりにいかなくてよくなるから、
バックも軽くできる気がしますね。

cobra2247をバックにしたら、今のtiger2522をそれに転用してみるとか。

新 epg.2ch.net の Apache を、event MPM にしてみた。
設定そのものはこんなかんで、worker MPMと変わるところがないみたい。

<IfModule mpm_event_module>
StartServers 24
ServerLimit 36
MaxClients 1152
MinSpareThreads 128
MaxSpareThreads 768
ThreadsPerChild 32
MaxRequestsPerChild 1000000
ThreadLimit 32
MaxMemFree 64000
</IfModule>

確かに今の過去ログのやり方のままだと，今後大変になるかも知れないんですよね．
とはいえ，ライブな dat と同じように mod_proxy でやると offlaw.cgi の改造が必要だし，
さらに mod_cache を使用するとなると /md を過去ログで食い潰すかも知れないし......

となると，いっそ NFS を使ってみるとか．以前雪だるまでライブな dat の読み出しに
NFS 使ってた時の問題，例えば不規則に dat の内容が壊れるとか ESTALE 発生が
カーネルごとコケる引き金になるとか，そういうのは過去ログでは発生しにくいのでは，
と思えなくもないですし......

ここは一つ、全鯖規模で過去ログの一元化を

>>892
過去ログはフロントでキャッシュする必要はないんじゃないかと。
(CacheDisableで過去ログのURLをはずすことはできないんですかね？)
offlaw.cgiは、誰かさんが泣きながら書き換えてもらって。

NFSは、サーバ間がちょっと密結合になってうれしくないかも。
# 感覚だけですが。

>過去ログはフロントでキャッシュする必要はない

私も原理はそれに賛成。
ただ /doom/kako/ 以下はインデックスなんで各フロントにあった方がいいかと

Yahoo! User Interface Library
ttp://developer.yahoo.net/yui/

|∀･)ﾉ

>>894
>(CacheDisableで過去ログのURLをはずすことはできないんですかね？)

確かに可能ですね．

>offlaw.cgiは、誰かさんが泣きながら書き換えてもらって。

このあたりは，実際に書き換える中の人次第ということで......

>>886
> 普通にラウンドロビンして、次にmatdか。

matdできになっているのは、負荷への耐性がどの程度あるか
わからない点なんですよね。

動作はばっちりだと思うのですが、アプリとして
動くみたいなので、カーネルとの切り替えがばかに
ならないのかなと。
(パケット1個単位で切り替えですよね。)

そんなこともあって、いっきにつっこむのではなく、
少しずつ動かした方がよいのではないのかと。

>>898
> matdできになっているのは、負荷への耐性がどの程度あるか
> わからない点なんですよね。

まずは(他の系が安定している)どっかで、試してみるか。
携帯(c)とかか。

>>881
live22x4 を、event MPMで動かしてみた。

・live22x4: Apache 2.2.0 + event MPM
・live22x5: Apache 2.2.0 + worker MPM (比較のため)

今日 or 明日あたりに、フロントに投入予定。

>>898
>matdできになっているのは、負荷への耐性がどの程度あるかわからない点なんですよね。

確かに．

>アプリとして動くみたいなので、カーネルとの切り替えがばかにならないのかなと。
>(パケット1個単位で切り替えですよね。)

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

パケット送出の方は1パケット単位ですね．マルチスレッドモードなら
まとめて取り込まれたパケットの送出をコンカレントに行いますが，SMP でないと無意味
（シングル CPU だとかえってコンテキストスイッチングによるオーバヘッドが発生する）
だと思うんで，デフォルトではシングルスレッドモードになってます．

live22x4/live22x5 フロントに投入します。

以下の登録をよろしくです。

(追加)
+live22y.2ch.net:206.223.150.110
+live22y.2ch.net:206.223.150.42

>>902 訂正です。
TTLは他同様、300でお願いします。

(追加)
+live22y.2ch.net:206.223.150.110:300
+live22y.2ch.net:206.223.150.42:300

>>903

done

proxy との相性が悪かったのか、event MPM では 502 エラー出まくり。
あわてて、worker MPM に戻すことに。

【実況】 live22x 鯖 Part10
http://qb5.2ch.net/test/read.cgi/operate/1139729945/379 あたり。

event MPMのバグじゃなくて、設定に1つ抜けがあった模様。
ううむ。

＊フロント作成時の重要な注意＊

192.168.100.1 live22x.2ch.net

を、/etc/hosts に必ず追加すること。

これを入れないと、mod_proxy による dat 取得が失敗する。
(live22x[1-5]は、live22x.2ch.net という名前で live22.2ch.net のプライベート側に
とりにいくため)

しかしどうして、動いたり動かなかったりってことが起きたんだ?

あ、わかった、、、。live22x は代表名だから、
自分にアクセスが向くと、だめになるということか。

live22x4 の event MPM を復活。

様子を観察中ですが、、、。

event MPMって、何か負荷が高いですね。
たまにhttpdがいっせいにRUN状態になります(topで)。

で、Apache statusで見てみると、こんなふうに
1つのworker にほとんどがぶら下がる感じになっているようです。
つまり、分散していない。

________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________................................
________________________________________________________________
________________________________________________________________
________________________________________________________________
___________C____________________________________________________
________________________________________________________________
_____________________________________R____C____C____C___________
W_RCC_C__C____W_W__CRC_CR_CWCC__________________________________

で、こんな具合にそのhttpdが負荷高くなって、LAが上がります。
(CPU idle timeが少なくなる)

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
98662 ch2live22x 21 20 0 96076K 68860K kserel 0 13:17 7.18% httpd
2005 ch2live22x 1 97 0 14292K 13572K select 2 0:14 2.78% speedy_back
2659 ch2live22x 1 96 0 13900K 13168K select 2 0:04 2.64% speedy_back
666 dnscache 1 96 0 32804K 32116K select 2 2:08 0.00% dnscache
667 dnslog 1 -8 0 1204K 576K piperd 0 1:29 0.00% multilog
98661 ch2live22x 8 20 0 67652K 44428K kserel 1 0:25 0.00% httpd
98653 ch2live22x 9 20 0 32096K 22444K kserel 1 0:13 0.00% httpd
98651 ch2live22x 7 20 0 25360K 16552K kserel 1 0:11 0.00% httpd
98642 ch2live22x 7 20 0 22668K 14328K kserel 0 0:11 0.00% httpd
98646 ch2live22x 7 20 0 27560K 17652K kserel 1 0:11 0.00% httpd

ようはひとことでいうと、挙動不審ってかんじですね。

17:00 ぐらいまで様子見たら、worker MPM に戻そうかと。

(Apche 2.2 + worker MPMで動かしているlive22x5は、特に問題なし)

受付嬢はたくさん窓口にいるのに、いきなりみんななぜか忙しくなって開いている窓口がひとつだけ
しかもその人はごにょごにょしていてまずー

ってな状態と解釈しましたが、違いますかね？

新 epg も、worker MPM に戻した。

>>912
概ね、そんなかんじかもです。

というか空いている窓口がいっぱいあるのに、みんな同じ受付に案内されてしまうかんじ。

次は、キャッシュありの状態に挑戦か。

mod_disk_cache の場合の容量指定

Apache 2.2系ではディスクキャッシュにした場合、
htcacheclean コマンドでキャッシュのパージをする。

定期的にcron等から起動するか、-d(インターバル)をつけて
デーモンにする。

例えばこんな感じで指定する。

htcacheclean -d60 -p/md/cache -l64m

-d: デーモンモード、インターバル時間(秒)
-p: キャッシュディレクトリ(httpd.confで指定したものを指定)
-l: キャッシュ最大容量

今の設定:

CacheDisable /dome/SETTING.TXT
CacheEnable disk /dome/
CacheDisable /dancesite/SETTING.TXT
CacheEnable disk /dancesite/
CacheDisable /endless/SETTING.TXT
CacheEnable disk /endless/
... (以下、板の分だけ)

<IfModule cache_module>
Include /home/ch2live22x/test/httpd/cache.conf <= 上記を指定しているファイル
# config cache directory
CacheRoot /md/cache
</IfModule>

これだけ。
今はまだ >>882 等のチューニングは何もしてない状態。

【実況】 live22x 鯖 Part10
http://qb5.2ch.net/test/read.cgi/operate/1139729945/537

537 名前：root▲ ★[] 投稿日：2006/02/17(金) 20:35:52 ID:???0 ?#
CacheDefaultExpire 1
CacheMaxExpire 1

に再設定。

さて、キャッシュヒットの様子って、
どうやったら見られるんだろう。

で、「連打」とか「みんながいっせいに」を防げればいいわけだから、
1秒効いてくれれば、かなりいけるんじゃないかなぁと思ったり。

で、特に携帯(c)系で妙な挙動が起こったらしく、
いったんオフに戻した。

全フロントをApache 2.2にしてから、再度実験か。
Apache 2.2 @ フロントが大丈夫かの確認も伴うので、明日以降ってかんじで。

>>908-911 う〜む......まだ event MPM は発展途上ってことですかね．
今後は非同期 write / read の機能も加わるようなので，今後に期待かな．

>>919
>さて、キャッシュヒットの様子って、どうやったら見られるんだろう。

LogLevel を debug にすればわかりますが，実運用環境で debug は
さすがにきついか...... HTTP レスポンスヘッダに Age が入ってるのが
ヒットしてる目印になるかな．というか，その Age が Squid に
悪影響を与えているのが >>921 だったり!?

>>922
> HTTP レスポンスヘッダに Age が入ってるのが
> ヒットしてる目印になるかな．というか，その Age が Squid に
> 悪影響を与えているのが >>921 だったり!?

とっても高い確率で、ビンゴの予感。

そういえば、2chの鯖って(root権ありのやつ)全部root氏の管理っすか？

>>924
管理というか、おもりしているですね。
私以外にも root password を知っている人はいます。

■ XOロケーションの２ちゃんねるラックの現状(2005年2月18日現在)

合計25台(tiger: 17, cobra: 2, banana: 6)
すぐに移設可能なのは上記中6台(tiger: 3, cobra: 1, banana: 2)

○ Love affair作戦 - tiger: 8, banana: 2 = total: 10

tiger2507
tiger2508
tiger2509
tiger2510
tiger2511
tiger2512
banana405
banana406
tiger511
tiger512

○ 雪だるま作戦 - tiger: 6, cobra: 1, banana: 2 = total: 9

tiger2522
tiger2523
tiger2524
tiger2525
tiger503
tiger507
cobra2247
banana403
banana404

○ 上記のどちらでもない(移設可能) - tiger: 3, cobra: 1, banana: 2 = total: 6

tiger504 - game10
tiger509 - news19
tiger510 - hobby7
cobra2245 - BBQ
banaan402 - VIP931/stock
banana307 - BBM

現在 banana402 を別のラックに移設中。。。

>>928
了解です。リストを更新しておきます。
IPアドレスは変わらないと。

はい　変わらないように移設とお願いしました。

他のも、移設しておきますかね。

準備が整わないなら今日じゃなくてもいいですが、
割と近日中にってかんじで。

安全に移設できるなら、今日のほうがいいですが。
やるなら、該当サーバshutdownします。

配置計画とかあるから
今日は無理ー

土曜で人手不足ぎみ

>>933
了解です。

んでは、現状を現地に伝えて(私からしたほうがいいのかな: やっておきます)、
配置計画を練ってもらうということで。

【�d汁】雪だるま作戦に思いを馳せながら雑談するスレッド Part37
http://aa5.2ch.net/test/read.cgi/nanmin/1139755994/966-967

なるほど。

うげっ

VIP931/stock
同居なのか、しらなかった

ちと鬱

>>937
適当なところに場所作ってくださいー、という指令で、
root権限ありのうち、いちばん空いていたサーバに入れたです。

ちなみにcook81と同居なことは、雪だるま作戦のスレでさんざん書いていたです。

>>936 mod_cache のコード見ると，ETag が weak か否かとキャッシュは
直接関係ないように思えますが......weak になるのは mtime が
リクエストタイムから1秒以内ということのようです．


で，フロントの省電力化という課題が浮上ですか．さてさて......
http://polywell.com/us/rackservers/

いやいや

舞い上がって視野狭窄していた自分に鬱ってことだす。

>>940
そういうことすか。

>>939
さっき私も同じWebページ見てましたが、
Pentium Mあたり使ったよさげなBladeは載ってなかったです。
(なので某スレには、たまたまあったNECのやつを例示)

でも、フレキシブルに相談には乗ってくれるんじゃないかなと。< Polywell

>>939上
ほんとだ・・・>>936は撤回します

live22x4のレスポンスヘッダ見て適当に書いただけだなんて恥ずかしくて言えません

banana613 の情報受け取りました。
root 権限あり banana に変身と認識。

ちと今日は体調不安につき、明日あたりから。

【実況】 live22x 鯖 Part10
http://qb5.2ch.net/test/read.cgi/operate/1139729945/815-834

RLimitCPU での暴走リミッターは、mod_cgid (worker MPM) だと効かない模様。

で、bbs.cgi 側でリミッターを入れるというアイディアあり。
http://qb5.2ch.net/test/read.cgi/operate/1139729945/826

/usr/ports/devel/p5-BSD-Resource
この ports をbananaにも入れてもらうように手配しよう、そうしよう。

>>943

2pix.2ch.se つくってくれくれ

>>945
やるやる。

本日中にDNS登録依頼出すところまでいこうかと。

で、そのかわりといってはなんですが、
foxBEsetの株価を取って$GB->{KABU}にセットするところで、
bbs.cgiが暴走することがあるようです。

その前のsplitとかfor文のところがあやしそうなのですが、
見ていただけると助かります。

で、どうも、何十・何百種類と持っている人だと、
変なことになっている、、、っぽいなと。

暴走はこんなかんじか。

(ここから上はアドレスが違うだけ)
#76 0x28143cc1 in S_regmatch ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#77 0x28142b32 in S_regmatch ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#78 0x28146176 in S_regtry ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#79 0x2814a48b in Perl_regexec_flags ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#80 0x280f72ef in Perl_pp_match ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#81 0x280f3ef5 in Perl_runops_standard ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#82 0x280a0f3e in perl_run ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#83 0x0804d34d in onerun ()
#84 0x0804da5e in speedy_perl_run ()
#85 0x0804bd2c in start_child ()
#86 0x0804c17c in main ()

bbs.cgi暴走問題も、ここでやろうかと。

@ex14
%gcore 90994
gcore: read from /proc/90994/mem: Bad address

64bit 環境では、gcoreがちゃんと動かない模様。しくり。

いただいたbanana613ですが、今までのIPアドレスレンジと違うわけですが、
(それ自体はめでたくて、PIEが成長したということだと思います)、
DNSの逆引きの設定がおかしいようです。

banana613から他のホスト等にアクセスすると、DNSを引きにいって
ハングアップ状態になります。

調べてみると、ns1.pacificinternetexchange.net と ns2.pacificinternetexchange.net
の設定がまずい状態のようです。

(ns1.pacificinternetexchange.net: 自分自身を別名として指している)
%dig +norec -t ptr 110.224.29.207.in-addr.arpa. @ns1.pacificinternetexchange.net.

; <<>> DiG 9.3.1 <<>> +norec -t ptr 110.224.29.207.in-addr.arpa. @ns1.pacificinternetexchange.net.
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48850
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;110.224.29.207.in-addr.arpa. IN PTR

;; ANSWER SECTION:
110.224.29.207.in-addr.arpa. 800 IN CNAME 110.224.29.207.in-addr.arpa.

;; Query time: 1 msec
;; SERVER: 206.223.144.254#53(206.223.144.254)
;; WHEN: Sun Feb 19 14:58:24 2006
;; MSG SIZE rcvd: 59

ns2.pacificinternetexchange.net: SERVFAILエラーになる)
%dig +norec -t ptr 110.224.29.207.in-addr.arpa. @ns2.pacificinternetexchange.net.

; <<>> DiG 9.3.1 <<>> +norec -t ptr 110.224.29.207.in-addr.arpa. @ns2.pacificinternetexchange.net.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37878
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;110.224.29.207.in-addr.arpa. IN PTR

;; Query time: 0 msec
;; SERVER: 206.223.146.254#53(206.223.146.254)
;; WHEN: Sun Feb 19 14:59:31 2006
;; MSG SIZE rcvd: 45

このため、banana613から他のサーバに設定ファイルを転送するのとかが、
とても苦しい状況に。

転送方向を変えるとかしてなんとかやりすごして設定作業しようと思いますが、
この状況だと実運用に入ってもいろんな影響が出る予感。

先方(PIE)に文句言って、直す必要ありですね。
正直、初期不良に近いかなと。

で、kill でも死なないのね(前バグありbbs.cgiで起きていたのと同じ)。

ローカルに持っている bbs.cgi @ ex14 に、

# resource limiter
use BSD::Resource;
setrlimit(RLIMIT_CPU, 120, 120);

をしかけて、120CPU秒で暴走が止まることを確認。

ex11, ex14, live22x[123] に、まずこれを入れよう。

>>955
> ex11, ex14, live22x[123] に、まずこれを入れよう。
done.

これでとりあえず、超火急ではなくなったと認識。

もしかすると、IsKoukokuを切ると収まるとか？
確かex14も稼働させているんですよね？

2pix.2ch.se の準備が整いました。
以下の登録をよろしくお願いします。

(新規追加)
+2pix.2ch.se:207.29.224.110

アカウント情報は、これからメールするです。

>>957
うーむ、keiba とか確かに稼動しているですね。
> +Rock54/54M

あとで、やってみるです。

>>957
しかし、朝の修正(http getでエラーチェック入れた)から、
暴走が起こりにくくなったのは事実ですね。

見ていますが、頻度が少なくなったんで(よいことなんですが)、
逆にデバッグがなかなかできにくいかも。

>>958
done.

>>947
管理人にあたらしい API 作ってもらったんで
それに乗り換えるべく準備中。。。
いましばらくお待ちを、

>>962
了解です。

たぶんですが、呼び側から板名を指定できるようになるのかしら。

んだんだ

なるほど。>>964

それなら、その後の微妙な処理をしなくてよさげと。

その予定でーす

で、今回はDNS逆引き設定のお願いをば。

モニタサーバで使用しているIPアドレスのうち一つを、讃岐君の環境専用にします。
ということで、以下のDNS逆引き設定の追加をお願いします。

(新規追加)
^26.0.153.223.206.in-addr.arpa:s2ch.net

>>967
done

>>958
done

鯖をまとめたら速そう。
IBMのメインフレームとか。

コンパイルﾏﾝﾄﾞｸｾになるな。

ヨナがくるまで待つか。

某もうすぐ咲くインターネットはSempronメインみたいです。
ｶﾙﾌｫﾙﾆｱと日本じゃ電気代10倍違うから、ランニングコストにもシビアになるんでしょうねえ。

じゅ、十倍…

>>972
もうすぐ咲くの社長さん、おげんきですかね。

>>973
電力会社的には、日本は5倍ぐらい信頼性高いっていうことのようです。
どっちがいいのかは、、、さて。

ということで、www2 関連のDNS登録変更&追加依頼いきます。
以下の変更をよろしくお願いします。

(現状)
+www2.2ch.net:206.223.151.10:300

(変更後)
+www2.2ch.net:206.223.150.96:300
+www2f1.2ch.net:206.223.150.64
+www2f2.2ch.net:206.223.150.74
+www2f3.2ch.net:206.223.150.84
+www2b.2ch.net:206.223.150.54

>>974
done

2chで『山梨でデータセンター』とかやったら面白い。電気はみんな自家発電。ヒロユキがぶどう作ってます、みたいな。回線はレスポンスがちと速くなるし、冬は雪を溶かすほどマシンが唸りを上げて社会に貢献。
山梨の一大観光名所になると。


山梨最近まで金融において孤島だったけどセブンイレブンにATMやっと入ったし。

目標は第二の理研スペックか。


まぁ夢物語だけどね。

>>975
どもです。観察中。
いまのところ、matd含めて問題ない模様。

>>976
建物の名称はサティアンですか。

>>978

そしてサーバのおもりはし＊ーｋ（りゃ


さあ　そろそろ　次スレの　季節じゃが　どなたか　立ててくださらんかのう？

>>979
今夜あたりに(そのぐらいでじゅうぶんかと)。

カルフォルニアでIDCだと小さい体育館ほどの自家発電装置を入れたりして
それなりにコストかかったりしそうだなぁ。
自動消火施設とか燃料の軽油とか。固定資産税とか。

>>+www2.2ch.net:206.223.150.96:300
DNSでポート指定って出来るんだ…
ちょっといい勉強になった
うちでもやってみるか

>>982
それはポートじゃなくてDNSのTTLじゃね？

あ、
そうみたいですねorz

どくどくさぼてんさん、他PVとられている方へ:

www2.2ch.net の PV ですが、

http://www2f1.2ch.net/_service/
http://www2f2.2ch.net/_service/
http://www2f3.2ch.net/_service/

の数値の合計となります。

http://www2.2ch.net/_service/

ではないので、ご注意くださいです。
(上記は上の3つのどれかが表示されるだけ)

http://www.2ch.net/_service/
http://menu.2ch.net/_service/

は、変わりありませんです。

matd からの「出」、つまり live22xN に行く経路を、
パブリック側とプライベート側のどっちにすべきか。

どっちもちゃんと動いたけど、さて、どっちがいいのかな。
今はパブリック側で設定。

その二種類で何が違うのかってとこかと、

それぞれの負荷(割り込み処理)のコスト計算ですね。
トラフィック的には、たかが知れているので。

live22x[123]のプライベート側は(非圧縮なので)、
あっしゅくしてから送っているパブリック側よりもトラフィックが多いです。
で、とりあえずパブリック側にしていると。

あと受け付け的には、同じI/Fで受けて送るのと、
違うI/Fに振るのとでは、どっちがいいのかなとか。

portsのPerlが、5.8.8になったもより。
どのへんが変わったんだべか。

>>987
パブリック側でよいのでは。
フロントのパブリック側の上りのトラフィックは基本的にはないですよね？
プライベート側の上りトラフィックはdatとかかなりのトラフィック量に
なると思うので。

LAN2個あれば……。

受付嬢にdat背負わせてもなぁ。
datだけ別鯖はないか。

■ テレビ番組欄＠2ch をつくろう 第3話
http://qb5.2ch.net/test/read.cgi/operate/1122520338/468-472

epg の DNS 書き換えは、帰宅後に新スレでやるということで。

>>990
このあたりとか（笑）
http://perldoc.perl.org/perl588delta.html

baila6.jpな鯖も入れ替えよっと♪

matd 稼働開始ですか．とりあえず今のところ異常なしのようで一安心かな．

matd 自体にとっては，パケット取り込みと送出の I/F が同じでも別々でも
差はないと思います（というか，取り込みに libpcap，送出に libdnet と
別々のライブラリを使ってますし）．OS にとってはどうか，ってのは
カーネルの stat 見てみるとか（Solaris でいうところの kstat とかで）．

トラフィックということでいうと，現状のようにキャッシュなしの場合と
mod_cache でキャッシュさせた場合とでは，条件がかなり変わってきますね．

あと，live22 の bbsd のと同じように，http://www2.2ch.net/_service/ で
matd の stat (SIGUSR1 で出てくるやつ) が見られると何か参考になるかも......

>>995
定時的に kill -USR1 あてて、とってみるですか。
帰宅後にごにょごにょしてみます。

kstat に相当するのは、、、。ふむ。

このへんの詰めも、次スレに向けての課題かなと。

で、このスレの >>1 が2005年7月21日ですか。7ヶ月で1スレと。
いろいろなことが進みました。
でも >>18 の問題は、結局スレの最後まで解決をみなかったなぁ。

家庭の保守は愛情つぎ込めw

鯖をローテンさせるのもﾏﾝﾄﾞｸｾ。

下の二つは仕方ない？

死なない程度にシステム移行出来ればいいのに。
私はプログラム書けないしネットの基本もわからんので誰かよろ。

セキュリティは元締めでやると管理は楽だけど効率がいくない。やはり末端に任せるしか無さそうだ。
クッキーかジャバに任せるのも手。

中の人頑張ってくんなまし。

>>985 一部バグっていました。今直しました。

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

新スレ立てました。

matd の本格稼動を祝いつつ、以降は次回の講釈にて。
↓１００１

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。