【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2

**FOX ★** · 04/07/01 13:55

日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。

たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、

Love Affair 作戦。
Part2 大黒埠頭

前スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/test/read.cgi/operate/1075887465/

**root ★** · 04/07/25 11:25

>>668
ありうるかも。ううむ。

**動け動けウゴウゴ２ちゃんねる** · 04/07/25 23:29

2ch→携帯ｽﾚにも書いたけど、23時頃からみれません
エラーでます
ＤｏＣｏＭｏのFOMAのP2102浸かってます
2ちゃん見れないと激しく鬱です
_|￣|○

◆BFzK/mtqM2 · 04/07/26 01:07

22～23時にかけて軒並み負荷上がってましたね。
何かトラブルでもあったのかな？

**FOX ★** · 04/07/26 01:10

http://server.maido3.com/pie/　を見ると
docomo2,3 au1,2 others BlackGoat と全部転送量がへこんでますね、

なぜだろう、、、

全部って事は、一番前か一番後ろが問題だったと
推測できるんだけど、、、不思議。

◆BFzK/mtqM2 · 04/07/26 01:26

あとで、root★さんに調べてもらいましょう。
>>670とかのエラーと何か関係があるのかな？
あと、live8もほど同じ時刻に死んでいたみたいだけど、関係あるのかな？

**よよよ** ◆EX/mumumu2 · 04/07/26 03:24

>>671-673
倒れている主人に口頭で伝えました。
「申し訳ないけど、明日以降で・・・」
と言っていました。

**動け動けウゴウゴ２ちゃんねる** · 04/07/26 03:25

>>674
お体にはくれぐれもお気をつけくださいと
お伝えください。。。

◆BFzK/mtqM2 · 04/07/26 03:31

>>674
いつでもいいですよー
ちょこっと見た感じでは、特にエラーは無かったです。

**動け動けウゴウゴ２ちゃんねる** · 04/07/26 06:10

>>672
転送量は下がってるけど、負荷は上がってる。
http://ch2.ath.cx/load/c-docomo2.html
http://ch2.ath.cx/load/c-au1.html

で、live8が落ちてた時間と一致しているので、datを取りに行こうとして
timeoutするまで処理が止まってしまうためでは？
http://ch2.ath.cx/load/live8.html

**FOX ★** · 04/07/26 11:46

>>677
おっ　たしかに、
それですね、

**動け動けウゴウゴ２ちゃんねる** · 04/07/26 12:55

横からすんません。ちと教えていただきたいのですが

Ｑ．ネットワーク的に、携帯用の各鯖って comic6(banana388) と同じスイッチの下に
　ぶら下がったりしていますか？

http://qb5.2ch.net/test/read.cgi/operate/1088767056/812

P.S.
root ★さん、お体をお大事に…

**root ★** · 04/07/26 14:16

>>673 >>677-678
ふうむ、live8のダウンがおおいに影響していそうですね。
blackgoatが落ちたときはともかく、人気があるところが一つ死ぬとこうなるのは、、、。

>>679
>>572 にもあるように、アドレスが近いですね。同じスイッチなのかな。
昨日のcomic6の不調(live8が落ちてしばらく後にcomic6も不調になった)も、
何か関連しているのかも。

**動け動けウゴウゴ２ちゃんねる** · 04/07/26 14:48

>>680 あ、どうもありがとうございます。元スレの方で、継続観測してみます。
今晩も起こるかどうか分かりませんがｗ

◆EA.clAssIc · 04/07/26 16:28

ﾀｲﾑｱｳﾄを5秒にしてみました

**root ★** · 04/07/26 21:18

遅延関連の設定をいじりました。

c.2ch不具合報告総合スレ
http://qb5.2ch.net/test/read.cgi/operate/1088828988/121-123

これで、改善するかどうか。

◆BFzK/mtqM2 · 04/07/26 21:35

なんかレスポンスが悪いような気がする。
トップとかはそこそこ軽いが、スレッドは重い。
BlackGoatの負荷が重くなってるのかな？

◆BFzK/mtqM2 · 04/07/26 21:39

