レス数が1000を超えています。残念ながら全部は表示しません。

[深刻] ２ｃｈ負荷問題ふたたび勃発

1 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:05

８・２６問題が再浮上かも。
http://teri.2ch.net/test/read.cgi/accuse/1011385033/
「いよいよ　何らかの手を打たなきゃどうにもならん状態になってきたようです」

関連ネタ
http://pc.2ch.net/test/read.cgi/tech/1002820903/360

2 ：2 ：02/01/19 21:07

2

3 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:07

先日の「第２次稲垣祭り」が相当こたえたっていう噂も。
またかよ…

4 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:09

sleep入れてスループット落とせば?

5 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:12

>4
リトライが増えて逆効果になるかも。

6 ：4 ：02/01/19 21:17

どうかな。遅くなるだけなら、普通の人は「待つ」んじゃないかな。
結果的に、単位時間あたりのリロード回数が減ることが期待できます。

さらに、直近n回にアクセスされたIPアドレスを覚えておいて、
アクセス数に比例してスループットを下げていけば、
「礼儀正しい」ユーザへの影響は少ない。
(proxyの問題はつきまとうけど)
でもこれはサーバプロセスがないと難しいね。

7 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:18

鯖自体はあまりいじれないってことじゃなかったっけ？

モー板つぶせよ

8 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:18

>>4
スループット目標下げりゃいーんだけど、
それやるとサーバレンタル屋がタダで貸してくれんのだとさ。

もともと目標設定すらなくて、
「速い！」てのを売りにしたいんだとそこのレンタル屋は、
要はIT世間でよくモメるパターンの話題の一つだってことだあな。

こういうのは、どっちかが折れて決着になるのが世の常。。。

9 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:21

dat直読み制限では、根本的な解決にならん気がするけど、
これ如何に？＞夜勤氏

10 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:22

>>5
ラーメン屋の出前の数には限りがある。
注文が増えても、ある一定のところで件数は横バイになるよ。

>>6
表示要求がきたらブラウザにn秒待ってからホントのデータを渡すように
metaタグとCGIの仕組みを組むとかすればある程度できるかも・・・ね

11 ：4 ：02/01/19 21:24

>8
スループットは下げられない、と。

じゃ、データ量を減らすしかないね。
「最新50」からリロードすると
「新着レスの表示」相当になるようにするのはどう?

12 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:26

read.cgi経由でデータ読む輩が増えると思われ。
これでは逆効果。＜dat直読み制限

13 ：4 ：02/01/19 21:31

>11
> 「最新50」からリロードすると
> 「新着レスの表示」相当になるようにするのはどう?

そんな都合のいい仕掛けは無理じゃん! と自分ツッコミ。

14 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:32

いつもどおりの泥縄政策だな。

ってゆーかunix板にスレ立てんなYO!

15 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:35

真の英雄Linux板でやってもらうか（ｗ

16 ：4 ：02/01/19 21:37

ていうか、有効で素人さんにもわかりやすい対処法がないまま
危機に突入しても、盛り上げようがないよね。

17 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:45

>>16
盛り上がる前に問題を消去ないし縮小する方がいいでしょ・・・

18 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:45

datをダイレクトに読んだ場合の負荷を綿密に計算しているのだろうか？
それも、転送量との兼ね合いを考慮した状態でね。
転送量の増加が必ずしも負荷の増加につながるわけではないけどね。

19 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:57

「オイスター作戦その一」の真の目的とは？？

658 名前：夜勤 ★ 投稿日：02/01/19 21:39 ID:???
>>653
まったくそのスレッドよんでいないけど、
目的が違っていると思うから　逆効果も何もないと思いますが、

20 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:06

全く読んでいないのに目的が違うと思っちゃう夜勤ﾏﾝｾｰ

21 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:10

>>19
なんで元レスの URL 書かないの?

22 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:13

>>18
負荷って言っても何の負荷かによるけれども
（てか、wでみたときの負荷？iostatで見たときの負荷？netstatで見たときの負荷？一体なあに？）
レスポンスは落ちるだろう。
でもreadまちのコンテキストがいっぱい並ぶのでスループットの下がり具合は
どうだろうか。

要はレスポンスの落ちこみ方によるんだな。
バッファキャッシュの当りかたがよくなって案外落ちなかったりしてね・・・

