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

**root▲ ★** · NG

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

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

等を取り扱います。

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

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

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

**root▲ ★** · 2006/03/18(土) 23:37:41

>>553
はやいですね。了解です。

>>556
> c.2chを経由するのではなく各サーバのdatを直接取るということなのかしら?

そうなりますね。

> c.2ch を作った意義はどうなるのだろう、、、

あえて若干のミスリードを承知でいうなら、、、。

高速な通信ができて、クッキーも使えて、
PCのブラウザと同じ感覚でアクセスが可能な高機能な端末が普及してくると、
みんな、徐々にそっちに移行していくことになるんじゃないかなと思っています。

iアプリだとそうはいかないですけど(携帯端末側で通信相手を1箇所しか指定できないので
ゲートウェイ方式にせざるを得ない = 公式p2同様バーボン外す必要あり)、
そうではない(アプリからでも普通にPCみたいに通信できるらしい)三洋のPHSとかでは、
普通のPCで動く専用ブラウザと同じように動く2ch専用ブラウザも、既にあるらしいです。

今回の試みはそれへの一歩というか、中間的な段階というか、
移行段階のひとつになるんじゃないかなぁとか、
少し思っています。

つまり、もしそれが必要であれば、
c.2ch のようなコンセプトを持った別のもの(白山羊でしたっけ)
を、考えないといけない時期に、いよいよもって来てしまったんじゃないかなと。

それでも私はたまにPCからでも使います。c.2ch。
京ぽんつないでアクセスしている時で、
普通のWebブラウザだけでちょろっと様子を見たい時とか。

**root▲ ★** · NG

で、>>476 を適用しても起きたみたい。例の虫踏み。
高負荷とsignal 10でのダウン。

当てていないパッチ >>462-463 があるので、
そのへんを、あとで。

**ピロリ** · NG

はじめから白ヤギ経由にしておいたほうがいいに一票。

**root▲ ★** · NG

>>568
今回のは「2ch専用ブラウザ」ではなくて普通の
「携帯用ゲートウェイ方式フルブラウザ」ですから、
向こう側のサーバからは、read.cgi 経由で読むか、
あるいはc.2ch かp2.2chか、あるいは他の外部メニューを使うか、
ということになるのかなと。

つまり各サーバにはdatちょくどりじゃなくて、read.cgi 経由でのアクセスになるです。
それでもリロードバーボンの解除は必要と。

書き込みバーボンは携帯の固有番号でやるので、これまでと同じ扱いですね。

白ヤギはいまごく一部のサーバのものしかないです。
http://liveb1.2ch.net/ がそれです。
まず２ちゃんねる側でインフラ作りが必要ということですかね。
裏方面とか。

**root▲ ★** · NG

で、まとめると、ピロリさんとしては、

・そんなとこから read.cgi を直に起動させちゃ、いずれ大変なことになる

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

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

業者サンには、自腹でばなな鯖をかりてもらってそこ経由でアレするコトを義務付けるとか

**讃岐フォアンフォアン▲** ◆SANUKI/VII · NG

ibisDXの新バージョンに2chブラウザ機能つければいいんじゃね？

**root▲ ★** · NG

>>572
別アプリとかね。

そろそろ、PC用専用ブラウザとおんなじような
何らかのガイドラインが必要になったりするのかしら。

**ピロリ** · NG

うわっ

read.cgi なんすか、、、

**讃岐フォアンフォアン▲** ◆SANUKI/VII · NG

2chブラウザ向けにliveb1でのbbsメニューってつくらないのかな、

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 00:10:18

ibisBrowserというものを根本的にわかってなかった説

**root▲ ★** · NG

>>574
はい。

つまり、携帯端末から普通のPCみたいにread.cgiを普通に叩くというか、
叩けるようになる時代がやってきてしまったと。

それをふまえて、>>566 の後半を書きました。

**root▲ ★** · NG

>>576
そういう私も、昨日ちょっとだけ(無料版ですが)使ってみただけなんです。
たまたまドコモの携帯があったんで。

動作原理わからないと、いろいろ判断できないです。

**root▲ ★** · NG

で、、、裏の方を向いて言っておくと。

携帯がどんどん進化してくると、
たぶんcやら裏やらではみんな、
満足してくれなくなる時代が必ずやってくると思います。
というか、もう来はじめているのかもしれないです。