転送量規制にかかっているとか。。。

と携帯から妄想してみる

**root ★** · 04/07/26 21:42

>>685
例の、blackgoatが「あふれ出す」時間と一致してますね。
diskdいれてみるか。

**root ★** · 04/07/26 21:47

まず、

cache_replacement_policy heap GDSF
memory_replacement_policy heap LFUDA

にしてみた。

**root ★** · 04/07/26 21:58

diskdを入れるにはkern.ipc.msgmnbとかをいじる必要があって、
それはrebootしないとだめ(sysctlでは不可)みたい。

というわけで、アクセスの多い今の時間はとりあえず保留。

**root ★** · 04/07/26 22:26

cache_mem を 80 MB に増やしてみた。
負荷が下がったみたい。

**root ★** · 04/07/26 22:29

あと、cache_swap_lowとcache_swap_highはどうすればいいのかしら。
ちなみにキャッシュディレクトリ(ディスク)は十分おおきいです。

**動け動けウゴウゴ２ちゃんねる** · 04/07/27 01:07

>>690 横からすんまそん。
cache_dir で指定したキャッシュの容量が大きければ、cache_swap_low _high の
差は数百Ｍｂｙｔｅにもなるかもしれません。そのためこの２つの数値を近づけた方が
いいかも… って記述しかありませんなぁ…
とはいえ、_low、_high ってヒステリシスなしきい（←なぜか変換できない（素））値やから
あまりシビアな設定にすると、酷い事になりそうやし。

とりあえず、デフォルトの 90、95 で様子を見て調整という、いつものパターンでしょうか？

＃ＩＭＥ２００２のあふぉたれめ。閾が「しきい」で変換できんやんけ

**動け動けウゴウゴ２ちゃんねる** · 04/07/27 01:09

「いきち」が正しい、はず。

◆BFzK/mtqM2 · 04/07/27 01:19

「しきいち」でも「いきち」ちゃんと閾値ってでるぞ　IME2000

**root ★** · 04/07/27 01:33

>>691
実際に大きいので、近づけてみるか。

もうちょっとしたら、blackgoatの設定変更やります。

**動け動けウゴウゴ２ちゃんねる** · 04/07/27 02:09

DDoS食らってる状態になるんだよみんなリロードしまくるでしょ

**root ★** · 04/07/27 02:47

diskd化完了。

結局、以下をblackgoatのカーネルに入れて再構築&リブート。

# for squid cache
options MSGMNB=16384 # max characters per message queue
#options MSGMNI=40 # max number of message queue identifiers
#options MSGSEG=2048 # max number of message segments in the system
#options MSGSSZ=64 # size of a message segment (Must be 2^N)
options MSGTQL=1024 # max amount of messages in the system

◆EA.clAssIc · 04/07/27 18:46

ちょと確認させて頂きたいのですが、
ﾒﾆｭｰの中身があるｻｰﾊﾞは、

c-au1.2ch.net
c-au2.2ch.net (docomo1.2ch.netと同じ)
c-docomo2.2ch.net
c-docomo3.2ch.net
c-others.2ch.net (c-others1.2ch.netと同じ)

の5種類ということで良いでしょうか?

**root ★** · 04/07/27 19:15

>>697
c-othersのところは他同様、以下が正しいかと。

c-au1.2ch.net
c-au2.2ch.net (docomo1.2ch.netと同じ)
c-docomo2.2ch.net
c-docomo3.2ch.net
c-others1.2ch.net

◆EA.clAssIc · 04/07/27 19:19

>>698
了解です、ありがとうございます。

**root ★** · 04/07/27 22:53

maximum_object_size_in_memory をデフォルト(8kbytes)から
1024kbytesにふやしてみた。

これで、datがうまくメモリに乗るようになる？

# TAG: maximum_object_size_in_memory (bytes)
# Objects greater than this size will not be attempted to kept in
# the memory cache. This should be set high enough to keep objects
# accessed frequently in memory to improve performance whilst low
# enough to keep larger objects from hoarding cache_mem .
#
#Default:
# maximum_object_size_in_memory 8 KB
maximum_object_size_in_memory 1024 KB

