X

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

■ このスレッドは過去ログ倉庫に格納されています
1root▲ ★
垢版 |
NGNG
日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。

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

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
NGNG
現状:

電車男の収入により、携帯システムの大幅強化が決定。
サーバ設置のための専用のロケーションが用意され、
全ポート1G対応の高性能スイッチ、tiny tiger (tigerのIDEディスクもの)の大量投入が決まった。

現在第一弾のtiny tiger6台が投入され、au/DoCoMoのフロントエンドに配置。
特に重かったau系の過負荷が解消された。

今後は●で購入したサーバとの分離、外向けdat公開サーバ(白山羊さん)の導入等を、
たんたんとすすめていく予定である。
NGNG
アクセラレータをAPCからeaccleratorにしてからというもの、
うそみたいに安定してるですね。< c-au/c-docomo

当分、これでいってみようかと。
2005/05/27(金) 18:02:30ID:???0
BGベンチマークテストやりますか？
NGNG
>>4
おぉ。

MRTG対応するです。
ベンチすると1周どころか、2周回ってしまう。

すぐできると思うので、ちと、まってくださいです。
2005/05/27(金) 20:14:18ID:???O
ワクワク。
NGNG
どきどき。
NGNG
ええと、どうもすぐにはCounter64、サポートできないっぽいです。
まじでか。

【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part18
http://qb5.2ch.net/test/read.cgi/operate/1115133136/601

代案を考えなきゃ。
NGNG
携帯→2ch運用情報スレッド19
http://qb5.2ch.net/test/read.cgi/operate/1115189922/786-788

ということで、c-others系もAPCをやめてeAcceleratorに変更。
NGNG
ということで、BG3で負荷試験中。

わかってきたことを、だらだらと。
NGNG
%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/

いつもの日曜の「急激に上がる時間」に符合して、キャッシュヒット率が下がり、
漏れ出すものが多くなっている。
NGNG
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
NGNG
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
NGNG
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
NGNG
# maximum_object_size_in_memory 8 KB
maximum_object_size_in_memory 1024 KB

は、上記のように大きくしてあるが、もっと大きくできるかもしれない。
NGNG
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割ぐらい(それでも多いけど)か。
NGNG
>>15 は1オブジェクトの大きさだから、 1MBytes で十分ですね。
(datとsuject.txtだから)
NGNG
memory_poolsは、今off。
onにしてトライする意味は、あるかもしれない。

# memory_pools on
memory_pools off
NGNG
ということで、いったん >>18 やるです。
これから squid をリスタート。
NGNG
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 が終わったら、観察へと。
NGNG
ちなみに memory_pools_limit は、未設定の状態。
NGNG
各サーバとも、BlackGoatから「漏れて出た」分、転送量が増えちゃってますね。
やはり「何としても漏らさないようにする」必要があると。

http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/
NGNG
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
NGNG
効果あるかも。軽くなってきたきがする。
NGNG
今 store の rebuild おわた。
これから、観察。

とりあえず 1:00 まで。
NGNG
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 もおわた。
本格観察開始。
NGNG
さっきより、はるかにうまく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
NGNG
重い(待たされる)ことは、かわらないっすね。

あとは「どっちがよりましか」か。
NGNG
一瞬軽くなったけど、また外からみた重さが重くなったですね。
HDD待ちかなぁ、やっぱ。
NGNG
で、>>27 は実はかんちがいで、それだけ HDD を「使ってしまう」
状態らしい。

やはり巷間言われているように、memory_pools は off のほうがいいのか。
いずれにせよ、我慢してしばらくこのまま。
NGNG
いまいちっすね。< memory_pools off

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

1:00にBG3の設定戻します。
それが終わったらここに書きますので、、BG3/BG4の配分を元に戻していただけますか。> できる方々
NGNG
こうすけさんに戻していただきました。
ぼちぼち、今回わかったことをだらだらと。
NGNG
○ 今回(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にまかせる)のほうが
効率よく動くらしい。
NGNG
HDDのI/O性能からすると、今の1.7倍のアクセスでI/O性能の50%強ぐらいだったから、
仮にsquidが理想のプログラムの動作をするようになったとすると、1.7倍の1.8倍ぐらいまでは
いける可能性があるということか。つまり、約3倍と。

ただ、ここまで性能をしぼり出すことはたぶんいろいろな理由によりできないから、
現在のシステムにおけるハードウェアの性能は、
めいっぱいまでがんがったとしても、やはり今の2倍とか2.5倍あたりまでかなと。
NGNG
…といったところか。