なんてか、現在のような隔離政策(とあえて言ってしまおう)には、
限界が見えてしまった(まだほんとの限界は相当先ですが)
のかも、しんないです。

なんてことを、海の上の滑り台の上でだらだらと考えてみる。

**ピロリ** · NG

つまり「うーむ」な状況と、

今の隔離した部分が増えることはあっても減ることはないでしょう。
そして新たな部分が加わると、それも急速に。

ちゃんちゃん

**root▲ ★** · NG

でもそれはそれで、悪いことではないのかな。

・魅力的な裏システム
・白ヤギ本格稼動

とか、とれる手段はまだまだあるかなと。

# ちょっと、ねむけ来た。
# 今日の午後(米国時間)が、つらいんだよなぁ。

**root▲ ★** · NG

>>580
Exactly.

踊りは続く?

◆PyBmQVnXTM · 2006/03/19(日) 00:33:27

たびたび質問をいたします。

User-Agentに下記の情報を送らなかった場合、
　Mozilla/4.0 (compatible; ibisBrowser; ipIPアドレス; ser端末固定番号)

公開PROXYからの投稿は受け付けていません

と出るのが正しい結果でしょうか。

**root▲ ★** · NG

>>583
新しいエラーメッセージ(必要な情報が送られてこない旨)
を、作ろうと思っているです。

(携帯で端末情報が来ないときと同じようなかんじのもの)

**root▲ ★** · NG

というか、まだbbs.cgiをいじっていませんので、>>584 のままかなと。

乗り継ぎ地点で時間とれると思うんで、しばらくおまちをば。
(今、国際線の機上におります)

**root▲ ★** · NG

>>585 のレスアンカーは >>583 の間違いです。

なにぶん趣味100%でいい加減にやっておりますので、
対応のディレイについては、ひらにおゆるしをば。

**ピロリ** · NG

そっちへ移動したほうがサーバ群にとって得々になるようにすれば
どんどん使えーな状況になると、

また考えるかのぅ
まずは散歩でもしてくるか、

今日も天気がいいぞ !

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 01:08:58

またススキノかって言いそうになって気付いた

株価【】 ▲ ◆cZfSunOs.U · 2006/03/19(日) 01:11:50

>>567 まぁ >>476 自体は共有オブジェクトロードエラーの対策ですから......

で，read.cgi のアクセスが増えると...... 前も言ってましたが，
read.cgi 出力も Last-Mod を吐いて mod_cache の対象にするって手もありますね．

**どくどくさぼてん** · 2006/03/19(日) 01:35:10

このスレが前回取得時から100レスも
レス数が増加してるから何事かと思った。
まぁ、、携帯関連の話って感じですかぁ。。

----
read.cgiを直接たたかれるとなるとー。。
携帯とはいえ、PCで表示できるサイトはたいてい
（画面サイズ以外）そのまま表示できるフルブラウザなわけですものね。。。

**root▲ ★** · NG

>>589
ですね。
というか、やらんといかん時期か。

で、個人的にはfork()のパッチがくさいかもなとか、思っていたり。
httpdへのアクセスが増えて、forkが起こるとだめと。

あ、なら、fork()しないようにhttpdを設定するとか有効なのかな。

株価【】 ▲ ◆cZfSunOs.U · 2006/03/19(日) 02:32:34

>>591 >>462 のを見ると，マルチスレッドプロセスの fork() に問題がある，
つまり例えば mod_cgi を使っててマルチスレッドの httpd が fork() を
実行するような場合に問題があるということで，そうでなければ worker MPM でも
マルチスレッドプロセスが fork() を実行することはなさそうにも思いますが......

**ピロリ** · NG

ここはじっくりと、

次世代の read.cgi を作ろう
1) 今実装が急がれるもの
2) 次をにらんだ先進性。

この際また書き直しますでー

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 02:47:37

最近停滞している↓これが動き出すってことですね。

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

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 02:57:59

>>541
でも書きましたがフルブラウザベンダーがrep2使ってくれればアクセス数は減る希ガス。

でも商用はやはり無理か。

ユーザーエージェントと自鯖ローカル認識させログイン出来るのつくればって俺のいうことじゃないな

株価【】 ▲ ◆cZfSunOs.U · 2006/03/19(日) 03:00:52

旧式ブラウザをばっさり切り捨てるという割り切りができるなら，
例えば read.cgi は read.html にしてしまって，dat の指定行だけ
XMLHttpRequest とか使って取ってきて JavaScript で HTML 化させる，
というような方法もありますけどね．