**root ★** · 04/07/27 22:59

c-others1、調整中。

**root ★** · 04/07/27 23:05

>>701 done.
c-docomo[23]、調整中&済み。
c-au[12]、これから少し調整します。

**root ★** · 04/07/27 23:09

とりあえずdone.
しばらくチェック。

**root ★** · 04/07/27 23:23

LAそのものはそれほどでもなく、入り口で詰まっているようなので、
様子をみながらhttpdの数を増やしてみた。< 各c-xxxx

**root ★** · 04/07/27 23:33

臨時にアクセラレータをはずしてみる。もたないか、もつのか。< c-docomo2

**root ★** · 04/07/27 23:35

ん、アクセスが多いときは、苦しい模様。< c-docomo2

アクセラレータ(キャッシュ)を入れるとamd64ではやや不安定。
アクセラレータをはずすととてももたないのか。

**root ★** · 04/07/27 23:40

c-docomo2、ほとんど瀕死かも。

c-docomo系が死んだら、c-au系やc-others系のhttpdが捌けるようになった。
blackgoatのI/O処理が滞っていたのか。

◆BFzK/mtqM2 · 04/07/27 23:42

Zend-optimaizerの方にしてみるとか。。。

◆EA.clAssIc · 04/07/27 23:46

root ★さん、
参考までに、docomo2でのｽｸﾘﾌﾟﾄの各ﾎﾟｲﾝﾄ毎の単純な処理時間です。
総処理 = 0.50580286979675
├初期化 = 0.0017189979553223
├ｽﾚｯﾄﾞ表示 = 0.50293588638306
｜　├ｿｹｯﾄ接続～切断 = 0.5008430480957
｜　└上記以外の処理 = 0.0020928382873535
└上記以外の処理 = 0.001147985458374

◆BFzK/mtqM2 · 04/07/27 23:47

やはり、datを全て読み込んで処理するので、そこがネックになっているようですね。

**root ★** · 04/07/27 23:50

どうも。

>>710 datをとってくるところが重いですか、、、。

c-docomo2、ログインもできないぐらいつらい状況。
しばらくだめだった場合、リブート依頼します。

◆EA.clAssIc · 04/07/27 23:53

BlackGoatへのｿｹｯﾄ接続～切断までの間では、
"ﾚｽ番1と指定のﾚｽ10個分を配列に格納する"という以外の処理は行っていないのですが、
最新10ｽﾚｯﾄﾞなどの表示では最後まで読み切らないといけないので時間がかかりますね…

**root ★** · 04/07/27 23:53

これからリブート依頼します。< c-docomo2

**root ★** · 04/07/28 00:00

>>712
そうですね。
blackgoatのディスクはストライピングにして、
かつnewfs -b 65536 -f 8192などとやってあるのですが、
そろそろI/O性能が苦しい状況なのかも。

今比較のために、一時的にaufsに戻してみた。
＊感覚では＊、diskdのほうが遅いような気がします。
統計的にも「漏れる」量が多いみたい。< blackgoat

**動け動けウゴウゴ２ちゃんねる** · 04/07/28 00:02

>>712
初期読み込みのデフォをレス番1～11に変更してみては？
それで統計取ってみて、最新を取る回数が多かったら戻すとか

◆BFzK/mtqM2 · 04/07/28 00:07

デフォルトで、１～11が表示されたら、その後、最新レス10を実行するから、
余計負荷がかかってしまう。

**root ★** · 04/07/28 00:26

cache_dir diskd /usr/local/squid/cache 100000 16 256
を、
cache_dir diskd /usr/local/squid/cache 100000 64 256

にして、squid -zの後にdiskdモードを復活させてみた。

◆EA.clAssIc · 04/07/28 00:38

>>715さん、
以前i2chでの統計を取ったのですが、
全ｱｸｾｽ中1/3が最新ｽﾚｯﾄﾞへのｱｸｾｽでした。
ですので、やはり>>716 ◆BFzK/mtqM2さんの仰る通りになってしまうかもです…

**root ★** · 04/07/28 00:48

cobra2247にログインできました。リブートして、調整中。

