日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。
たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、
Love Affair 作戦。
Part2 大黒埠頭
前スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/test/read.cgi/operate/1075887465/
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
■ このスレッドは過去ログ倉庫に格納されています
1FOX ★
04/07/01 13:55ID:???04/07/27 02:09ID:qEEWZV21
DDoS食らってる状態になるんだよ みんなリロードしまくるでしょ
696root ★
04/07/27 02:47ID:??? 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
結局、以下を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
ちょと確認させて頂きたいのですが、
ﾒﾆｭｰの中身があるｻｰﾊﾞは、
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種類ということで良いでしょうか?
ﾒﾆｭｰの中身があるｻｰﾊﾞは、
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種類ということで良いでしょうか?
698root ★
04/07/27 19:15ID:??? >>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
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
>>698
了解です、ありがとうございます。
了解です、ありがとうございます。
700root ★
04/07/27 22:53ID:??? 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
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
701root ★
04/07/27 22:59ID:??? c-others1、調整中。
703root ★
04/07/27 23:09ID:??? とりあえずdone.
しばらくチェック。
しばらくチェック。
704root ★
04/07/27 23:23ID:??? LAそのものはそれほどでもなく、入り口で詰まっているようなので、
様子をみながらhttpdの数を増やしてみた。< 各c-xxxx
様子をみながらhttpdの数を増やしてみた。< 各c-xxxx
705root ★
04/07/27 23:33ID:??? 臨時にアクセラレータをはずしてみる。もたないか、もつのか。< c-docomo2
706root ★
04/07/27 23:35ID:??? ん、アクセスが多いときは、苦しい模様。< c-docomo2
アクセラレータ(キャッシュ)を入れるとamd64ではやや不安定。
アクセラレータをはずすととてももたないのか。
アクセラレータ(キャッシュ)を入れるとamd64ではやや不安定。
アクセラレータをはずすととてももたないのか。
707root ★
04/07/27 23:40ID:??? c-docomo2、ほとんど瀕死かも。
c-docomo系が死んだら、c-au系やc-others系のhttpdが捌けるようになった。
blackgoatのI/O処理が滞っていたのか。
c-docomo系が死んだら、c-au系やc-others系のhttpdが捌けるようになった。
blackgoatのI/O処理が滞っていたのか。
root ★さん、
参考までに、docomo2でのｽｸﾘﾌﾟﾄの各ﾎﾟｲﾝﾄ毎の単純な処理時間です。
総処理 = 0.50580286979675
├初期化 = 0.0017189979553223
├ｽﾚｯﾄﾞ表示 = 0.50293588638306
｜ ├ｿｹｯﾄ接続〜切断 = 0.5008430480957
｜ └上記以外の処理 = 0.0020928382873535
└上記以外の処理 = 0.001147985458374
参考までに、docomo2でのｽｸﾘﾌﾟﾄの各ﾎﾟｲﾝﾄ毎の単純な処理時間です。
総処理 = 0.50580286979675
├初期化 = 0.0017189979553223
├ｽﾚｯﾄﾞ表示 = 0.50293588638306
｜ ├ｿｹｯﾄ接続〜切断 = 0.5008430480957
｜ └上記以外の処理 = 0.0020928382873535
└上記以外の処理 = 0.001147985458374
711root ★
04/07/27 23:50ID:??? BlackGoatへのｿｹｯﾄ接続〜切断までの間では、
"ﾚｽ番1と指定のﾚｽ10個分を配列に格納する"という以外の処理は行っていないのですが、
最新10ｽﾚｯﾄﾞなどの表示では最後まで読み切らないといけないので時間がかかりますね…
"ﾚｽ番1と指定のﾚｽ10個分を配列に格納する"という以外の処理は行っていないのですが、
最新10ｽﾚｯﾄﾞなどの表示では最後まで読み切らないといけないので時間がかかりますね…
713root ★
04/07/27 23:53ID:??? これからリブート依頼します。< c-docomo2
714root ★
04/07/28 00:00ID:??? >>712
そうですね。
blackgoatのディスクはストライピングにして、
かつnewfs -b 65536 -f 8192などとやってあるのですが、
そろそろI/O性能が苦しい状況なのかも。
今比較のために、一時的にaufsに戻してみた。
＊感覚では＊、diskdのほうが遅いような気がします。
統計的にも「漏れる」量が多いみたい。< blackgoat
そうですね。
blackgoatのディスクはストライピングにして、
かつnewfs -b 65536 -f 8192などとやってあるのですが、
そろそろI/O性能が苦しい状況なのかも。
今比較のために、一時的にaufsに戻してみた。
＊感覚では＊、diskdのほうが遅いような気がします。
統計的にも「漏れる」量が多いみたい。< blackgoat
04/07/28 00:02ID:hrKUFbXp
717root ★
04/07/28 00:26ID:??? cache_dir diskd /usr/local/squid/cache 100000 16 256
を、
cache_dir diskd /usr/local/squid/cache 100000 64 256
にして、squid -zの後にdiskdモードを復活させてみた。
を、
cache_dir diskd /usr/local/squid/cache 100000 64 256
にして、squid -zの後にdiskdモードを復活させてみた。
719root ★
04/07/28 00:48ID:??? cobra2247にログインできました。リブートして、調整中。
720root ★
04/07/28 00:48ID:??? cobra2247 = c-docomo/c-docomo2
721root ★
04/07/28 00:53ID:??? 設定更新&リブートかけました。正常にもどったはず。
722root ★
04/07/28 01:31ID:??? こんどは、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
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
04/07/28 01:49ID:hrKUFbXp
bbs.cgiで、逆順のdatも作るようにし、c.2ch.netやread.cgiの初期読み込みではそちらを
使うようにするとか。
キャッシュヒット率が下がって逆効果かな？
使うようにするとか。
キャッシュヒット率が下がって逆効果かな？
今ちょと新しいｽｸﾘﾌﾟﾄをあげてﾃｽﾄしているのですが、
先程の重い時間帯で3秒設定だとまずﾀｲﾑｱｳﾄです。
5秒でもほとんどﾀｲﾑｱｳﾄ状態でした。
先程の重い時間帯で3秒設定だとまずﾀｲﾑｱｳﾄです。
5秒でもほとんどﾀｲﾑｱｳﾄ状態でした。
ﾀｲﾑｱｳﾄで
「今BlackGoatが思いです｡｡｡」とか表示すれば、
ﾘﾛｰﾄﾞ抑制にもなるかもですね、、、
5秒超にはしたくない感じです。
「今BlackGoatが思いです｡｡｡」とか表示すれば、
ﾘﾛｰﾄﾞ抑制にもなるかもですね、、、
5秒超にはしたくない感じです。
04/07/28 03:00ID:PGPY8Pdd
大規模squidのボトルネックはHDD回りなので、できればcache_dir用にスライスを確保したほうがいいかも。
noatimeは当然として。
asyncでもいいかも。
容量があんまり小さいスライスだとoptimize TIME to SPACEを食らうので4倍以上で。
あと外周部分にあるとうれしいので/の次に確保してたり。
noatimeは当然として。
asyncでもいいかも。
容量があんまり小さいスライスだとoptimize TIME to SPACEを食らうので4倍以上で。
あと外周部分にあるとうれしいので/の次に確保してたり。
730root ★
04/07/28 04:43ID:??? >>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)。
いまこんなかんじ。
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)。
731▲:/usr/local/bin/ch2 -o i686 ◆P8fXJj6wwo
04/07/28 12:42ID:VdCldNq8 途中割り込みでスマソです。
>>730
IDEのストライピングだとつらそうですね。
かといってUltraSCSI320のそれにしようとすると余計な投資になるし・・・
blackgoat自体がキャッシュサーバですから
RAMディスクで捌くってのは・・・すでにやっているんですかね。
>>730
IDEのストライピングだとつらそうですね。
かといってUltraSCSI320のそれにしようとすると余計な投資になるし・・・
blackgoat自体がキャッシュサーバですから
RAMディスクで捌くってのは・・・すでにやっているんですかね。
732root ★
04/07/28 13:22ID:???733▲:/usr/local/bin/ch2 -o i686 ◆P8fXJj6wwo
04/07/28 15:12ID:VdCldNq8 >>732
その400MBプロセスなsquidってどこのやつですか。
その400MBプロセスなsquidってどこのやつですか。
734▲:/usr/local/bin/ch2 -o i686 ◆P8fXJj6wwo
04/07/28 15:18ID:VdCldNq8735▲:/usr/local/bin/ch2 -o i686 ◆P8fXJj6wwo
04/07/28 15:24ID:VdCldNq8 ちょっと考察。
携帯からのある意味実況レベルに近い通信要求を
バックエンドを１台で捌くというのはかなりきついと思います。
しかもblackgortが落ちたら携帯からのアクセスは不可能。
投資ができるなら、の話ですが、
もう１台バックエンドを用意して負荷分散させたほうがいいかもしれません。
どちらかのバックエンドが落ちたときにバックアップさせるという意味合いもあるし。
携帯からのある意味実況レベルに近い通信要求を
バックエンドを１台で捌くというのはかなりきついと思います。
しかもblackgortが落ちたら携帯からのアクセスは不可能。
投資ができるなら、の話ですが、
もう１台バックエンドを用意して負荷分散させたほうがいいかもしれません。
どちらかのバックエンドが落ちたときにバックアップさせるという意味合いもあるし。
736FOX ★
04/07/28 15:37ID:??? 1) フロントエンドを充実させて需要に見合う供給をおこなった。
2) 当然、BlackGoatは大忙し、
3) この大忙しを解決する方法は当初の予定通り、BlackGoatの仕組みで行う
というように順調に予定通り進んでいるということですなぁ。
せっかく作り出した重い状態。せっせとデータを取らなければ、、、
BlackGoat の各種データをとって、思考実験(机上演習)です。
帯域等は現在取っているので、アクセス数やそのへんも何とか
データが取れないかな? とい段階かと、
BlackGoat を増設するのは考えないで行きます。
だってすぐ解決しちゃうもん。
2) 当然、BlackGoatは大忙し、
3) この大忙しを解決する方法は当初の予定通り、BlackGoatの仕組みで行う
というように順調に予定通り進んでいるということですなぁ。
せっかく作り出した重い状態。せっせとデータを取らなければ、、、
BlackGoat の各種データをとって、思考実験(机上演習)です。
帯域等は現在取っているので、アクセス数やそのへんも何とか
データが取れないかな? とい段階かと、
BlackGoat を増設するのは考えないで行きます。
だってすぐ解決しちゃうもん。
737未承諾広告※ ◆TWARamEjuA
04/07/28 15:47ID:KybxMNb+ >>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 採取のコストが幾分か下がるのではないかと。。。
負荷分散しても片方が墜ちると共倒れになる悪寒ですよね。。。＠基本的に片肺でも生きていかないと・・
ちょっと考察。
最新 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 採取のコストが幾分か下がるのではないかと。。。
738未承諾広告※ ◆TWARamEjuA
04/07/28 15:55ID:KybxMNb+ もしかして、分割して取得するとキャッシングがうまく効くのかな？
例えば。。。
活きのいい DAT があっても、全取得となるとキャッシュが効かないはず。
でも、例えば先頭から 4KB は活きが良くても悪くても、内容はあぼーんが入らない限り変わらないはずなので、
この部分は ETag: を使って照合すれば、うまくキャッシングされているのではないだろうか？と。
ただし、ETag の管理をするために、また複雑な操作が必要になってくるかもかも。。。
（殊に呼び出し側の c-* 族の I/O 処理とかとか）
例えば。。。
活きのいい DAT があっても、全取得となるとキャッシュが効かないはず。
でも、例えば先頭から 4KB は活きが良くても悪くても、内容はあぼーんが入らない限り変わらないはずなので、
この部分は ETag: を使って照合すれば、うまくキャッシングされているのではないだろうか？と。
ただし、ETag の管理をするために、また複雑な操作が必要になってくるかもかも。。。
（殊に呼び出し側の c-* 族の I/O 処理とかとか）
739root ★
04/07/28 15:56ID:???740FOX ★
04/07/28 16:18ID:??? そこで、BlackGoat に疑惑が集まっているのですが、
この辺が明らかになればいいなぁ。。。
1) 観測された c.2ch.net に起こった現象 (docomoが重いとか、)
2) 推測される原因 (BlackGoatの反応が遅すぎ)
3) BlackGoat に起っているであろう現象、具体的な症状の推測 (LA の増大とか)
4) 実際にその具体的な症状がせ起っているか、
5) 起っているなら、解決策は?
ここで重要なのは、 3) -> 4) の関係です。
3) で推測して、実際に 4) で現象が起っているかどうかの確認。
確認手段が無い場合は、手段を作る。逆に、こうすれば解決するのでは?
という作業は間違っても行ってはいけない。
この辺が明らかになればいいなぁ。。。
1) 観測された c.2ch.net に起こった現象 (docomoが重いとか、)
2) 推測される原因 (BlackGoatの反応が遅すぎ)
3) BlackGoat に起っているであろう現象、具体的な症状の推測 (LA の増大とか)
4) 実際にその具体的な症状がせ起っているか、
5) 起っているなら、解決策は?
ここで重要なのは、 3) -> 4) の関係です。
3) で推測して、実際に 4) で現象が起っているかどうかの確認。
確認手段が無い場合は、手段を作る。逆に、こうすれば解決するのでは?
という作業は間違っても行ってはいけない。
742root ★
04/07/28 16:21ID:??? >>740
で、いまのところ起こっているのは、ディスクI/O負荷の増大なわけです。
あとは、苦しい時間(昼とか夜23:00ごろとか)に、キャッシュの効きが悪くなる。
いずれにせよ、観察・確認できる手段をなんとかする方向で動いてみます。
とりあえずsnmpあたりでつついてみるか。
で、いまのところ起こっているのは、ディスクI/O負荷の増大なわけです。
あとは、苦しい時間(昼とか夜23:00ごろとか)に、キャッシュの効きが悪くなる。
いずれにせよ、観察・確認できる手段をなんとかする方向で動いてみます。
とりあえずsnmpあたりでつついてみるか。
743FOX ★
04/07/28 16:25ID:??? >ディスクI/O負荷の増大なわけです
という推測があった場合、
じゃ具体的に、定量的に BlackGoat でどういう数字がでているかを推測して
かつ実際に計測して、どうなっているか、、
もし推測と実測値が極めて一致したならば
最初の命題「ディスクI/O負荷の増大なわけです」
という推測がかなりピンポンであるといえるかと、
もし他にもこの図式がなりたてば、ほぼ確実といえるかと、
という推測があった場合、
じゃ具体的に、定量的に BlackGoat でどういう数字がでているかを推測して
かつ実際に計測して、どうなっているか、、
もし推測と実測値が極めて一致したならば
最初の命題「ディスクI/O負荷の増大なわけです」
という推測がかなりピンポンであるといえるかと、
もし他にもこの図式がなりたてば、ほぼ確実といえるかと、
744未承諾広告※ ◆TWARamEjuA
04/07/28 16:26ID:KybxMNb+745▲:/usr/local/bin/ch2 -o i686 ◆P8fXJj6wwo
04/07/28 17:19ID:VdCldNq804/07/28 19:05ID:PGPY8Pdd
747root ★
04/07/28 20:07ID:??? 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以外の仕事はしていない。
>>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以外の仕事はしていない。
748root ★
04/07/29 01:07ID:??? うすうすわかってはいたけど、深夜の時間(混む時間)は、
リクエスト数はあまり変わらないのに、キャッシュヒット率が下がる。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/blackgoat-hits.html
で、datをひんぱんに外に取りに行くので処理に時間がかかるし、
その分携帯とのコネクションも滞留する。
この原因は何だろう。
夜の時間は「いろんなところのスレが参照される」から、キャッシュにない場合が増える、
ということなのかな。
で、リクエスト数自体がその時間もあまり変わらないのは、
ひょっとすると携帯ネット=>インターネットの間で、何かのリミッターが入っているのかも、かも。
リクエスト数はあまり変わらないのに、キャッシュヒット率が下がる。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/blackgoat-hits.html
で、datをひんぱんに外に取りに行くので処理に時間がかかるし、
その分携帯とのコネクションも滞留する。
この原因は何だろう。
夜の時間は「いろんなところのスレが参照される」から、キャッシュにない場合が増える、
ということなのかな。
で、リクエスト数自体がその時間もあまり変わらないのは、
ひょっとすると携帯ネット=>インターネットの間で、何かのリミッターが入っているのかも、かも。
749root ★
04/07/29 01:27ID:??? 突然軽くなったかも。
750root ★
04/07/29 01:28ID:??? で、またすぐに重くなった。
751root ★
04/07/29 01:29ID:??? パケット落ちはないから、ネットワークまわりやスイッチ関係じゃなさそうだなぁ。
--- 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
--- 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
752root ★
04/07/29 01:32ID:??? う、激しく誤爆した。
OpenJaneを立ち上げなおそう。すまそ。
OpenJaneを立ち上げなおそう。すまそ。
04/07/29 05:53ID:DcqIsASS
memory_pools はoffのほうが良いです。
BSD Magazineのシステムチューニングの回参照
BSD Magazineのシステムチューニングの回参照
754root ★
04/07/29 11:07ID:??? >>753
これですか。読んでみます。
http://www.ascii.co.jp/BSDmag/200214/contents.html
http://www.ascii.co.jp/BSDmag/200214/
FreeBSDではmemory_pools offにしたほうがいいというのは、
Googleに聞くと結構あるみたい。
これですか。読んでみます。
http://www.ascii.co.jp/BSDmag/200214/contents.html
http://www.ascii.co.jp/BSDmag/200214/
FreeBSDではmemory_pools offにしたほうがいいというのは、
Googleに聞くと結構あるみたい。
755root ★
04/07/29 11:08ID:??? memory_pools off にしました。
756root ★
04/07/29 11:55ID:??? こちらにも。
携帯→2ch運用情報スレッド10
http://qb5.2ch.net/test/read.cgi/operate/1089186698/639
639 名前：root ★[sage] 投稿日：04/07/29 11:46 ID:???
キャッシュ効果の観察のため、いったんblackgoatのキャッシュをゼロクリアしました。
その影響で数分間、c系が不安定になったかも。
今は正常に戻ったはず。
携帯→2ch運用情報スレッド10
http://qb5.2ch.net/test/read.cgi/operate/1089186698/639
639 名前：root ★[sage] 投稿日：04/07/29 11:46 ID:???
キャッシュ効果の観察のため、いったんblackgoatのキャッシュをゼロクリアしました。
その影響で数分間、c系が不安定になったかも。
今は正常に戻ったはず。
757root ★
04/07/29 12:41ID:??? >>755 にすると、
2004/07/28 20:38:59| assertion failed: comm.c:751: "p != NULL"
というエラーが出て、squidが死ぬ模様。
後で調べることにして、いったん退却(memory_pools onに戻しました)。
2004/07/28 20:38:59| assertion failed: comm.c:751: "p != NULL"
というエラーが出て、squidが死ぬ模様。
後で調べることにして、いったん退却(memory_pools onに戻しました)。
758未承諾広告※ ◆TWARamEjuA
04/07/29 12:59ID:ct6lg4mV >>757
8. Key changes squid-2.5.STABLE5 to 2.5.STABLE6:
* Several "Assertion error" bugs fixed
これの関係かしらん？
8. Key changes squid-2.5.STABLE5 to 2.5.STABLE6:
* Several "Assertion error" bugs fixed
これの関係かしらん？
759root ★
04/07/29 13:25ID:??? >>758
今のもの:
2004/07/28 20:41:01| Starting Squid Cache version 2.5.STABLE5 for i386-portbld-freebsd5.2.1...
…つまり、STABLE6にしろと。
今のもの:
2004/07/28 20:41:01| Starting Squid Cache version 2.5.STABLE5 for i386-portbld-freebsd5.2.1...
…つまり、STABLE6にしろと。
760root ★
04/07/29 13:53ID:??? STABLE6に更新して、再度挑戦中、、、。
761root ★
04/07/29 13:55ID:??? だめですね。やはり出ます。
2004/07/28 21:54:12| assertion failed: comm.c:751: "p != NULL"
もとに戻しました。
2004/07/28 21:54:12| assertion failed: comm.c:751: "p != NULL"
もとに戻しました。
762未承諾広告※ ◆TWARamEjuA
04/07/29 13:56ID:ct6lg4mV >>759
http://www.squid-cache.org/bugs/show_bug.cgi?id=761
こちらを判らないながらも眺めてみたのですが、違う種のアサーションエラーみたいですね。
でもって、最新の ports が存在するのかな？（＠まだ ports の仕組みが判ってなかったりもしますけれども（苦笑）
・・・と書いているうちに、、、
>>760
おつですおつですm(_ _)m
http://www.squid-cache.org/bugs/show_bug.cgi?id=761
こちらを判らないながらも眺めてみたのですが、違う種のアサーションエラーみたいですね。
でもって、最新の ports が存在するのかな？（＠まだ ports の仕組みが判ってなかったりもしますけれども（苦笑）
・・・と書いているうちに、、、
>>760
おつですおつですm(_ _)m
763未承諾広告※ ◆TWARamEjuA
04/07/29 14:24ID:ct6lg4mV764FOX ★
04/07/29 15:59ID:??? この一時間のcomic6の様子ですが、、、
comic6.2ch.net サーバ
.dat 呼び出し回数 = 59632
deny from 206.223.150.190 #(7465) 12.52%
BlackGoat からこんなにたくさん。。。
これで正常なのか、異常なのか、
comic6.2ch.net サーバ
.dat 呼び出し回数 = 59632
deny from 206.223.150.190 #(7465) 12.52%
BlackGoat からこんなにたくさん。。。
これで正常なのか、異常なのか、
767▲:/usr/local/bin/ch2 -o i686 ◆P8fXJj6wwo
04/07/29 17:18ID:5ivMrPxN >>763
投げるべきでしょう。結果は期待できないですがね。
投げるべきでしょう。結果は期待できないですがね。
「やるべき事」と本質がずれてしまいますが(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 が起こってるんでしょうなぁ。
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 が起こってるんでしょうなぁ。
04/07/29 21:09ID:DcqIsASS
んーそこで落っこちるということはsquid.confで矛盾した設定をしているような気が。
771root ★
04/07/29 23:22ID:??? 【.htaccess】読みこみできない【規制作戦】
http://qb5.2ch.net/test/read.cgi/operate/1082968554/868 でポイントした、
http://pc5.2ch.net/test/read.cgi/linux/997328024/182-189 にあった、
> reload-into-imsはno-cacheとreloadの命令をIf-Modified-Sinceの
> リクエストに変えてしまうもの。つまり無いのに、あるかのように装って差分だけ
> 送れと言うわけなのれす。
を読んで、reload-into-ims も追加設定してみた。< blackgoat
http://qb5.2ch.net/test/read.cgi/operate/1082968554/868 でポイントした、
http://pc5.2ch.net/test/read.cgi/linux/997328024/182-189 にあった、
> reload-into-imsはno-cacheとreloadの命令をIf-Modified-Sinceの
> リクエストに変えてしまうもの。つまり無いのに、あるかのように装って差分だけ
> 送れと言うわけなのれす。
を読んで、reload-into-ims も追加設定してみた。< blackgoat
772root ★
04/07/30 01:32ID:??? 明らかに軽くなった気がして、かつパフォーマンスも前日より出ているので、
今日squidに施したセッティング変更は総合的にはいい方向だったとおもわれ。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/
今日squidに施したセッティング変更は総合的にはいい方向だったとおもわれ。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/
04/07/30 05:42ID:IPwBzIoJ
http://qb5.2ch.net/test/read.cgi/operate/1082968554/866-868
refresh_patternのminの値は最終更新日時があると参照されない
＞FRESH if lm-factor < percent, else STALE
ここでSTALE(古い)と判断されたときoverride-lastmodが有効だと
＞FRESH if age < min
＞else STALE
これがテストされる(minの値が参照される)
ということか。
つまり、今まで120delayはまったく効いてなかったということだな。
refresh_patternのminの値は最終更新日時があると参照されない
＞FRESH if lm-factor < percent, else STALE
ここでSTALE(古い)と判断されたときoverride-lastmodが有効だと
＞FRESH if age < min
＞else STALE
これがテストされる(minの値が参照される)
ということか。
つまり、今まで120delayはまったく効いてなかったということだな。
04/07/30 14:20ID:VTaak0RI
DATをかっさらう悪用で.htaccessで携帯メニューをダウンさせる不届きものが…。
（パクリトロスの2ちゃんねるアーカイブとか言う香具師）
対策しないと、c.2chに円滑に移行出来た所で本末転倒では…。
（パクリトロスの2ちゃんねるアーカイブとか言う香具師）
対策しないと、c.2chに円滑に移行出来た所で本末転倒では…。
ただいま帰宅しました。
とりあえず、i.i2ch.netの方は再開しました。
さてこのあとどうしましょうか？ ＞ ひろゆきさん、FOX★さん、root★さん
（１） 現状のまま219.113.242.218から直接差分を取る。
（２） GlackGoatを通して差分を取る。
（３） GlackGoatを通して差分せずに取る。
（４） 私家版GlackGoatを作るって、そっちで（２）か（３）
他の私家板（domo2.netなど）にも、開放できるように（４）というのもありなんじゃないかと思ったりして、、、
とりあえず、i.i2ch.netの方は再開しました。
さてこのあとどうしましょうか？ ＞ ひろゆきさん、FOX★さん、root★さん
（１） 現状のまま219.113.242.218から直接差分を取る。
（２） GlackGoatを通して差分を取る。
（３） GlackGoatを通して差分せずに取る。
（４） 私家版GlackGoatを作るって、そっちで（２）か（３）
他の私家板（domo2.netなど）にも、開放できるように（４）というのもありなんじゃないかと思ったりして、、、
777▲:/usr/local/bin/ch2 -o i686 ◆P8fXJj6wwo
04/07/31 12:33ID:rBi2iqvk >>777
間違えてた orz
間違えてた orz
04/07/31 14:04ID:S91iSbrB
BlackGoatが落ちたりしたら、私家版全てが使えなくなるってのモナー。
今回のはミラーでディレイ０秒になってたからでそ。
ディレイ６０秒くらいにしてやれば、問題ないのでわ？
今回のはミラーでディレイ０秒になってたからでそ。
ディレイ６０秒くらいにしてやれば、問題ないのでわ？
04/08/01 00:34ID:/iIoW5ht
ディレィ調節は本当に意義があるのか？
04/08/01 10:01ID:UbFDq+9x
２ちゃん側にとってはありまくり
04/08/01 10:48ID:CAXZIMEU
実況で重婚
783782
04/08/01 10:54ID:CAXZIMEU 実況でディレイで新着が見られない
↓
新着と同じレスしてしまう
↓
重婚発生
↓
鯖資源の無駄
↓
新着と同じレスしてしまう
↓
重婚発生
↓
鯖資源の無駄
04/08/01 12:11ID:/iIoW5ht
ディレイ調節は、不便だけで、あまり絶対的な効果はないような？？？
04/08/01 13:27ID:Cn1/hsFL
04/08/01 15:10ID:/iIoW5ht
有効ではなく絶対的な効果があるのか？と聞いているのですが…。
単純な個人ユーザーにとって、２分間のディレイは大変な不便を感じています。
単純な個人ユーザーにとって、２分間のディレイは大変な不便を感じています。
04/08/01 15:27ID:CAXZIMEU
>>783と同様の事になる。
あと、実況以外でも”からけよめ”と煽られる。
あと、実況以外でも”からけよめ”と煽られる。
789マァヴ ◆jxAYUMI09s ＠マァヴ ★
04/08/01 17:57ID:??? 絶対的な効果ありまくりです(^_^;)２ｃｈの掲示板サーバの負荷が二桁くらい下がる
04/08/01 20:28ID:iPnO9Kpv
>>787
不満でしたらマシン代を寄付してやって下ちい
不満でしたらマシン代を寄付してやって下ちい
>>root ★さん、
質問なのですが、
現在c.2ch.netにｱｸｾｽすると、各ｷｬﾘｱごとに振り分けられたｻｰﾊﾞにﾘﾀﾞｲﾚｸﾄされます。
DoCoMoなら、c-docomo。(http://c-docomo.2ch.net/z/-/1C/i)
auなら、c-au。(http://c-au.2ch.net/z/-/1C/i)
その他は、c-others。(http://c-others.2ch.net/z/-/1C/i)
1)
このﾄﾞﾒｲﾝ部分をc.2ch.netで見せることは可能なのでしょうか?
つまり、実際はc-docomo2やc-docomo3に振り分けられていても、
ｱﾄﾞﾚｽ上はc-docomoであるのと同じように見せることは可能でしょうか?
2)
例えば他ｷｬﾘｱがそのｱﾄﾞﾚｽにｱｸｾｽしたときに、
そのｷｬﾘｱ用のｻｰﾊﾞにﾘﾀﾞｲﾚｸﾄすることは可能でしょうか?
つまり、auで(http://c-docomo.2ch.net/z/-/1C/i)にｱｸｾｽした場合、
(http://c-au.2ch.net/z/-/1C/i)にﾘﾀﾞｲﾚｸﾄすることは可能でしょうか?
3)
もし上記どちらかが可能な場合、それを行う上で何か不都合なことは発生しますでしょうか?
質問なのですが、
現在c.2ch.netにｱｸｾｽすると、各ｷｬﾘｱごとに振り分けられたｻｰﾊﾞにﾘﾀﾞｲﾚｸﾄされます。
DoCoMoなら、c-docomo。(http://c-docomo.2ch.net/z/-/1C/i)
auなら、c-au。(http://c-au.2ch.net/z/-/1C/i)
その他は、c-others。(http://c-others.2ch.net/z/-/1C/i)
1)
このﾄﾞﾒｲﾝ部分をc.2ch.netで見せることは可能なのでしょうか?
つまり、実際はc-docomo2やc-docomo3に振り分けられていても、
ｱﾄﾞﾚｽ上はc-docomoであるのと同じように見せることは可能でしょうか?
2)
例えば他ｷｬﾘｱがそのｱﾄﾞﾚｽにｱｸｾｽしたときに、
そのｷｬﾘｱ用のｻｰﾊﾞにﾘﾀﾞｲﾚｸﾄすることは可能でしょうか?
つまり、auで(http://c-docomo.2ch.net/z/-/1C/i)にｱｸｾｽした場合、
(http://c-au.2ch.net/z/-/1C/i)にﾘﾀﾞｲﾚｸﾄすることは可能でしょうか?
3)
もし上記どちらかが可能な場合、それを行う上で何か不都合なことは発生しますでしょうか?
04/08/01 23:44ID:65dDfZRJ
ここも夏色気分の香具師が多くなってきましたね
04/08/02 12:51ID:rZ9hEif8
5分遅延すれば実況とかチャットとかは機能停止させられるような
■ このスレッドは過去ログ倉庫に格納されています