書き込んだ際も，ページ全体をリロードじゃなくて新着分だけ取ってきて追加表示するとか．
イメージ的には http://sunos.saita.ma/leaflet.html のように．

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 03:06:39

かっこええ！！

**root▲ ★** · NG

>>592
httpd が増える時って、forkしないんでしたっけ。

**root▲ ★** · NG

【実況】　live22x　Part13
http://qb5.2ch.net/test/read.cgi/operate/1141564207/878-879

前にちょっと間違った情報を書いた気がします。
live22x[123] は、Apache 2.0.55

**root▲ ★** · NG

…でした。

**root▲ ★** · NG

# live22 special setting
<IfModule mpm_worker_module>
StartServers 96
# Serverlimit 128
Serverlimit 96
# MaxClients 4096
MaxClients 3072
MinSpareThreads 256
MaxSpareThreads 3072
ThreadsPerChild 32
MaxRequestsPerChild 32000000
ThreadLimit 32
MaxMemFree 64000
</IfModule>

2行コメントアウトした。
これで、httpdが増える(fork)はなくなったはず。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 05:00:56

規制とかのシステムでも忙しくなりそう。ホントrootさん頼りになるなぁ。

つ旦~　じっくり逝きましょう

株価【】 ▲ ◆cZfSunOs.U · 2006/03/19(日) 06:21:07

>>598-602 乙です．

>httpd が増える時って、forkしないんでしたっけ。

fork() するのは親プロセスで，マルチスレッド MPM 使用時でも
親プロセスはシングルスレッドなんで...... で，マルチスレッドプロセスは
fork() させない方がよいという考えから mod_cgid というのもあるんで．

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 09:27:06

ibisユーザーって、とことん自己中心的って言うか、
自分が使ってるアプリのことしか考えてないな
ibisスレも見てきたが、厨房意見が多すぎ

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 09:41:56

>>604
それで？

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 09:52:33

結局、契約者数約800人の低価格、スポンサーつかないお子さまアプリってこと

まで書かないとわからないのか…
やっぱり厨房ユーザーの集まりだ

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 09:55:46

>>604-606
スレ違い。
VIPでやってください。

◆2ZQBOv2.jQ · NG

>>606
スポンサーは、Exciteがついた。
流石に800人よりは、増えている。

久しぶりにきたibisのGoodニュースなんだ見逃して
やってくれ。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 10:59:06

嘘を流すような池沼にかまっちゃいけませんよ＞＜

◆2ZQBOv2.jQ · NG

>>609
http://keitai.excite.co.jp/ibisdx/

**ひろゆき＠どうやら管理人 ★** · NG

・各ベンダーがキャッシュサーバを用意する
2chの元サーバには多大な負荷がかからない。
2ch側はなんの作業もする必要がない

・各ベンダーのためにキャッシュサーバを2ch側で用意する。
2ch側でキャッシュサーバをベンダーのために作って運用しなきゃいけない
各ベンダーに取得の仕方を周知しなきゃいけない。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 11:16:08

>>610
アンカーつけなかったから誤解させてスマソ。
12月で894人？だっけ。サバを読みすぎだと言いたかった。
まあ、妬んでいるだけだろうけどね。

◆2ZQBOv2.jQ · NG

>>612
こっちこそスマソ。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 11:22:43

ひろゆき発見
記念パピコ

**root▲ ★** · 2006/03/19(日) 11:26:59

>>611
各ベンダーに白山羊を勝手に作らせればいいんじゃないのかい?

ってことですか。
で、ベンダーというのは、例えば携帯アプリを作っているベンダーってことですかね。

ただ、カネにならないようなことをベンダーさんが
自分のコスト(身銭)切ってやりますかね。

**root▲ ★** · NG

んで、なんか、

ベンダー = がっくしメニュー

とかいう展開がいいなとか、ちょっとおもた。

というか前から、脳内にはあったわけだけど。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 11:28:49

http://c-others.2ch.net/test/-/chakumelo/1134628198/1-
フルブラウザといえばやっぱりパスワード漏洩＆アク禁＆カウンタ工作事件でしょうｗ

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 11:33:36

そうかガックシがあったね。

だったらガックシのプログラム(CGI)をベンダーにいれ運用するのを条件にやるのもありかも。

