X



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

■ このスレッドは過去ログ倉庫に格納されています
1root▲ ★
垢版 |
NGNG
2ch特化型サーバ・ロケーション構築作戦のスレッドです。

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

等を取り扱います。

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

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

前スレ:
2ch特化型サーバ・ロケーション構築作戦 Part19
http://qb5.2ch.net/test/read.cgi/operate/1121886018/
NGNG
>>609
http://keitai.excite.co.jp/ibisdx/
611ひろゆき@どうやら管理人 ★
垢版 |
NGNG
・各ベンダーがキャッシュサーバを用意する
2chの元サーバには多大な負荷がかからない。
2ch側はなんの作業もする必要がない

・各ベンダーのためにキャッシュサーバを2ch側で用意する。
2ch側でキャッシュサーバをベンダーのために作って運用しなきゃいけない
各ベンダーに取得の仕方を周知しなきゃいけない。
2006/03/19(日) 11:16:08ID:9MeC7Is8P
>>610
アンカーつけなかったから誤解させてスマソ。
12月で894人?だっけ。サバを読みすぎだと言いたかった。
まあ、妬んでいるだけだろうけどね。
NGNG
>>612
こっちこそスマソ。
614動け動けウゴウゴ2ちゃんねる
垢版 |
2006/03/19(日) 11:22:43ID:sv9NTwPeO
ひろゆき発見
記念パピコ
615root▲ ★
垢版 |
2006/03/19(日) 11:26:59ID:???0
>>611
各ベンダーに白山羊を勝手に作らせればいいんじゃないのかい?

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

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

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

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

というか前から、脳内にはあったわけだけど。
2006/03/19(日) 11:28:49ID:s3I680azO
http://c-others.2ch.net/test/-/chakumelo/1134628198/1-
フルブラウザといえばやっぱりパスワード漏洩&アク禁&カウンタ工作事件でしょうw
2006/03/19(日) 11:33:36ID:XITF70sxO
そうかガックシがあったね。

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

出来ればカキコはアプリから抜けて携帯直でいければいいんだけど俺auだし、IMONAとopera mini(mini.opera.com)ですむユーザーだからワカンネ。
619root▲ ★
垢版 |
NGNG
勝手に、は、ちょっといまいちだな。

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

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

だけどjigの場合は、3万人のユーザーがいるらしいからやらないだ
ろうとオモタ
621ひろゆき@どうやら管理人 ★
垢版 |
NGNG
「同一IPから大量にアクセスがきたらBANしますよ」
「それが嫌なら、がっくしメニューを導入してください。」
で話が済むなら、楽でいいなぁ。

622root▲ ★
垢版 |
NGNG
>>620
今のcでいうBlackGoatみたいなものなら、
既存のありもので比較的容易に作れます。

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

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

だって、dat取得の負荷が下がるんだから、
こちらとしてはばんばんざいで。
623root▲ ★
垢版 |
NGNG
>>621
そうすね。

>>622 あたりは、次善の策なのかな。
datキャッシュサーバをベンダーさんに準備してもらって、
そこからのアクセスだけ、リロードバーボンをスルーにすると。
NGNG
>>622
c.2chと携帯PCブラウザ(おそらく公開p2or自鯖p2経由)
は、等価のシステムですむのですか?
625root▲ ★
垢版 |
NGNG
>>624
ん、何と何がどう「等価」なのかしら。
(すみません、質問の意図がよくわからんです)
2006/03/19(日) 12:06:20ID:FpAWTOrI0
流れを切って悪いですが、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:41ID:fmo3Z2XB0

.       ∧_∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
       (;´Д`)< スンマセン、直ぐに片付けます
  -=≡  /    ヽ  \     この池沼は無視してください
.      /| |   |. |   \___________
 -=≡ /. \ヽ/\\_
    /    ヽ⌒)==ヽ_)= ∧_∧
-=   / /⌒\.\ ||  ||  (´・ω・`) ←◆2ZQBOv2.jQ
  / /    > ) ||   || ( つ旦O
 / /     / /_||_ || と_)_) _.
 し'     (_つ ̄(_)) ̄ (.)) ̄ (_)) ̄(.))
628root▲ ★
垢版 |
NGNG
>>626
いきます。
NGNG
>>625
つまりroot氏が例に出されたXeon dual/2G mem/SCSI HDD
なサーバ2台で携帯ユーザーが全員(ありえないが)ibisに乗
り換えたとしてもやっていけるのかということです(それをibis
では、なく2ch側が準備すると仮定した場合です)。

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

