【Love Affair】携帯からのアクセスに対する考察・次の一手 Part4
■ このスレッドは過去ログ倉庫に格納されています
日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。
たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、
Love Affair 作戦。
Part4 (タイトル)募集中
前スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/operate/kako/1075/10758/1075887465.html
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
http://qb5.2ch.net/test/read.cgi/operate/1088657713/
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part3
http://qb5.2ch.net/test/read.cgi/operate/1095146311/
Wikiページ http://info.2ch.net/wiki/pukiwiki.php?Love%20Affair 現状:
電車男の収入により、携帯システムの大幅強化が決定。
サーバ設置のための専用のロケーションが用意され、
全ポート1G対応の高性能スイッチ、tiny tiger (tigerのIDEディスクもの)の大量投入が決まった。
現在第一弾のtiny tiger6台が投入され、au/DoCoMoのフロントエンドに配置。
特に重かったau系の過負荷が解消された。
今後は●で購入したサーバとの分離、外向けdat公開サーバ(白山羊さん)の導入等を、
たんたんとすすめていく予定である。 アクセラレータをAPCからeaccleratorにしてからというもの、
うそみたいに安定してるですね。< c-au/c-docomo
当分、これでいってみようかと。 >>4
おぉ。
MRTG対応するです。
ベンチすると1周どころか、2周回ってしまう。
すぐできると思うので、ちと、まってくださいです。 ええと、どうもすぐにはCounter64、サポートできないっぽいです。
まじでか。
【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part18
http://qb5.2ch.net/test/read.cgi/operate/1115133136/601
代案を考えなきゃ。 ということで、BG3で負荷試験中。
わかってきたことを、だらだらと。 %uptime
7:31AM up 1 day, 12:26, 1 user, load averages: 1.46, 1.65, 1.80
LAはずっとこんなかんじ。こんなところか。
I/Oまわりがついていけてないっぽいかんじ。
裏づけとしては、キャッシュヒット率の低下がある。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/
いつもの日曜の「急激に上がる時間」に符合して、キャッシュヒット率が下がり、
漏れ出すものが多くなっている。 disk I/Oはこんなかんじ。
%iostat 1
tty da0 da1 pass0 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
0 2 25.71 43 1.07 22.59 47 1.04 0.00 0 0.00 7 0 12 5 76
0 229 31.17 267 8.12 31.12 270 8.20 0.00 0 0.00 11 0 15 8 66
0 76 23.57 92 2.12 19.51 106 2.02 0.00 0 0.00 15 0 18 10 57
0 76 23.25 148 3.37 22.34 144 3.13 0.00 0 0.00 14 0 17 9 61
0 76 25.10 137 3.35 21.01 156 3.21 0.00 0 0.00 16 0 19 9 55
0 76 23.36 112 2.55 22.62 115 2.54 0.00 0 0.00 14 0 19 9 58
0 76 24.89 125 3.03 24.38 126 2.99 0.00 0 0.00 16 0 15 12 56
0 76 24.85 149 3.60 22.33 161 3.52 0.00 0 0.00 14 0 19 10 57
0 76 24.14 114 2.68 20.56 127 2.55 0.00 0 0.00 15 0 17 11 58
0 76 24.10 79 1.86 22.51 90 1.98 0.00 0 0.00 15 0 19 9 57
^C paging / swapping は、起こっていないようだ。
top すると、こんなかんじ。
CPUはまだ半分ぐらいidleしている。
last pid: 13107; load averages: 1.74, 1.80, 1.82 up 1+12:33:19 07:38:15
122 processes: 2 running, 120 sleeping
CPU states: 15.4% user, 0.0% nice, 17.6% system, 10.0% interrupt, 57.0% idle
Mem: 345M Active, 1369M Inact, 201M Wired, 68M Cache, 112M Buf, 19M Free
Swap: 2048M Total, 120K Used, 2048M Free
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
615 squid 20 0 285M 282M kserel 3 27.2H 26.03% 26.03% squid top -Sはこんなかんじ。
ネットワークの割り込み処理(swi1)や、
em1 em0の割り込み負荷もあるが、まだ大丈夫っぽい。
ahd1やahd0 (SCSI Ctrler)もしかり。
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
11 root 107 0 0K 12K RUN 3 30.6H 66.02% 66.02% idle: cpu3
12 root 107 0 0K 12K RUN 2 29.4H 61.77% 61.77% idle: cpu2
13 root 105 0 0K 12K RUN 1 26.8H 51.22% 51.22% idle: cpu1
14 root 104 0 0K 12K RUN 0 24.6H 46.44% 46.44% idle: cpu0
615 squid 20 0 285M 282M kserel 1 27.2H 26.81% 26.81% squid
134 root -44 -163 0K 12K WAIT 2 249:35 21.63% 21.63% swi1: net
42 root -68 -187 0K 12K RUN 2 117:44 8.25% 8.25% irq29: em1
41 root -68 -187 0K 12K RUN 2 25:31 3.86% 3.86% irq28: em0
4 root -8 0 0K 12K - 2 11:44 0.68% 0.68% g_down
137 root 76 0 0K 12K - 3 12:14 0.05% 0.05% yarrow
3 root -8 0 0K 12K - 1 6:16 0.05% 0.05% g_up
135 root -28 -147 0K 12K WAIT 1 8:44 0.00% 0.00% swi5: clock sio
155 root 20 0 0K 12K syncer 3 6:53 0.00% 0.00% syncer
140 root -36 -155 0K 12K WAIT 0 4:10 0.00% 0.00% swi3: cambio
90 root -64 -183 0K 12K WAIT 0 2:13 0.00% 0.00% irq77: ahd1
89 root -64 -183 0K 12K WAIT 0 1:58 0.00% 0.00% irq76: ahd0
153 root 171 52 0K 12K pgzero 0 1:23 0.00% 0.00% pagezero # maximum_object_size_in_memory 8 KB
maximum_object_size_in_memory 1024 KB
は、上記のように大きくしてあるが、もっと大きくできるかもしれない。 systat -v
Disks da0 da1 pass0 pass1
KB/t 26.68 25.47 0.00 0.00
tps 172 175 0 0
MB/s 4.48 4.34 0.00 0.00
% busy 43 44 0 0
% busy はまだ4割ぐらい(それでも多いけど)か。 >>15 は1オブジェクトの大きさだから、 1MBytes で十分ですね。
(datとsuject.txtだから) memory_poolsは、今off。
onにしてトライする意味は、あるかもしれない。
# memory_pools on
memory_pools off ということで、いったん >>18 やるです。
これから squid をリスタート。 store を rebuild 中。
2005/05/29 07:57:32| Store rebuilding is 9.7% complete
2005/05/29 07:57:49| Store rebuilding is 10.8% complete
2005/05/29 07:58:05| Store rebuilding is 11.8% complete
...
rebuild が終わったら、観察へと。 ちなみに memory_pools_limit は、未設定の状態。 各サーバとも、BlackGoatから「漏れて出た」分、転送量が増えちゃってますね。
やはり「何としても漏らさないようにする」必要があると。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/ rebuildはだいぶすすんだけど、もうしばらくかかる模様。
2005/05/29 08:16:34| Store rebuilding is 63.5% complete
2005/05/29 08:16:59| Store rebuilding is 64.6% complete
2005/05/29 08:17:23| Store rebuilding is 65.6% complete 今 store の rebuild おわた。
これから、観察。
とりあえず 1:00 まで。 2005/05/29 08:30:06| Beginning Validation Procedure
2005/05/29 08:31:17| 262144 Entries Validated so far.
2005/05/29 08:32:30| 524288 Entries Validated so far.
2005/05/29 08:32:54| Completed Validation Procedure
2005/05/29 08:32:54| Validated 601874 Entries
2005/05/29 08:32:54| store_swap_size = 25528592k
Validation もおわた。
本格観察開始。 さっきより、はるかにうまくHDDの性能を出せている気がする。
Disks da0 da1 pass0 pass1
KB/t 22.65 20.06 0.00 0.00
tps 283 287 0 0
MB/s 6.25 5.61 0.00 0.00
% busy 87 86 0 0 重い(待たされる)ことは、かわらないっすね。
あとは「どっちがよりましか」か。 一瞬軽くなったけど、また外からみた重さが重くなったですね。
HDD待ちかなぁ、やっぱ。 で、>>27 は実はかんちがいで、それだけ HDD を「使ってしまう」
状態らしい。
やはり巷間言われているように、memory_pools は off のほうがいいのか。
いずれにせよ、我慢してしばらくこのまま。 いまいちっすね。< memory_pools off
http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/
1:00にBG3の設定戻します。
それが終わったらここに書きますので、、BG3/BG4の配分を元に戻していただけますか。> できる方々 こうすけさんに戻していただきました。
ぼちぼち、今回わかったことをだらだらと。 ○ 今回(2005/5/29)のBG負荷試験でわかったことをだらだら
今のBG3/4は、現在のピーク値(約10,000access/min)の約1.7〜1.8倍ぐらい、
つまり17,000〜18,000access/minぐらいが、限界値らしい。
つまり、今の1.8倍のアクセスがフロントエンドから来ると、何かしないと早晩破綻する。
今の伸び率のグラフから推測すると、、、ざっくり言って、もって今年中か。
auががんがってるから(企業努力してるってことなので念のため)、ことによるともっと早いかも。
限界値ではI/Oが限界に達するらしい。
ただ、HDDのアクセスはまだハードウェアの限界ぎりぎりではなく、50%程度らしい。
つまり、squidをもっとチューニングするとか、1台で2つ動かすとかすれば、
もっとHDDの性能を使える可能性がある。
CPU資源は、まだ使い切られていなかった
squid の memory_pools の設定は、off (squidではなくFreeBSDにまかせる)のほうが
効率よく動くらしい。 HDDのI/O性能からすると、今の1.7倍のアクセスでI/O性能の50%強ぐらいだったから、
仮にsquidが理想のプログラムの動作をするようになったとすると、1.7倍の1.8倍ぐらいまでは
いける可能性があるということか。つまり、約3倍と。
ただ、ここまで性能をしぼり出すことはたぶんいろいろな理由によりできないから、
現在のシステムにおけるハードウェアの性能は、
めいっぱいまでがんがったとしても、やはり今の2倍とか2.5倍あたりまでかなと。 …といったところか。
とりあえず今すぐにBGが破綻するわけではなそう(ちょっとだけ時間に余裕がある)、
というのは、少しだけいい情報だったかも。 BG3 disk I/O (read)
http://mumumu.mu/mrtglog/2005/05/30/io/blackgoat3ior.html (*1)
同じく、(write)
http://mumumu.mu/mrtglog/2005/05/30/io/blackgoat3iow.html (*2)
1) たくさんの板のリクエストに答えなければいけなくなり、メモリのヒット率が悪くなり、
結果としてHDDを読む率がどばっと増えた。(*1)
それでもまだ、ラッシュが起こる20:00まではなんとかなってた。
2) ラッシュを迎えると、HDDのキャッシュヒット率も下がり、外のサーバにデータを思い切り
取りにいきはじめた。また、HDDにもしょっちゅう書き込む事態が発生した。(*2)
これにより、破綻状態になった。
squidは、
a) メモリキャッシュ => リクエスト元に内容返す
b) HDDキャッシュ => HDD読む => メモリキャッシュに置く => リクエスト元に内容返す
c) いずれもだめ => 外へとりにいく => HDDに書く => メモリにキャッシュする => リクエスト元に内容返す
という動作をするので、まず a) が1台になった時点でパンク状態になり、
ラッシュを迎えた時点で b) もパンクしたということか。 (妄想)
これなら、tiny tigerのフロントエンドそれぞれでメモリキャッシュモードだけののsquidを立ち上げて、
BlackGoatと多段にすれば、さらに1段得をするような気が、しないでもない。 あと、せっかくsquidなんだから、BG3とBG4を「兄弟｣にしてみるか。 あと、
# cache_mem 8 MB
cache_mem 80 MB
に現在変更してあるけど、
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
13755 squid 20 0 269M 265M kserel 1 446:13 0.29% 0.29% squid
だから、もっと増やす道もあるかも。 BG3 で、ためしに 256MB にしてみた。
# cache_mem 8 MB
#cache_mem 80 MB
cache_mem 256 MB しばらく動いてsquidが肥大していって、
FATAL: xcalloc: Unable to allocate 1 blocks of 4104 bytes!
と言って落ちました。
もうちょっと小さくするか。128MBあたりで。 # cache_mem 8 MB
#cache_mem 80 MB
cache_mem 128 MB
これで、しばらく観察。
BG4はとりあえずそのまま(比較のため)。 >>42
それほどかわらなそうなので、将来とか緊急時を考えると
キャッシュメモリを大きく与えたほうがよかろうということで、
BG4 もこれにした。
で、「親子実験」ができそうなので、
もうしばらくしたら、c-au系で実験しようかなと。 準備できました。実験開始します。
依頼は、c.2ch 不具合報告スレにて。 squid的設定内容:
1) c-au4 c-au5 c-au6 のsquidは、HDDにファイルをキャッシュしない(メモリキャッシュのみ)
2) c-au4 c-au5 c-au6 はお互いに sibling (兄弟姉妹)
3) blackgoat3 blackgoat4 を parent (親) ラウンドロビン設定
c-au4での設定例
1)
cache_dir null /dev/null
2)
cache_peer 192.168.0.162 sibling 8080 3130
cache_peer 192.168.0.163 sibling 8080 3130
3)
cache_peer 192.168.0.3 parent 8080 3130 round-robin
cache_peer 192.168.0.4 parent 8080 3130 round-robin 4) c-au4 c-au5 c-au6 のsquidは、とりあえず遅延なしに設定
refresh_pattern . 0 0% 60 override-lastmod reload-into-ims ICP (ひらたくいえば、squid同士がお話しするための部分)のアクセスコントロールを
あけていませんでした。
icp_access allow private
icp_access deny all
を、BG3/4とc-au4/5/6のsquidに追加し、再起動。 で、この際に、上記の親の部分の round-robin オプションがない状態になりました。
今、au4/5/6 とも、オプションがない状態。
まずはこれで実験してみて、あとで復活するかんじで。 で、never_direct を、c-au4/5/6系にいれておけば、だいじょうぶかな。
これも、あとで。 round_robin 復活させました。
never_direct allow all を c-au4/5/6 に入れました。
これで、BG3/4からとれない時に直接とりにいってしまう(さっきの状態)ことは、ないはず。 恥ずかしい統計情報(c-au4/5/6からだだ漏れ)を、手で消しました。
普段はこういうことはしないんですが、これが残っていると
今後の傾向がつかめないので、やむを得ず。ううむ。 こんなもんなのか？と思っていたが
感覚が麻痺していたのか＠だだ漏れ 帰宅後、失敗談を告白するです。
今は正常に動いているはず。
ローカルsquidの様子をとりはじめた。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/ squid がメモリを食っていくので、cache_mem を 32 MB まで減少。< c-au4/6
# c-au5 は、リブート要請へと。 さすがに 32 MB は少ないようなので(ヒット率減少)、
64 MB に戻した。 こんどは、FDを使い果たし。
「マイルド(前のc-au1 bananaと同じ)」を、tigerと同じに戻した。
kern.maxfiles=32768
kern.maxfilesperproc=16384
↓
kern.maxfiles=131072
kern.maxfilesperproc=65536 ＜今日のミス＞
1) 親・仲間に対し、ICPを許可していなかった
まぬけなことに、ICP (他のsquidサーバと、
キャッシュが存在するかどうか通信するためのプロトコル)を、
それぞれのサーバに対して許可していませんでした。
つまり、親子、兄弟との間での会話が、一切できない状態になっていました。
→ ICPを許可して、解決。
2) 親や仲間とうまく通信できなかった場合に、
自分でとりにいってしまう設定を殺していなかった
このため、1) の影響で２ちゃんねるの掲示板サーバに、
大量の「トラフィック漏れ」が起こった。
→ 1) の問題解決後、squid.conf で never_direct allow all を設定。
3) FDがsquidを動かすには小さすぎた
→ /etc/sysctl を修正・システム変数を再設定したうえで、squidをインストールしなおし。 また、squid が CPU 使いまくりな状況に。
原因切り分けのため、いったん c-au[456] をリブート。 「マイルド設定」を全面的にやめ、
# increase listen queue
kern.ipc.somaxconn=8192
kern.ipc.maxsockbuf=2097152
を復活。< c-au4/5/6 # none
cache_peer 192.168.0.3 parent 8080 3130 round-robin
cache_peer 192.168.0.4 parent 8080 3130 round-robin
cache_peer 192.168.0.162 sibling 8080 3130
#cache_peer 192.168.0.163 sibling 8080 3130
sibling (仲間)の設定を1つだけにしてみた。
c-au1 => c-au2
c-au2 => c-au3
c-au3 => c-au1
を設定。 あとは、
・設定的にディスクキャッシュを作ることにするけど、それは md にする
あたりかなと。 2005/05/30 15:40:35| WARNING! Your cache is running out of filedescriptors
2005/05/30 15:40:51| WARNING! Your cache is running out of filedescriptors
2005/05/30 15:41:07| WARNING! Your cache is running out of filedescriptors
2005/05/30 15:41:23| WARNING! Your cache is running out of filedescriptors
なんていうかんじで転んで、
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.3, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.4, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.162, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.4, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.3, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.3, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.4, port 3130: (55) No buffer space available
というかんじになり、あとはだめだめな状態に。< c-au4
とりあえず、子供同士の兄弟関係(sibling)を全部やめて、
親だけを参照するようにしてみた(効果があるかは不明)。 まだ「話だけ」の状態みたいだけど、ブレイクすると(以前のYBBの時のように)世の中変わるかも。
携帯電話の参入、１２年ぶり受け入れへ・総務省方針
http://www.nikkei.co.jp/news/main/20050602AT1F0100Y01062005.html で、au系でやっているローカルキャッシュ実験ですが、
いいときで30%ぐらい、平均すると2割ぐらいヒットしているみたい。
http://mumumu.mu/mrtgc/mrtg-rrd.cgi/loveaffair/c-au4-hits.html
もうちょっと実験して、うまいようなら他のやつにも。 >>65 の比率は前に「ミニ雪だるま」をex7でやったときとほぼ同じなので、
やはりsubject.txtとかが、かなり効いているみたい。
あとで、ログ解析とかしてみるか。 p2.2ch.net不具合報告スレ４
http://qb5.2ch.net/test/read.cgi/operate/1118316599/551-552
c-au4 で以下のように設定を変えてみた。
問題なさそうなら、全部に入れてみるか。
;session.cache_limiter = nocache
; changed by mumumu, 2005/6/28
; http://qb5.2ch.net/test/read.cgi/operate/1118316599/551-552
session.cache_limiter = private_no_expire >>83
c.2chというかclAssIcは
前からキャッシュ出来ていた気がする。
現在も効いてます。 p2のスレで、キャッシュについて興味深い話が続いているわけですが、
c-docomo系とc-au系で、キャッシュの効き方の相違? なのか、
トラフィックの出方に、相当違いがあります。
ここ見てもらうとわかるのですが、
概ね同じ設定をしているDoCoMo系とau系ですが(台数も同じ)、
アクセス数や２ちゃんねるから出て行くトラフィックは概ね比例しているのですが、
携帯側から「入ってくる」トラフィックに、大幅な違いがあります。
http://mumumu.mu/mrtgc/mrtg-rrd.cgi/traffic/
具体的にはau系のほうが、圧倒的に「入り」が多い。
これは、なぜなんでしょうか。 >>85
proxy\d+.docomo.ne.jp というくらいだから実はキャッシュしているとかとか。 >>86
２ちゃんねる(c)から見た「出」じゃなくて「入り」なんですよね。
「出」だったら、そうかなと思うんですが。
つまり、auのほうがDoCoMoよりも、「携帯側から」何かがたくさん来るんですよ。
こんど、tcpdumpでもしてみるか。 >>87
http://mumumu.mu/mrtglog/2005/05/18/traffic/
このグラフを見ると、「c-docomo2.2ch.net/c-docomo.2ch.net」の入りも多いですよね？
たしか、ａｕだけラウンドロビンしてませんでしたっけ？
あと、それから、ローカルキャッシュの分かと。思います。 >>88
その頃は、c-docomo2と同じサーバで動いていたロードバランサを経由していたからです。
なので、そのデータは参考になりませんです。
いまはDoCoMo/auとも、ラウンドロビンです。
ロードバランサ経由なのは、others系だけ。 >>89
pekoスレ見てきました。はい。そうでした。
あと思いつくのはローカルキャッシュだけか、、
tcpdumpの内容にワクテカです。 セキュリティのためにbpf切ってるから、
いっぺん、リブートしないといかんですね。
機を見て、やってみるです。 >>92
あー、そっかぁ。そうですね。
そういや、Accept: がすんごい長いですね。auって。
でもちゃんと、Accept: */* を送ってくるわけだけど。
某Vo(りゃ。 診断くんで環境変数しか見たことないけど、
headerはそれ以外も含むのかしら。
アクセス数がほぼ同じなので10倍くらい
違う事になりますねぇ。
誰かにDoCoMo借りてみよう。
そんなに何も送ってないとは。 ○ Vodafoneの接続用IPアドレスレンジとして、公表しているもの以外も使われている件について
携帯→2ch運用情報スレッド20
http://qb5.2ch.net/test/read.cgi/operate/1117638822/729-742
ということで、結構ショッキングなことが発覚しました。
これからc-othersの接続ログをあさって、実際に接続があったIPアドレスを調べてみるです。
(該当スレの734)
734 名前：root▲ ★[sage] 投稿日：2005/07/05(火) 03:32:06 ID:???0 ?##
うーむ、
これって、
http://whois.nic.ad.jp/cgi-bin/whois_gw?key=210.169.176.0/24
ここのWebに出てないんだけど。
http://www.dp.j-phone.com/dp/tech_svc/web/ip.php
とりあえず、Vodafone用のIPレンジとして追加しておくです。 昨日のアクセスログを掘って、
UA = Vodafone or J-PHONE なものから、接続先のIPアドレスを抽出しました。
202.228.227.3
202.228.227.4
202.228.227.6
202.228.227.7
202.228.227.8
202.228.227.9
206.223.150.148
210.146.60.199
210.146.60.200
210.154.135.71
210.158.198.62
210.169.193.224
210.169.193.225
210.228.189.56
210.228.189.77
211.127.12.240
211.127.183.55
211.8.159.131
211.8.159.132
211.8.159.133
211.8.159.134
211.8.159.135
211.8.159.136
211.8.159.203
219.118.171.51
221.112.172.235
61.195.194.6
61.195.195.138
64.233.166.136
64.233.178.136 で、これを >>96 の URL にある、
210.146.7.192/26
210.146.60.192/26
210.151.9.128/26
210.169.193.192/26
210.175.1.128/25
210.228.189.0/24
211.8.159.128/25
211.127.183.0/24
とてらしあわせると、、、。
202.228.227.* これは対応しなくてよさげ
206.223.* なのは、PIE(c-control)ですね。これもOK。
210.154.135.71 これも対応しなくて大丈夫かな。
210.158.198.62 これもとりあえずOK。
211.127.12.240 はちと気になるですね。
219.118.171.51 これも大丈夫そう。
221.112.172.235 これもOKか。
61.195.192.0/22 は、Vodafoneになっているけど、掲載がないじゃん。
http://whois.nic.ad.jp/cgi-bin/whois_gw?key=61.195.192.0/22
64.233.160.0/19 は、Googleか。 >>98
> 211.127.12.240 は、ODNですね。これも大丈夫か。 voda公式の情報と違うのはこの２つかな。
◆210.146.60.199
a. [IPネットワークアドレス] 210.146.60.128/25
b. [ネットワーク名] VF-LIVE-K
f. [組織名] ボーダフォン株式会社
◆61.195.194.6
etwork Information: [ネットワーク情報]
a. [IPネットワークアドレス] 61.195.192.0/22
b. [ネットワーク名] VODAFONE
f. [組織名] ボーダフォン株式会社 61.195.* なIPアドレスからは、Vodafone 702NKが接続してきているですね。
3G用?
でも、Webに記載がないし、
何せ、逆引きが jp-?.ne.jp じゃないんだよなぁ。
%nslookup 61.195.195.138
Server: localhost
Address: 127.0.0.1
Name: ca1.tik.access-internet.ne.jp
Address: 61.195.195.138
%nslookup 61.195.194.6
Server: localhost
Address: 127.0.0.1
Name: dt31caky01.kyo.access-internet.ne.jp
Address: 61.195.194.6 >>100
> ◆210.146.60.199
は、公式サイトにある、
210.146.7.192/26
に入っているですね。
しかし、あやしいので、210.146.60.128/25 で登録しなおしておくです。
しかしこの 61.* なアドレスは何者だ?
とりあえず、登録はしておこう。
なんかもう、むちゃくちゃ。 access-internet.ne.jp も、Vodafoneみたいですね。
しかしいきなりこんなふうに変えると、
昔のバージョンのbbs.cgiでも対応できないですね。
Vodafoneの逆引きはJP-?.ne.jp だと決め打っていたし。
今の(私が先日変えた)bbs.cgiも、公式サイトのIPアドレスレンジの情報が不足しているんじゃ、
対応できないっすよ。ぶちぶち。 >>102
Googleのキャッシュでみたら、
指定事業者名ボーダフォン株式会社
指定事業者略称J-PHONE
アドレスブロック
61.195.192.0/22
61.195.196.0/22
61.195.200.0/21
202.179.192.0/20
202.179.208.0/20
って、ありましたね。
検索ワードは、【ボーダフォン株式会社】と【61.195.192.0/22】です。
はてさて。 とりあえず、210.146.60.128/25 61.195.192.0/22 を
VodafoneのCIDRブロックに追加した bbs.cgi を配りました。
>>104
むー。 >>104
追加しとこう。
で、実害が出たら考えよう。
むぎゅー。 とりあえず、蹴りいれとく
∧＿∧ ＜公表しているIPと違い過ぎるんだよ
（ ・∀・）
と⌒ て) .人 ｶﾞｯ
（ ______ﾇﾙﾎﾟ >_∧∩
) ） Ｖ｀Д´）/ ←vodafone
レ' /
#vodaのIPはすべて地域割りになってるから
210.146.7.192/26
210.146.60.192/26
210.151.9.128/26
210.169.193.192/26
210.175.1.128/25
210.228.189.0/24
211.8.159.128/25
211.127.183.0/24
これも上が北海道で下が九州沖縄
だから表に載ってないIPも使ってる対応地域が存在するはず しかし、こんなことでほんとにいいのか?
なんで、2005年6月3日現在の情報が最新じゃない
(というか、間違ってる、に近いと思う、特に >>96)んだ?
みんな、困ってないのかなぁ? >>107
そのトリップはVoda使いさんですね。そのせつはどうも。
どっかに、もっと正確な情報はないんかいな。
特に3G方面。 >>104
ちなみに、このリストは2004年12月21日の物らしいですけど。
whoisしてみたら、ボーダフォンになってますね。 で、>>96 の URL は、こっちのほうがいいのかな。
(今は同じ物の模様)
http://developers.vodafone.jp/dp/tech_svc/web/ip.php
いずれにせよ、この数字があてにならなくて、
かつDNSの逆引きも部分的に jp-?.ne.jp じゃなくなってるとしたら、
いったい、どーせいっちゅーねん。 ＞61.195.* なIPアドレスからは、Vodafone 702NKが接続してきているですね。
3G用?
これは有名なVodafone 702NKがボーダフォンライブ！を経由せずにネットに繋がるとき
の分でしょ、２ちゃんねらはそこそこつかッテルはず
（といっても定額対象外になるからガンガンはつかえないけど）
PCとかに接続せず単体標準でこの機能があるのは702NKだけだから３G用というより事実上７０２K用
＞どっかに、もっと正確な情報はないんかいな。
＞特に3G方面。
それがあれば誰も苦労はしな（ry >>112
そうなんですか。< 702NK用
とりあえずVodafone扱いにしておきました。なんだかなぁ。
で、最後の行は、、ねぇ。
ちなみにさっき追加した 210.169.176.0/24 は、
逆引きすると jp-c.ne.jp と vodafone.ne.jp が
混在しているようです。
というか、逆引きもいつの間にか部分的に jp-?.ne.jp じゃなくなってるのね。
なんか、すごいっすね。
わたしゃ趣味100%でやってるから、何の責任もないし義務も発生しないわけだけど、
業務でWebサイト構築している人とか、みなさんどうなっちゃうんだべ。 たぶんこんな感じ
ボーダフォンライブ！を通過するもの→定額対象→IP地域割り→ jp-地域番号.ne.jp
ボーダフォンライブ！を通過しないもの→定額対象外→IP地域割りなし→アクセスインターネット扱い 携帯の機種情報を送らないとボーダから書きこみ出来ないようになってしまったみたいですが、
ボーダのコネクトカードも巻き込まれてしまってます。
これはPDAやノートに刺すタイプの通信カードなので機種情報を送りつけません。
この場合は諦めるしかないでしょうか？ >>115
ふーむ、そういうかんじなのですか。
逆引きが vodafone.ne.jp になるやつ(例は >>114 のアドレスブロック内にある)は、
どうなるんだべ。 >>116
コネクトカード、ってのがあるですか。
んじゃ、後で追加した access-internet.ne.jp のやつは、はずしておくです。
702NKとか、コネクトカードだけなのかな。ここは。 ttp://www.vodafone.jp/vc701si/?cc_A301=#
これか。。ややこしい。。 ＞逆引きが vodafone.ne.jp になるやつ(例は >>114 のアドレスブロック内にある)は、どうなるんだべ。
アドレスブロックを丸々この地域ですと割り当てているわけじゃなく
＊割り当てているもの＊が結果としてその地域に割り当てているという理解です
前はひとつの地域に割り当てられていたIPも寄せ集めのばらばらのものでした 逆引きが access-internet.ne.jp だった、下記IPアドレスブロックをはずしました。
これで、副作用は出ないはず。
"61.195.192.0/22", "61.195.196.0/22", "61.195.200.0/21",
"202.179.192.0/20", "202.179.208.0/20"
ということは、702NKからこのサービス使って書き込む場合は、
Vodafone Live! を経由しないから、普通のPDAとかから書いているのと同じ扱いなのね。
ちゃんとIPアドレスで識別できて、リファラとかもちゃんと吐くなら、
それはそれで、問題ないかと。 >>118
結構マイナーですが、あります。
access-internet.ne.jpを外して頂ければ
多分これらの通信カードは巻き込まれなくなると思います。
お手数掛けます。 「61.195.192.0/22は暴打からアクセスするときに使うIPアドレス？ そうなら公式サイトの情報を更新してくれ」とフォームで送信しちゃった(^^;;;) うひー ということでまとめると、今回の騒動で追加したのは、
210.169.176.0/24 … jp-c.ne.jp だったのに、表にまるっきりなかった
210.146.60.128/25 … 210.146.60.192/26があるので、前半分を新たに追加した
の2つということになるです。 >>124
それよりも、現に jp-c.ne.jp な 210.169.176.0/24 が
まるっきり掲載されていなかったことのほうが、
私としてはショッキングでした。 >>124
いいんじゃないっすか（汗
多分、ちゃんと回答してくれると思いますし。 >>123
了解です。
10分もすれば、全サーバに反映されるかと。 jp-c.ne.jp なのは、このへんみたいですね。
210.169.176.192/26 あたりかな。
これが表に出てないのって、明らかにミスだと思うなぁ。
210.169.176.192=wt-l7sgcx01.skyweb.jp-c.ne.jp
210.169.176.193=wt-l7sgcx02.skyweb.jp-c.ne.jp
210.169.176.194=wt-l7sgcx03.skyweb.jp-c.ne.jp
210.169.176.195=wt-l7sgcx04.skyweb.jp-c.ne.jp
210.169.176.196=wgp5proxy11.skyweb.jp-c.ne.jp
210.169.176.197=wgp5proxy21.skyweb.jp-c.ne.jp
210.169.176.198=wgp6proxy11.skyweb.jp-c.ne.jp
210.169.176.199=wgp6proxy21.skyweb.jp-c.ne.jp
210.169.176.219=ams5wwwp1.skyweb.jp-c.ne.jp
210.169.176.220=ams5wwws1.skyweb.jp-c.ne.jp
210.169.176.221=www.skyweb.jp-c.ne.jp
210.169.176.226=www.sky.jp-c.ne.jp
そろそろねるです。 純減の嵐の中
jp-c.ne.jp
東海地区だけは増やす理由があったんでしょうか
東海地区＝vodaの最重要拠点
かつての一時期は天下のドコモより契約数が多い時もあった
∧＿∧
（ ・∀・） と言いながら去っていくのだった（完）
（ ⊃┳⊃
ε(＿)ﾍ⌒ヽﾌ
（ （ ・ω・）
≡≡≡ ◎―◎⊃⊃ >>131
どもでした。
元・東海デジタルホンでしたっけ。
しかし私も愛知県出身ですが、
愛知県ってIDO = auが強いようなイメージがあるんですが。 お疲れ様です。
上場廃止で開示責任がなくなったとphs板で聞きました。
それ関係の不備でしょうか。（チェック人不足）
愛知でauが強いのはトヨタの周りだけかと。 >>134
そうなんですよね。IPアドレスブロックリストが消えているです。
>>135
上場とIPアドレスブロックの開示って、関係あるんだべか。
というか責任うんぬんより、それでいいのかなぁってかんじで。
こういう「正確さが命」な項目について、不正確な情報を掲載しておくっていうセンスが
よくわかんないすね。自分にもメリットないような気がするんですが。
何度も言いますけど私がうーむになるのは、別に大したことないです。
それよりも、これでほんとに大丈夫なのかなって、
余計な心配をついしてしまうです。
トヨタの周りは、確かにau強いかも。 乙です
俺もメール送ったけど帰ってこない(´･ω･`) >>137
どもです。
追加は「正式」になったってことですね。 > ※ サービス向上の為に、ボーダフォンライブ！サーバは
> 予告なく増設させていただきますので予めご了承願います。
なので、Vodafoneに言わせると、
何がわるいのってかんじなのかもしんないすね。 # 俺の書き込みに
# 変なフラグ『o』立てるの止めてくれ >>140
予告なしはかまわんが事後報告というかメンテしてないのが悪いんじゃゴルァ、と。
# 俺はコテハンしたく無いし
# 無意味にあおられたくも無い
# ID末尾に「o」付けるの
# 今直ぐ、止めろ！！
なんつか、携帯各社でIDのお尻変えてやれば
書き込みの質や量が利用者にも判りやすく
規制時の不満及びそれに関する感情的な書き込みも減らせると思う
>>146
おまえみたいな馬鹿を見るのは久しぶりだ そもそも携帯orPCの区別自体別にいらないと思ってるからな・・・ 携帯PHS板に予告なしでキャリア別ID導入したら面白いだろうけど
面白いだけで終りだな ここ数日でわかったことは、
・今のしくみそのままだと、BG3/4に倍のリクエストが来たら、さばくことはできなくなる
ってことだなぁ。 >>153
携帯からのアクセスが今のペースで延び続けると、
半年くらいでリクエスト数が倍になりそうな気がするんだよねぇ、、、 >>155
週末もその話題になったです。
さて、どうするべかと。 どうも、ただ増やすだけじゃつまらんと、思っているようですよ。 んじゃ、SANUKIsystemに移行って事で。（ぇ） 例えば、全部メモリ上にdatをキャッシュとかしたら、
リブート直後がキッツイよなぁ。 なんか今たわけた事を言ってしまったような気がする。
ちゃんとおさらいしないと。 >>161
これ、結構まじめに考えているです。
従来のクラシックメニューでは、datをローカルに持っていたわけですが、
これを復活させられないかなと。
もちろん、HDD上に持つ気はなくて、メモリディスク上ですが。
できるようならシステムの設定変えて、メモリディスク用意しますが、
いかがでしょう。
ただし、メモリが多いc-docomo系とc-au系のみですが。 うちで試してみるとか？
上手くいったらクラシックメニュー移植 >>165
試していただけるんであれば、ぜひ。
うまくやれば、BGの延命につながります。 >>164
という事はtiny tigerにはまだ余力があるって事ですね？
振り分けの時にtime outするのは何故なんでしょうか。
BG4のお返事待ち？ >>168
普段(BG3が動いている時)も、タイムアウトするですか? >>169
BG3が立ち上がって元に戻す時はサクサクです。 >>170
なるほど。
だとすると、中身の問題ですかね。
>>168 のとおり、返事を待っているとか。 アク禁してぇぇええええええ！今すぐアク禁してほしいのぉぉぉおおおおお！！！！ ●● ●●● ● ●●
/ (●), ､(●)V (●), ､(●)ヽ
|:::: .,,ﾉ(､_, )ヽ :l:::::.. ●,ﾉ(､_, )ヽ l＿
／￣￣￣＼● -=ﾆ=- ' 人::... -=ﾆ=- ' 丿 ●
/ (●), ､(●)ヽ￣￣￣￣￣￣￣＼￣, ､(●)ヽ
☆ |::::..,,ﾉ(､_, )ヽ､,, l '' ●''''' ''''' ＼(､_, )ヽ､,,l
│ ヽ:::..-=ﾆ●- ' 丿 （●）, ､（●） |=ﾆ=- ' 丿
│ ●￣￣￣＼ ,,ﾉ(､_, )ヽ､,,● | ￣￣＼
│ / (●), ､(●)ヽ:::::: ヽ｀-=ﾆ=- ' |), ､(●)＼
│ |::::.. ,,ﾉ(､_, )ヽ l:::●::::::::. ノ(､_, )ヽ､,, l
│ ヽ:::. .-=ﾆ=-／￣￣￣＼ ／￣￣￣＼ﾆ=-' 丿
＼ ＼＿● / (●), ､(●)V (●), ､(●)ヽ＿／
＼／￣● |::::.. ,,ﾉ(､_, )ヽ､,,l:::::. .ﾉ(､_,)ヽ､ l
/ ヽ:::..｀-=ﾆ=- '.人::●.. -=ﾆ=- ' ﾉ 貴様ら許さんぞ
））） | ●＿＼＿＿＿／ ＼＿＿＿／
i :::／;;;:::::::＼ ＼ ::::/
/ ::::/＼''' ::::i＼ ● :::::|::／
| ::::| ● | :::| |＼＿／/
＼＿／ ＼＿_/ ＼＿●
タイトルから考察してみる。
パソコン・携帯電話・他と
２ちゃんねるをぶっ壊しつつ鯖の管理人が警察に逮捕される予感がするぞ。 恋愛サロン板や失恋板[love6.2ch.net]にレス出来ない！(502) 携帯から書けないな
ﾍﾞｯｶﾝｺ使っても書けねぇや… ■ このスレッドは過去ログ倉庫に格納されています