23 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:14

>>20
今回の改造の目的は転送量の削減でも負荷の軽減でもないからじゃない?

24 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:15

牡蠣→課金らしい。

25 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:32

無知でなんだが、dat直読みの場合ってgzip圧縮かかるの？
かからないならread.cgi使う事で転送量は多少減るんじゃない?
かかるなら...意味ねーな。

26 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:38

>25 こんどはCPU負荷で落ちるから。

27 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:55

>>24
カーカキンキン、カーキンキン？
某ｃｈじゃあるまいし。

28 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:58

寄付金集めればいいじゃん。
結構集まるでしょ。

29 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:03

レベルの高いLinux板に解決してもらおうよ。

30 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:03

１クライアントＩＰごとにトラフィック量を細かく制御する
ことができればいいんじゃないかなぁと思いますけどね。
こういうの、サーバレベルで可能なのかなぁ。

31 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:04

>>28
それは 1ch というんでは。

32 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 00:08

要するに今回の目的は、DAT直読みで課金ってことですか？

33 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:17

あぼーん禁止にすれば差分読むの簡単になって転送量が減るのでは？

34 ：名無しさん ：02/01/20 00:23

>>32
> 要するに今回の目的は、DAT直読みで課金ってことですか？
そういう方向みたいですね。

ID:pikopikopo---n@tora3.net
PASSWORD:detaramenahito

35 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:26

負荷問題への提案

1. CGIの改善 (read.cgi改良スレ読んでないんですぅ、が)
　そろそろ C使いに、効率的なCGIを作ってもらう時期.

2. サーバ構成の改善
　クラスタリング ＋ Layer4スイッチ ＋ キャッシュ・サーバ
　みたいな構成にして、板毎のサーバ分割から、動的負荷分散へ
　移行してみてはいかが？
　＃ちょっと萌えるテーマだ.

3.ビジネス・モデル
　i-mode 1000円っつうのはシャレにもビジネスにもならん気がする.
　とりあえず、金取れる所から、小額(200〜300円/月)でもとる方が、
　現実的だと思う.
　あと、「コミュニティ」以外の体裁を整えて、付加サービスとして
　２チャンネルがついてくる、という形も、検討すべきだと思う。

36 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:37

とりあえず、広告でもクリックしてみよう。

37 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:49

>>36 十回程クリックしてみましたが何か？

38 ：35 ：02/01/20 01:04

って既にC言語なんだ.

http://www.gedoh.org/aki/2ch/current/bbs/

現状把握に時間がかかりそう>>俺方面

39 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:05

>>35
> 　そろそろ C使いに、効率的なCGIを作ってもらう時期.
今も C だよ。
もっと効率的にしろ、ってこと?

40 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:06

http://www.yakin.cc/
88.9 Mb/sか。たしかにヤバイ状態かもしれない。

41 ：35 ：02/01/20 01:15

ﾁｮﾄすまん。

read.cgi改良スレッド３
http://pc.2ch.net/test/read.cgi/tech/1002820903/

と話が錯綜して、よく把握できないっす。

42 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:25

有料化したら無料の所のドミノ倒しが再現するだけでは？

dat読み制限ってことは、
2ch依存症のヘビーヲタのリロードがかなりの割合を
占めてるんだろうね。
という漏れもxyzzy+2ch-mode中毒者（汗

43 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:38

>>40
非営利なサイトで88.9Mb/sは尋常ではないわな。
下手なサーチエンジン系サイトより多いかも。
クラスタリングや負荷分散が必要なレベルに
なってきてるっていることは間違いない。

44 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:40

いや、アレだろ。read.cが単独でlistenして、1プロセス毎に
30クライアントくらいずつまとめて面倒みるのが‥‥

45 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:40

dat読み課金だってyo!

46 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:42

1ch有料化と時期同じく2chも有料化。
あぶれた難民は在野に下るなんてシナリオどう？

ちたぁ粛清されんじゃねえか？

47 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:46

＞dat読み課金だってyo!
ブラウザで見れば関係ありませんね : )

48 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:49

>>43 キャッシュ・サーバも有効そうです。>>再読み込み方面

まっとうな専用キャッシュ・サーバは、
結構古めのHWに専用OS使っていて、スループットが高そう。
だけど、むちゃくちゃ高価。