**root ★** · 04/07/28 00:48

cobra2247 = c-docomo/c-docomo2

**root ★** · 04/07/28 00:53

設定更新&リブートかけました。正常にもどったはず。

**root ★** · 04/07/28 01:31

こんどは、BlackGoatがおなかいっぱいか。
LAは低いけど(プロセスが多いわけではないので)、ディスクI/Oがかなり苦しめの予感。

Disks ad0 ad1
KB/t 25.34 22.48
tps 133 141
MB/s 3.29 3.09
% busy 75 82

%iostat -w 1 -c 10
tty ad0 ad1 cpu
tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id
0 39 25.71 63 1.58 22.53 68 1.49 19 0 29 16 37
0 180 17.53 47 0.80 18.17 48 0.85 39 0 45 16 0
0 59 25.94 200 5.07 24.00 201 4.71 28 0 63 9 0
0 59 31.13 260 7.89 30.37 272 8.08 34 0 61 5 0
0 239 20.51 90 1.80 18.86 97 1.79 32 0 44 25 0
0 59 25.98 164 4.17 22.70 152 3.38 39 0 50 11 0
0 59 23.82 89 2.07 20.53 98 1.97 29 0 45 26 0
0 59 23.95 160 3.75 22.97 146 3.27 39 0 51 10 0
0 59 26.05 81 2.06 22.52 91 2.00 36 0 35 28 0
0 60 26.57 278 7.21 21.11 278 5.73 36 0 64 0 0

**root ★** · 04/07/28 01:38

パフォーマンスが出ないため、>>717 を前の設定 (16 256) に戻した。

◆EA.clAssIc · 04/07/28 01:46

お疲れ様です。
BGへのﾀｲﾑｱｳﾄ、もう少し短くしてみますか?

**動け動けウゴウゴ２ちゃんねる** · 04/07/28 01:49

bbs.cgiで、逆順のdatも作るようにし、c.2ch.netやread.cgiの初期読み込みではそちらを
使うようにするとか。
キャッシュヒット率が下がって逆効果かな？

**root ★** · 04/07/28 01:59

>>724
今dat取得のタイムアウトは5秒でしたっけ。
タイムアウトを早めると、タイムアウトが頻発するのかな。

◆EA.clAssIc · 04/07/28 02:04

今ちょと新しいｽｸﾘﾌﾟﾄをあげてﾃｽﾄしているのですが、
先程の重い時間帯で3秒設定だとまずﾀｲﾑｱｳﾄです。
5秒でもほとんどﾀｲﾑｱｳﾄ状態でした。

◆EA.clAssIc · 04/07/28 02:11

ﾀｲﾑｱｳﾄで
「今BlackGoatが思いです｡｡｡」とか表示すれば、
ﾘﾛｰﾄﾞ抑制にもなるかもですね、、、
5秒超にはしたくない感じです。

**動け動けウゴウゴ２ちゃんねる** · 04/07/28 03:00

大規模squidのボトルネックはHDD回りなので、できればcache_dir用にスライスを確保したほうがいいかも。
noatimeは当然として。
asyncでもいいかも。
容量があんまり小さいスライスだとoptimize TIME to SPACEを食らうので4倍以上で。
あと外周部分にあるとうれしいので/の次に確保してたり。

**root ★** · 04/07/28 04:43

>>729
いまこんなかんじ。
ccd使って、2本のIDEディスクをストライピングで使用。
/dev/ccd0は、newfs -U -b 65536 -f 8192で初期化。

%pwd
/home/squid_local/cache
%df -k .
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ccd0 136319544 35531976 89882008 28% /home
%mount | grep home
/dev/ccd0 on /home (ufs, local, noatime, nosuid, soft-updates)
%cat /etc/ccd.conf
# ccd ileave flags component devices
ccd0 64 none /dev/ad0s1f /dev/ad1s1d

ひどいときには両ディスクとも% busyが80%ぐらいになるですね(>>722)。

**▲:/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 04/07/28 12:42

途中割り込みでスマソです。

>>730
IDEのストライピングだとつらそうですね。
かといってUltraSCSI320のそれにしようとすると余計な投資になるし・・・