とりあえず今すぐにBGが破綻するわけではなそう(ちょっとだけ時間に余裕がある)、
というのは、少しだけいい情報だったかも。
NGNG
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) もパンクしたということか。
NGNG
(妄想)

これなら、tiny tigerのフロントエンドそれぞれでメモリキャッシュモードだけののsquidを立ち上げて、
BlackGoatと多段にすれば、さらに1段得をするような気が、しないでもない。
NGNG
あと、せっかくsquidなんだから、BG3とBG4を「兄弟｣にしてみるか。
NGNG
あと、

# 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

だから、もっと増やす道もあるかも。
NGNG
BG3 で、ためしに 256MB にしてみた。

# cache_mem 8 MB
#cache_mem 80 MB
cache_mem 256 MB
NGNG
しばらく動いてsquidが肥大していって、

FATAL: xcalloc: Unable to allocate 1 blocks of 4104 bytes!

と言って落ちました。

もうちょっと小さくするか。128MBあたりで。
NGNG
# cache_mem 8 MB
#cache_mem 80 MB
cache_mem 128 MB

これで、しばらく観察。
BG4はとりあえずそのまま(比較のため)。
NGNG
>>42
それほどかわらなそうなので、将来とか緊急時を考えると
キャッシュメモリを大きく与えたほうがよかろうということで、
BG4 もこれにした。

で、「親子実験」ができそうなので、
もうしばらくしたら、c-au系で実験しようかなと。
NGNG
準備できました。実験開始します。

依頼は、c.2ch 不具合報告スレにて。
NGNG
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
NGNG
4) c-au4 c-au5 c-au6 のsquidは、とりあえず遅延なしに設定

refresh_pattern . 0 0% 60 override-lastmod reload-into-ims
NGNG
ICP (ひらたくいえば、squid同士がお話しするための部分)のアクセスコントロールを
あけていませんでした。

icp_access allow private
icp_access deny all

を、BG3/4とc-au4/5/6のsquidに追加し、再起動。
NGNG
で、この際に、上記の親の部分の round-robin オプションがない状態になりました。
今、au4/5/6 とも、オプションがない状態。
まずはこれで実験してみて、あとで復活するかんじで。
NGNG
で、never_direct を、c-au4/5/6系にいれておけば、だいじょうぶかな。
これも、あとで。
NGNG
round_robin 復活させました。

never_direct allow all を c-au4/5/6 に入れました。
これで、BG3/4からとれない時に直接とりにいってしまう(さっきの状態)ことは、ないはず。
NGNG
恥ずかしい統計情報(c-au4/5/6からだだ漏れ)を、手で消しました。
普段はこういうことはしないんですが、これが残っていると
今後の傾向がつかめないので、やむを得ず。ううむ。
2005/05/30(月) 23:31:02ID:u+WT0kTqO
こんなもんなのか？と思っていたが
感覚が麻痺していたのか＠だだ漏れ
NGNG
帰宅後、失敗談を告白するです。
今は正常に動いているはず。

ローカルsquidの様子をとりはじめた。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/
NGNG
squid がメモリを食っていくので、cache_mem を 32 MB まで減少。< c-au4/6
# c-au5 は、リブート要請へと。
NGNG
さすがに 32 MB は少ないようなので(ヒット率減少)、
64 MB に戻した。
NGNG
こんどは、FDを使い果たし。
「マイルド(前のc-au1 bananaと同じ)」を、tigerと同じに戻した。

kern.maxfiles=32768
kern.maxfilesperproc=16384
↓
kern.maxfiles=131072
kern.maxfilesperproc=65536
NGNG
＜今日のミス＞

1) 親・仲間に対し、ICPを許可していなかった

まぬけなことに、ICP (他のsquidサーバと、
キャッシュが存在するかどうか通信するためのプロトコル)を、
それぞれのサーバに対して許可していませんでした。
つまり、親子、兄弟との間での会話が、一切できない状態になっていました。

→ ICPを許可して、解決。

2) 親や仲間とうまく通信できなかった場合に、
自分でとりにいってしまう設定を殺していなかった
このため、1) の影響で２ちゃんねるの掲示板サーバに、
大量の「トラフィック漏れ」が起こった。

→ 1) の問題解決後、squid.conf で never_direct allow all を設定。

3) FDがsquidを動かすには小さすぎた