っつうわけで、安くて高性能なキャッシュサーバを立てる
方法はないのでしょうか？

49 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:49

どれだけ負荷分散しようが、
同じサーバー群からデータが出ていくわけだから意味ないのでは？
それより、2ch専用のcacheサーバプログラムをつくって配布するべきだろう。

50 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:53

あと、祭り発生時、読み書きが激流のように発生している時、
サーバ←→キャッシュ・サーバ間のトラフィックを押さえる
方法はないのでしょうか？
HTTPの範囲指定GETを使うとか、専用プロトコルを使うとか..

51 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:56

>>49
ユーザ側に配布するのですか？
あるいは、ミラー・サイトやアクセス・ポイントみたいな話ですか？

52 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:58

カキコできるスレ →無料 誰でも読める
DAT落ちのスレ →有料、monazilla系のツールでしか読めない。IDとパスが必要
html化した過去ログ →無料 誰でも読める

53 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:00

！！！＞http://teri.2ch.net/test/read.cgi/accuse/1011457309/

54 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:09

>>40
1/14〜15のレコードは明らかに稲垣祭りだね。
冬厨時期と少しずれていたのが幸いだったかもしれない。
これが１週間早かったらと思うとゾッとする。

55 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:09

>>50
read.cgi側で、response headerに付けるキャッシュ有効期限を長くしたらいいんじゃないの。

>>52
「dat落ちのスレ」の何が問題なんだろう???
(「dat直読み」自体が問題なのかな。広告が出ないので)

56 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:12

>>55
> 「dat落ちのスレ」の何が問題なんだろう???
この課金法だとブラウザの人にとってはいままでどおりってことじゃない？

57 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:15

88.9MB/Secの転送量・・・
サーバ→クライアントの下りだけ考えてみると、

・http://pc.2ch.net/unix/のリロード(HTML部のみ) 76KB
　→約1198回/Secの転送

・このスレの最新50リロード(HTML部のみ) 14KB
　→約6503回/Secの転送

BIGIPだのキャッシュ鯖だの要るな確かに。

58 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:17

どっかのベンチャーからキャッシュサーバと回線を無償で貸してくれないかな。
あの2chの負荷に耐えたとなれば宣伝効果はあるだろう。
f4

59 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:19

>>56
そりゃそうなんだけど、
「専用ブラウザの人の『dat落ちスレ』負荷」なんて問題になる?

60 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:21

＞どっかのベンチャーからキャッシュサーバと回線を無償で貸してくれないかな。
＞あの2chの負荷に耐えたとなれば宣伝効果はあるだろう。
それってまさしく、８月破綻まえのモデルでは‥‥

61 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:21

>>55 キャッシュ有効期限を長くする
最新情報が見えなくなる→リロード→負荷増大

62 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:22

>>19

63 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:23

>>19がどうした?

64 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:25

UNIX板の面目を果たすために、
安価かつ高性能なキャッシュ・サーバの
構築方法を提案できたらいーな。

レンタル鯖 or WebProg板方面逝った方が、情報収集しやすいのかな？

65 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:27

トリップ持ってる2ch.netの人間が、要件を整理して提示しないと何ともならんな。
どこかにあるのかね。

66 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:27

＞64
行くなら通信技術板じゃないの？

でも正直今の2chはロードバランサやキャッシュサーバで
なんとかなるレベルを超えてる気がする…。
Big-serverも変なプライド捨てて素直に制限かけるべきと思う。

67 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:30

いずれにせよ対策方法自体を2ch.netの外にもっていかんと
前の破綻前と同じ路線の対策しか打てない
↓
今すでにキャッシュの有効期限決め＋データ圧縮をやってるものが
こうして動いている
↓
httpdとOSに手入れず、
gzip以上に転送データを小さくする方法があればいいけど。
↓
ロードバランサーでは2ch.netの出入りパケットが減るわけがない
（特定の板の処理負荷を減らすことができるだけ）
↓
キャッシュサーバを置いてもクライアントへ出ていくデータが減るわけではない
（httpdの処理負荷減らすだけになる）
↓
あぼーん

68 ：sage ：02/01/20 02:37

>>57,>>66
祭り発生状態の板/スレだけ、
ピンポイントで制限 or キャッシュ＋負荷分散できたら、
他の板の住人はちったーしやわせになれるんでわ？