blackgoat自体がキャッシュサーバですから
RAMディスクで捌くってのは・・・すでにやっているんですかね。

**root ★** · 04/07/28 13:22

>>731
メモリディスクか。
現時点では入れてないですね。

squidのプロセスが400Mを超えるようなので、メモリディスクはちょっとどきどき。
というか、入れるとしたらどこがいいのかな。

**▲:/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 04/07/28 15:12

>>732
その400MBプロセスなsquidってどこのやつですか。

**▲:/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 04/07/28 15:18

>>733
あ、blackgoatのでつねｗ
wikiに書いてあるの忘れてたｗ

**▲:/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 04/07/28 15:24

ちょっと考察。

携帯からのある意味実況レベルに近い通信要求を
バックエンドを１台で捌くというのはかなりきついと思います。
しかもblackgortが落ちたら携帯からのアクセスは不可能。

投資ができるなら、の話ですが、
もう１台バックエンドを用意して負荷分散させたほうがいいかもしれません。
どちらかのバックエンドが落ちたときにバックアップさせるという意味合いもあるし。

**FOX ★** · 04/07/28 15:37

1) フロントエンドを充実させて需要に見合う供給をおこなった。
2) 当然、BlackGoatは大忙し、
3) この大忙しを解決する方法は当初の予定通り、BlackGoatの仕組みで行う

というように順調に予定通り進んでいるということですなぁ。
せっかく作り出した重い状態。せっせとデータを取らなければ、、、

BlackGoat の各種データをとって、思考実験(机上演習)です。
帯域等は現在取っているので、アクセス数やそのへんも何とか
データが取れないかな? とい段階かと、

BlackGoat を増設するのは考えないで行きます。
だってすぐ解決しちゃうもん。

**未承諾広告※** ◆TWARamEjuA · 04/07/28 15:47

>>735
負荷分散しても片方が墜ちると共倒れになる悪寒ですよね。。。＠基本的に片肺でも生きていかないと・・

ちょっと考察。
最新 10 スレの取得方法案。
　HEAD で DAT の Content-length を取得。
　Content-length から 20480 引いた場所から末尾まで取得。（ 1 レスは最大で2048Bytes でしたっけ？）
　Range: bytes=(Content-length-20480)-(Content-length-1)
　\n を区切りにして、末尾から 10 レス取得。
　my @Part_Log = (reverse split /\n/,<DAT>)[0..9];

演算が増えるけれどもその分、 DAT 採取のコストが幾分か下がるのではないかと。。。

**未承諾広告※** ◆TWARamEjuA · 04/07/28 15:55

もしかして、分割して取得するとキャッシングがうまく効くのかな？
例えば。。。
活きのいい DAT があっても、全取得となるとキャッシュが効かないはず。
でも、例えば先頭から 4KB は活きが良くても悪くても、内容はあぼーんが入らない限り変わらないはずなので、
この部分は ETag: を使って照合すれば、うまくキャッシングされているのではないだろうか？と。

ただし、ETag の管理をするために、また複雑な操作が必要になってくるかもかも。。。
（殊に呼び出し側の c-* 族の I/O 処理とかとか）

**root ★** · 04/07/28 15:56

>>736
そのとおりっすねぇ。

いろいろ試行錯誤してるわけですが、スキル不足のためなかなかはかどらず。
なかなかつらいすけど、いい経験させていただいているぐらいに思うのがいいのかも。

アクセス数は負荷を上げない方法でぜひとりたいですね。
例えばどの時間にどの板に要求が多いのかとか、とりたいことはいろいろ。

>>735 >>737
バックエンドを2台(横並び)体制にするなら、何か考える必要があるすね。
いずれはそうなることも視野に入れる必要がありそう。

**FOX ★** · 04/07/28 16:18

そこで、BlackGoat に疑惑が集まっているのですが、
この辺が明らかになればいいなぁ。。。