あとなぜ公式p2や自鯖p2経由だろかと思ったかというと現状で
p2が携帯PCブラウザ経由の書き込みの際に最も便利な手段
だから(逆にいうと他の方法が使いづらい)
630root▲ ★
垢版 |
NGNG
>>626 を適用した httpd をコンパイル中。
631root▲ ★
垢版 |
NGNG
httpd を再スタート。
632root▲ ★
垢版 |
NGNG
>>626 を適用した。
2006/03/19(日) 12:30:40ID:XITF70sxO
すまんが、携帯PCブラウザってフルブラウザのことだよな。

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

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

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

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

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

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

俺はどっちでも良い希ガス(あえていうならorzでそのまま放置みんなに解放)
634root▲ ★
垢版 |
NGNG
>>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:17ID:FpAWTOrI0
すばやい適用どうもです。
まだ問題あると思いますが、少しはましになると良いと思います。。。
636root▲ ★
垢版 |
NGNG
また踏みましたね。
637root▲ ★
垢版 |
NGNG
虫を踏んだ瞬間を観察した。

ucond も見たけど、
fileli って、top 的にどういう状態なのかしら。
ufs というのもあったし。
638root▲ ★
垢版 |
NGNG
前にも書いたけど、

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

で、いったんこうなると、httpd をリスタートしないと直らないと。
で、kill でもそう簡単には死んでくれないし、最後にはhttpdがsignal 10で落ちる。
2006/03/19(日) 12:53:00ID:FpAWTOrI0
filiはfilelistロックです。
システム全体のファイルディスクリプタリストをロックしています。

ufsが出るということは、おそらくPREEMPTIONつきカーネルですね。
6.0からデフォルトですが、ネットワークIOが多いシステムだと、PREEMPTIONなし
の方が速かったりします。
640root▲ ★
垢版 |
NGNG
>>639
さっきLA急上昇中に、fileli が大量発生していました。
ufs なのもたくさんいました。

options PREEMPTION # Enable kernel thread preemption

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

ファイルシステムまわりは前にも少し疑ったことがありますが、
どうなんだろう。
641root▲ ★
垢版 |
NGNG
httpd は通常時はkserel(libpthread)かaccept(libthrとかprefork)ですね。
で、やばくなった時は大量に ucond とかの状態になったり、
大量に ufs (これは結構あった)とか fileli (これはさっきはじめてみた)
の状態になるです。
2006/03/19(日) 13:02:18ID:FpAWTOrI0
ufsは、vnodeロックです。
6.0からVFSがGiant Freeになったのは御存じだと思いますが、

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

ということが起こるので、結果的にvnodeが長時間ロックされる可能性があります。
よって、同じファイルに大量にアクセスが集中すると、処理の遅延が発生します。
643root▲ ★
垢版 |
NGNG
虫を踏んだ瞬間の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
644root▲ ★
垢版 |
NGNG
>>642
つまり PREEMPTION なしのほうが、よいということですか。
645root▲ ★
垢版 |
NGNG
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
646root▲ ★
垢版 |
NGNG
httpd 止めました。

PREEMPTION なしのカーネルに入れ替えます。
2006/03/19(日) 13:06:31ID:FpAWTOrI0
絶対とは言いませんが。。。
vmstatで見たとき、最初の r b w の b の部分がめちゃくちゃな数字になっているなら、
おそらく、かなりvnodeのロック競合が起きてると思われます。。。
648root▲ ★
垢版 |
NGNG
>>647
あたりな予感。
649root▲ ★
垢版 |
NGNG
で、>>647 の緩和策としては、options PREEMPTION をやめる以外に、
どのあたりが考えられるでしょうか。
2006/03/19(日) 13:11:52ID:FpAWTOrI0
とりあえず、それで試してみて違いをみるのが良いかと。。
前のカーネルも保存されてますから、駄目ならすぐ戻せますし。
651root▲ ★
垢版 |
NGNG
長年の勘から、今度の(vnode lock競合)は、とってもとっても、あたりっぽい気がします。
あらゆることが符合している。プロセス側でCPU時間を食わないというのも。
2006/03/19(日) 13:22:31ID:FpAWTOrI0
んー、でもhttpdがシグナル10で落ちるとかは、ロックとは関係ないと思います。
競合が起こって処理が重くなっても、シグナル10にはならないかと。
653root▲ ★
垢版 |
NGNG
%sysctl kern.sched.preemption=0
sysctl: oid 'kern.sched.preemption' is read only

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