69 ：sage ：02/01/20 02:38

>>67 回線占有幅が問題なのですか？

70 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:41

主に汎用ブラウザ(IE,NN)方面について、
HTTP圧縮はサポートしていないのでしょうか？

71 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:44

＞70
その話は5ヶ月前に既出。
すでにread.cgiが実装してる

72 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 02:47

パケットシェーパー入れるのが手っ取り早いんじゃない。

73 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:49

ひろゆき曰く、祭り自体は大した問題ではない。
その後に新参者が定着し転送量が高値安定するのが問題。

gzip化で時間稼ぎの間にP2P実用化、のシナリオ通りには
やっぱ行かなかったね。半年しか持たんとは。

74 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:50

とりあえず、ここいらみて8月危機を復習しとけ。
http://hpcgi1.nifty.com/BWP/diary.cgi?action=view&date=20010830

75 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:52

しかし逆に考えれば
これだけの巨大な情報システムが
草の根ネット的に無料で運営されてきた
というのもすごいような

76 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:53

結局今回問題なのは転送量かサーバ負荷かどっち？
サーバ負荷ならあの人の言うとおり mod_perl 入れれば少しは
マシになるのでは。

77 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:56

つーかさ，寒波募集したら？

78 ：49 ：02/01/20 02:57

>>51
後者です。
だれか作ってみない？

79 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:57

「転送量」は単なる指標に使っているだけなのか、
それとも「通信回線の帯域圧迫」>>「サーバのCPU、I/O負荷増大」と理解していいのか?

80 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:59

UNIX板で2chの問題を解決しようというのは反対。
また変な感謝age荒らしが来たらたまらん。

81 ：山師 ：02/01/20 03:01

CPU足すわけにもいかんし
エンタープライズ系が使えるわけでもないし
サーバー増やすのは限界だし
modぶち込むには、HE社の技術を説得せんといかんらしいし（できるかもしれないけど、交渉が必要　すぐにはできないらしい）

82 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:01

>80
おまえ一人の殻に閉じこもってろよ。
他人とコミュニケーション取ろうとするな。

83 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:06

>>80
今回はまだ何もしてないのに感謝age荒らしの心配なんかするな。

84 ：呼んだ？ ：02/01/20 03:10

感謝age

85 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:11

こういう２ｃｈの状態はインターネット業界みんな起こりうる状態で
あって、注目に値すると思うぞ。

ただ単純にサーバ増やしたり、回線を増やすことを考えるのではなくて
少ない資源でどう対処するかを考える事も技術の進歩になるのだから。

86 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:15

ITバブルの頃って、
取らぬ狸の皮算用で過剰投資が問題になったが、
現実にビジネス・モデル＆負荷問題が起きている例で、
どうやって問題解決していくか、
漏れもケース・スタディーとしてすごく興味がある。

87 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:16

あのflashでいってた、「いつか限界がくる」の
その限界が来そう、って事だろ。
鯖の力を増やせば、その分帯域も喰うから、
いっぱいいっぱいの状態にしてある、って話も
きいたぞ。

88 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:18

つか、２ちゃん救うことに意義が見つけられない・・・

89 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:21

>>86
けど実際問題コードチューニングするのも限界があるし、
まして今安定稼動してるシステムに手を入れる暴挙なんて極力避けたいしなぁ。
負荷問題の解決方法は結局のところマシンのリプレースしかないと俺は思うんだけど。

90 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:24

SE or コンサル感覚でいくと、
結局ビジネス・モデルの確立が、
問題の根っこにあるとは思う。

３リオで、ギコネコ・キャラクター商品売って見るとか...

91 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:26

>>80,88
なんか自慢げな書き方だなあ。お前が2ch救えるわけでもないだろうに。
技術的に興味のある話題ってだけでいいだろ。

92 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:27

>88
>つか、２ちゃん救うことに意義が見つけられない・・・
そう考えずに、こういうケースが目の前で動いてるって
考えればいいんでは？

こういう状況ってなかなか作れるものではないと思うのだが。

93 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:31

まずは性能モデルでもつくってのんびり眺めてみては？
構成が見えんのがツライところだが。

read.cgi ver5.26+ (01/10/21-)