1) 観測された c.2ch.net に起こった現象 (docomoが重いとか、)
2) 推測される原因 (BlackGoatの反応が遅すぎ)
3) BlackGoat に起っているであろう現象、具体的な症状の推測 (LA の増大とか)
4) 実際にその具体的な症状がせ起っているか、
5) 起っているなら、解決策は?

ここで重要なのは、　3) -> 4) の関係です。
3) で推測して、実際に 4) で現象が起っているかどうかの確認。
確認手段が無い場合は、手段を作る。逆に、こうすれば解決するのでは?
という作業は間違っても行ってはいけない。

**root ★** · 04/07/28 16:19

>>740
> 逆に、こうすれば解決するのでは?
> という作業は間違っても行ってはいけない。

きもにめいじます。

**root ★** · 04/07/28 16:21

>>740
で、いまのところ起こっているのは、ディスクI/O負荷の増大なわけです。
あとは、苦しい時間(昼とか夜23:00ごろとか)に、キャッシュの効きが悪くなる。

いずれにせよ、観察・確認できる手段をなんとかする方向で動いてみます。
とりあえずsnmpあたりでつついてみるか。

**FOX ★** · 04/07/28 16:25

>ディスクI/O負荷の増大なわけです

という推測があった場合、
じゃ具体的に、定量的に BlackGoat でどういう数字がでているかを推測して
かつ実際に計測して、どうなっているか、、

もし推測と実測値が極めて一致したならば
最初の命題「ディスクI/O負荷の増大なわけです」
という推測がかなりピンポンであるといえるかと、
もし他にもこの図式がなりたてば、ほぼ確実といえるかと、

**未承諾広告※** ◆TWARamEjuA · 04/07/28 16:26

>>740
資料が無いのでどうしても机上の空論だけになってしまいますよね（汗）
って事でもうしばらく静観してます m(_ _)m

**▲:/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 04/07/28 17:19

>>739
そうですか。

現状では１台でなんとかなっていますし、
今のうちに問題点を洗っておいたほうが良いという
>>736の狐の内臓の人の意見には同意です。

とりあえず

＞バックエンドを2台(横並び)体制にするなら、何か考える必要があるすね。
＞いずれはそうなることも視野に入れる必要がありそう。

みたいな認識で十分かと。

**動け動けウゴウゴ２ちゃんねる** · 04/07/28 19:05

>>732
400Mって。
squid.confはちゃんとmemory_pools offになってますか？
デフォルトはonなのですがメモリ管理はカーネルに任せた方がいいのでoffにしないと。

**root ★** · 04/07/28 20:07

http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/

>>746
いまこんなかんじすね。
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
32057 squid -8 0 398M 395M biord 59:41 20.41% 20.41% squid

memory_poolsはデフォルト(on)。
onとoff、どっちがいいのかな。

# blackgoatはmemory 1G積んでます。squid以外の仕事はしていない。

**root ★** · 04/07/29 01:07

うすうすわかってはいたけど、深夜の時間(混む時間)は、
リクエスト数はあまり変わらないのに、キャッシュヒット率が下がる。

http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/blackgoat-hits.html

で、datをひんぱんに外に取りに行くので処理に時間がかかるし、
その分携帯とのコネクションも滞留する。

この原因は何だろう。

夜の時間は「いろんなところのスレが参照される」から、キャッシュにない場合が増える、
ということなのかな。

で、リクエスト数自体がその時間もあまり変わらないのは、
ひょっとすると携帯ネット=>インターネットの間で、何かのリミッターが入っているのかも、かも。

**root ★** · 04/07/29 01:27

突然軽くなったかも。

**root ★** · 04/07/29 01:28

で、またすぐに重くなった。

**root ★** · 04/07/29 01:29

パケット落ちはないから、ネットワークまわりやスイッチ関係じゃなさそうだなぁ。

--- comic6.2ch.net ping statistics ---
201 packets transmitted, 200 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.948/10.371/116.189/14.277 ms

**root ★** · 04/07/29 01:32

う、激しく誤爆した。
OpenJaneを立ち上げなおそう。すまそ。

**動け動けウゴウゴ２ちゃんねる** · 04/07/29 05:53

memory_pools はoffのほうが良いです。
BSD Magazineのシステムチューニングの回参照

