X

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

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

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

等を取り扱います。

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

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

前スレ:
2ch特化型サーバ・ロケーション構築作戦 Part19
http://qb5.2ch.net/test/read.cgi/operate/1121886018/
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も多いですね。うーん。。
711root▲ ★
垢版 |
2006/03/19(日) 19:21:02ID:???0
日曜(現地)も仕事入っていたりしますが、
合間を見て、管理人ではない「西村さん」の案件をやろうかなと。

長い、しかし有意義な1日だった。
712root▲ ★
垢版 |
2006/03/19(日) 19:23:44ID:???0
>>710
「リソース待ち」っぽいのは、この症状が出たころ(昨年末)から感じていて、
このスレの過去スレにも書いたですね。

page fault 多いですか。
vm 関係も微妙にチューニングの必要ありかもと。

今日はほんとにありがとうございました。
PREEMPTIONの件で、ここ数ヶ月止まっていたことが
一つ前に進んだ気がします。

そんでは、もうひとねいり。
2006/03/19(日) 19:45:00ID:M/Cfljrg0
YOUどうせならcurrent 使っちゃいなYO
2006/03/19(日) 23:08:32ID:JvDTJEGU0
無茶言うな
2006/03/20(月) 00:21:51ID:iuDJLqcCO
俺も複数チンポシーン好きだけど、本番ないのが惜しかったなパー穴
パー穴の複数チンポとデミパの本番のいいとこどりなやつキボン
ぶっちゃけ林間が見たい
あの下品なテイストのままで。
2006/03/20(月) 00:38:27ID:d1aOtDjn0
いいからVIPに帰れよ貴様はｗ
2006/03/20(月) 00:46:36ID:5gAnijz40
そういえば......matd の方は WBC の時どんな感じだったんでしょうね．
限界近いぐらいか，それともまだ余力十分か......
718root▲ ★
垢版 |
2006/03/20(月) 03:15:24ID:???0
>>717
特に問題はなかったようです。
限界近いか余力十分かは、、、stats をとらないといかんですね。
719root▲ ★
垢版 |
NGNG
>>490 と >>583 とを前提にしたコードを、
ぼちぼち入れていきます。

これから組んで、できたらまず qb5 と qb6 に入れようかと。
入れたらその旨知らせるので、別途試してみていただけると助かります。
2006/03/20(月) 12:47:58ID:4l/kRRnp0
>>719
承知しました。報告いたします。
2006/03/20(月) 12:52:12ID:iUUzAkXUO
西村さんの意見かぁ。

だんだんひろゆきさんがホリエモンみたくイメージキャラクター化しているように感じるのは俺だけ？
2006/03/20(月) 14:00:34ID:Nsn+9yOI0
「管理人ではない」とわざわざ書いてあったりするのに
管理人にされてしまう西村さんﾃﾗｶﾜｲｿｽ
723root▲ ★
垢版 |
NGNG
bbs.cgi再開発プロジェクト7
http://qb5.2ch.net/test/read.cgi/operate/1130918407/488

qb5 サーバに携帯用ブラウザ対応版 bbs.cgi を入れました。
というわけで、書き込みテストをよろしくお願いいたします。

テストはこちらでやっていただけますと助かります。

[test] 書き込みテスト 専用スレッド 59 [ﾃｽﾄ]
http://qb5.2ch.net/test/read.cgi/operate/1140966906/

なお今回の bbs.cgi 内の対応は「一般的に」行ったので
(ブラウザ依存の取得ルーチンの追加だけで対応可能)、
仮に同様の情報を提供いただける、他の携帯用ブラウザがあれば、
それらへの対応も、技術的には可能になったはず。
2006/03/20(月) 15:16:21ID:4l/kRRnp0
>>723

http://qb5.2ch.net/test/read.cgi/operate/1140966906/944

にて、正常に送信できたことを報告いたします。
725root▲ ★
垢版 |
NGNG
>>724
どうもです。

IDの一致を見たいので、普通に c.2ch.net 経由で書いていただけると助かります。
726root▲ ★
垢版 |
NGNG
経由で => 経由でも
2006/03/20(月) 15:22:30ID:4l/kRRnp0
申し訳ありませんでした。

>>723

http://qb5.2ch.net/test/read.cgi/operate/1140966906/944

にて、正常に送信できたことを報告いたします。


----------

携帯用ブラウザからの情報を正しく取得できませんでした。
と出ました。


弊社側のサーバがそちらに対応していないようです。
対応いたします。
728root▲ ★
垢版 |
NGNG
>>727
???

一度書けたのに、どうしたのでしょう。
2006/03/20(月) 15:29:55ID:4l/kRRnp0
>>728
> 一度書けたのに、どうしたのでしょう。

action属性の値を厳密化(../test/bbs.cgi)しすぎていたため、c.2ch.net に書き込めませんでした。
c.2ch.net 経由でも書き込めたことを
http://qb5.2ch.net/test/read.cgi/operate/1140966906/947
にて報告いたします。
730root▲ ★
垢版 |
NGNG
>>729
了解です。そういうことでしたか。

あともうひとつ(実はこれがさきほどの質問の意図でしたが)、
ibisBrowser 経由ではなく、同じ携帯で直接iモードからc.2ch.net経由で
同じスレッドに書き込んでいただけると助かります。