出来ればカキコはアプリから抜けて携帯直でいければいいんだけど俺auだし、IMONAとopera mini(mini.opera.com)ですむユーザーだからワカンネ。

**root▲ ★** · NG

勝手に、は、ちょっといまいちだな。

「作らせるように仕向ける」というか
一歩進んで「自ら進んで作っていただける」ようにするということか。

大リーグボール1号(古いな)みたいな。

◆2ZQBOv2.jQ · NG

>>619
ibisの場合は、それで2ちゃんねらを大量確保出来る可能性があり
現状でユーザー数がまだまだ少ないから設備投資額もかなり安く
すむ(ユーザーが増えるたびに増設すればいいだけで一気にやる
必要がない)のでやるかも。

だけどjigの場合は、3万人のユーザーがいるらしいからやらないだ
ろうとオモタ

**ひろゆき＠どうやら管理人 ★** · NG

「同一IPから大量にアクセスがきたらBANしますよ」
「それが嫌なら、がっくしメニューを導入してください。」
で話が済むなら、楽でいいなぁ。

**root▲ ★** · NG

>>620
今のcでいうBlackGoatみたいなものなら、
既存のありもので比較的容易に作れます。

で、２ちゃんねるの携帯ユーザの大半を受け付けても、
Xeon dual/2G mem/SCSI HDDなサーバ2台で、全部さばけています。

BlackGoatはパフォーマンスを出すためにいろんなチューニングしまくりですが、
これらはすべて公開の場でやっているし、
もし必要なら、別途改めて設定を公開してもよいです。

だって、dat取得の負荷が下がるんだから、
こちらとしてはばんばんざいで。

**root▲ ★** · NG

>>621
そうすね。

>>622 あたりは、次善の策なのかな。
datキャッシュサーバをベンダーさんに準備してもらって、
そこからのアクセスだけ、リロードバーボンをスルーにすると。

◆2ZQBOv2.jQ · NG

>>622
c.2chと携帯PCブラウザ(おそらく公開p2or自鯖p2経由)
は、等価のシステムですむのですか？

**root▲ ★** · NG

>>624
ん、何と何がどう「等価」なのかしら。
(すみません、質問の意図がよくわからんです)

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 12:06:20

流れを切って悪いですが、apache workerのバグを1つ見つけたのでパッチをUPします。