…いや、ここは安全策でカーネルを作り直そう。
654root▲ ★
垢版 |
NGNG
>>652
それは、重くなってkillでも死ななくなった後に起こるですね。< signal 10
2006/03/19(日) 13:27:08ID:FpAWTOrI0
killで死なない(kill -9じゃないと駄目)というのは、正常時もそうじゃないですか?
少なくとも、うちではそうです。
SIGTERMは無視されます。
656root▲ ★
垢版 |
NGNG
リブート中。< live22
657root▲ ★
垢版 |
NGNG
>>655
例の(conftest)問題ですか。
658root▲ ★
垢版 |
NGNG
httpd / bbsd 上げた。< live22
2006/03/19(日) 13:32:20ID:FpAWTOrI0
killの問題はApacheのソース等をもう少し見ないと何ともです。。。
プロセス宛のシグナルをどのスレッドが受け取るか
受け取ったスレッドはシグナルをマスクしてないか
そのあたりですね。。
2006/03/19(日) 13:33:15ID:TOXEGCMQ0
>>626 確かに,spurious wakeup もある pthread_cond_wait() の使い方としては
元のは筋が悪いですね.ap_queue_pop() 内での使い方もちょっとダウトな感じですが......


それはそうと,PREEMPTION というのによって,アクセス殺到時にファイル I/O と
ネットワーク I/O の race condition が顕在化してたってところなんですかね.
661root▲ ★
垢版 |
NGNG
PREEMPTION なしのカーネルに入れ替えました。
気のせいか、足元が軽くなったような気がします。
2006/03/19(日) 13:35:10ID:FpAWTOrI0
>>660
>ap_queue_pop() 内での使い方もちょっとダウトな感じですが......
それは自分も感じたんですが、テストした限りだと1行の変更だけで問題なさそうでした。
663root▲ ★
垢版 |
NGNG
現在の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:34ID:FpAWTOrI0
>>663
前と比べてどうですか?
665root▲ ★
垢版 |
NGNG
今はまだ、なんとも。