**root ★** · 04/07/29 11:07

>>753
これですか。読んでみます。
http://www.ascii.co.jp/BSDmag/200214/contents.html
http://www.ascii.co.jp/BSDmag/200214/

FreeBSDではmemory_pools offにしたほうがいいというのは、
Googleに聞くと結構あるみたい。

**root ★** · 04/07/29 11:08

memory_pools off にしました。

**root ★** · 04/07/29 11:55

こちらにも。

携帯→2ch運用情報スレッド10
http://qb5.2ch.net/test/read.cgi/operate/1089186698/639
639 名前：root ★[sage] 投稿日：04/07/29 11:46 ID:???
キャッシュ効果の観察のため、いったんblackgoatのキャッシュをゼロクリアしました。
その影響で数分間、c系が不安定になったかも。

今は正常に戻ったはず。

**root ★** · 04/07/29 12:41

>>755 にすると、
2004/07/28 20:38:59| assertion failed: comm.c:751: "p != NULL"

というエラーが出て、squidが死ぬ模様。

後で調べることにして、いったん退却(memory_pools onに戻しました)。

**未承諾広告※** ◆TWARamEjuA · 04/07/29 12:59

>>757
8. Key changes squid-2.5.STABLE5 to 2.5.STABLE6:

* Several "Assertion error" bugs fixed
これの関係かしらん？

**root ★** · 04/07/29 13:25

>>758
今のもの:
2004/07/28 20:41:01| Starting Squid Cache version 2.5.STABLE5 for i386-portbld-freebsd5.2.1...

…つまり、STABLE6にしろと。

**root ★** · 04/07/29 13:53

STABLE6に更新して、再度挑戦中、、、。

**root ★** · 04/07/29 13:55

だめですね。やはり出ます。
2004/07/28 21:54:12| assertion failed: comm.c:751: "p != NULL"

もとに戻しました。

**未承諾広告※** ◆TWARamEjuA · 04/07/29 13:56

>>759
http://www.squid-cache.org/bugs/show_bug.cgi?id=761
こちらを判らないながらも眺めてみたのですが、違う種のアサーションエラーみたいですね。
でもって、最新の ports が存在するのかな？（＠まだ ports の仕組みが判ってなかったりもしますけれども（苦笑）
・・・と書いているうちに、、、

>>760
おつですおつですm(_ _)m

**未承諾広告※** ◆TWARamEjuA · 04/07/29 14:24

Squid Web Proxy Cache
http://pc5.2ch.net/test/read.cgi/unix/1034236482/l50
こっちに投げてみるのも手かな？（苦笑）

**FOX ★** · 04/07/29 15:59

この一時間のcomic6の様子ですが、、、

comic6.2ch.net サーバ
.dat 呼び出し回数 = 59632

deny from 206.223.150.190 #(7465) 12.52%

BlackGoat からこんなにたくさん。。。
これで正常なのか、異常なのか、

**root ★** · 04/07/29 16:03

>>764
15:00(JST)台ですか。
アクセスログを確認してみます。

**root ★** · 04/07/29 16:22

まだログを見ていませんが、今日の昼にやった >>756 の作業が影響しているのかもです。>>764

**▲:/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 04/07/29 17:18

>>763
投げるべきでしょう。結果は期待できないですがね。

◆KAGESsh/NQ · 04/07/29 17:46

「やるべき事」と本質がずれてしまいますが(squid の bug 探し、潰し)…

squid 本家に投げてみるというのも、手かもしれない。
bug track 見てる限りでは、comm.c での assertion faild は出てないみたいですね。
チト source 引っ張ってきて覗いてみたら、

１．何か(すんません、真剣に見てません)の handler 削除のために、
　comm_remove_close_handler() call
２．削除対象探索 in comm_remove_close_handler(), comm.c
　が、探索のキモの部分が for(xxxx; p != NULL; xxxx) になってて、探索対象が
　見つからなければ、for() を抜けて、assert(p != NULL); で落っこちる。

つうことで、多分 memory_pools off の時に、無用な comm_remove_close_handler
call が起こってるんでしょうなぁ。