→ /etc/sysctl を修正・システム変数を再設定したうえで、squidをインストールしなおし。
NGNG
また、squid が CPU 使いまくりな状況に。

原因切り分けのため、いったん c-au[456] をリブート。
NGNG
「マイルド設定」を全面的にやめ、

# increase listen queue
kern.ipc.somaxconn=8192
kern.ipc.maxsockbuf=2097152

を復活。< c-au4/5/6
NGNG
# 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

を設定。
NGNG
あとは、

・設定的にディスクキャッシュを作ることにするけど、それは md にする

あたりかなと。
NGNG
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)を全部やめて、
親だけを参照するようにしてみた(効果があるかは不明)。
2005/05/31(火) 20:18:38ID:RT9Y7UpV0
ichiou hosyu
NGNG
まだ「話だけ」の状態みたいだけど、ブレイクすると(以前のYBBの時のように)世の中変わるかも。

携帯電話の参入、１２年ぶり受け入れへ・総務省方針
http://www.nikkei.co.jp/news/main/20050602AT1F0100Y01062005.html
NGNG
で、au系でやっているローカルキャッシュ実験ですが、
いいときで30%ぐらい、平均すると2割ぐらいヒットしているみたい。
http://mumumu.mu/mrtgc/mrtg-rrd.cgi/loveaffair/c-au4-hits.html

もうちょっと実験して、うまいようなら他のやつにも。
NGNG
>>65 の比率は前に「ミニ雪だるま」をex7でやったときとほぼ同じなので、
やはりsubject.txtとかが、かなり効いているみたい。

あとで、ログ解析とかしてみるか。
NGNG
今晩サッカーがあるけど、時間帯が微妙に遅いかな？
2005/06/06(月) 23:41:35ID:Gh1i/34o0
hosyu
2005/06/10(金) 02:26:26ID:aGPAzdx40
sage
2005/06/12(日) 15:19:58ID:H8nsS6+dO
test
2005/06/20(月) 00:20:54ID:TBNuSRbE0
てすと
2005/06/22(水) 14:31:33ID:i2KAdWjC0
けいたいねぇ
2005/06/22(水) 14:39:03ID:qg1u1aRV0
youjo ita
2005/06/22(水) 14:58:21ID:OuirBcdL0
なんだかんだいってvodafoneがお得
2005/06/22(水) 21:38:15ID:Sr4wrO5M0
test
2005/06/23(木) 11:17:57ID:Y/SaG3Bn0
人多なのか？
2005/06/23(木) 15:12:46ID:2jWiHWWB0
>>74 docomoにしる。
2005/06/23(木) 17:54:07ID:oloqvSVA0
iyada yo
2005/06/23(木) 18:48:55ID:KlgkVLKh0
アステル最強伝説
80denpa
垢版 |
2005/06/27(月) 13:41:51ID:Pyy/peUe0
denpa waruiyo
NGNG
海底、、
82root▲ ★
垢版 |
NGNG
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
NGNG
http://qb5.2ch.net/test/read.cgi/operate/1118316599/556-557

ちと難しそうなので、いったん元に戻したです。
必要なら、PHP側でやったほうがいいの鴨。
2005/06/28(火) 19:29:13ID:o9xMth8eO
>>83
c.2chというかclAssIcは
前からキャッシュ出来ていた気がする。
現在も効いてます。
NGNG
p2のスレで、キャッシュについて興味深い話が続いているわけですが、
c-docomo系とc-au系で、キャッシュの効き方の相違? なのか、
トラフィックの出方に、相当違いがあります。

ここ見てもらうとわかるのですが、
概ね同じ設定をしているDoCoMo系とau系ですが(台数も同じ)、
アクセス数や２ちゃんねるから出て行くトラフィックは概ね比例しているのですが、
携帯側から「入ってくる」トラフィックに、大幅な違いがあります。
http://mumumu.mu/mrtgc/mrtg-rrd.cgi/traffic/

具体的にはau系のほうが、圧倒的に「入り」が多い。
これは、なぜなんでしょうか。
NGNG
>>85
proxy\d+.docomo.ne.jp というくらいだから実はキャッシュしているとかとか。
NGNG
>>86
２ちゃんねる(c)から見た「出」じゃなくて「入り」なんですよね。
「出」だったら、そうかなと思うんですが。

つまり、auのほうがDoCoMoよりも、「携帯側から」何かがたくさん来るんですよ。

こんど、tcpdumpでもしてみるか。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況