突然、b がガーンと来て(りゃ ってかんじだったです。
2006/03/19(日) 13:46:51ID:FpAWTOrI0
vnodeロック競合が多発していると、b の部分が激しくぶれる(数字が極端にかわる)です。
あと、cs(コンテキストスイッチ)の回数が減ってるかなぁと。
667root▲ ★
垢版 |
NGNG
>>666
破綻が起きるまでは、そんなに変わってなかった気がします。< bの数字

# 前のをとっておけばよかったですね。
# vmstat は基本中の基本だし。
2006/03/19(日) 13:54:29ID:TOXEGCMQ0
SIGTERM が効かないってのはこんなのもありますが......

shutdown and linux poll()
http://www.mail-archive.com/dev@httpd.apache.org/msg30808.html
Apache 2.2 -X commanlinde option broken?
http://www.mail-archive.com/dev@httpd.apache.org/msg30977.html
669root▲ ★
垢版 |
NGNG
>>653
kern.sched.preemption は read only っぽいですね。
やはり、オプションでやるのかと。
670root▲ ★
垢版 |
NGNG
健康的にLAが上昇しました。
ちゃんと7とか8になった。
正しくCPU idle timeもキープ。

今のところ、いいかんじです。
671root▲ ★
垢版 |
NGNG
%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
85 3023 0 1131292 2532700 5032 1 0 0 4850 0 0 0 12187 41916 24118 20 19 61
8 3081 0 1126956 2534188 7303 0 0 0 7750 0 1 5 21404 36884 25371 62 38 0
205 2855 0 1129324 2532880 7596 0 0 0 7392 0 1 0 22261 45461 28639 59 41 0
46 2988 0 1129680 2532144 8139 0 0 0 8093 0 1 0 22777 38962 24436 61 39 0
233 2730 0 1130376 2531200 8625 0 0 0 8420 0 12 0 22656 48120 29367 59 41 0
220 2668 0 1131024 2530280 9143 0 0 0 9032 0 2 0 24220 48893 33151 54 46 0

ううむ。
672root▲ ★
垢版 |
NGNG
またですね。

でも、原因はほぼ特定できた感じ。

%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
85 3023 0 1131292 2532700 5032 1 0 0 4850 0 0 0 12187 41916 24118 20 19 61
8 3081 0 1126956 2534188 7303 0 0 0 7750 0 1 5 21404 36884 25371 62 38 0
205 2855 0 1129324 2532880 7596 0 0 0 7392 0 1 0 22261 45461 28639 59 41 0
46 2988 0 1129680 2532144 8139 0 0 0 8093 0 1 0 22777 38962 24436 61 39 0
233 2730 0 1130376 2531200 8625 0 0 0 8420 0 12 0 22656 48120 29367 59 41 0
220 2668 0 1131024 2530280 9143 0 0 0 9032 0 2 0 24220 48893 33151 54 46 0
673root▲ ★
垢版 |
NGNG
さて、どうしたものかな。

%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
112 2667 0 1106144 2559064 5300 1 0 0 5134 0 0 0 12528 42228 24038 22 20 58
295 2456 0 1097740 2560648 10136 0 0 0 10654 0 47 0 23360 60869 28125 58 42 0
265 2505 0 1099660 2560952 13812 0 0 0 13943 0 1 0 27769 55191 28873 60 40 0
184 2606 0 1100868 2559300 11510 0 0 0 11099 0 13 0 24122 64490 22761 57 43 0
63 2767 0 1104988 2555948 12390 2 0 0 11739 0 1 0 22741 58083 22351 59 41 0
246 2609 0 1106496 2556744 10841 0 0 0 10997 0 1 2 22095 65358 24619 56 44 0
674root▲ ★
垢版 |
NGNG
PREEMPTION なしにしたら、さっきみたいに操作不能になるほどへろへろにはならなくなったけど、
やっぱり起こることは同じみたいですね。

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
7998 ch2live22 1 132 0 4004K 3560K RUN 1 0:19 37.27% perl5.8.7
7733 root 1 132 0 2148K 1508K RUN 2 0:04 3.85% logbuffer
8155 root 1 4 0 6128K 3120K sbwait 1 0:00 1.61% sshd
7852 root 1 126 0 7872K 7120K CPU0 0 0:01 0.94% top
7759 ch2live22 34 131 0 15576K 9924K ucond 2 0:03 0.44% httpd
7843 ch2live22 34 131 0 15420K 9832K ucond 2 0:03 0.40% httpd
7797 ch2live22 34 132 0 16216K 10396K RUN 0 0:04 0.35% httpd
7809 ch2live22 34 132 0 16428K 10504K ucond 3 0:03 0.35% httpd
7785 ch2live22 34 129 0 15156K 9584K ucond 3 0:02 0.30% httpd
7817 ch2live22 34 131 0 15180K 9560K ucond 0 0:03 0.20% httpd
7813 ch2live22 34 130 0 15456K 9780K ucond 3 0:02 0.20% httpd
7792 ch2live22 34 128 0 16004K 10304K ucond 2 0:02 0.20% httpd
7768 ch2live22 34 131 0 15296K 9724K ucond 3 0:03 0.15% httpd
7815 ch2live22 34 131 0 15172K 9540K ucond 1 0:03 0.15% httpd
7842 ch2live22 34 131 0 15340K 9740K ucond 1 0:03 0.15% httpd
7806 ch2live22 34 131 0 15268K 9612K ucond 3 0:03 0.15% httpd
7796 ch2live22 34 130 0 15816K 10172K ucond 1 0:03 0.15% httpd
675root▲ ★
垢版 |
NGNG
httpd / bbsd の再起動装置を止めました。

「破綻」は、しなくなりましたね。
一歩前進。

さて、根本的な対策は、、、。
2006/03/19(日) 14:03:34ID:FpAWTOrI0
何かすごい数字ですね。。。>vmstat

ところで、
sysctl net.isr.direct
は設定してます?
677root▲ ★
垢版 |
NGNG
してないです。

%sysctl net.isr.direct
net.isr.direct: 0
2006/03/19(日) 14:10:32ID:FpAWTOrI0
設定すると、ちょっとだけパフォーマンスがよくなるかも。
679root▲ ★
垢版 |
NGNG
%sysctl net.isr.direct=1
net.isr.direct: 0 -> 1
680root▲ ★
垢版 |
NGNG
焼け石に水っぽいですね。

しかし、状況は確かに改善しました。

・完全破綻には至らない
・RUN状態もちゃんと出るようになった

あとは、設定次第でもっとさばけるように出来るのか、
それともバックエンドはもう、現状では処理能力の限界なのか。
681root▲ ★
垢版 |
NGNG
>>680
> しかし、状況は確かに改善しました。

は、>>679 ではなくて、PREEMPTION なしカーネル。
682root▲ ★
垢版 |
NGNG
さて、、、。

ようやくある意味「普通に重い」状況にできました。というか、なりました。
ここからどうするか、というかんじですかね。
2006/03/19(日) 14:19:55ID:TOXEGCMQ0
何か前ちょっと /md に問題があるかもみたいなカキコを見かけたようなこと
あるような気もしますが,普通に HDD 使ったらいいとかいう可能性ないですかね?
/md ならどうせ落ちれば中身消失するのだから,代わりに async でやるとか.
684root▲ ★
垢版 |
NGNG
…今は、落ち着いている感じ。

「ある閾値を超えると破綻する」が、
「ある閾値を超えると重くなる」に、変わったのかな。

>>683
どうなんでしょうね。
vnode というぐらいで、md でもコストかかるところなわけで。
685root▲ ★
垢版 |
NGNG
>>684
> vnode というぐらいで、md でもコストかかるところなわけで。

つまり、HDD でやる意味はあるのかもしれないですが、
どうなんだろうか。
2006/03/19(日) 14:27:08ID:FpAWTOrI0
重いのってバックなんですよね。
張り付けられたtopの結果見るとperlが動いてますが、これはcgi?
すいません、システムよくわかってないです。

システムがわかれば、単純なモデルを別途つくってみて、負荷かけたりして
調べてみてもいいんですが。。。
687root▲ ★
垢版 |
NGNG
>>686
定時処理プログラムです。

板の圧縮とかごみそうじとか、そのへんをしています。
688root▲ ★
垢版 |
NGNG

こんなかんじですね。< vmstat

108 3950 0 1474100 2049932 7617 0 0 0 7706 0 1 1 2849 94327 12814 61 39 0
40 4014 0 1480832 2050368 7916 0 0 0 7938 0 1 0 3308 43599 18318 58 42 0
268 3767 0 1480180 2050188 7763 0 0 0 7952 0 13 0 3084 63361 22205 48 52 0
74 3938 0 1467188 2051744 9684 0 0 0 9884 0 1 0 2638 72894 17037 59 41 0
12 3987 0 1479668 2050332 8085 0 0 0 8077 0 9 0 2921 59468 18077 56 44 0
3853 138 0 1471408 2051324 9379 0 0 0 9387 0 1 0 2761 85201 16557 58 42 0
141 3904 0 1475660 2049816 9507 0 0 0 8912 0 1 0 3036 59267 17773 59 41 0
117 3868 0 1477232 2049804 7241 0 0 0 7592 0 1 0 2539 63877 17439 56 44 0
28 3957 0 1473444 2050380 7578 0 1 0 7580 0 14 2 2660 67876 16204 61 39 0
236 3715 0 1477644 2049608 8732 0 0 0 8640 0 1 42 2926 62428 21377 54
689root▲ ★
垢版 |
NGNG
で、accept で推移していて、
あふれている時は httpd が ucond とか RUN になるという状態ですね。今。
2006/03/19(日) 14:35:06ID:FpAWTOrI0
あと、topの結果は、スレッドを展開したもの(H を押して表示されるもの)の方が
わかりやすいです。
といっても、おそらく多数のスレッドが動いてますから、結果が長すぎて駄目ですかね。
691root▲ ★
垢版 |
NGNG
net.isr.direct も、一定の効果を発揮した模様。

【桜餅】負荷監視所_20060317
http://live14.2ch.net/test/read.cgi/liveplus/1142591997/847

sysctl @ live22 に追加しました。

# Thank you for AC, http://qb5.2ch.net/test/read.cgi/operate/1140540754/676
net.isr.direct=1
692root▲ ★
垢版 |
NGNG
>>690
top -H ですね。
693root▲ ★
垢版 |
NGNG
rsync (過去ログの同期)が、それなりに負担になっているなぁ。
仮に rsync で同期をやるとしても、過去ログrsync用バックエンドを別に持たせるかんじかな。
694root▲ ★
垢版 |
NGNG
httpd / bbsd の再起動装置を止めた。 @ live22
695root▲ ★
垢版 |
NGNG
>>694
s/止めた/再起動しても上がらなくした/
2006/03/19(日) 14:51:46ID:TOXEGCMQ0
いっそ過去ログは全部 memories に転送する仕様にしてしまうとか......
697root▲ ★
垢版 |
NGNG
ファイルは全部 mfs 上なので、mfs の設定をチューニングすればいいのかな。

/sbin/mdmfs -M -s ${_MDSIZE} -i 2048 -o noatime md /md

現在こんなかんじ。

/dev/md0 on /md (ufs, local, noatime, soft-updates)

softupdate なしの async にする(前に1度負けてますが)とか、そのへんか。
698root▲ ★
垢版 |
NGNG
>>696
で、read.cgi と offlaw.cgi をいじるかんじですか。
2006/03/19(日) 14:57:13ID:TOXEGCMQ0
>>698 read.cgi の方はライブ dat のやり方を流用すればいいのでそんなに難しくはないでしょうね.
問題は offlaw.cgi ですが......
700root▲ ★
垢版 |
NGNG
offlaw.cgi は、元ソースがどこにあるかすら知らなかったり。
2006/03/19(日) 15:26:10ID:TOXEGCMQ0
>>700 う〜む......


ともあれ,

・ ファイルシステムチューニング
・ mod_cache 有効化(Squid 問題解決)

このあたりで何とかなるかどうかってとこですか<重さ
702root▲ ★
垢版 |
NGNG
寝落ちしてました、、、。

em1: RX overrun

というのが3回ほど。
703root▲ ★
垢版 |
NGNG
news18 は LA=15-20 ぐらいだけど、何とかなりそうな感じ。
前に入れた自動Saborinが働いているかな。

ex13 ex14 は特に問題なしで。

で、live22 ははじめて、「今の限界まで正しく使われた」感じです。
それはそれで問題だが。
704root▲ ★
垢版 |
NGNG
次の大きなステップ(フロント増設・バックcobra稼動)に進むためには、
サーバの移動とかをたんたんとすすめるってかんじですね。
705root▲ ★
垢版 |
NGNG
で、ソフトウェア設定的に大きな器にする(>>701 など)のは、
ようやく別途すすめられる状態にあいなったと。

というわけで、虫はとれたっぽい。
が、課題はまだたくさんある、といったところかなと。

live22関係は、今日はこんなところで。
2006/03/19(日) 17:56:58ID:FpAWTOrI0
もうやってるかもしれませんがシステムのチューニングだと
sysctl kern.ipc.somaxconn
の設定も有効でした。ただ、今の状況だと、効果あるかわかりませんが。。

あと
>>462-463の修正はほとんどRELENG_6に入ったし、emドライバの修正もあるんで、
6.1-PREPRELEASEにあげるのも良いかも?
2006/03/19(日) 18:00:31ID:FpAWTOrI0
× 6.1-PREPRELEASE
○ 6.1-PRERELEASE
708root▲ ★
垢版 |
NGNG
やっぱり目が覚めちゃう件について。

>>706-707
RELENG_6_1 が切られたら、さっそくというかんじですね。

で、今の live22 の kern.ipc.somaxconn の値。

# increase listen queue
kern.ipc.somaxconn=8192
kern.ipc.maxsockbuf=2097152
709root▲ ★
垢版 |
NGNG
MacOS X (Darwin)の例ですが。
http://www.tech-arts.co.jp/macosx/macosx-jp/htdocs/16500/16582.html

> というわけで、小さなファイルをたくさん抱えて何回もアクセスするような処理を
> 行っており、それら全部載るくらいのメモリを持っている場合は、
> maxvnodes の値を見直してみる価値はあるのではないでしょうか。

本家は、

11.13 Tuning Kernel Limits
http://www.freebsd.org/doc/en/books/handbook/configtuning-kernel-limits.html

ここにも、vnode 関係の記述があるですね。

今は頭がぼーとしてるんで、あとでこのへん読んでじっくりと。

live22は今、
kern.maxvnodes: 100000

の模様(デフォルト)。
2006/03/19(日) 19:19:16ID:FpAWTOrI0
>>708
やはり、基本的な設定はされているんですね。
8192もあれば、普通なら問題ないと思います。。

個人的に、vmstatの b のところが、2000とか3000とかいってるのが気になるというか、
正直、そんな値初めて見ました。
リソース待ちなわけですが、何を待ってるんだろう。。
ってpage faultも多いですね。うーん。。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。

ニューススポーツなんでも実況