--- server/mpm/worker/fdqueue.c.origFri Nov 11 00:20:05 2005
+++ server/mpm/worker/fdqueue.cSun Mar 19 10:49:17 2006
@@ -163,7 +163,7 @@
* now nonzero, it's safe for this function to
* return immediately.
*/
- if (queue_info->idlers == 0) {
+ while (queue_info->idlers == 0) {
rv = apr_thread_cond_wait(queue_info->wait_for_idler,
queue_info->idlers_mutex);
if (rv != APR_SUCCESS) {

このパッチは、配列の要素数を越えてアクセスし、メモリ内容を破壊してしまう
問題を修正します。
問題が発生すると、Segmentation Faultや、httpdがどんどん増えてしまう現象が
発生します。

良かったら、試してみてください。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 12:08:41

.　　　　　　　∧＿∧　／￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　（；´Д｀）＜　スンマセン、直ぐに片付けます
　　-=≡ 　/　　　ヽ　＼　　　　　この池沼は無視してください
.　　　　　 /|　|　　 |. |　　＼＿＿＿＿＿＿＿＿＿＿＿
　-=≡　/.　＼ヽ／＼＼_
　　　　/　　　ヽ⌒)==ヽ_）=　∧＿∧
-= 　 /　/⌒＼.＼　||　　|| 　(´･ω･`) ←◆2ZQBOv2.jQ
　　／／　　　 >　） || 　 ||　( つ旦O
　/　/ 　　　　/ ／＿||＿ ||　と＿)＿) ＿.
　し'　　　　　（＿つ￣(_））￣ (.)）￣ (_））￣(.)）

**root▲ ★** · NG

>>626
いきます。

◆2ZQBOv2.jQ · NG

>>625
つまりroot氏が例に出されたXeon dual/2G mem/SCSI HDD
なサーバ2台で携帯ユーザーが全員(ありえないが)ibisに乗
り換えたとしてもやっていけるのかということです(それをibis
では、なく2ch側が準備すると仮定した場合です)。

jigやibisが顧客を2ちゃんねらーかどうかの判断は、出来ない
から結局全員分の対応をしなくては、いけないから2chの携帯
ユーザーよりは、当然増えるわけだし。

あとなぜ公式p2や自鯖p2経由だろかと思ったかというと現状で
p2が携帯PCブラウザ経由の書き込みの際に最も便利な手段
だから(逆にいうと他の方法が使いづらい)

**root▲ ★** · NG

>>626 を適用した httpd をコンパイル中。

**root▲ ★** · NG

httpd を再スタート。

**root▲ ★** · NG

>>626 を適用した。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 12:30:40

すまんが、携帯PCブラウザってフルブラウザのことだよな。

アイビズがなにしたいのかしらんがまぁドコモにもIMONAは有るわけで、

アイビズは何がしたいんだ？

アイビズユーザーが知らないだけ？それともアイビズからカキコ&リードする利点はリンク先のサイトを見たいのが一番だろう(妄想)。

ならばこれができるのはorzとrep2な訳だ(おれはこれしか知らない)。

rep2はアイビズが鯖用意してログインとお気に等のユーザー情報を変える等の負担が掛かるし内輪な感じ。

orzはオープンだし改変の必要はあんまり必要ないがするとしたらすべてアイビズの中で完結させるようにする。

俺はどっちでも良い希ガス(あえていうならorzでそのまま放置みんなに解放)

**root▲ ★** · NG

>>626
ftp://ftp.peko.2ch.net/pub/patch/apache22/apache-2.2.0-fdqueue.c.patch
ftp://ftp.peko.2ch.net/pub/patch/apache22/Makefile.local

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 12:44:17

すばやい適用どうもです。
まだ問題あると思いますが、少しはましになると良いと思います。。。

**root▲ ★** · NG

また踏みましたね。

**root▲ ★** · NG

虫を踏んだ瞬間を観察した。

ucond も見たけど、
fileli って、top 的にどういう状態なのかしら。
ufs というのもあったし。

**root▲ ★** · NG

前にも書いたけど、

何かのタイミングでCPUのアイドルタイムが0になり、LAが急上昇をはじめるんですよね。

で、いったんこうなると、httpd をリスタートしないと直らないと。
で、kill でもそう簡単には死んでくれないし、最後にはhttpdがsignal 10で落ちる。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 12:53:00

filiはfilelistロックです。
システム全体のファイルディスクリプタリストをロックしています。

ufsが出るということは、おそらくPREEMPTIONつきカーネルですね。
6.0からデフォルトですが、ネットワークIOが多いシステムだと、PREEMPTIONなし
の方が速かったりします。

**root▲ ★** · NG

>>639
さっきLA急上昇中に、fileli が大量発生していました。
ufs なのもたくさんいました。

options PREEMPTION # Enable kernel thread preemption

になっています(デフォルトから変えていない)。< live22

ファイルシステムまわりは前にも少し疑ったことがありますが、
どうなんだろう。

**root▲ ★** · NG

httpd は通常時はkserel(libpthread)かaccept(libthrとかprefork)ですね。
で、やばくなった時は大量に ucond とかの状態になったり、
大量に ufs (これは結構あった)とか fileli (これはさっきはじめてみた)
の状態になるです。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 13:02:18

ufsは、vnodeロックです。
6.0からVFSがGiant Freeになったのは御存じだと思いますが、

1)スレッドAがvnodeロックを取得
2)ネットワークIOにより割り込みが発生し、スレッドAの処理を横取り(PREEMPTION)
3)割り込み処理実行中
4)スレッドAが再スケージュリングされてvnodeロックを解放

ということが起こるので、結果的にvnodeが長時間ロックされる可能性があります。
よって、同じファイルに大量にアクセスが集中すると、処理の遅延が発生します。

**root▲ ★** · NG

虫を踏んだ瞬間のtopをとれた。2つ。
必ず最初に fileli が大量発生するっぽい。

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
53194 root 1 97 0 8680K 2840K fileli 3 0:00 11.56% bzip2
50106 root 1 -8 0 2148K 1124K piperd 0 0:46 4.83% logbuffer
50625 ch2live22 2 -4 0 2512K 1248K ufs 1 0:27 0.93% bbsd
52490 root 1 96 0 7900K 6976K CPU2 3 0:02 0.54% top
50198 ch2live22 34 97 0 15144K 8592K fileli 2 0:10 0.29% httpd
53193 ch2live22 1 96 0 3044K 2344K CPU3 3 0:00 0.27% perl5.8.7
50172 ch2live22 34 97 0 14240K 8116K fileli 1 0:10 0.24% httpd
50192 ch2live22 34 97 0 15756K 9104K fileli 1 0:10 0.20% httpd
50134 ch2live22 34 97 0 14592K 8372K fileli 3 0:10 0.20% httpd
50118 ch2live22 34 97 0 14980K 8816K fileli 2 0:11 0.15% httpd
50178 ch2live22 34 97 0 15088K 8828K fileli 2 0:11 0.15% httpd
50179 ch2live22 34 97 0 15124K 8652K fileli 1 0:10 0.15% httpd
50157 ch2live22 34 97 0 14360K 8288K fileli 0 0:10 0.15% httpd
50163 ch2live22 34 97 0 14472K 7936K fileli 1 0:10 0.15% httpd
50144 ch2live22 34 97 0 14724K 8576K fileli 3 0:10 0.15% httpd
50181 ch2live22 34 97 0 14404K 8264K fileli 3 0:10 0.15% httpd
50195 ch2live22 34 97 0 14644K 8004K fileli 2 0:10 0.15% httpd
50188 ch2live22 34 97 0 14116K 8008K fileli 2 0:10 0.15% httpd
50131 ch2live22 34 97 0 15980K 9604K fileli 0 0:10 0.15% httpd
50173 ch2live22 34 97 0 14228K 8124K fileli 3 0:10 0.15% httpd
50124 ch2live22 34 97 0 16148K 9060K fileli 3 0:11 0.10% httpd
50111 ch2live22 34 97 0 15576K 9156K fileli 2 0:11 0.10% httpd
50126 ch2live22 34 97 0 14856K 8804K RUN 3 0:11 0.10% httpd
50177 ch2live22 34 97 0 14956K 8948K fileli 3 0:11 0.10% httpd
50122 ch2live22 34 97 0 15020K 8800K fileli 2 0:11 0.10% httpd
50200 ch2live22 34 97 0 15768K 9228K fileli 3 0:11 0.10% httpd

**root▲ ★** · NG

>>642
つまり PREEMPTION なしのほうが、よいということですか。

**root▲ ★** · NG

2つ目のサンプル。

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
53593 ch2live22 1 131 0 2744K 2060K fileli 1 0:02 14.49% perl5.8.7
53689 ch2live22 2 105 0 1800K 1044K ucond 0 0:01 10.76% bbsd
53432 root 1 130 0 7048K 4792K select 0 0:01 5.05% httpd
53447 root 1 130 0 7048K 4792K select 0 0:01 2.96% httpd
53449 root 1 -8 0 2144K 1120K piperd 1 0:00 1.66% logbuffer
53608 root 1 131 0 16428K 15520K CPU2 0 0:00 1.24% top
53679 ch2live22 34 132 0 14528K 7736K fileli 1 0:00 0.83% httpd
53688 ch2live22 34 132 0 13780K 7248K fileli 1 0:00 0.83% httpd
53680 ch2live22 34 132 0 13648K 7088K fileli 0 0:00 0.83% httpd
53684 ch2live22 34 132 0 13284K 6720K ucond 1 0:00 0.50% httpd
53635 ch2live22 34 132 0 16392K 8980K fileli 1 0:00 0.44% httpd
53628 ch2live22 34 132 0 14532K 8020K fileli 0 0:00 0.44% httpd
53633 ch2live22 34 132 0 13344K 6748K ucond 3 0:00 0.44% httpd
53657 ch2live22 34 132 0 13588K 6828K fileli 1 0:00 0.44% httpd
53558 ch2live22 34 132 0 15268K 8996K fileli 1 0:01 0.39% httpd
53614 ch2live22 34 132 0 15036K 8512K fileli 3 0:00 0.37% httpd
53625 ch2live22 34 132 0 14060K 7724K fileli 3 0:00 0.30% httpd
53638 ch2live22 34 132 0 13680K 7100K ucond 0 0:00 0.30% httpd
53637 ch2live22 34 132 0 13316K 6716K ucond 0 0:00 0.30% httpd
53669 ch2live22 34 132 0 13656K 7128K fileli 1 0:00 0.30% httpd
53538 ch2live22 34 132 0 15120K 8856K fileli 1 0:01 0.29% httpd
53553 ch2live22 34 132 0 15836K 9364K fileli 1 0:01 0.29% httpd
53567 ch2live22 34 132 0 14752K 8192K RUN 3 0:00 0.20% httpd
53604 root 1 4 0 6128K 2496K sbwait 1 0:00 0.20% sshd
53542 ch2live22 34 132 0 15380K 9036K fileli 3 0:01 0.19% httpd
53555 ch2live22 34 132 0 13968K 7408K ucond 3 0:00 0.19% httpd

**root▲ ★** · NG

httpd 止めました。

PREEMPTION なしのカーネルに入れ替えます。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 13:06:31

絶対とは言いませんが。。。
vmstatで見たとき、最初の r b w の b の部分がめちゃくちゃな数字になっているなら、
おそらく、かなりvnodeのロック競合が起きてると思われます。。。

**root▲ ★** · NG

>>647
あたりな予感。

**root▲ ★** · NG

で、>>647 の緩和策としては、options PREEMPTION をやめる以外に、
どのあたりが考えられるでしょうか。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 13:11:52

とりあえず、それで試してみて違いをみるのが良いかと。。
前のカーネルも保存されてますから、駄目ならすぐ戻せますし。

**root▲ ★** · NG

長年の勘から、今度の(vnode lock競合)は、とってもとっても、あたりっぽい気がします。
あらゆることが符合している。プロセス側でCPU時間を食わないというのも。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 13:22:31

んー、でもhttpdがシグナル10で落ちるとかは、ロックとは関係ないと思います。
競合が起こって処理が重くなっても、シグナル10にはならないかと。

**root▲ ★** · NG

%sysctl kern.sched.preemption=0
sysctl: oid 'kern.sched.preemption' is read only

/boot/loader.conf に書けばいけるのかな。

…いや、ここは安全策でカーネルを作り直そう。

**root▲ ★** · NG

>>652
それは、重くなってkillでも死ななくなった後に起こるですね。< signal 10

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 13:27:08

killで死なない(kill -9じゃないと駄目)というのは、正常時もそうじゃないですか?
少なくとも、うちではそうです。
SIGTERMは無視されます。

**root▲ ★** · NG

リブート中。< live22

**root▲ ★** · NG

>>655
例の(conftest)問題ですか。

**root▲ ★** · NG

httpd / bbsd 上げた。< live22

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 13:32:20

killの問題はApacheのソース等をもう少し見ないと何ともです。。。
プロセス宛のシグナルをどのスレッドが受け取るか
受け取ったスレッドはシグナルをマスクしてないか
そのあたりですね。。

株価【】 ▲ ◆cZfSunOs.U · 2006/03/19(日) 13:33:15

>>626 確かに，spurious wakeup もある pthread_cond_wait() の使い方としては
元のは筋が悪いですね．ap_queue_pop() 内での使い方もちょっとダウトな感じですが......

それはそうと，PREEMPTION というのによって，アクセス殺到時にファイル I/O と
ネットワーク I/O の race condition が顕在化してたってところなんですかね．

**root▲ ★** · NG

PREEMPTION なしのカーネルに入れ替えました。
気のせいか、足元が軽くなったような気がします。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 13:35:10

>>660
>ap_queue_pop() 内での使い方もちょっとダウトな感じですが......
それは自分も感じたんですが、テストした限りだと1行の変更だけで問題なさそうでした。

**root▲ ★** · NG

現在のvmstat

%vmstat 1
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr da0 da1 in sy cs us sy id
0 104 0 878836 2932948 3883 2 1 0 3641 0 0 0 7382 30923 17308 13 12 75
3 104 0 878852 2932796 3396 0 0 0 3456 0 1 3 11891 28176 25397 17 13 69
3 104 0 878852 2932720 3335 0 0 0 3406 0 0 0 12497 28749 26367 15 20 66
5 104 0 878892 2932544 3306 0 0 0 3343 0 1 0 11849 26574 25956 16 16 69
4 104 0 878900 2932408 2818 0 0 0 2887 0 1 0 12440 28562 26705 14 16 69
4 104 0 878916 2932264 2458 0 0 0 2488 0 0 0 12287 28141 25719 18 17 65

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 13:41:34

>>663
前と比べてどうですか?

**root▲ ★** · NG

今はまだ、なんとも。

突然、b がガーンと来て（りゃってかんじだったです。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/19(日) 13:46:51

vnodeロック競合が多発していると、b の部分が激しくぶれる(数字が極端にかわる)です。
あと、cs(コンテキストスイッチ)の回数が減ってるかなぁと。