サーバ安定化できました！
07/20 01:10 - あとがき
- すーーーーごい遠回りでしたが、なんとかなって良かったです。
- 「サーバ入れ替えで解決」とかいうオチじゃなくて本当に良かった。それじゃあP2Pでやってる意味がないよね。
- 分散サーバの力をだいぶ借りてるけども。
- 不具合が起きたら、まず自分を疑ったほうがいいみたいです。
- こんなのでよければ、今後ともよろしくです。
- しばらくは反動で何もしないと思います。
- 何もしなくってもきちんと動くP2P地震情報サーバ。しあわせ。
- しばらくは反動で何もしないと思います。
- このページはもうすぐ消えるでしょう。
- じゃ、おやすみなさい。
07/20 00:51 - LOG
- 掲示板に書いた「全ピアデータの結合処理」の時間について、せっかくデータ収集したのを使わないのはもったいない。グラフ化。
- 1500を過ぎたあたりから急激に増加する恐ろしい現象でした
07/20 00:25 - LOG
- 長い道のりでした。私はいま、次々とログが流れていくP2P地震情報サーバを見ています。
- 今までのことが嘘のように、P2P地震情報サーバが動いています。
- しあわせです。
07/19 23:20 - LOG
- 安定動作。解決です。リザルト、じゃなくてディゾルブ… これはつぶつぶのエフェクトだな、、、 解決、ソルブ。solve。
- ピア数表示が安定するには30分程度掛かるかと思います。
- 接続が安定するのにも30分程度掛かるかと思います。リトライ分がいま押し寄せています。
07/19 23:11 - LOG
- 分散サーバの一部にパイロットテストということで渡す
- かゆ うま
- って書けと言われました
07/19 22:52 - LOG
- 稼働中。それにしても、ピア減ったか？
07/19 22:21 - LOG
- 稼働中。
- 「起動日時 07/19 22:01」という表示がまぶしい。変わるなよ。
07/19 22:04 - LOG
- サーバにて稼動開始。いちばんドキドキするところ。
- CPU使用率が100％と表示されるたびに寿命が縮む思いをする。
07/19 21:44 - LOG
- 「解決した」とか言ってたが、それをサーバプログラムのコードに取り込んでいなかった
- アホか。危ない危ない
07/19 21:42 - LOG
- 「津波予報っぽかったら『不明だけど発表されてるよ』くらい出す」完了。
- 遠地地震の震源不具合は重要性が低いのと時間がないのとでパスさせていただきます。
07/19 21:18 - LOG
- 「また津波予報解除」修正。
- 本日確認の「津波予報区が出ない」修正。
- あとは「津波予報っぽかったら『不明だけど発表されてるよ』くらい出す」。
07/19 20:35 - LOG
- 今回「発表されていたのに、予報区が拾えなくて解除と配信した」津波予報ですが、これ実はフェイルセーフです。
- 「『解除』と誤判定して『配信をやめる』」としてしまうと、表示が全く無いので「テレビを見る」という動作すら起こらない
- でも問題がありすぎるので、「予報区が拾えなくても発表ぽかったら『不明だけど発表されてる』くらいは出そう」という仕組みに変えます。
07/19 20:22 - LOG
- 解決しました。
- 「津波予報が解除された後、しばらくしてまた津波予報の解除が表示される」を修正しています…
07/19 20:16 - LOG
- 実装の結果は60秒後！
- ―この番組は、電源ボタンのプラスチック部分が壊れたサーバの提供でお送りしています
07/19 18:32 - LOG
- 問題特定。あとは解決策を考え実装するのみ。
- こりゃ二重のお詫び文掲載だわな。
07/19 18:15 - LOG
- チェック中。
- なお、P2P地震情報サーバソフトウェアはメインPCで稼働中です。普段よりは耐えられるはずです。
- サーバ側でカウントするピア数表示あたりは変な値になっています。ごめんなさい。
07/19 10:05 - LOG
- 原因調査として次の2箇所をチェック予定。
- 全ピアデータの「結合」部分
- 全ピアデータの「送信」部分
07/19 09:27 - LOG
- 間接原因分かりました。パケットキャプチャが役に立ちました。
- 対サーバの同期機能に初期通信ステップがあるのですが、
- その中に含まれる「全ピアデータ要求」コードの受信直後に固まっていました。
- 具体的にどの場所で、どんな原因で固まっているのか、はもう少し調べる必要がありそうです。
- だって、3000ピア前後を境に急に発症するわけですから…
07/19 00:10 - LOG
- 現在考えられる原因は次の通りです：
- 処理量が多すぎる
- 対ピア・対サーバの通信処理を同一プログラムで行うことに問題がある
- 対サーバの同期＜送信＞処理に問題がある
- 判断の根拠は次の通り：
- 全機能オンのとき、およそ3000ピアを超えると固まる（本サーバ制御:1000, 同期制御:2000 程度）
- 対サーバの同期機能をオフにすると、正常に動作する（ただし、本サーバ制御:1700 のみ）
- 対ピアの通信機能をオフにしても、正常に動作する（同期制御:3000 程度、ただし同期処理は受信方向のみ）
- それにしてもピア数が出ないのはおかしいだろう。すっかり動いてるんだから。
- NTFS暗号化でカウントするユーザアカウントに対する権限を与えていなかった これは洒落じゃない
07/19 00:05 - LOG
- ふりだしに戻る。
本日中に「Winsock OCXの代替コントロールを試験導入」します！
ここ数日におけるサーバの不安定な動作によって皆様にご迷惑をお掛けしておりますことをお詫びいたします。詳しくは掲示板をご覧ください。
本ページでは、当面の対策として説明した「Winsock
OCXの代替コントロールを試験導入」実装の開発状況をリアルタイムにお知らせします。
開発内容
次の通信に用いるコントロールを変更（取消線＝変更済み）：必須：対ピア通信、対ピアポート開放チェック、対サーバ同期通信任意：対ピアデータ配信、syslog配信、地震情報・津波予報検査
開発は 7/18 開始、 7/18 終了を目標
07/18 22:01 - 開発の終了と問題の解決失敗を宣言します
「Winsock OCXの代替コントロールを試験導入」について、開発の終了と問題の解決失敗を宣言します。
本日中に「Winsock OCXの代替コントロールを試験導入」するという目標は達成出来ましたが、残念ながら問題の解決には至りませんでした。「よりオープンに」という方針のもとサービス状況を公開しておりますが、これは自動処理であって嘘をつきません。「障害発生中」「停止」と表示されていれば、それは事実です。
皆様には大変ご迷惑をお掛けしておりますことを深くお詫び申し上げます。
07/18 23:44 - LOG...
う、動いて……いる……だと……？まあ待て、ここで結論を出すのは早計だ。またこんなことになりかねん。
状況を整理しよう。コントロールが問題ではない（Winsockだろうが代替だろうが、3〜4分固まって自然復帰を繰り返した）全機能オンのとき、おおよそ3000ピアを超えると固まる（本サーバ制御:1000,同期制御:2000）対サーバの同期機能を切ると動いている（ただし本サーバ制御:1700ピアのみ）対ピアの機能を切ると動いている（同期制御:3000〜4000、ただし本サーバ制御はゼロなので同期受信のみ実施）
考えられる原因は、こうなる。処理量が多すぎる（ある処理量を上回ると急に調子が悪くなる特典つき）同期「送信」が悪い（送信処理に問題が含まれている）複合技が悪い（処理量が多すぎる、とだいたい同じ意味）
07/18 23:29 - LOG...
サーバ間の同期機能を疑ってみましょう。同期機能オフモード。これで動いたらいろんな意味で洒落にならん。
07/18 22:48 - LOG...
気になるのは、1サーバ体制のPRCP情報共有プラグインサーバは平然と動いているということ。何かこう、特定ピア数を境目に決定的な違いが起こるのだろうか…
07/18 22:29 - LOG...
メインPCでサーバソフトウェア稼働中…
07/18 21:54 - 進捗度:90% (デバッグ中)
こりゃ敗北宣言するしかないわな。全部きれいに停止してるのを見たら泣けてくる。「うなだれてる画像クレ」といったらこんなのが送られてきました
07/18 21:50 - 進捗度:90% (デバッグ中)
実装でp2pquake.ddo.jpの表示が停止になっちゃってるな。本当は（それなりに）動いてるんだけど。
07/18 21:39 - 進捗度:90% (デバッグ中)
奥の手発動中。これで固まったら敗北宣言。
07/18 21:32 - 進捗度:90% (デバッグ中)
奥の手「ソケット数固定化」でどうにかならんかね。いざ実装中
07/18 21:19 - 進捗度:90% (デバッグ中)
数値戻ってるけど気のせいだよね。固まりっぱなしでしょうがないというか分散サーバ落ちすぎだろ…
07/18 21:07 - 進捗度:91% (デバッグ中)
あれ… 固まって… る…？ 100%…？
07/18 20:53 - 進捗度:91% (デバッグ中)
順調に動いていて気味が悪い。最初「君が悪い」と誤変換されて思わず投げ捨てそうになった。しばらくまったりしておきましょう。
07/18 20:43 - 進捗度:90% (デバッグ中)
実地試験中。
07/18 20:24 - 進捗度:87% (デバッグ中)
しばらく回しておいて、30分動いたら実地試験しよう。ルータに「ip_conntrack: table full, dropping packet.」とか出やがるので、コネクションの多いシステム（IRCとかIRCとかIRC）のサービス終了を本格的に考えなければいけません。
07/18 20:22 - 進捗度:86% (デバッグ中)
エセマルチスレッドのイベントドンブリドリブンにはもう飽き飽きした。ポート開放を調べていたら他ピアの受信データを処理し、データ処理をしていたら他ピアの接続要求を処理し、ポート開放？ 10秒経ってるし失敗じゃね？とかいうことになる。ひどい。
現在5分連続稼働中
07/18 20:09 - 進捗度:85% (デバッグ中)
エラー時もリセットカウントを足すようにして解決 出来てないし…
07/18 20:03 - 進捗度:81% (デバッグ中)
結局、バックログ一杯(5)になったらリセットする「ダメ」対応でしのぐ。と言いたいが、しのげていない。
07/18 19:51 - 進捗度:80% (デバッグ中)
ConnectionRequestイベントが発生しなくなる なんで？なんでじゃなくて、Acceptしないからバックログ溜まって駄目なことになってるだけ
07/18 19:15 - 進捗度:78% (デバッグ中)
リジューム。ルータがダウンしていた。
07/18 18:50 - 進捗度:78% (デバッグ中)
ふたたびサスペンド。腹が減っては何とやら。
07/18 18:39 - 進捗度:77% (デバッグ中)
コンパイルエラー ++++動作中エラー ++++処理方法がまずくて、一度エラーが起きると接続を受け付けなくなっている。
07/18 18:21 - 進捗度:76% (デバッグ中)
コンパイルエラー ++++動作中エラー +++型変換忘れその2。
07/18 18:13 - 進捗度:75% (デバッグ中)
ローカルで1ピアを制御できました。
07/18 18:07 - 進捗度:70% (デバッグ中)
コンパイルエラー ++++動作中エラー ++仕様のズレでトラブル1個。
07/18 17:02 - 進捗度:65% (デバッグ中)
コンパイルエラー ++++動作中エラー +バインドがうまくいかない。型変換を忘れていたという酷いオチでした。
07/18 17:00 - 進捗度:65%
対サーバ同期通信 移行完了。デバッグへ移行。これからが長い（はず）。
07/18 16:42 - 進捗度:50%
対サーバ同期通信 移行開始。デバッグを30%と見積もっているけど恐らく甘い。
07/18 16:35 - 進捗度:50%
対ピア通信 移行完了。
07/18 15:52 - 進捗度:35%
対ピア通信 移行中。
07/18 15:33 - 進捗度:20%
新規実装終了。これからやっていただくのは、GREP掛けて置換していく簡単なお仕事です
07/18 14:55 - 進捗度:13%
新規実装「どのNICにバインドするか」について概ね考えがまとまる。（次の3択にする 1: デフォルト値にまかせる, 2: www.google.co.jp へ接続に使ったNIC, 3: 指定IPアドレスを持つNIC）
07/18 13:55 - 進捗度:12%
リジューム。
07/18 10:12 - 進捗度:12%
対ピア通信 移行中。新規実装が必要で少し時間が掛かりそうです。私用につき14:00までサスペンド。
07/18 09:58 - 進捗度:10%
対ピアポート開放チェックを移行。
07/18 09:47 - 進捗度:4%
津波予報チェック部分を移行。
07/18 09:39 - 進捗度:2%
津波予報チェック部分を移行中…
07/18 09:20 - 進捗度:1%
おはようございます。実装が必要な範囲を調べています。
07/18 00:50 - 進捗度:0%
開発の開始を宣言し、終了目標を 22:00 に設定します。開発が終了すればこのページは消滅します。ひとまず寝ます。