それで、その書き込みのIDの末尾だけがQからOに変わればすべて解決になります。
(つまり、素で携帯から書いたものと同じIDになってほしい)
よろしくお願いします。
2006/03/20(月) 15:38:13ID:4l/kRRnp0
>>730

iModeブラウザから書き込みました。

http://qb5.2ch.net/test/read.cgi/operate/1140966906/950

末尾のみが違うことを確認できました。
732root▲ ★
垢版 |
NGNG
向こうで確認しました。うまくいっているようですね。
それでは、全サーバにこのbbs.cgiを配布するということで。
2006/03/20(月) 15:41:11ID:4l/kRRnp0
ありがとうございました。

今後ともよろしくお願いいたします。
734root▲ ★
垢版 |
NGNG
配布しました。
10分程度で全サーバ有効になるはず。

以降の不具合報告等についてはここではなく、
こちらのスレを使っていただけると助かります。

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

IPアドレスの追加・変更やUAの仕様変更、
あるいはDoCoMo以外の機種への対応があった場合には、
これまで通り、こちらのスレで報告をお願いします。

ということで、よろしくお願いします。
2006/03/20(月) 15:46:20ID:4l/kRRnp0
>>734

承知しました。
よろしくお願いいたします。
2006/03/20(月) 19:14:24ID:6DJajcET0
sage
2006/03/20(月) 19:36:44ID:v9vJz1+40
昨日PREEMPTIONなしをお薦めした者ですが、
PREEMPTIONとDEVICE_POLLINGについて簡単なベンチマークを行ってみました。
ベンチマークには自作のApacheモジュールを使用しました。
そのモジュールは、/var/tmp/bbs.txtというファイルを開いた後にファイルをロックし、
そのファイルにHello, world!!!という文字列を50回書き込んで、
クライアントにtest OK!という文字列を返すという簡単なものです。
abを使用して、同時1000接続、合計1000000リクエストでテストしました。

<テスト結果>
PREEMPTIONあり + DEVICE_POLLINGなし:
Requests per second: 1999.76 [#/sec]

PREEMPTIONあり + DEVICE_POLLINGあり:
Requests per second: 1836.68 [#/sec]

PREEMPTIONなし + DEVICE_POLLINGなし:
Requests per second: 5005.48 [#/sec]

PREEMPTIONなし + DEVICE_POLLINGあり:
Requests per second: 6528.52 [#/sec]

良かったら御参考に。
738root▲ ★
垢版 |
2006/03/20(月) 19:44:31ID:???0
今日も目が覚めてしまった件。

>>737
どうもです。DEVICE_POLLING ですか。

前に一度、matd の時に挙動不審になって負けた経験がありますが、
あれはPREEMPTIONあり + DEVICE_POLLING ありだった時(下記で一番悪い)なので、
別途やってみる意味はありますね。

live22は幸運にもリモートコンソールでアクセスできるので、
最悪ネットワークがしくっても、なんとかできるので。

また、あとで挑戦ということで。
2006/03/20(月) 19:53:38ID:v9vJz1+40
あ、あと、最後の「PREEMPTIONなし + DEVICE_POLLINGあり」では、

・vmstatで見たとき、run queueに2桁しかたまらない
・vmstatで見たとき、cpu idleが0ではない

という特徴がありました。他のものはrun queueは3桁でidleは0でした。


…それにしても、リソース待ちの状況が作り出せないです。
どうやったらそうなるのか、個人的に興味があるんですが。
2006/03/20(月) 19:58:27ID:3AhPRBbd0
>> 709
現在のlive22xの過去ログの数を数えたら、167315個ぐらいあるようなきがする...
rsyncって配下のファイル全部なめたりしませんよね。

とりあえず、 sysctl vfs.numvnodes の値を見た方がよいのかも。
2006/03/20(月) 20:18:07ID:JBGtAjYz0
>rsyncって配下のファイル全部なめたりしませんよね。
ファイルリストを作るために舐める気がした。
2006/03/20(月) 23:32:54ID:5gAnijz40
rsync が負担になってるとすると......長期的には offlaw.cgi 改造で
rsync を使わずに済む形に持っていくとして，今できる対策ということでは，
例えば LA が上がるなど忙しい時には一時的に rsync を止めてしまって，
ゆとりができてから rsync を再開させるようにするとか．
743root▲ ★
垢版 |
2006/03/20(月) 23:35:52ID:???0
おはようございます。

過去ログ部分のrsyncをゆっくりにして(rsyncの系統を分ける)、
>>742 のような策も入れてみようかと。
2006/03/20(月) 23:43:08ID:4MqdJb6z0
鯖に関して外部との共同作業ってのは、初めてかもしれないな
2006/03/21(火) 01:11:05ID:+mO7md5D0
系統を分けるんなら負荷の低いときには早めに同期するとかしてほしいなあ
2006/03/21(火) 01:20:13ID:yoz+wfO50
いつの間にか出てたようです。

squid-2.5.STABLE13
ttp://www.squid-cache.org/Versions/v2/2.5/squid-2.5.STABLE13-RELEASENOTES.html
2006/03/21(火) 10:51:03ID:8MeS4SLs0
740なこといいましたが、本当にrsyncのファイルアクセスのせいかわからないので、
メモリに余裕があるのなら、まずは、 kern.maxvnodes=200000ぐらいにして
リソース待ちが発生しないかためしてみるのがよいのかも。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況