Deprecated: Function ereg() is deprecated in /virtual/oocp/public_html/boinc.oocp.org/sah/util.inc on line 200
以下は下記原文 13 Dec. JST 時点の 翻訳 草稿 です。 転記などはご遠慮ください。 オリジナルの知的財産権は University of California に属します。
原文: Technical News
最終更新時刻 14:12:36, 2007年05月05日(JST)

技術ニュース(〜2007年1月まで)

logo7
(2007/05/5) この技術ニュースの翻訳ページに 追加の記事を入れるのは現在止めております。
2007年の2月から、技術ニュースの原文が 掲示板の1つへと形態を替え、Matt氏以外の投稿も含めて記事がかなり増えました。 量と形態をどうするかが問題で訳しきれなくなっております。
下記のニュースは、技術的に細かいことにまで言及しています。 これらは、技術的すぎるので、 入り口のページにある通常のニュース欄に載せずにここに載せてあります。
January 9, 2007 - 22:00 UTC
新しい BOINC 複製データベースをどのようにするかについて、 毎週の定期停止時間にテストを実施しています。 いまのところ問題は生じていないのですが、最繁時間帯にも耐えられるところまでは、 まだ到達していません。 ほとんどの場合もっと多くの検査(たとえば、そのサーバが使う RAID が、ディスクドライブの故障にも耐えうるなど)をしますし、 フル稼働させる前には全システムをプロジェクトのサーバクローゼットに移動します。

残念なお知らせもあります。 このプロジェクトでほぼ3年働いてくれた、 すばらしきシステム管理者 Court Cannick さんが、 より大きくて良い仕事へ移ると最近宣言しました。 実は、本日が彼が居る最後の日です。 彼が我々とやった仕事には、 数多くのシステムを稼働状態にしたこと、そして、プロジェクトの UPS を制御できる状態にしたこと、ルータの設定、新しいコンソールサーバの設置といったものがあり、 さらに我々を助けてくれたことがらとして クラシックのプロジェクトから BOINC ベースへの難しい移行、 データストレージ用の DLT テープを活性挿抜できるハードディスクドライブへと移行させた作業がありました。 彼の良い今後を願い、SETI 関連の集まりでこれからずっと逢えることを期待しています。

 
January 2, 2007 - 23:30 UTC
技術ニュースの下記項目に追加情報があります。 最近生じているワークユニットのダウンロードがうまくいかない件は、 データベース・テーブル(リザルト)に壊れた部分があることに関係がありました。 毎週の定期停止時間の間に、この部分をきれいに直しました。 この週末は実質的に 2日以上の停止があったので、当然ながらサーバが需要に追いつくのに少し時間が要ります。 ワークユニットはプロジェクトの能力一杯のスピードで送出されています。
 
January 2, 2007 - 18:30 UTC
Happy new year! 気忙しい休日の期間が過ぎていきました。

数週間前に、プロジェクトのサーバクローゼット用の空調設備が故障し、 全システムを包む気温がすぐに10度上昇しました。 もちろんこの故障は週末に起こったもので、 高温値は警告システムの設定値のほんの少し下にとどまったので、 警告のメイル等を我々が受取ることはありませんでした。 この故障は、ベイエリアを襲ったまれな寒波が原因でした。

 
パイプが凍結したので、空調装置は自己防御のため停止したのです。 今回は運が良かったと考えていた矢先、数日後に再びこの空調設備が故障してしまいました。 あるパイプに漏れが生じているのが見つかり、修理しました。 そういうわけで、警告システムの設定値を調整しなおしました。

この休みの期間に、アップロード・サーバを何回か再起動せざるをえませんでした。 アップロード・サーバが重要なマウントを不定期に失ったからです。 この問題は SETI@home 拡張版が公開される前はより頻繁に生じていました。 (SETI@home 拡張版がプロジェクトのバックエンドサーバの負荷を大きく下げたので頻度が落ちたのです)。 しかし、参加者が増え、コンピュータが速くなるにつれ、同じ問題が再発しつつあります。 なぜこれが発生するのか、そしてどうやって直すかについて 我々はブレインスト-ミングをしてアイデアを出そうとしています。

リザルト・テーブルへの問い合わせが遅いことがあるという問題がありましたが、 それは今までたまに一時的しか起こらないものでした。 ところが、 この数日をみると発生頻度が許容範囲を超えつつあるようです。 サーバからサービス群を別のところに移動して負荷をさげたり、 サーバ群を再起動し、MySQL をリブートしたりしましたが、効果がありませんでした。 そこで今はテーブルの整合性検査を(毎週の定期データベースバックアップ時間に)実施しています。 おそらく、インデクスが壊れているのが見つかるでしょう。 何か新しいことが見つかったらお知らせしましょう。

 
December 8, 2006 - 00:15 UTC
今週末の最新情報をお届けします。 いつもながら、 皆さんに普通は伝えるまでもないような裏方の仕事で手一杯でした。 新しい例のマルチビーム用スプリッターは仕上がりが近づいており、 まもなくベータテストに入るでしょう。 ということは、 採取したてのデータで新しい解析をする処理が現れてくるということです。 Astropulse プロジェクトも、大きく前進しています。 Arecibo でのデータ採取は現時点ですべて自動化されています。 データでドライブが満杯になると、運用者に警告がだされて、 空のドライブとの交換をするようになっています。 データで一杯になったドライブが十分な数になると、運用者はここにドライブを送ってきます。 そしてここでは、インターネットを通じてそのデータを HPSS へコピーし、ワークユニットに変換することができるようになるまでの間、保存されます。

ここしばらく、参加者の経験という領域に深く注意をむけていました。 この領域へは今まで開発するための資源がなかった (そしてこれからもない)ところでした。 とりわけ、 新しい申請フォーム(原文) を使えば、クラシック版 SETI@home のころに獲得したけれど、 新しいアカウントに結びつけることができずにいた功績値(credit)を、 参加者の皆さんが再び手にすることができるようにしました。 さらに今週から、インターネット電話 (つまり Skype)を使って 技術サポート(原文)をしてくれるボランティアの方々のプールが用意できました。 このボランティアの人数は増えつつあります。

最後に、一つ前の技術ニュースの追記にまた追記事項があります。 それは、Intel 社の寄付は 実は、 デュアル・コア Xeon プロセサを 4つもつシステムであるということです。 4つのプロセサのうち、2つしか稼働状態でなかったのですが、 それでも hyperthreading のおかげでプロセサが8つあるように OS からは見えていました。 このシステムの BIOS をいじくって、ついに残りの2つのプロセサも認識させました。 今では hyperthreading の効果を入れると、OS によれば 計16個の 3GHz プロセサがあるということになります。

 
December 5, 2006 - 23:15 UTC
今日、定例のデータベース停止をいつもより少し遅れて実施しました。 (いつもこの作業を担当している人物が病気でお休みしたからです)。 それにもかかわらず、我々が主張している 4時間枠の中におさまるほど短い時間で終了しました。

一つ前の技術ニュース記事に追加情報があります。 最近の Intel 社からの寄付は、クワッド・デュアルコアの Xeon プロセサシステムではありません。 それは、クワッド・シングルコア Xeon プロセサのシステムで、 ハイパースレッディング機能を持っているものです (OS からみると、それは 8 プロセサを持つように見えます)。

 
November 29, 2006 - 19:00 UTC
昨晩、ほんの短い間でしたが停止していました。 これは、 ワークユニットを保持しているファイルサーバへのマウントを データ・ダウンロードサーバが失ってしまったからです。 この現象はまさしく確率的に生じるものです。 サーバ自身は自分の仕事をしっかりこなしています。 同様の現象を、かってシステム全体に負荷が重くかかったときに見たことがあります。 サーバが、ワークユニットとリザルトとをやりとりする頻度は、 拡張版クライアントでは大幅に少なくなっています。 ですから、 上記のような負荷が原因で発生しやすくなる問題も発生することが減りました。 ムーア則と恒常的な参加者増加は有り難いことなのですが、 それゆえに、この問題をまたいつか解決しなければならなくなるでしょう。

もうひとつ残っている問題で、不定期に起こる問題があります。 それは データベースへのアクセスが「異常になる期間(rough periods)」に関係しています。 (詳しくは昔の記事を見てください)。 基本的に起こっていることが何かを説明しましょう。 あるプロセスが24時間に1回くらいの頻度で、参加者/計算機/チームに関する有用な情報を XML形式のファイルに書き出しています。 このファイルは、 他のサイトでリーダーボードやグラフ表示等を公開できるようにするためのものです。 これらの統計情報を納めたデータベースのテーブルは、 大きくなりつづけています。 一旦、上記の処理が走りはじめると、このテーブルが リザルトのテーブルをメモリ上からはじき出してしまうということはあり得ることです。 そこで、我々はこのデータベース問い合わせを効率化する検討を行っています。

また、我々は新しい BOINC データベース・サーバを立ち上げることを考えているところです。 (SETI@home 用の科学データベースはこれとは別もので、 既に新しいサーバハードウェアの上で快調に動作しています。 ) 最近 Intel 社がいくつかのハードウェアを寄付してくれました。 その中には、 デュアルコアの Xeon プロセサを4つ備えた(つまり、3GHz のプロセサが合計8つある) システムがあります。 現在我々はこのシステムの奇妙な振る舞いをいくつか経験しており、 それらを解決しようとしています。 まだその最中ですが、 このシステムを信頼できるようになったら、 これをプロジェクトの BOINC データベース・サーバにして、 現在のデータベース・サーバは複製サーバにします。 これができれば、 必要なときに即時のバックアップが可能になりますので、 毎週恒例の停止をしなくて済むようになります。 まだほかにもあります。 Intel 社の別のシステムは既に設定が済んでおり、 バックエンドの科学 CPU サーバの一つとして使われています。 (このシステムは、アレシボから送られてきたハードディスク・ ドライブから新しいデータを読むことにも使っています)。

クラシックの頃のデータテープで、未着手だとわかっているテープが残っていました。 先週、その最後のテープが読み込まれて、 プロジェクトのスプリッタへの待ち行列に追加されました。 このテープの次は、何らかの形でこの作業の流れを通ったことがあるものの、 何か理由があってこのプロジェクトの主データベースには反映されなかったテープを対象に、 読み込みをしていきます。 そうなってしまった理由としてあり得るのは、 まず、データ不良(こうではないことを祈ります)、あるいは、 テープドライブの故障が理由で読まれずに残されたもの (これが想像以上にかなり多い)、粗末な初期解析のためそうなった、 あるいは、重複検査中の失敗につながったデータベース破壊のため、 といった理由が挙げられます。 ですから、90年代末のテープが待ち行列の中に現れても、 驚かないでください。 1998年に採取したデータは、2006年のものと同じ価値があります。 というのも、探している地球外知性体は何光年もかなたから信号を送ってきています。 時間がたっても信号が継続しているという一貫性を探し求めるに当たって、 この数年の差は問題になりません。

 
November 14, 2006 - 23:45 UTC
プロジェクトのダウンロードサーバが昨日午後から仕事の送出を停止していましたが、 それを検出できず、今朝やっと修正しました。 われわれはネットワークのアップグレードの大仕事の最中です。 (これについては別途ニュースで流しますので注目しておいてください)。 その作業の中で、新しいネットワークの取り回しをテストするために行った設定変更が、 長い暗号のようなシンボリックリンク連鎖がたどれなくなるという 潜在していた問題を表面化させてしまいました。 言い換えると、しまった!というやつです。
 
November 8, 2006 - 00:30 UTC
今朝早く、いつもの BOINC データベースのバックアップのため、 システムを停止しました。 大したことではありませんが、このとき、 プロジェクトのサーバクローゼットを少々掃除する時間を取りました。 すると、絡み合ったイーサネットケーブルがたくさん見つかりました。 これらは取り回しを直さねばならないでしょう。 より本格的な掃除をするには、 サーバ群を一時停止しなければなりません。 計画停止がこのために必要です。

新しいデータレコーダは完全に機能する直前まできています。 今日まで一週間ほど動いていますが、 (種々の問題がおきるたびに人間の介入が必要になる状態から脱して)、 もう少し自動化した運用ができるようになると、 より速くデータを収集できるようになります。 新しいデータからワークユニットを作り出すようにスプリッターを直すことや、 そのデータをクライアントが処理できるようにする作業もしていますが、 今は主に上記のデータレコーダを完全稼働させるために時間を割いています。

 
October 31, 2006 - 20:30 UTC
最近まで当プロジェクトの科学データベースとして稼働してきた サーバ castelli を本日の定期保守時間に最終的に停止させました。 この科学データベースは、現在 thumper 上で稼働しています。

上記は外からみるかぎりは正しい話です。 しかし実態としては、本日電源を切ったマシンは galileo という スケジューリング・サーバでした。 サーバ castelli は複数の CPU と数ギガバイトの RAM、さらには更新したての OS を載せているマシンでしたので、実は古いマシンである galileo を停めて、 サーバ castelli の名前を単に galileo に変更したのです。 わかりました?

いずれにしても、新しいスケジューラが既にコンパイルされている状態なので、 早晩それが実装されます。 当プロジェクトは稼働状態に戻りましたが、 スケジューラ・ソフトウェアを交換してテストするために、短期間はシステムを停めるでしょうから、 今後、荒波を航海する期間がある程度生じると思ってください。 また、先週と同様、バックアップ処理後に BOINC データベースの性能の暴れが起きています。 これは落ち着くまで数時間かかります。

 
October 25, 2006 - 19:00 UTC
現在データベースの診断を小規模に開始しました。 最近の問題 (一つ前の記事を参照)を調査するためです。 どういうことかというと、 いままでリザルトは処理が完了した後、すくなくとも 1日はデータベースに残しておいたのですが、 今回その代わりに、処理が完了したらすぐにデータベースから削除しています。 ということは、リザルトのデータが当プロジェクトの科学データベースに取り込まれるやいなや、 参加者のデータベースから消えますから、皆様のアカウント・ページからは完了したリザルトが見えなくなります。 この状況は見た目のものだけであり、しかも一時的なものです。 データベースの中に他とつながりがなくなってしまった「孤児」状態のリザルトがないことを期待しています。 また、上述したリザルトの行の削除処理は、孤児状態のリザルトが無いことを確かめる助けとなるでしょう。
 
October 18, 2006 - 18:30 UTC
2つ前の記事で書いたの同様に、先週のサーバ問題とは全く相関なしに 「異常な期間(rough spots)」が生じています。 今朝もこれが発生し、 バックエンドサーバ群を停止・再起動するまでずっと継続しました。 通常1秒で終わるデータベース問いあわせが、いったいどんな原因で 1000秒もかかるようになってしまうのか? 奇妙な点が以下のようにいくつかあります。 (a) 他の似た問い合わせは同じような影響を受けません。 (b) 「異常な期間」においてさえ、同じマシンで全く同じ問い合わせをコマンドラインから発行すると、 応答は1秒以下で戻ります。 そのサーバのログをみても、おかしなところはまるでありません。 これでは調査はお手上げです。 たぶん、mysql をアップグレードするのが順当なところでしょう。
 
October 12, 2006 - 19:00 UTC
忙しい週末でした。 木曜の午後にこのプロジェクト用のメイルサーバが一度は立ち上がったものの、 動かなくなりました。 いずれこのサーバは取り替える計画だったのですが、 この事件で実質強制的に取り替えることになりました。 まだこのサーバの回復作業は終わっておらず、 設定の複雑さに取り組んでいます。 メイルサーバの振る舞いは 現在だいたいは まともですが、 ときたま思わぬ動きをして手当てを要しています。

日曜には、プロジェクトのアップロード・サーバ(kryten) が他のマシンに NFS マウントをすることができなくなりました。 この異常が他のバックエンドサーバ全体に 将棋倒しのように波及してしまいました。 以前からこの NFS マウントが突然うしなわれる件が起こっていましたけれども、 これほど痛ましい結果にはなったことはありません。 しかし、対処方法は昔と変わらず単純です。 つまり、そのマシンを再起動するのです。 それでも、再起動の際には、 アップロード済みリザルトをたくわえる RAID 装置で 再同期処理が走るのを止めることはできないので、 それがうまく完了するようにプロジェクトを数時間停止しました。 稼働状態へ戻したところ、滞積しているトラヒックをかなり素早くこなしていきました。

全体的にみると、昔に比べてこの 6-12ヶ月のサーバ稼働時間の成績はすばらしいものです。 そこで最近活動していない参加者に復帰のお誘いメイルを一斉に投げたのですが、 そのとたんに、数台のサーバがダウンしてしまったわけです。 なんとタイミングの悪いことでしょうか。 まあしかたありません。

 
October 12, 2006 - 19:00 UTC
一昨日、新しいスケジューラをインストールしたところ、参加者のプレファレンスに関して小さなバグが見つかりました。 これはすぐに修正を作りましたので、更新された版をまもなく適用します。

今日は上記とは別のスケジューラの問題が見つかりました。 この数日の間、仕事がそれほど高速に送出されていない時に、2回の異常状態の期間がありました。 フィーダプロセスはスケジューラ経由で送出するリザルト用の待ち行列の長さを 100個以上に維持しようとします。 そのために その待ち行列を満杯にするリザルト生成処理が必要かどうか、 データベースへ問い合わせを出して継続的に調べています。 このデータベースへの問い合わせは通常は1秒以下で処理が終わるのですが、 何らかの理由で 1000秒ほどもかかるようになりました。 その時間の間に、 上記の小さな待ち行列は空になり、送出する仕事がなくなったのでしょう。 この現象が2〜3時間生じていました。 その時間の間、 フィーダプロセスが出す上記のデータベース問い合わせは、 ほとんどの場合は即座に結果が返っていましたが、たまに1000秒かかっていたようです。 結局は正常な状況に戻り、現在は安定しています。 これがどういうことだったのか調査しています。

今のところ新しい科学データベースはうまく動作していますが、 突然の不都合が起きた場合を心配して、古いほうの科学データベースサーバも稼働状態にしてあります。 数週間運用してみて、新サーバの状態に満足したら、古いサーバをお役御免にします。 データに関しては、新しいマルチビームデータ(1TB を越えるほどになりました) を収集している状況ですが、このデータが公式に用いられるまでには、 新しいスプリッタを作る作業や、クライアントに小さな表面上の変更、 そしてそのテスト作業をベータサイトで行う必要があります。 最近しばらくは、まだ処理されたことのなかった古いクラシック版のデータについて作業をしています。 今まで我々は、主に RFI によるデータ破壊がおきている可能性のある日のテープは処理を後回しにしており、 その時点では優先度の高い、よりきれいなデータの入っているテープが手に入っていましたので、 処理するものに不足はなかったのです。

 
October 9, 2006 - 20:15 UTC
ワークユニット生成のためこの週末に準備したテープの山が、 実はデータが壊れて読めない状態であることがわかりました。 そこで、今朝から正常なテープをできるだけ速く読み込んでいますが、 ちょうど今、溜めていた仕事が底をつきました。 今この文章を打っているうちに、新しいテープイメージがネットワーク上ですぐにも使えるようになるので、 そうしたらしばらくのうちに需要に追いつきます。
 
October 5, 2006 - 21:30 UTC
昨晩までで、科学データベースのすべてのデータを、古いデータベースサーバ (castelli) から新しいサーバ(thunper)へ移しきりました。 そこまでは良い話です。 しかし、まだベータプロジェクトのデータも thumper へ移動させなければなりません。 それまでは、ベータプロジェクトは停止させたままになります。 新しいデータベースには細かいチューニングがまだ必要ですが、 この作業は毎週の定期停止時間(あるいはごく短時間の停止)の中で行います。 いずれの停止時間で実施するにせよ、通常のリザルトとワークユニットの流れには影響はありません。

ところで、thumper というサーバの名前は、Sun 社が新しい Sun Fire X4500 システムの新シリーズに付けた愛称から単純にもってきたものです。 もう 1台手に入ったら、bambi と名づけるでしょう。

 
October 4, 2006 - 23:30 UTC
新しい科学データベースが動きだしました。 しかし残念ながら、 実用に供するにはまだ思わぬ性能チューニングが必要とわかりました。 現在このデータベースは、とても長い時間のかかるインデクスの構築処理の最中です。 なぜこのように時間がかかるのか正確に理解して、チューニングする必要があります。 しかし同時に、現在処理中のインデクス構築を途中で中止したくはありません。 ですから笑顔で耐えて、終わるのを待つしかありません。 うまくいけば、 今夜のうちに稼働状態にできるかもしれませんが、おそらくは明日の朝になるでしょう。 この大都会の中の生活とはこんなものです。

追加情報: 上記のインデクス構築処理はこれを書いたすぐ後に完了しました。 今、新しい仕事を送出しています。

 
October 3, 2006 - 21:15 UTC
この記事を書いている今、当プロジェクトの科学データベースの最終移行ステップを忙しく進めているところです。 この作業のため、スプリッターとアシミレータは現在停止させています。 科学データベースへのデータの追加と更新が今はできないからです。 したがって現在は新しい仕事を生成していません。 明日には稼働を再開する計画ですので、 それまでに仕事が不足することにはならないはずです。

追記: ベータプロジェクトの科学データも当然移行の対象ですので、 そちらのプロジェクトを今は完全に停止させてあります。

 
September 28, 2006 - 21:30 UTC
新しいドライブ筐体は(アレシボから送られてきたデータ一杯のドライブを読むためには) 使いものになりませんでした。 書くと長くなりますので結論から言うと、 原因はわかっていません。 しかし、新しい科学データベース・サーバを決めるのにさらに時間をかけるのはうんざりです。 そこで、計画を少し修正することにしました。 基本は、 このドライブ筐体を別のサーバに取りつけます。 どのサーバに付けるかはっきり決めていません (まず、データ転送帯域幅の要件や、PCI カードのサポートなどを確定させる必要があります)。 なんとかして近いうちに上記のデータをネットワークへつなぎ、その後、ワークユニットへの分割をすることにします。

結局こうすると、新しい科学データベースへの移行の最終段階実施を待つ必要はなくなりました。 それはつまり、1日程度の部分停止(その間スプリッタとアシミレータを停止します) で、残りの全てのデータを新しいサーバに移動するということになります。 その次に、完全な停止(しかし、より短時間です)期間を設けて、 新しいデータベースを使うように全ての設定を切り替えて、 プロジェクトが適切に動作することを確認します。 この作業は、来週火曜の定期停止時間の中で行うかもしれません。 大きな作業が近づいたら、ウェブの入り口のページに表示します。

1ヶ月ほどまえについに SETHI プロジェクトを立ち上げて再開したことを書いておくべきでした。 我々が Arecibo で集めているデータを使って、すくなくとも何らかの科学研究が行われています。 このデータは、近傍の星間物質に含まれる水素の詳細分布図になります。 しかし、再観測にむけた SETI の候補信号のほうはどうなっているでしょうか。 何が起こってきたでしょうか。

実は、候補信号の絞りこみ作業は(とても長い間)止まっておりました。 優先する他の大仕事があったからです。 (たとえば、プロジェクト全体の BOINC 移行、 新データレコーダの開発・導入・試験・稼働、新データベース・サーバへのデータ移行とそのサーバの立ち上げ、 無数のトラブルへの対処などなど)。 上記の新データベースが稼働し始めたならまず、時間を食う解析とデータ修正を行う必要があります。 そのあとで、テラバイトもあるスパイク、ガウシアン、パルス、トリプレットのデータの中に 潜む E.T.を探す作業を行うことができます。

 
September 11, 2006 - 22:00 UTC
先週金曜に発生した科学データベースの故障から、ほぼ稼働状態に回復しました。 今では新しい仕事を生成することができており、アシミレータは滞積してきたリザルトを解消しつつあります。 しかし、危険な状態から決して脱したわけではありません。

古い方のデータベース(故障中)からは、データのアンロードが未完です。 データ破壊はなかったものの、現在は RAID 10 ミラーの片側半分だけを使って運用しています。 ということは、もう一台だけでもドライブが故障したら、 データベース全体が失われてしまいます。 いったい何が起きたと思いますか。 上記のミラーディスク1組は、2つの独立したドライブアレイで構成されていますが、 この2つのドライブアレイの片方が死んでしまったのです。 これが昨週の金曜日に起きた大きな悩みの種であり、週末ずっと警戒体制をとることになってしまいました。

古いデータベースに残っているデータは、24時間以内にアンロードされるはずです。 そうしたら、そのデータを検査し、新しいサーバにロードします。 次に、両方のデータベースに載っているデータが等しいことを確かめます。 これが終われば、プロジェクト全体を1日停止して、 1週間前にこの計画を開始してから今までの間に生成したワークユニット・ 受信したリザルトをすべて新しいサーバへ移動します。

最後に、新しいデータベースを使うように全ての設定を切り替え、このプロジェクトを再開します。 万事うまくいってくれれば、新しいサーバへと完全に乗り換えられるでしょう。 そして、古いサーバをすっかり引退させることができるでしょう。

一方で、データレコーダについては良い知らせがあります。 DLT ドライブに多くの問題があったため、 この新しいマルチビームレコーダでは少しのデータしか採取できていませんでした。 この DLT の技術的問題を回避する試みの一つとして、交換可能な SATA ドライブに対象のデータを格納する方法に取り組んだところ、 実装もテストも含めてうまくいったのです。 今朝時点で、アレシボ側ではデータレコーダの全部分が稼働しています。 これに合わせるため、研究室においても部品の注文、設置、テストをしますが、 近いうちに終えることができます。 最終的には、テープでデータの移動をする代りに、 500GB ドライブ群をまるまる持ち回ることになるでしょう。

 
September 8, 2006 - 22:00 UTC
このプロジェクトで送出するべき仕事が足らなくなってしまいました。 おそらく週末までこの状態がつづきます。 なぜそうなっているか説明しましょう。

最近、Sun 社から寄付を受けた新しいサーバがあります(詳細は後を見てください)。 これを我々は新しい科学データベースのサーバにすると決めました。 現状の科学データベースはしっかり動作しています。 しかし、古くて(遅い)システムで動いており、 付けてある中古のファイバチャネル接続ディスクが異なる原因でしばしば故障しています。

先週ようやく我々の望むようにこの新しいサーバを設定し終えました。 今週は、旧システムからデータベースの全テーブルをアンロードし始めました。 ディスクの動作負荷が増えたので、前述のディスクが昨晩完全に異常を呈しました。 というわけで、今朝このデータベースをたち下げなくてはなりませんでした。 現在まだこのシステムの復旧作業中です。

BOINC のバックエンド機能のほとんどはこの科学データベースに依存していません。 しかし、スプリッターとアシミレータは依存しています。 アシミレータが停止状態になることは大きな問題ではありません。 ただ、 計算結果を科学データベースに組み入れるのが遅れるだけです。 しかし、 スプリッターが稼働しないと、新たな仕事を作り出すことができません。 このため、このプロジェクトの送出待ちの仕事をためる待ち行列が、 本日の午後にすでに空になってしまいました。

データベースの復旧は、とても今日や今週末のうちには終わりそうにもありません。 たとえ週末のうちに復旧できたにしても、最優先の仕事はスプリッターを稼働させることではありません。 まずは、まだアンロード作業が残っている少数のデータベース・テーブルを、 問題のディスクがまた故障する前にアンロードすることになります。

あなたのコンピュータを忙しく保ちたいなら、いつでも 複数のプロジェクトの仕事をする ことができます。

 
August 22, 2006 - 22:30 UTC
本日、いつものデータベース・バックアップのための停止を行い、 その時間の中で、UPS バッテリ一式の交換と、ファイルサーバの OS アップグレイド、種々のサーバプロセスのソフトウェアのバージョンアップ を実施しました。 仕事が不足する事態になったことを除いては、全てうまくいきました。 なぜ不足したかというと、どうも現在扱っているデータのノイズレベルが高いためのようです。 つまり、普通より計算処理にかかる時間が大幅に少ないのです。 送出待ちの待ち行列が現在は空ですが、それは特定の時点で送出するために余裕としてあるワークユニットの数が 0 であるということだけです。 現状の仕事の需要に対してわずかに追いついていないというだけです。 テープイメージをオンラインにもっとするにつれて、現在の傾向は持ち直すはずです。
 
August 10, 2006 - 14:00 UTC
状況の変化はというと・・・

毎週の定期停止の時間に、Webサーバ群も同時に停めました。 調子がわるい UPS のバッテリーを交換するためです。 この手順のどこかでヘマをやったため電線がショートしてしまい、 新品のバッテリーのコネクタが大きなスパークとともに蒸発して消えてしまいました。 ちょっとした見ものの騒ぎでしたが、幸いけが人はありませんでした。 交換のバッテリーが手に入るまでは、その UPS のつながっていたサーバは予備 UPS で運用しています。

かの新データレコーダは現在のところまだデータを集めることができていません。 それは、テープドライブの不可解なエラーのためです。 この原因を調べている間は、当面、データをディスクドライブで収集することを試みます。 このドライブはトレイに収納されたホット・スワップ可な SATA II ドライブ群で、これらをバークレーとアレシボの間で今後往復させます。

テープドライブのエラーについて言っておくと、元々の DLT IV テープドライブの最後の1台もついに故障して動かなくなりました。 確かにこれらのドライブは古いものなのですが、 壊れたとなると、困ったことに SETI@home のデータで読まねばならない テープを我々はこのドライブの形式でたくさん持っているのです! しばらくは Super DLT ドライブを使ってこれらのテープを読んできました。 交換用のドライブも発注済みです。

新しい Sun のサーバ (July 26 付けのニュースに詳細あり) の設定がほとんど終了しました。 なぜ長くかかったかのかというと、Linux がブートドライブをどのように認識するかに ついて、混乱していたからです。 短く言ってしまえば、24台のドライブ構成のとき、 ブートドライブは /dev/sdm であり、2次ドライブは /dev/sdo になります。 もちろん、Fedora Core 5 インストーラはその権限のもとで、/dev/sda にインストールの 全ての結果を書き込みます。 OS のインストールが一旦終われば、 ソフトウェア RAID 上で動作する 大きな(2テラバイト超の) Linux ボリューム管理ファイルシステムをいくつか作成する処理が始まります。 これが本当に長い時間かかる処理で、新しい RAID 装置にファイルシステムを載せたときと同様、 最初の RAID の同期に数時間が必要です。

この新しいサーバは、単独の科学データベースサーバにする計画です。 当てにならないファイバチャネルと調子の悪いディスクドライブとが付いている E3500 システムを置き換えます。 E3500にあるデータをファイルに落とし、新しいデータベース・サーバに格納する必要があるので、 長い停止が必要になります。 しかし、この作業のほとんどは「楽屋裏」で行われ、 普通の参加者の活動にはたいして中断がおこりません。 すなわち、この作業手順の間、スプリッターとアシミレータが停止状態になるだけです。

 
August 2, 2006 - 18:00 UTC
アップロード用サーバをリブートするために、このプロジェクトを短時間停止しなければなりませんでした。 時たま、アップロード用サーバは科学データベース用サーバへの NFS マウントの うちのどれかを気まぐれに失うことがあります。 今回その結果として、 アシミレータが科学データベースに計算結果を追加できなくなり、 結果のアップロードも普通はできない状態になりました。
 
July 26, 2006 - 17:30 UTC
先週末の電源の瞬断によって、このプロジェクトの科学データベースが壊れました。 ミラー構成の RAID の一つが故障したものの、最終的には被害を受けたすべての ディスクドライブのデータを同期させることができ、それ以上のトラブルにならずに稼働状態似戻すことができました。

しかしながら、当プロジェクトはより速くて信頼性の高い 新しい科学データベース用のサーバがぜひほしいと願っています。 Sun 社は最近 Thumper (X4500) システムを我々にベータテストを目的に寄付してくれました。 これをデータベース・サーバとして使うことも許してくれています。 そこで我々はこのシステムの設定の最中です。 このシステムには、 デュアルコアの opteron が2つ、8 GB の RAM、500GB の SATA を24個 (これは搭載可能台数の半分で、合計12 TB ) が付いています。 我々の科学データベース自身には、約 1 TB の格納容量しか必要としません。 ということは、新しいデータレコーダが毎日 最大で 300GB データを記録するようになれば、 残りの容量を一時的なテープ・イメージの格納に使えるわけです。 (新しいデータレコーダについては、科学ニュースレターが近々出ます)。

 
July 7, 2006 - 17:30 UTC
今朝、5:00AM ごろから(12:00 UTC)、 研究所全体に渡って停電となっていました。 これは、 近くにある Lawrence Hall of Science というビルで電気設備の問題を調査することになったためです。 なぜ我々の研究所まで停電にしなければならないのかよくわかりませんが、 とにかく停電してしまいました。

停電直前の3:00AMまで待ってシステム全体の立ち下げ作業をしたい人は誰もいなかったので、 平日であった昨日の終わりに立ち下げを行いました。 いくつかの依存関係で問題があったほかは、今朝の再立ちあげですべての システムとサービスはきれいに再開されました。 (依存関係というのはつまり、あるサーバが稼働状態に戻るまで別のサーバがハングしてしまうということ)。

結局、電気設備の保守をしている人たちがやったことは、問題点を探し出すことだけでした。 聞かされたところによると、問題を解決するには将来もっと長い停電が必要になるということです。

 
April 11, 2006 - 23:00 UTC
本日、ハードウェアの再構成のために一度停止しました。 ケーブルの引き回しに問題があったので、思った半分程度しか仕事は片づきませんでした。 2時間ほどで再開したのはこのためです。

今回作業が完了したのは、当プロジェクトの BOINC データベース・サーバに搭載した メモリを倍増させる作業(8G から 16Gバイトへ)です。 ところが、 40z サーバのサービスプロセッサが出力する誤解を招くメッセージ群が、 この単純でかつ平凡な作業をおくらせてしまいました。 サービスプロセッサのイベントログから、昔の「重大エラーメッセージ」を消しておかないかぎり、 DIMM を追加しても、追加したことを認識しないのです。

スループット改善のデータを採るため、実は新しいメモリの全部は使わずに再起動しました。 まずは新しいメモリの半分だけを使いました。 その結果、I/O待ち状態の時間がはるかに少なくなりました。 これは我々が望んでいたとおりの結果です。 明日、毎週恒例のデータベース保守 (バックアップと圧縮)の後で、新しいメモリをすべてデータベースのために使うようにする計画です。 さらに、db_purge を設定しなおして、リザルトをより長い時間残すようにします。

 
April 6, 2006 - 18:00 UTC
BOINC のデータベースサーバと ウェブサーバ boinc.berkeley.edu を守っている UPS の動作が昨晩からおかしくなり始めました。 これでデータベースのほうが影響をうけることはありません。 というのも冗長電源構成を別に持っているからです。 しかし、BOINC ウェブサイトのほうは その晩 2、3回見えなくなってしまいました。 30分ほど前にこのプロジェクトを短時間停止して、上記の2つのサーバを 信頼がおける電源につなぎ換えました。 しばらくはそのままにします。
 
March 30, 2006 - 22:30 UTC
うまくいったようです。 これで難所を通り抜けました。 プロジェクトの BOINC データベースの大きさを格段に小さくしました。 どんな方法を使ったかというと、リザルトの削除待ち行列を消し去ること、 さらに db_purge 処理を加速することにより、リザルトの中身がディスクから 消えたらすぐに、プロジェクトのデータベースからもすべて消すようにするという 方法をとりました。 普通の状況では、少なくとも 1日は、古いリザルトの行をデータベース内に保持しており、 それによって、参加者の方々が最近計算を終えたリザルトを自分のリザルト一覧表示で 見ることができるようにしています。 この週末の間は、様子を見るためと、 遅れを取り戻すために、古いリザルトの保持を抑制します。 翌週になれば、以前のように db_purge パラメタを緩めて、 計算が終わったリザルトの行が生き残る期間を長くするかもしれません。

いずれにしても、データベースの大きさを圧縮できたので、 そのほとんどの部分がメモリ上に載るようになりました。 これで、 今ではとても性能が改善されています。 この状態は、もちろん、 サイズが大きくなり(同時にテーブルがディスク上で断片化する) のにしたがって、すぐに変化していきます。 しかし、追加のメモリ( Sun v40z 用メモリー 2GB DIMM 4つ) が今すぐにも得られる見込みなので、それを心待ちにしています。

つけ足しですが、以前の SETI@home クラシック用データサーバだった (古くて大きな Sun E450) は、昨日のサーバクローゼット再構成の仕事の中で、 まだとても有用であると判明しました。 それはかなりの大きさがあり、頑丈な車輪が ついているおかげで、研究室からサーバクローゼットへと 重いラック仕立ての機器を運び込むときに、台車として完璧に用をなすのです。

 
March 30, 2006 - 00:30 UTC
本日の停止時間のうちに、新しい(しかしとても音の大きな)ハードウェアを サーバクローゼットの中に移動しました。 それは、なにをおいても、 この1年かそこらの間 BOINC 主データベースを動かしている Sun v40z と、boinc.berkeley.edu 用の ウェブサーバ および alpha 版プロジェクトを 動作させている Dell linux サーバの 2つです。 一方、クローゼットの中から運び出したマシンは、 クラシック版 SETI@home の サブ科学データベースを受け持っていた cyclops (Sun 450)です。 まもなく、その古いデータをバックアップしてから、 落とし直します。
 
March 27, 2006 - 23:30 UTC
当プロジェクトは、また別の良くない症状におちいっています。 リザルト/ワークユニットの待ち行列が、時間がたつにつれ大きくなりすぎました。 これらの待ち行列がすこしでも短くなるように、システムの活動を停める必要があります。 あまりにも多くのリザルトレコードを保持するがゆえに余分に生じた負荷を、 プロジェクトのデータベースが処理できなくなってしまい、その間に ワークユニットを格納するディスク領域が足らなくなってしまったのです。 というわけで、新しい仕事を送りだすことは、そのための領域が確保できるまで行えません。
 
March 21, 2006 - 20:00 UTC
手短な状況報告: お気づきかもしれませんが、今、現時点で 当プロジェクトのデータサーバ群への接続の具合が不安定です。 これには2つ理由があります。 1つには、毎週定期的に実施しているデータベースの圧縮とバックアップの 前日に至っているので、データベースの状態が一番良くない日であるからです。 (データベースは断片化が進み、1週間のあいだに脹れ上がっているので、 物理的により小さな領域にきっちり詰め込まれているときに比べると、 データをその中から見つけ出すのにより多くのディスク I/O を必要とするのです)。 2つめの理由は、新しいコンソールサーバに接続するために、 スケジューラを手早く再起動したばかりだからです。

上記の状況のほかは、この数週間は並の忙しさでした。 新しいデータレコーダが完成して試験もしました。 拡張版の SETI@home クライアントはほとんど完成に近づきました。

 
March 2, 2006 - 21:15 UTC
その後、長時間かけて綿密な RAID 再同期処理を行ったところ、 マスター科学データベースのディスクアレイには、ドライブ故障が 3つあることがわかりました。 我々の持っている予備のディスクは、ホットスペア用のディスクが 2つ、取り置きが 1台あります。 ということは、このアレイは RAID 10 なので、データ内容の紛失はないはずだということになります。 しかし、これらの故障したディスクを取り扱うために、再同期の処理には追加の時間がかかったのでした。

しかし、なぜこれほど多くのディスクが故障したのでしょうか。 この装置は少し前に当プロジェクトに寄贈された古いディスクアレイでしたから、 そのディスクはかなり疲労していたのです。 このシステムでも、 すでにいくつか他のディスクが故障した経験がありましたから、 大きな驚きではありませんでした。 ひとたび再同期がすべて終わると(この記事を書いている時点から、だいたい 20分後の予定ですが)、 マスター科学データベースを再開して、そのテーブルを検査します。 (この検査には 24時間かかるかもしれません)。 そして、他のハードウェア検査もします。 それで全部正常なら、アシミレータとスプリッターを再開させます。 なにか異常が見つかれば、その対処のためにまた 1日余分に停止するかもしれません。

 
February 28, 2006 - 21:15 UTC
本日予定していた停止時間には、サーバクローゼットからさらに 2、3台の装置を運び出すはずでした。 (クラシック SETI@home のデータサーバと、古い科学データベースが入っている大きくて重い ディスクアレイが対象です)。 それを安全に遂行するため、つまり、移動する装置を何台かの重要なマシンにたまたまぶつけてしまって、 正常でない停止をさせないように、あらかじめ重要なマシンの電源を落としておきたいと思っていました。

プロジェクトのある湾岸エリアは現在荒々しい冬季にあり、今日の嵐がもたらした雷が キャンパス全体の停電を引き起こしました。 もちろん、この研究室も 朝8時に巻き添えになりました。 サーバ群の多くは支障なく停止しました。 この停電のもとで、とにかく我々は予定の仕事を進め、 クローゼットの整理を終わらせました。 これで、辛い姿勢をとらなくても、ラックの後ろに回ることが再びできるようになりました。

ネットワーク全体の立ち上げはつらい仕事になりました。 というのも、サーバ群はあらかじめ決めた順番で停止・回復をする必要があるからです。 ですから、隠れていたマウントの問題が数多く現れてきました。 (これは、 再起動することでしか解消されません)。 さらに、いくつかのディスクドライブは、 fsck をかける必要がありました。 それでも、プロジェクトのマスター科学データベースを 除いては結局きれいに再起動されました。

マスター科学データベース用のマシンでは、ファイバチャネルのループの1つが生き返りませんでした。 ケーブル不良でしょうか? GBIC がおかしいかな? まだよく分かっていません。 というのも、 その端末装置がブート時診断メッセージの全てを取り出せるほど上手く動かなかったからです。 ラップトップのマシンを接続して、診断メッセージを見ようと hyperterm を使って格闘しました。 今のところ分かっているのは、そのマシンは動いているということです。 説明できる理由はないですが再起動はうまくできました。 それでも、すべての メタデバイスは再同期が必要でした。 この再同期処理には、最大 24時間かかるかもしれません。 その間、マスター科学データベースは停止します。 ということは、 スプリッターとアシミレータは動作できないということであり、 そのかなり長い停止が終わるまでに、おそらく送出する仕事に事欠くでしょう。 なんともはや、そういうことなのです。

 
February 28, 2006 - 00:30 UTC
我々がどこかに消え去ってしまったと思われないように、手短に記事の更新をしておきます。 我々は、大がかりな後片づけの期間に突入していました。 つまり、 プロジェクトのサーバ用クローゼットに新しいマシンを入れる準備として、たくさんのマシンを移動しました。 システム全体をばらばらに分解していましたので、この際、全サーバの /usr/local 以下を 掃除し、古い版のソフトウェアを更新するなど、色々のことを我慢してやっても良かろうと判断しました。 当然、どこもかしこも動かなくなりました。 この二週間ほどの間、小さな不具合をあっちで直し、次はこちらという具合の もぐら叩きゲームに時間を費やしていました。 これらの不具合のいくつかに、気がつかれたかもしれません。 例えば、日替わりのはずの「参加者の紹介」は、パスの設定がおかしくなって、 1週間ほど変化しなくなっていました。

それ以外にもいくつか小さな問題がありました。 アシミレータの1つは、 エラーメッセージも出さずに異常終了しつづけました。 デバッグに少々苦労した後、やっとそれはデータベースの中に壊れたレコードが 1つ あったためだと分かりました。 しかしそれ以外は、ゆっくりとですが着実に進捗しました。 新しいデータレコーダはもうすぐ用意ができます(現在、ストレス・テスト中です)。 さらに、明日は古いサーバをもっとたくさんクローゼットから追い出す計画をたてています。

 
February 16, 2006 - 23:00 UTC
本日、もう一度データベースのバックアップと圧縮を素早く実施した後、 MySQL の版を再びアップグレイドしました(最新の 4.1.x になりました)。 このアップグレイドで問題は発生せず、いくつかの問題が解消されたようにみえます。 もっとも顕著なのは、参加者の皆さんが、"merge computers" の機能を再び このプロジェクトのウェブサイトで使えるようになったことです。 この機能が発行していた問合わせが、このシステムを動かない状態にしていたことがありました。
 
February 7, 2006 - 23:00 UTC
この数日のうちに2回ほど停止をいたしました。 一つは意図せぬものでした。 前にも書いたように、プロジェクトのウェブサイトが持つ "merge computer" 機能に関連して、データベースのロックに問題が残ったままなのですが、 うっかりしてこの機能を有効な状態に戻してしまったために、停止させてしまいました。
 

昨日は、いつも実施しているデータベースのバックアップと圧縮を行いました。 処理能力の問題をなぜ抱えているのかを解明する作業を続けるあいだ、 このような停止を週に2回実施しようとしています。

本日は、ワークユニットを格納しているディスクアレイの一部であった ディスク筐体を1つ交換しました。 再起動してもシステムが古いディスクを認識しようとしなかったことを除けば、 この作業は面倒を起しませんでした。 ついにこの問題の原因が突き止められました。 システムの qlogic 製 ファイバチャネル・カードの設定を「リフレッシュ」 してやらねばなりませんでした。 このために必要だった操作は、 コンソールを装置につないでBIOS画面に入り、なにもせずにすぐに終りにする というだけのことです。 いずれにせよ、このシステム全体は稼働状態にもどり、 走っています。

 
February 7, 2006 - 23:00 UTC
SETI@home 拡張版が使えるようになると、このプロジェクトのサーバ負荷は大きく軽減されます。 というのも、拡張版でのワークユニットは処理するのに時間がかかるからです。 (処理量が多くなりますから、ワークユニットあたりの功績(credit)も、 それを反映して大きな値になります)。 しかしそれまでは、このプロジェクトのサーバにかかる負荷状況はしだいに 悪化していきます。 具体的には、毎水曜日に稼働を停めて 実施していたデータベース・テーブルの圧縮・バックアップ処理は、 一日前にずらさざるを得ませんでした。 もしかすると、この大きな トラフィックをなんとかするまでの間に、停止時間を週2回とる スケジュールに移行するかもしれません。

先週はその他にもサーバに関する問題がありました。 ディスクのリモートマウントのゴミ(stale mounts) を掃除するために、いくつかのサーバを 再起動しなければならなかったとか、そういう諸々のことです。 空調の聞いたクローゼットへ新しい本番マシンへ押し込むため、 クラシック用バックエンドサーバを停止・転用させる仕事を精力的に進めています。 新しい本番サーバの温度が上がりすぎて、もう長く待っていられないほどの量の警告が 表示されるようになってきているからです。 現状では、 BOINC のバックエンド サーバの半分が、人間のためのスペースである狭い研究室にまだ置かれて います。 そこは、うるさいマルチ CPU のシステムを置くようなところではないのです。

本日の停止時間はいつもより少し長くなりました。 古いマスター科学データベースの マシンを停止させていたからです。 これで、おおきな筐体をもつ A5000 ディスク 4台がお役御免になります。 明日には、 前述のクローゼットからこれらを追い出せます。 現在のマスター科学データベースの候補信号テーブルには、 いくつか新規のフィールドを追加しなければなりませんでした。 この影響で、この記事を書いている時点でアシミレータ群は稼働させていません。 新しいテーブル構成にあわせてアシミレータをリコンパイルし、テストしている最中だからです。

 
February 1, 2006 - 22:30 UTC
この月曜に起きたデータベースのクラッシュ事件を、我々は MySQL を本当にアップグレイドするべき時期にきたことの警告として受け止めました。 今まで走らせていた MySQL は 4.0 です。 本日、定期停止時間の最中に 4.1に 上げました。 通常のデータベース・バックアップが済んだ後に作業を開始しましたが、 この種のアップグレイドは手順が単純であったことなどありません。 基本的には、新しい版を tar で展開し、あるべき場所へシンボリックリンクの指す先を変更してから 再起動するわけです。

バックエンドのプロセスを1つずつ個別に試験していきました。 それぞれは皆上手く動作しましたので、全部一緒に動かしましたが、 とたんにデータベース・サーバが行き詰まりました。 新しい innodb テーブルのロック問題に何らかの関係があると推測して、 関連するパラメタを手直ししました。 同時に、いくつかインデクスを再構築も したのですが、結局、効き目がありませんでした。

ついに、ある特定のクエリが出た後に全ての問題が積み上がってしまっていることを 発見しました。 そのクエリは、"merge hosts" の update 操作でした。 この機能は当プロジェクトのウェブサイトのためのものです。 いくつかの理由で別々のものとしてデータベース上は見える 参加者の計算機が生じることがあるのですが、それらを同じものとして束ねて 見せることが参加者にできるようにする機能です。 これが問題を引き起こすなど誰も予測していませんでした。 それで、この機能は問題の詳細が理解できるようになるまで使えないように することで対処しました。 これでうまく行くはずという論理はどんなものかというと、 この機能だけが php 経由で innodb テーブルへの更新をするものであり、 新しい MySQL ライブラリを使う php はリコンパイルする必要があったのかもしれないから、 というものです。 いずれにせよ、このプロジェクトは今は稼働状態に戻っています。 きっと 今晩はこのまま動きつづけてくれるでしょう。

また別の マシン sagan の話です。 このマシンは今は何も仕事をしているわけではなく、 サーバ・クローゼットは暑苦しくなってきていたので、 sagan を本日からずっと停止することにしました。 このマシンは SETI@home 用のデータ・サーバ役を果たしていたマシンでした。 ですから、クラシックで送出された全てのワークユニットと、 受信されたすべての計算結果は、このマシンのイーサーポートを通過しました。 このマシンをこれからどうするか、特に計画は持っていません。 オークションにでも出してみますかね?

 
January 30, 2006 - 23:15 UTC
正午ごろ(現地時間)に、 BOINC のデータベースが止まりました。 。 不整合のある状態になってしまったので、正常な動作をしなくなりました。 こうなるとデータベースは自動的に稼働をやめて、時間のかかる回復処理を始めます。 それが終わった後で我々はこのプロジェクトを稼働状態に戻しました。 このプロジェクトにかかる負荷が増え続けているために、 上記の事態が以前より頻繁におこるようになってきています。 そこで、おそらく今週の後半に MySQL の版をアップグレードしようと計画しています。
 
January 24, 2006 - 22:00 UTC
お知らせしていたように、本日はいくつかのディスクを入換える作業をするために停止しました。 ワークユニット格納用のサーバエンクロージャの代わりの装置が到着しており、 交換は簡単な作業のはずでした。 ところが爆発のようなことまで起こって、それどころではありませんでした。

ワークユニット格納用のサーバを停止するため、スプリッタとダウンロード処理をする 全てのマシンでまずそれをアンマウントせねばなりません。 しかし、 koloth と kryten の 2台であらゆる種類のマウント関連の問題が起こりました。 結局、データの通るパイプを掃除するために、kryten を再起動せねばなりませんでした。 それでも、kryten のシャットダウンには、45分もかかりました。 なぜそんなにかかったのかは、 わかっていません。 リザルト格納用のディスク群が kryten に接続しているのですが、 それらがとても忙しく何かのために動いていたので、電源を強制的に落としたくはありませんでした。

とうとう、そのディスク群が静かな状態に落ち着きました。 ところが、 その後もまるまる 15分 なにも動きがないのです。 我々はとうとう諦めて、 電源を落としました。 そして電源スイッチを ON にもどしたら、こんどは電源がはいらないのです。 もう一度、OFF、 ON と操作してみました。 すると今度は電源ケーブルあたりから煙が立ち上り、 火花が吹き出しました。

うわ〜ぉ。

電源コードはすこし溶けてしまったようでした。 それは捨てて、 新しい電源コードともっと良いサージ保護回路をそこに直接つなげて、 kryten の電源を入れました。 ところが (プシューと音がして) 15 秒もたたないうちに死んでしまいました。 明らかに、電源供給回路が悪いのです。

とても幸運なことに、我々は 予備の E3500 電源供給装置 を地下室に眠らせていました。 それと交換するのは簡単な作業でした。 そして kryten の電源を入れ直して しっかり上手く動きだしました。 これで、とてもほっとしました。 というのも、現時点では kryten のためのバックアップとなる良いサーバマシンはまったくないからです。 慎重にチェックした後、すべてを再マウントして、とうとう稼働状態にもどすことができました。 (訳注。 やれやれ)。

 
January 20, 2006 - 23:30 UTC
プロジェクトのマスター科学データベースの合併処理が完了しました。 SETI@home の クラシック版および BOINC 版の両方のクライアントから戻ってきた 検証済の候補信号のすべてが、1ヶ所のサーバにまとめられました。 これで、我々は次の段階の科学分析プログラミングを開始するかもしれません。

合併処理の最後の段階は月曜に開始しました。 それは予想より長くかかり、 送出する仕事が足りなくなってしまいました。 仕事がなくなった状態は、 まる 1日におよびましたが、今、仕事を提供するように稼働状態に戻しました。 合併処理は実は昨日のうちに終わっていました。 しかし、新しいスプリッタとアシミレータ のコンパイルに問題が発生したため、新しい仕事の生成が今し方までできなかったのです。 もちろん今までの長引いた停止の後と同様に、サーバ群全体が「遅れを取り戻す」 までにしばらくはかかるでしょう。

 
January 17, 2006 - 23:30 UTC
データベース合併処理の最後の大段階が今朝始まりました。 アシミレータとスプリッターを現在停止させているのはこのためです。 要するに、先月(合併処理を始めた時点からの期間に) 集約されたデータを全て今、合併させています。 この処理には2日ほどかかるはずです。 この長さに渡って送り出す仕事が蓄えられている分で 充分であることを願っています。

長い週末の間、接続の問題がいくつかありました。 負荷が高くなったときには、 アップロードとダウンロードのサーバの両方で、オートマウンタに問題がおこり、 突然マウントした先のいくつかが不規則にはずれてしまいました。 これが生じてもアップロードとダウンロードのサーバは機能しつづけますが、 いくらか格落ちした状況で動作することになり、結局は再起動が必要になってしまいました。 また、フィーダ・プログラムにはまだ、共有メモリーセグメントで行き詰まるというバグがあるので、 送出する仕事を充分にはキャッシュできません。 これら両方の問題は調べている最中です。 さらに、研究所のファイアウォール/ルータには解決がのびのびになっている問題があり、 研究所の管理者が担当しています。 だいたいのところ、事態はかなり改善されて現在にいたっていますが、 いつものように残務を消化するための期間が2〜3日必要かもしれません。

良い話としては、クラシック版のデータサーバを停止しましたから、 Cogent が提供する 数少ない貴重な IP アドレスの 1つを空けることができました。 そこで、プロジェクトのスケジューラを我々専用の Cogent 回線 のほうに移そうとして作業をしています。 そうすれば、研究所のルータからその分の 帯域幅を外せるので、上記の問題があっても影響をうけずにすむようになります。

 
January 12, 2006 - 18:30 UTC
今朝、手早くデータベースの圧縮とバックアップをもう一度行いました。 2時間しかかかりませんでした。 というのも、プロジェクトのデータベースは、 今や現運用が必要とする最低の大きさになっているからです。 追加でデータベース用サーバマシンの BIOS 設定の変更のためにリブートする時間をかけました。 (この BIOS 設定変更は、それ自身無害ではあるものの、このサーバのログをいっぱいにしてしまう うるさいメッセージを消すために行いました)。

作業を早めに始めたのは、だめになった UPS 用バッテリーの 交換用のバッテリーが到着していることを期待してのことニでした。 しかし、今朝までには到着していませんでした。 もし到着していたら、 この停止時間のうちに UPS を使いまわして交換する作業をしたはずです。 多分次回に実施することになります。 いずれにせよ、もう全てがきちんと動作していて残務も消化しましたから、 データベースの圧縮とバックアップのための停止時間は、定例の毎水曜に戻します。

注目すべきことに、このプロジェクトでは 1日ごとに 120万個の リザルトを処理できています。 この数値は、当初我々が期待していた 処理可能能力である 100万個/日 をかなり上まわっています。 しかし、明らかにプロジェクトのサーバ群は無理をしており、 何かが起きたら 1ヶ月におよぶバックエンドの沈滞症状におちいる可能性があります。 将来の SETI@home アプリケーションは、計算処理に今より長い時間がかかるワークユニットを採用しますから、 それが助けになるでしょう。 また、いつかはハードウェアを新調できればと思っています。 データベースの複製サーバを新調したいです。 そうすれば、現在のような定期的な停止をしなくて済みます。

マスター科学データベースの合併処理は、主な部分が完了しました。 合併処理の最終段階を実施する停止期間について、その形態と停止機能範囲の計画を行っています。 以前の技術ニュースで述べた予想とは異なり、この作業のための停止は 1日以上必要かもしれません。 この停止期間を我々は「部分的な」停止にしたい (つまり、参加者はその期間、 アップロードとダウンロードができるようにしたい) のです。 そのためには、 「完全停止」する期間がほとんどなくなるくらい最小化できるように、 慎重に計画しなければなりません。

その他の愉快なニュース: クラシックプロジェクトで 「いんちき」をした明白な兆候のある参加者について、 その功績(credit) の値を調整する作業を最終的にやり終えました。 クラシックのプロジェクトでは、 実際の仕事をせずにシステムを騙して功績を得ることがとても簡単にできました。 最終的に、上位 10000名の参加者のうち 約 900名から、功績の一部または全部を除去することになりました。 (これらの全ての参加者は、だいたい 20000 以上の功績(credit)を獲得していました)。 それ以下のところでは、ひどい「いんちき」の兆候を明らかにするには、データが充分ではありませんでした。 (もちろん、残りの数百万の参加者について検査をするためには、時間もディスク領域も充分にありません)。 この調整が済んだ功績値のデータは、まだであれば近いうちに BOINC データベースに反映されるはずです。 これで事件は解決。

 
January 9, 2006 - 21:30UTC
この週末、キャンパス全体に渡ってインターネットへの接続にいくつもの問題が起こりました。 接続が不定期の間隔で失われ、通信できない期間が数分続くということがおきました。 これについてはすでに解決されたと考えています。

BOINC データベースをさらに圧縮しバックアップするために、もう一度短い停止を本日実施しました。 連続しておこなった圧縮処理によって、データベース・サーバのスループットは大幅に改善されました。 技術ニュースの中で以前に書いた理由によって、 プロジェクトのデータベースは 31GB まで脹れ上がっていました。 それはすべて、 BOINC バックエンドシステムの少数の待ち行列に*最近溜まったリザルトのせいです。 1月2日に 25GB まで縮み、5日には 19GB になりました。 今日の圧縮で、とうとう 大きさは 13GB しかなくなりました。

これでバックエンドサーバ群はとてもうれしい状態になりました。 80Mbits/s の速度でデータを送出できており、コネクションの切断も起こっていません。 初めに起こる混雑状態を抜け出したら、サーバ状態の計数を再開することができるかもしれません。

一方、マスター科学データベースの合併処理は終盤に差しかかっています。 スパイク信号とガウシアン信号のテーブルはすでに合併を済ませました。 残っているのは、パルス信号とトリプレット信号のテーブルです。 さらに、12月中旬ごろから送られてきている リザルトと候補信号の整理を 最終的に実施しなければなりません。 この作業のための停止期間と停止機能範囲(あるいは停止しなくて済む可能性も含めて) については、これから決定するところですが、それほど劇的なものにはならないでしょう (つまり、おそらくは 1日以下の停止、もしかすると数時間で済むかもしれません)。

 
January 5, 2006 - 23:30 UTC
一日半の長い停止の後、このプロジェクトを稼働状態に戻しました。 この停止の間に、12月初旬と同じレベルにまで BOINC データベースを掃除しきりました。 もちろん、BOINC クライアントが一斉に仕事の要求をこのプロジェクトのサーバに投げてくるので、 サーバの動きはのろくなり、痛みを伴う期間が生じることになります。 今までいつもそうだったように、結局はこの期間を乗り切ることができるでしょう。 一方で、マスター科学データベースの合併処理はとても順調に進んでいます。 リザルトと候補信号のテーブルの複写が予想以上に速く進んでいるのです。
 
January 4, 2006 - 21:30 UTC
今は、データの流れる「パイプ」を掃除するため自ら課した停止時間のただ中です。 BOINC のデータベースに圧縮処理を月曜に施したおかげでかなり良くなりました。 最後まで残っていたやっかいな残務の待ち行列がなくなるほどにまで改善されたのです。 しかし、我々が望んでいたほどには速くなっていません。

いくつか数字をあげてみましょう。 BOINC のデータベースは、全体をアンロードして圧縮なしの ASCII ファイルにすると、 大きさは通常だいたい 17GB になります。 これほどの大きさになるのは、 主に膨大な数のワークユニットとリザルトのテーブルが含まれているためです。 アシミレータとファイルデリータの問題のせいで、12月 21日までにデータベースの 大きさは 26GB に達しました。 12月 28日 には 31GB でした。 古いワークユニットと リザルトを消せないために、プロジェクトのデータベースは通常の大きさの約2倍までになってしまいました。 まったく酷い状態にありました。

新年に入って少し回復し、月曜に行った圧縮処理で大きさは 26GB にまで戻りました。 それでも、百万個のワークユニットと四百万個のリザルトの残務を抱えていましたから、 それを消し去るまではそれ以上データベースのサイズは小さくなるはずもありません。

今朝、プロジェクトのスケジューラを停止し、溜まっている待ち行列が最終的に消えるようにしました。 これがすっかり済むには明日の朝までかかります。 今後数週間に渡って改善しないかと見守っていくよりも、 ぐっと我慢してこの症状を消し去ることを選びました。 待ち行列群の長さがすべてゼロになったら、 もう一度すばやくデータベース圧縮とバックアップを行い、稼働状態に戻します。

 
December 20, 2005 - 00:30 UTC
この数日小さな騒動がたくさんありましたが、全般にわたって概ね順調に運用されています。 ワークユニット用のディスクが満杯に近づいてきていたので、ワークユニットの生成を 金曜日には抑えなければなりませんでした。 領域の空きをつくろうと作業している間に、 そのディスクの 1つのパーティションが故障して短時間の停止を引き起こしました。 (さらにその修理のため今朝も短時間の停止をしました)。 その上、土曜には当プロジェクトが使っている ISP 接続で 2時間ほど、 一種のルータ循環問題が起こりました。 今日は、スプリッターに食わせるためテープを待ち行列に置いたのですが、 そのいくつかは結局中身が空でした - そのため、スプリッターはそれを処理しても何も生成しませんでした。 ですから一晩は送出するリザルトが少々乏しくなるかもしれません。 しかし、明日には回復します。
 
December 17, 2005 - 01:00 UTC
昨日、SETI@home クラシック プロジェクトを停止しました。 しかし実際のところは、 すべてのサーバがまだ動いたままです。 新しいワークユニットを送出するのを止めて、古いクライアントに対して 送るメッセージを BOINC へ切替えるよう促すものに変えた、これだけの変化です。 この切替えを実施したとき、幸にも BOINC のバックエンドサーバ群は完璧に動作してくれました。

上手くいっているといっても、それはマスター科学データベースの合併処理の最中に我々がまだいるという 事態は除いての話です。 合併処理は現時点で、25% まで済みました。 この処理のおかげで、 アシミレータによってまだデータベースに組み込まれていない「遅延した」ワークユニットが、 今まだ、ぼぼ百万個あります。 それらは、サーバ状態ページの「取込み待ちのワークユニット (waiting for assimilation)」 キューには現れません。 これらのワークユニットは、合併処理を始めた最初の数日間に溜まったものです。 しかし、そこでデータベースを切替えたので(以前の記事参照)、今になって 取込みを行う前にいくらかのデータベースの後片づけを必要とします。

1テラバイト容量の記憶装置がこのプロジェクトには1つしかなく、遅延させられた ワークユニットはそのうち、350GBを占めています。 さらに、新規参加者の流入が続いており、 (それらがワークユニットを要求する量が増えているため)、このプロジェクトの ワークユニット用記憶装置はほとんど満杯です。 前回、満杯の事態に陥ったときには、長さゼロのワークユニットがクライアントに送出してしまい、 結果的には害のない悩みで済んだものの、まずいことになってしまった経緯があります。 本日、短い時間の間スプリッターを停止して、アシミレータとデリータがすこしばかり追いつくようにし、 新しい仕事のための空き領域ができるように仕向けました。

より多くの記憶領域をあけるため、遅延させられたワークユニットを別の記憶装置に移動させてしまうよう手を打っています。 この処理は新しい仕事をスプリッターで作るのと同じ速度で動くようにしていますから、 問題の記憶装置を近いうちに満杯まで使い切ってしまうことは決してないでしょう。 (現時点で、その記憶装置の使用率は 98%。 その値は下がりつつあります)。

 
December 13, 2005 - 06:00 UTC
よし、当面のサーバの問題に関してはジャングルから抜け出しました。 このプロジェクトでは多くの場合そうなのですが、本当の問題点は現象の陰にうまく隠されていただけだったので、 最終的な解決策は基本的には単純でした。

12月5日、月曜の朝早くから、当プロジェクトのアップロード・ダウンロード用サーバである kryten への接続が切れるという現象が起きはじめました。 より細かい説明はすでに載せた記事をご覧ください。 サービスを載せる場所(マシン)を次々に入換えましたし、この大騒動にウェブサーバを1台追加もしました。 ファイルシステムのチューニングをして、Apache の設定もいじくりました。 しかし、 これだけやっても、効果がありませんでした。 もしかして、DOS 攻撃をうけているのでは? と、調べて見ましたが違いました。 プロジェクトのデータベースが、性能の隘路だったのでしょうか。 いや違います。

進捗が芳しくなかったのは、同時にマスター科学データベースの合併作業もやっていたからです。 おまけに、修正を加えるたびにサーバの再起動が必要だったり、 うまく作業が進んでいることを確かめるために、長い時間待たねばならなかったからです。

金曜日までは決定的証拠を手にしていませんでした。 その時点で、 マシン kryten は アップロード処理だけをやっていました。 すなわち、 ソケットから読みだしたデータをローカルディスク上のファイルに書き出す処理です。 このハンドラのどこが問題なのでしょうか。 我々はその ファイルアップロード・ハンドラ (file_upload_handler) を FastCGI を使うプロセスとして書き直しました。 私、Matt が 書き直しを担当し、Jeff がどのようにコンパイルするか考え出しました。 しかし、それは動作しませんでした。 この週末は、 このアップロードハンドラは置いておいきました。 そして、 より多くのリザルトによる混乱でアップロードの問題が悪化しないように、 ワークユニットのダウンロードを止めました。

月曜になってプロジェクトのスタッフ全員が戻ってきたとき、 David はバックエンドサーバのコードに小さな最適化を行いました (一組の冗長な fstats 呼出しを取り除くというもの)。 そこで私はとうとう思い出しました。 FastCGI で動作する場合、printf(x) と fprintf(stdout,x) は、大いに違うものだということを。 で、この午後、例のファイルアップロード・ハンドラ を FastCGI で動かすことができました。

このファイルアップロード・ハンドラはプロジェクトのデータベースにはアクセスしないものですから、 我々は多くの効果を期待していたわけではありません。 このハンドラは基本的には、 送られてきたファイルをソケットから読み出して、ディスクに書くだけです。 ですから、ハンドラが FastCGI 化されても、プロセスが大量に生成されることによるオーバヘッドを節約できる、 これだけのはずです。

ところが、これが充分過ぎるほど効いたのです。 以前は、毎秒、数回のアップロードを処理する程度の能力でした。 しかし、この FastCGI 化したハンドラは、毎秒 90 回以上の処理能力を いきなり発揮しました。 1、2時間のうちに、1週間たまっていた残務を消化してしまいました。 もちろん、これによって、アップロードに成功したクライアントプログラムは追加の仕事を求めますから、 プロジェクトのスケジューラには新しい圧力がかかります。 明日の朝にはすべてが元どおりになってくれるのではと、我々は想像しています。 ただ念のために、数個のバックエンド・プロセスを今夜はずっと止めておきます。

その一方、バックグラウンドでは、 マスター科学データベースの合併作業がゆっくりとではありますが、滞りなく進んでいます。

 
December 8, 2005 - 03:00 UTC
この数日、当プロジェクトのアップロード・ダウンロード用サーバで、 接続が切れてしまう現象が続いていました。 このため、巻き込まれた方々皆さんをイライラさせておりました。 また、我々はマスター科学データベースの合併作業の第一段iii階を完結させようとして手一杯でした。

アップロードとダウンロードを別のサーバに分担させたおかげで、 現時点では仕事を取りに来れば誰でも取れます。 この状態はまだサーバ状態の表示をするページに反映させていませんが、 現状は、両方の仕事をこなせるマシンをなんとか手に入れるまでの仮の解決でしかないかもしれません。 そうです、クラシック版のプロジェクトの処理量が減るに従って、 より多くのサーバ入換えがあるかもしれませんから。

今のところ、アップロード用サーバで接続切れがまだ生じています。 けれども、 良いニュースとして、ワークユニットのダウンロード 1回に対し、 4回のリザルトのアップロードの処理をこなしているということが分かっています。 ということは、アップロード・サーバは順調に残務を消化しつつあるということです。 この記事を書いている時点では、毎秒 約 35個のリザルトを受信し、毎秒 約 8個のワークユニットを送出しています。

マスター科学データベースの合併作業では、思わぬ障碍に数回つきあたってしまい、かつ、 元の状態にもどるには作業を進めすぎていました。 作業スペースが不足してきたので、 予備の計画を使うことにしました。 つまり、3つめのデータベースを作るのです。 新しいワークユニットとリザルトはこの新しい 3つめのデータベースに追加されるので、 今までの 2つのデータベースの間でデータを移動する作業をゆっくりと、 時間的切迫感を感じることなく実施することができます。 こうした結果、合併作業の計画は少々複雑化してしまいますが、 当座の緊張を大いに減らしてくれます。

 
December 6, 2005 - 04:30UTC
新規参加者の流入によって、データの流れが滞ったのは致し方ないところです。 二日ほど前に、アップロード・ダウンロード用のサーバ(kryten) で、接続が切れはじめました。 このサーバは新しいコア・クライアントのダウンロードも受け持っていました。 すぐにクライアントのダウンロードをバークレーのキャンパスネットワークを流れるように移動しましたが、 これはよろしくありませんでした。 というのも、これによって通常のキャンパスネットワークに、 20 Mbit/s の追加トラフィックが生じてしまったからです。

月曜の朝これを修正するため、2台めのウェブサーバ(penguin) を BOINC クライアントのダウンロードサーバに振替えました。 以前このマシン penguin は、BOINC のアップロード・ダウンロード用サーバとして稼働していたことがあるので、 Cogent ネットワークで通信するための配線とハードウェアが揃っていました。 それで大した騒ぎにならないうちに、コア・クライアントをダウンロードするトラフィックを キャンパスネットワークから移動することができました。 では、2台めのウェブサーバ役はどのマシンにするのでしょうか。 そう、別の Sun D220R マシン(kosh) はその時点でとても多くの仕事をしているわけではなかったので、 そこに apache/php を動かしてバックアップ用のウェブサーバに仕立てました。 DNS マップの情報がインターネット中に伝播しきるには時間がかかるので、 このプロジェクトのホームページへの接続に失敗した人もいらっしゃるかもしれません。

しばらくの間、マシン kryten で接続が切れる状態がその後も続いていました。 当初は kryten に直接接続されているアップロード用ディレクトリが大きくなりすぎたせいだろう、 と思っていました。 なぜなら、アシミレータ群は稼働状態にもどりつつあったからです (これらアシミレータはアップロードディレクトリの中のファイルは読み出ししかしません)。 調べてみると、アップロード用ディレクトリの中のファイルは、半分が不要になった古いファイルでした。 これらは、ずっと昔の 8 月のサーバ問題から放置されたままのものでした。 良い機会がきたらこれらは消し去ります。 マシン kryten で、ufs ディレクトリのキャッシュ・パラメタを増やしてみましたが、 全く効果がありませんでした。 ということは現在の災難の原因はダウンロード用ディレクトリにあるか (このディレクトリは別のサーバに置かれています)、あるいは まだ見つかっていないデータの隘路がどこかに潜んでいるに違いありません。

これらの問題を診断し対処している間に、マスター科学データベースの合併を本当に開始しました。 このため、バックエンド・サーバのほとんどを停止した状態にしてあり、 合併作業の第一段階が済むまでは停止したままにしておきます(今から 2日ほどかかるでしょう)。 送出用に用意したリザルトの蓄えが、この第一段階の間は足りて欲しいものです。 バックエンド・サーバ群を止めているおかげで、実は kryten を助けることになっています。 kryten にはワークユニットのアップロードとリザルトのダウンロードの仕事が滞積しており、 これらを消化中です。

ここへの書き込みはこれからも増えていきます。 サーバで起きている現在の問題で発見があれば載せますし、 データベースの合併処理が進めばそれも。

 
November 30, 2005 - 22:30 UTC
マスター科学データベースの合併はまったく作業がとまってしまいました。 突然の幸運で全てがうまくうごいてくれないかぎり、 12月15日の SETI@home クラシックの停止をすぎるまでは、 決してこの冒険ともいえる作業に取り掛からないでしょう。 というのも、合併作業を進めようとして修正やら回避策をうつのですが、 そのたびに思わぬ障害物が現れてしまい、プログラムとデータベースの絡んだ悪夢のような事態になってしまっています。

プロジェクトのサーバ用クローゼットは、毎日変化していっています。 SETHI プロジェクトが最近、新型の 2 CPU Opteron システム(4GB RAM と3TB のドライブがついています) を購入しました。 (このプロジェクトは SETI@home の生データを使って、我らの天の川銀河にある水素を研究しています)。 これをサーバ用クローゼットのラックに納めたかったのですが、 マシン kryten (BOINC のアップロード・ダウンロード用サーバ)が、 運び込む道を塞いでいました。 そこで、kryten を第二研究室へ移動しました。 しかし、その前にまず、Cogent の接続とプロジェクト内 ギガビット・スイッチへのケーブルを、 その第二研究室に引き回さねばなりませんでした。 また、この第二研究室には マシン isaac ( 何はおいても boinc.berkeley.edu のウェブサーバ ) と jocelyn ( BOINC プロジェクトのデータベース・サーバ) があります。 これらのマシンを我々は クラシックの方が止まったらすぐに上記のクローゼットに移設したいと思っています。

この移設ができれば、マシン sagan (クラシックのデータサーバ)の電源を切ることができ、 邪魔にならないところに動かせます。 すると、4台 の A5000 ディスクアレイをまとめて移動することができます。 (これらの A5000 は、マシン galileo に接続されているディスクアレイです。 galileo にはクラシック用の今は動かしていないマスター科学データベースが載っています)。 これらの移設作業は、大規模なシェルゲームのほんの始まりでしかありません。

BOINC コア・クライアントのダウンロード用サーバの役を、 isaac から kryten に移しただけでなく、ウェブの負荷バランスを保つために DNS マップと URL群の変更を行いました。 警告メイルの送出はまだ続いている最中ですが、それによって新しいコア・クライアント のダウンロード回数が急激に増加し、ピークは 40 Mbit/s にも届きました。 このダウンロード用サーバである isaac は、 キャンパスネットワークを介してインターネットに接続していたものですから、 当然、他の通信に悪い影響を与えました。 そこで、これらの通信トラフィックをすべて、 プロジェクトの Cogent リンクに移しました。 今のトラフィック量は、 いつ何時でも 100 Mbit/s に近いところで留まっています。 BOINC コア・クライアントのダウンロード、そして、 SETI@home クライアントのダウンロード、SETI@home/BOINC 用のワークユニット、 SETI@home クラシック用のワークユニット、これら全てのトラフィックは プロジェクトが ただ 1本持っている Cogent 接続からインターネットへ出ていっています。 もちろん、クラシックのほうの活動は来週以降には大きく減りますから、 帯域幅の制約が問題になることはないはずです。

 
November 22, 2005 - 21:30 UTC
昨日から、SETI@home の参加者に大量のメイルを送りはじめました。 このメイルで 古いプロジェクトを 12/15 には閉鎖することを警告しています。 今朝時点で活動していると認められる20万人のクラシック版参加者に送信しました。 活動していない参加者には、今、メイルを送っている最中です。

BOINC へ新しく参加者が流入しているため(さらに、タイミングが悪いことに、 googlebots や 他のウェブスパイダーの影響で)、当プロジェクトのウェブサーバの負荷が、 この 12時間ほど異常に高くなっていました。 これを解消するため、結局我々はは 2台めのウェブサーバを増設し、 負荷を分担させることにしました。 DNS 情報の更新がインターネットに広がっていくにつれて、 マシン klaatu (これが1台しかなかった元々のウェブサーバ)にかかっていた負荷が減っており、 一方、マシン penguin (2台めの新ウェブサーバ) の分担する負荷が増えつつあります。 両方のマシンとも、Sun D220R です(2 x 440MHz Sparc, 2 GB RAM)。

この高負荷問題がおきた一つの理由は、ウェブサーバの設定で、必要以上に多くのプロセスを作るようにしてあったことです。 これらが消えずに残り、仕事をしていないスレッドがデータベースをオープンしていました。 その結果、データベースのコネクションが不足してしまったのです。 この状態を示すメッセージを見た参加者も、 負荷が一番高くなったときにはいらっしゃいました。

一見これはデータベースの問題に見えたのですが、実のところ今はこのデータベースで、 10% の性能向上を享受しています。 先週のことですが、 myisam というデータベース・テーブル群から(このテーブルにはウェブ掲示板の他には大したものは入っていません)、 少々メモリを innodb というテーブル群へ移動しました。 (こちらには、 参加者、計算機、リザルト、ワークユニット などの表が含まれます)。 myisam に割り当てていた余分のメモリは要らなかったのです。

ところで、例のマスター科学データベースの合併については(先日の記事参照)、 来週初めを念頭に作業を継続中です。

 
November 18, 2005 - 00:30 UTC
マスター科学データベースの合併(一つ前の投稿を参照)については、再び延期しなければならない模様です。 少なくとも次週、おそらくもっと先へ延期されます (ご存知のように来週は休日 Thanksgiving Day があり、実質は短いですから)。 データ移動のための C++ で書かれたツール群の開発は継続中であり、そのソフトウエアが完全にテストできる前には 拙速に何もしたくありません(もしそうしたら、科学データベースをだめにしてしまうかもしれませんから)。

一方で、この合併作業と、全クラシック参加者へ出す BOINC への移行依頼の大量メイルとは、 組合せて実施しなければなりません。 このメイルの送出を今週開始できたらいいなと思っていましたが、合併処理の遅れで全てがずれ込んでしまいました。 (長い停止期間を必要とするかもしれませんし、 新しい大量の参加者がこのプロジェクトに最初にアクセスを試みたときに失敗することも避けたいので、 当然こうなりました)。 たぶん、大量の依頼メイルの作業は来週初めに開始します。 合併処理はもっと後に始めます。

 
November 16, 2005 - 23:00 UTC
本日は、水曜定例の停止時間にプロジェクトのデータベースおよびアップロード・ディレクトリの バックアップを行い、さらに、この機会をつかっていくつかの装置の移動を行いました。

我々は、別途資金を得て活動している天の川銀河内水素サーベイのプロジェクトと、 親密な関係をもって活動しています(多かれ少なかれスタッフの顔ぶれも重複しているところがあります)。 このサーベイプロジェクトは、SETI@homeのデータを使って活動しているプロジェクトです。 彼らは最近新しく 3U サイズのサーバ(Opteron 2 CPU に 4GB RAMを積み、3TBの SATAディスク付き) を購入しました。 このサーバは我々のサーバ・クローゼットに設置作業中です。 この設置作業のために、 BOINC のアップロード・ダウンロード用サーバをどけて道を開ける必要がありました。 実のところ、混み合ったサーバ・クローゼット内から完全に外に運び出さねばならなかったのです。

例のごとく、これは簡単な仕事ではありませんでした。 というのも、このサーバは、 当プロジェクトのプライベイト ISP との間にネットワーク接続を必要としますし、 ワークユニットを格納するサーバと通信するために、ギガビット・スイッチへも接続しなけばならないからです。 しかし、唯一可能な選択肢は、通常の古い LAN のポートしか設備のないオフィスへと移動することでした。 結局、長い イーサネット・ケーブルを一山購入して、研究所のメイン・スイッチへプラグをつなぎ換えねばなりませんでした。 それでも、この移動作業は問題なく進み、電源をいれると全ては上手く動作しました。 一発で動いてくれたときは、それは嬉しかったですよ。

一方で、マスター科学データベースの合併で起きた、昨日からの問題にまだ取り組んでいます。 (詳細については、一つ前の投稿をご覧ください)。

これら 2つのデータベースを合併させるには、大規模なシェル・ゲームが必要です。 (訳注:シェル・ゲームというのは、3つのうつ伏せに置いたカップのどれかの下にコインを入れて、 カップを素早く動かしてコインがどこにいったか当てさせるマジックゲームの類いのことらしい)。 というのも、データベースのテーブル間には、関連性の制約の連鎖があるからです。 全ての候補信号(スパイク、ガウシアンなど)は、それが属するリザルトに関係があり、 リザルトはワークユニットに関係があり、ワークユニットはワークユニット・グループに、 ワークユニット・グループはテープにと関連の連鎖があるのです。 2つのデータベースを合併するとその処理の中で、テーブルのすべての行の id が変化することになるのですが、 そうであっても、これらの関連性の制約は、そのまま維持しなければなりません。

我々はこの処理をさせるために、とてもたくさんの SQL 文を開発し、テストもしたのですが、 ユーザ定義型の行を含む 2つのテーブルではテストしていませんでした。 それらのユーザ定義型には、それはそれで不定長のリストを含んでいました。 Informix の SQL エンジンはこれらに遭遇して、止まるべくして、止りました。

もちろん、すでに我々はこれらのテーブルへの追加や更新をする C++ のコードをたくさん持っていましたから、 Jeff は今日 SQL の代わりに C++ を使って、合併のための処理に加える修正にずっと取り掛かっていました。 明日には(本日の停止による遅れを取り戻した後で)、再びマスター科学データベースの合併処理を 試みることができるように、この修正の作成とテストが出来上がることを期待しています。

 
November 15, 2005 - 21:00 UTC
(更新 22:45 UTC - 後述の追加部分をご覧ください)

本日、マスター・データベースの大合併の作業を開始しました。 この処理段階の本質は単純です。 つまり、 SETI@home クラシックと SETI@home/BOINC で得られた 科学的データをまとめて、大きなデータベース一つにするということです。 しかし、今回の作業がこの数ヶ月実施してきた作業の頂点となります。

この数ヶ月はなにをしてきたのでしょうか。 まず初めに、 1つのサーバにある全てのデータを別のサーバに移動しなければなりませんでした。 そして、冗長なデータを削除し、以前からのレコードにあたらしいフィールドを追加して内容を入れました。 さらに、データベースを合併させるソフトウエアを書いてテストしました。 これらは、 全てデータベースの関係制約を維持したまま実施しなけばなりませんでした。 要するに、たくさんの整理作業、たくさんのテスト、データベースの全データを主要な処理段階ごとに 毎回バックアップすることでした。

この合併処理が走っている最中は、マスター・データベースへの更新はなにもできません。 このプロジェクトのスプリッター(データベースへ新しいワークユニットを追加します)を停止しましたし、 アシミレータ(これは新しい候補信号を追加します)も停止しました。 この前の週末に、約200万個の未処理のリザルトを生成しておきましたので、 クライアント群をこの停止期間のほとんどのあいだ、仕事に不足させることはないはずです。 アシミレータの待ち行列はもちろん、たいへん大きくなります。 候補信号のデータを除いた他の全ての合併処理が終われば、スプリッターは稼働状態に戻せるでしょう (この時点で、スプリッターが新しい仕事を合併したデータに追加しても、 関係データベースの制約条件を逸脱することは起こりません)。 合併処理がすべて完了すれば、プロジェクトの全機能も稼働状態に戻します。 そうすれば、アシミレータの待ち行列も素早く短くなっていきます。

現在、SETI@home クラシックで行われている科学活動は、 SETI@home/BOINC で行われているものと重複しています。 今回の処理が科学データの最後の合併作業になります。 クラシック・プロジェクトは年内には停止します。

いつかは、このマスター科学データベースをより高速のマシンの上で、 大きくて早いディスクを付けて運用したいと強く希望しています。 そのときがくれば、また停止期間が必要ですが、その作業は 単純にデータを unload/reload するものになります(それに対して、 今回の作業は、unload/reload/correct/merge という作業です)。

追記 (22:45 UTC): ユーザ定義型のカラムをもつ行をマージしようと試みたら、 思いがけない大きな問題に突き当たりました。 とりあえず、合併作業のための稼働停止からいったん復帰して、全機能を今晩は稼働状態に戻します。 おそらく明日の朝から合併作業を初めからやり直します。

 
September 22, 2005 - 18:00 UTC
最近、 BOINC バックエンドのサーバーのプログラムを少々変更しました。 使われていないディレクトリハッシュ関数に関係するコードを取り除きました。 さらに、sah_validator プログラムにあるメモリーリークを見つけようと試しました。 性能劣化にすぐに結びつく効果はないものなので、 このメモリーリークはどちらかといえば無害なものです。 しかし、 それでも直しておくべきものです。
 
September 15, 2005 - 22:00 UTC
本日 あるテストを BOINC データベースサーバーで行うために、 プロジェクトを 1時間ほど停止しました。 すこし前に書いたように、このデータベース・サーバーはよりいっそう速く動作できるはずです。 (すでに今では、必要とされている速度より速くなってはいるのですが)。 いったい何でこの性能にとどまっているのか、Sun 社が調べるのに必要な詳細データを集めるため、 プロジェクト全体を停めました。
 
September 14, 2005 - 19:00 UTC
これを書いている時点では、毎水曜に行うデータベース・バックアップを実施している最中です。 実は今日の停止は 3時間よりすこしばかり長くなってしまいます。 というのは、アップロード用ディレクトリもテープに吸い上げているからです。

このアップロード用ディレクトリは、RAID 化された記憶装置の上にあります。 それでも、破滅的な大故障に遭遇する可能性を考慮すれば、 このディレクトリの内容をデータベースと同期したタイミングでバックアップしておくことは良いことでしょう。 もし、このディレクトリ内のファイルを、特定できないある時点で失ってしまったら、 その後片づけをするのは悪夢のような作業です。 というのは、 データベースの中を調べあげて、ディスク上にもはやないファイルのエントリを見つけ出さなければなりませんし、 それらがいったいどんな状態であったのかを見抜かねばなりません。 さらに次に、 それぞれの場合ごとに適切な対処をしなければなりません。 おまけにもちろん、多くの功績(credit)と科学的計算の結果が失われることでしょう。

しかし今では、全ての待ち行列は健全な状態にあり、処理は追いついていますから、 この2ヶ月の間に滞積していたすべてのリザルトを消化することができました。 この1週間でディスク上のファイル数は、1100万個から350万個にまで減りました。 このサイズになれば、テープにバックアップするのに、2.5時間で済みます。 もちろんそうしないわけはありません。 最初に、それらのファイルを tar ユーティリティを使ってアーカイブしようとしましたが、これはあまりに速度が遅すぎました。 ufsdump を使ってバックアップするほうが格段に速いのですが、 そうし始めたのは停止予定時間内のかなり後ろのほうになってからでした。 というわけで、今回の停止は 30分ほど延長されているのです。

もう一つの話題: サーバー状態 のページ末尾にある用語集を整理し、改善しました。

 
September 11, 2005 - 19:00 UTC
何週間もの間、追い詰められた状態のサーバー群を相手にし、つらい思いの停止期間を経験した後、 このプロジェクトは稼働状態に戻りました。 溜まった仕事を片づけつつあります。 解決策を実施するまでに1ヶ月がかかりましたが、結局はいつも同じことが問題でした。 すなわち、何十ものプロセスが、1つのファイルサーバーに載っている 何千ものディレクトリ内のそれぞれ1万個を超える個数のファイルへ、 不規則なアクセスをする、さらにそのファイルサーバーには、 これらのディレクトリ情報をすべて保持するには充分な量の RAM がないときている、 ということでした。

このファイルサーバーにはすでに最大限まで RAM を搭載してあるので、 すぐに可能な選択肢は、我々の研究室にある部品から2つめのファイルサーバーを作ることだけでした。 そういうわけで、アップロード用とダウンロード用のディレクトリは、 今は物理的に異なる装置に載っており、お互いにもう競合することはありません。 アップロード用ディレクトリは、実際のところアップロード・ダウンロード用サーバーに直結しています。 ですから、結果のリザルトの書き込みは、ローカルな記憶装置になされます。 ということは、システム全体を大きく助けることになります。

これはとても良いニュースではあるのですが、この姿が最終形態ではありません。 新しいアップロード用ファイルサーバのディスク群は古いものなので、 近日中のどこかの時点で、このシステムを全部取り替えたいのです( より大きくて新しくより速いディスクと、より速い CPU のものに)。

 
September 9, 2005 - 17:00 UTC
(この記事は昨日の投稿の更新です)。
 
システムのアップロード・ダウンロード用ファイルサーバーから、 別のファイルシステムへ、全てのリザルトを移動しているところです。 (この別のファイルシステムは、アップロード・ダウンロード用サーバに直結しています)。 できる限り高速な方法で複写を行っています。 とりあえずの推定は少々いかがわしいものでした。 現在、全ファイルの転送処理に総計で、だいたい48時間かかると分かっています。 (米国太平洋時間帯で土曜の朝に終わるはずです)。 済んだら、全てのバックエンドサーバーを稼働状態に戻し、 全ての待ち行列を解消します。 アップロード用ディレクトリはローカルディスクにあるのですから、 アップロードのトラフィックがあっても、ダウンロードディレクトリの動きが鈍くなるはずはありません。 とても大きな性能改善がなされるはずです。
 
September 8, 2005 - 17:00 UTC
システムのアップロード・ダウンロード用ファイルサーバーから、 別のファイルシステムへ、全てのリザルトを移動しているところです。 (この別のファイルシステムは、アップロード・ダウンロード用サーバに直結しています)。 できる限り高速な方法で複写を行っています。 とりあえずの推定では、24時間ぐらいかかります。 済んだら、全てのバックエンドサーバーを稼働状態に戻し、(現地時間の) 一晩中かけて全ての待ち行列を解消します。 明日の朝(同、現地時間)、全てを稼働状態に戻します。 アップロード用ディレクトリはローカルディスクにあるのですから、 アップロードのトラフィックがあっても、ダウンロードディレクトリの動きが鈍くなるはずはありません。 とても大きな性能改善がなされるはずです。
 
September 7, 2005 - 20:30 UTC
現在の苦悩を解決する一時的対策が、もう目の前にあります。 実際、すでに半分は実装済みです。 毎週定例になったデータベース・バックアップのための停止の際に、 古い複製データベース・サーバ(すでに数ヶ月使っていなかったもの)のディスクボリュームを取り外し、 現在アップロード・ダウンロードを全て処理している E3500 マシンに接続しました。 今ちょうど、新しい 0.25TB の大きさの RAID 10 ファイルシステムが、 作成・同期処理の最中です。 この処理には 1 日かかるでしょう。

この領域には、アップロード用ディレクトリを全部納めることができますが、 それ以上は入りません。 従いまして、アップロードとダウンロードのディレクトリを、 別々の2つのファイルサーバに分割中です。 このアップロード用のディスクは、 リザルトファイルを書き出すサーバに直結しています。

システムの用意ができたら、アップロード用ディレクトリを新しい場所へ移動します。 これに、ほぼ半日かかると推定しています。 移動の最中、全てのサービスを停止します。 もう、すぐにでもこの移動作業が始まるかもしれません。

気をつけていただきたいのは、この処置が恒久的な修正にはなっていないものの、 新しいクライアント(あるいは新しいハードウェア)が到着するまでに、 できるだけ早くなにかの対策を打たねばならないということです。 できれば、アップロードのほうだけでなくて、ダウンロードも含めた両方のディレクトリを、 サーバー直結の記憶装置へと移動させるべきだったのでしょうが、 それに充分なディスク領域を我々は持っていないのです。 さらに、使おうとしているディスクは古いものなので、潜在的に故障率は高いといえます (この RAID システムには、数個の活性交換が可能なディスクがついています)。 しかし、待ち行列を消すことが上手くいっていないために、空き領域は減りつづけており、 もう我々には他の選択肢はありません。

 
September 4, 2005 - 23:00 UTC
ご想像のとおり、リザルトとワークユニットを置いてあるファイルサーバが、 なぜか分かりませんが読み書き動作が遅いので、まだ苦しんでいます。 かっては、このサーバはもっと良く働いてくれていたのに、 何が変ってしまったのか我々には分かっていないのです。 たぶん、新しい参加者が押し寄せてきたため?でしょうか。 本日、いくつかの設定変更を試してみましたが、どれも効果がありませんでした。 たとえば、いくつかのサービスを Solaris 9 マシン群から、 Solaris 10 マシン群へと移動しました。 Solaris 10 マシン群は、 初めはそのファイルサーバへのアクセスがとても速いように見えましたが、 実際の負荷をかけてみると速くはありませんでした。 Linux マシン群もこれらのマシンより大して速くアクセスできません。

我々が試したことがどれも役に立たなかったのは、基本的に、 そのサーバ上の nfsd デーモンがいつもディスク待ち状態になっているからです。 たとえ世界最速のマシン上に、バリデータやアシミレータなどのプロセスをいくら追加したとしても、 このディスク群が処理保留状態であるなら、何の改善もありえません。

しばらくの間、待ち行列群はほとんど変化がなく、 バックエンド・サーバ群はそのうちの一部しか走っていなかったので、 再びこのファイルシステムは満杯に近づいていっています。 ということで、大問題は、「これに対してどうするつもりなのか?」です。

当プロジェクトの掲示板で、何人かの方が示唆したのは、 アップロード・ダウンロード用ディレクトリを、異なるサーバに分割して置くことでした。 これはいままでもずっと、我々の計画にあったのでですが、 ハードウェアが不足していて実施できないのです。 私たちの周りには、すぐに使える 1テラバイトのストレージは転がっていません。 ある程度の空きを用意するために、 多くの資材をいろいろな場所に整理・移動する計画を立ててはみましたが、 結局のところ、新しい領域にアップロード・ダウンロードディレクトリを複写するためには、 きっととても長い停止期間を必要とするでしょう(ぞっとしますね)。

より良い一つの解決法は(同時により早い解決法でもあるのは)、 科学計算をより多く実施するような、 新しい SETI@home/BOINC クライアントを公開することです。 (チャープ・レイトの分解能を大きく上げて計算します)。 すると、ワークユニットの計算により長い時間がかかります。 この策は参加者の功績(credit)量に影響を与えません。 (BOINC の功績の値は実際の計算量を元にしており、 もっと恣意的なワークユニット数を基準にしていないからです)。 それでも、プロジェクトのサーバにかかる負荷量は、この方法で 75% も減ります(もっと減るかもしれません)。 それはもちろん、処理対象のワークユニットとリザルトが、 より少なくなるからです。 こうすると、我々のバックエンド・サービス群すべてに、良い効果がすぐに現れるはずです。 そして、よりストレスの少ない状況で、ディスク待ちの問題を診断することができるようになります。 我々はまだこの新しいクライアントをテスト中ですけれども、 この仕事を主務としている科学者とプログラマが、近いうちに休暇から戻ってきます。

また別の方々からは、SETI クラシックを単に停めるという方法を取るべきだと言われました。 追加のハードウェアをそこから得るためです。 この方策を採用するとしたら、 それはすくなくとも BOINC のユーザインタフェースを改良し終えて、かつ、 前述の新クライアントを公開した後でなければ、あり得ません。 その上、クラッシックのプロジェクトが停止した後も、すぐにそのサーバを流用できるわけではありません。 プロジェクトの後処理として、最善の場合でも、1ヶ月間のデータ管理の仕事の後でしか、 クラシックのサーバ群を使うことはできません。 その後で、OS アップグレードや、 ハードウェア設定などに最善でも一週間かかるでしょう。 早い話が、選択肢にならないのです。

 
September 2, 2005 - 21:30 UTC
現状報告の更新: 1週間という長い期間停止したので、その分、回復にとても長くかかりました。 (現地時間の) 今朝、やっと TCP コネクションの切断が起こらなくなりました。 (つまり、今はこのプロジェクトのスケジューラやアップロード・ダウンロード用 ハンドラに要求を出せば、それら全てを処理できるということです)。 しかし、しばらくのあいだは、新しい仕事送出のための待ち行列は空になってしまっています。 これは必ずしも仕事がなにもないということではありません。 新規の仕事を蓄えておけるほど速く仕事を生成できない、ということを意味しているだけです。 同様に、検証待ちリザルトの待ち行列は長くなっていっています。 (従って、待ち状態になったリザルトを提出した参加者へ功績(credit)を付与するのが遅れるということを意味します)。

それでも、これらの待ち行列はどちらも近いうちに状況が好転し、 良い方向に向かう兆しがあります。 この状況を週末にかけて我々は注視します。 もし全てうまくいけば、リザルトの取込みを行うアシミレータも稼働状態にするかもしれません。

気をつけていただきたいのは、 SETI@home クラシックのデータサーバをこの数日停止していることです。 これしているのは、 定期的な OS のパッチあて作業と、 奮闘している BOINC のサーバ用に帯域幅を確保するのを助けるためです。

 
August 31, 2005 - 20:45 UTC
昨日、公開用サーバ群を稼働状態に戻しました(戻したのは、スケジューラ、 アップロードおよびダウンロード・サーバ、バリデータです)。 アシミレータとデリータの待ち行列は全部消えてはいなかったのですが、 そうしました。 一週間は充分に長かったと感じています。 他に残っている問題を見つけるための診断データをより多く取れるはずです。

期待どおり、別の問題をみつけだしました。 アップロード・ダウンロード用の サーバがとても忙しい状態にあり、NFS のマウントが不規則にはずれていました。 はずれるマウントの中には、/usr/local のように必須のものも含んでいます。 このため、 file_upload_handler はその晩ずっと、 ふらふらとした動作を続けていました。 今朝、 (データベースバックアップのため実施している毎水曜の停止の後で)、 この問題が automounter の問題であったことを突き止めました。 必要なパーティションについて ハードマウントをいくつか設定しました。 その結果、このサーバは大変良い状態で動作しています(それでもまだ、 遅れを取り戻すには、ほど遠いのですけれども。 毎秒、何百ものコネクションが切れており、 幸運な 20から30個/秒の量の RPC だけが通過できています)。

1ヶ月ほど前に上手く稼働していたのと比べてみると、 当プロジェクトは、全般的な性能不足のために、 まだ少々滞りがちです。 この問題を解決するために多くの時間を費やしています。

さらに、説明をしておきます。 期限を過ぎたファイルに関して、 功績(credit)を付与する動作について、私は間違った内容を知らされていました。 正しい仕組みは以下の通り。 標準のリザルト(canonical result)がディスクに残っている限りは、 (つまり、ファイル消去のためのデリータによって消されないうちは)、 功績が付与されます。 長い停止からの回復中ですので、功績が失われる危険を最小にするため、 できる限りファイル・デリータを動かしません。 これはとても難しいことではないはずですが、 古いリザルトをかかえているディスク群の空き領域は、かなりの速度で埋まっていきつつあります。

 
August 29, 2005 - 23:00 UTC
この 1週間そうであったように、まだこのプロジェクトは止まったままです。 明日で実に まる 1 週間の停止になります。 私たちは、あと一晩サーバ群を停めて、 残っている取込みと削除待ちの行列を消し去ろうと決めましたが、 何があっても明日のどこかの時点で稼働状態に戻します。 この長い停止に関して、良いニュースと悪いニュースの両方があります。

良いニュースのほうは、検証待ちの行列が全部なくなったということ。 ですから、滞積していた功績(credit)が決して付与されないのではないか、と心配していた人は、 これでとても安心したでしょう。 同様に、 自分の行った計算結果が本来勘定にいれられるべきであるのに、 サーバに届く日時が期限を越えてしまうと危ぶんでいた方々も、 もう心配しなくて済みます。 それぞれのワークユニットがデータベースに残っている限りは、 功績(credit)は付与されるからです。 しばらくの間、 db_purge の処理を停めておきますので、長い停止の後で期限超過した扱いにならずに、 皆さんはワークユニットの計算結果をサーバに返すことができます。 加えて注目すべきなのは、不要リザルトの消去処理は数日前にすでに仕事を終えており、 すでにリザルトを置いてあるディレクトリの大きさが、40% も小さくなっていることです。

次に悪いニュースのほうです。 リザルトを置くディレクトリの大きさがかなり小さくなり、 いくつもの待ち行列が消え去ってくれたので、大方のサーバが暇な状況になっています。 しかし、それにもかかわらず、 取込み処理のアシミレータと ファイル消去のデリータは期待よりとても処理速度が遅いのです。 この 1週間でかなりの処理速度向上が成し遂げられたのですが、まだ充分ではありません。 以前はそれほど明白でなかった NFS の奇妙な振る舞いが発生し続けています。 そこでこれを解明すべく調査を急いでいます。 明日になる前に何に問題があるのか見つけられれば、 と期待しています。

もうひとつ書いておくべき話題があります。 サーバ状態の表示ページに、 小さな間抜けなバグが見つかりました。 スケジューラが走っていなくても、稼働中の表示が続くというバグです。 これは修正しました。

 
August 25, 2005 - 20:30 UTC
古い不要リザルトを消去するデリータおよび バックエンドシステムが、 その遅れを取り戻せるように、 プロジェクト全体を停めて、それらをまる一晩走らせつづけました。 ただ今、全ての努力は古いファイルのデリータに注がれています。 というのも、その処理がもう少しで完了するからです。 (一時間のうちには決着が付きます)。 それが済んだら、バックエンドシステムを立ち上げなおし、 どのくらいの速度で仕事をこなせるようになったか調べます。 (このときは、スケジューラと古いファイルのデリータとの競合はなしで測ります)。 これで待ち行列が素早く短くなるようなら、本日が終わる前に全てを稼働状態にもどせるかもしれません。 さもなくば、明日の朝でしょう。
 
August 24, 2005 - 22:00 UTC
停止している時間がある長さを超えると、 再開後の結果返却のために当システムのサーバへ押し寄せるであろう要求の量は、 おそらくそれ以上悪化することはありません(というのは、ある時点から 参加者だれもが 新しい仕事を待つ状態になるからです)。 という言い訳で、少なくとももう一晩、スケジューラを再び停止します。 この時間で、現在の問題とその他の課題に取組みます。

もう一度、現在の問題点を述べてみます。 (a) 検証まちの仕事が大変多く滞積していること。 (b) リザルトとワークユニットを保持している ディスクアレイが満杯状態に近いこと。 昨晩ずっと、「古い不要リザルト」を削除するデリータを走らせつづけました。 今のところ、古い不要リザルトのうち、70% まで消しました。 (より細かい話については、前回の投稿が下記にありますので、ご覧ください)。

通常行っているデータベースのバックアップを終えたのち、 バックエンドのプロセスを全て動かしました(検証、取込み、および通常のファイル消去のプロセスです)。 これによって、それぞれの待ち行列が短くなるはずです。 実際は、検証をするバリデータの待ち行列だけが隘路になっています。 しかし、その待ち行列が短くなるには、取込み(アシミレータ)と ファイル削除(デリータ)のプロセスが追いついて動作しなければなりません。

 
August 23, 2005 - 22:30 UTC
(現地時間で)今朝、停止する前に、 不要ファイル削除の第1回め(後述)の効果が、 大して現れていないということに 少々困惑させられました。 そこで調べて気がついたのが、昨晩 アップロード・ダウンロード用 ディレクトリを置いてある RAID システムに障害が起こっていたということでした。 このRAID システムは再構成処理を開始しており、そのために低性能なモードで動作しつづけていました。 データは失われていません。

そこで本日の停止で実施する計画内容を白紙に戻し、 ファイルの掃除をする代わりに、その RAID の再構成を早く終わらせるよう、 BOINC の全システムを停めることにしました。 この RAID システムが低性能モードのままでは、プロジェクトは効率的に動きません。

再構成処理が終わる前に、ゆうに晩(現地時間) になってしまうので、 まる一晩は当プロジェクトを停めておきます。 なぜそれほど長くかかるのでしょう?  あのアップロード・ダウンロード用ディレクトリは、 1 テラバイト一杯の大きさがあり、その RAID 装置についている別の 1 テラバイト級のボリュームが再同期処理をしているからです。 再構成処理が終われば、不要ファイルの削除処理を起動して、 眠っている間じゅう走らせておきます(辛抱強く待っていても良いのですが、 これはどんなタイムゾーンに住んでいるかによりますね)。

以上に加えて、我々は待ち行列を解消するための、より攻撃的な計画を立てつつあります。 当初我々が感じていたのは、古いファイル消去と待ち行列の解消のために、 二日以上の停止を伴う作業をしたとすると、参加者の方々に辛い思いをさせるだろうということでした。 特にシステムを稼働状態に戻したあと、 要求に追いつこうとして システム全体がのろのろとしか動かないのは辛いだろうと。 しかしながら、それどころではなくなりました。 アップロード・ダウンロード用の ディレクトリが置いてあるディスクアレイは、危険なほど満杯に近くなっています。 ですから、つらいところですが、すぐに行動を起こさねばならなくなりました。 明日、稼働状態に戻したら、どのような具合であるか調べます。

 
August 22, 2005 - 18:00 UTC
たくさんの「不要な」リザルトファイルを消すために、3時間の停止計画実施しています。 現在、その第一日めの作業中です。 本日の停止期間が終わったら、この投稿の末尾に結果の数値を付け加えます。 それまでは、現状について良く聞かれる問いとその答えを面白く書いておきましょう。

問: 不要なリザルトというのは何処から生まれたのですか?
答: ワークユニットの計算を1つ終えたクライアントが、 そのリザルトをファイル・アップロード・ハンドラに送りつけると、 このハンドラはそのリザルトをファイルシステムに書き込みます。 このファイル・アップロード・ハンドラは、プロジェクトのデータベースとはつながっていません。 その後、そのクライアントはスケジューリング・サーバに接続して、 「リザルト XYZ をアップロードしたので、次の仕事をください」 と言います。 するとデータベースとの接続をもっているスケジューリング・サーバは、 普通はデータベースの中のリザルトの項目を更新し、クライアントにはさらなる仕事を送ります。 ところが、もしアップロードされたリザルトが期限をはるかに超過したものであったとすると、 そのために、データベースの中の対応するリザルト項目がすでに消されている場合があります。 すると、その場合はスケジューリング・サーバはそれ以上の処理は行わないません。 結果として、 リザルトのファイルはシステムの中に残ってしまいます。 この問題はすでに修正されようとしています。 以上の説明を補強する話もあります。 それは、 BOINC を使う参加者が増えるにつれて (新しい参加者が BOINC 版に参加「せざるをえない」ようになってからは特に)、 期限内にリザルトを返せないような遅いコンピュータ、忙しいコンピュータが増えているのだ、 という説明です。

問: それで、この状況のどこが問題なんでしょうか?
答: 不要の古いファイルがとてもたくさんプロジェクトのサーバ上にあるので、 検証の処理速度が遅いのです。 アップロード用ディレクトリにあるリザルトファイルのうち、40% が不要の古いファイルだというのが、我々の計算です。 リザルトを検証するには(あるいは、取込んだり、消去するには)、 対象のファイルの中身を読み出す必要がありますが、 その前にまず、ファイルシステムは「ディレクトリ検索」 という処理をしてリザルトのファイルを探し出す必要があります。 単一のディレクトリ内にファイルが増えれば増えるほど、 この検索処理にいっそう長い時間がかかるようになっています。

問: そのディレクトリがそれほど肥大化した理由は他にはありませんか?
答: はい、実はほかにも原因はあります。 1ヶ月ほど前にマスター科学データベースが壊れるという事故がありました。 回復可能な事故ではあったのですが、何日かは、 そのデータベースへ書き込みができない状態だったので、 データベースへの取込み処理をするアシミレータを停止せざるをえませんでした。 このため、特に古くもない通常のファイルも、通常より長い時間、 そのディスク上に置かれざるを得ませんでした。 この状況になって、 デリータというプロセスに、論理的な誤りがあることに気がつきました。 (デリータとは、取込み処理が終わった後で、ディスク上からファイル消去をするプログラムです)。 ワークユニット と リザルトを ディスクから消去する速度が、同じ速度に設定されていました。 しかし、リザルトは ワークユニットに比べて 4 倍の速度で消去するべきなのです。 (というのは、ワークユニットごとに 4倍の数のリザルトがあるのですから)。 このため、リザルト消去の速度は ワークユニットの消去速度で抑制されていました。 これらの問題は全て修正が済んだので、通常のファイル消去の待ち行列は、 ゆっくりとではありますが確実に短くなっています。 ところが、この状況は検証処理をするバリデータの未処理の仕事の山という問題を悪化させています。

問: 百万個ものリザルトが検証待ちで滞っている状況にどうしたらなりえるのでしょう? この状況は SETI@home/BOINC のシステムは完全に破綻しているということなのでは?
答: ここで、遠近法的なチェックをしてみましょう。 SETI@home クラシック のプロジェクトでは、参加者に功績(credit)を付与し、 その後で検証の処理をしていました。 現在の数字を挙げましょう。 SETI@home クラシック には、 だいたい 5 千万個のリザルトが検証処理を待っている状況で溜まっています。 別の時点では、この数字は 数億個であったこともあります。 それでも、 これに気をとめる人がいなかったのは、クラシックのプロジェクトが、 参加者に功績(credit)をまず先に付与していたからです。 BOINC の検証システムは実はクラシックのものより速度は上で、 より洗練されたものに仕上がっており、今のよくない状況は 前述のいくつかの問題によってもたらされたものです。 それらの問題は全て修正されるか修正作業中です。

問: 不要の古いファイルを消すために、なぜシステムを停める必要があるのですか?
答: そうしたほうが、格段に速く作業が終わるからです。 プロジェクトの全機能が稼働しているときには、 アップロード用ディレクトリにアクセスするプロセスがとてもたくさん動いているので、 意味ある速度で不要ファイルを消去するのは無理です。 もし消去を同時に行ったら、 すべての処理がほんとうに遅くなってしまうでしょう。

 
August 19, 2005 - 17:30 UTC
昨日、古いリザルトファイルを全て削除するには、プロジェクトを だいたい 24 時間停止して処理をする必要があると判明しました。 この停止は 3時間ごとの長さに分けて数回かけて実施します。 というのは、この処理の様子を監視しながら実施したいということと、 長時間の停止をすると遅れを取り戻すための厳しい期間が必要になってしまうからです。 この削除がすっかり終わる前の段階でも、きっと効果が現れて、 バリデータの待ち行列が縮小し始めるのではないかと期待しています。
 
August 18, 2005 - 16:00 UTC
前述の記述ニュース項目で不明確だった点を説明します。 我々は以下の条件が満たされるまでは、 ファイルの消去とデータベースの項目消去にとりかかることはありません。 その条件とは、あるワークユニットに対して標準のリザルトを選択して取込みを行い、 そのワークユニットに関する「全ての」リザルトが、受信され(て検証成功す)るか、 あるいは、締め切り期限を超過してしまうかのどちらかになるということです。
 
August 18, 2005 - 01:00 UTC
バリデータが遅れている主な原因は、アップロード用ディレクトリに ファイルがたくさん有りすぎるということです。 これらのたくさんのファイルは、 削除を待って行列をなしているのですが、デリータのほうも同じ原因、つまり、 ディレクトリが大きすぎるために処理が遅くなっているのです。

さらに、アップロード・ディレクトリにはデータベース中に関係付けうる行を持たないような、 たくさんのリザルトファイルがあります。 これらの関係が切れてしまったリザルトファイルは、 ファイル消去のプログラムによって消されることは決しておこりません。 このようなリザルトができてしまうのは、ワークユニットに対して返却されたリザルト数が 定足数に達して、検証および取込み、ファイル消去(ワークユニットとリザルトの両方)と 最終的なデータベース上の記録の消去が終わった、その後で、1つ以上のリザルトが 到着したときです。 (おそらく、これらのリザルトはラップトップマシンで 間欠的に計算されたがゆえに遅くなったのでしょう)。 関係が切れてしまったリザルト群は、消さねばならない大きなお荷物です。

本日の停止の間に、両方の種類の古いリザルト・ファイルを高速消去する作業を始めました。 まず第一に、データベースに対して、まだ検証作業が残っているワークユニットで最も古いものを 見つけ出す検索をさせました。 次に、そのワークユニットの最古のリザルトの受信日時を データベースで検索しました。 そして今度は、安全を見込んでその日時から 1ヶ月過去の 時点に戻り、その時点よりも古いリザルトファイルを全て消す処理を開始しました。 ところが、上手いこといきませんでした。 予測していた数の 約 25% しか削除の対象にならなかったのです。 詳しく調べたところ、これら消去して良いファイルの 75% は、 安全のために見込んだ 1ヶ月の期間のなかで受信したものと分かりました。 このプロジェクトはこんなにも速く成長しているのです。

しばらくしたら短時間また停止して、消去してよいファイルの全てを消すための 時刻を求めます。 そして、それらのファイルを全て片づけるために、 長時間の停止または何回かの停止を計画します。 停止してこれらの作業をしなければならない理由は、それらのファイルを置いてある ファイルサーバに削除処理がかける負担を考慮しているからです。 我々はこの作業を加速する方法を探しつづけています。 そして、もちろん、 このようなファイルが再び溜まることを避ける方法も探しています。

 
August 11, 2005 - 20:45 UTC
お気づきではないかもしれませんが、米国太平洋側時間帯で水曜の 10:00am ぐらいに、 毎週定期的な停止をしており、この時間にデータベースのバックアップと、 当プロジェクトがダウンしたときだけ必要となる管理上の仕事を片づけています。 本日もそのバックアップを取ってから、現在の処理上の隘路がどこにあるのかを見つけるため、 色々なマシンで一連のベンチマークを流しました。 すでにあたりは充分に付けていたのですが、我々の仮説を具体的な数値で裏づけることができたのは幸いでした。

基本的には、当プロジェクトのサーバ群は期待されている仕事を「こなす」ことができています。 しかし、資源の割当てをいじくると、たとえばあるサーバプロセスを他のマシンで走らせたり、 他の処理が追いつくようにあるプロセスを停止したりといったことをすると、 予想外の結果になります。 バックエンドにあるシステム全体が、 非常に複雑な依存関係の固まりになっているのです。

ともあれ、今日の心配ごとのリストは以下のとおりです。

  • アップロード・ダウンロードのディレクトリの大きさの件:  バックエンド・プロセスのうち数個は、細かいファイル(今回の場合はリザルトのファイルです) がたくさん詰まった大きなディレクトリにアクセスする必要があります。 ファイル数が多ければ、それだけアクセス時間がかかります。 我々はこの問題を解決するため独自に、全ファイルが 1000個のサブディレクトリにばらまかれるようにしました。 これによって、あるファイルを見つけようとするときに、システムはファイル名のハッシュ値を計算することで、 1000個のサブディレクトリのうち求めるファイルがどこに置かれているか分かるようにしました。 普通の状況ならば、この仕組みはとてもうまく機能するのですが、 最近、これらのサブディレクトリが手に負えないほどの量のファイルで一杯になっています。 (そうなった主な理由は、アシミレータをバグ修正とサイエンス・データベース保守のために停止したからです)。

    ディレクトリの枝分かれを増やしても、解決しないでしょう。 ディレクトリサイズの大きなサブディレクトリ群が同様にできてしまうからです。 もちろん、枝分かれをさらにもう一段枝分かれさせることもできるでしょうが、 そのためにはかなりの量のプログラムコードの変更と、さらに、 実装するため長い停止期間を必要とします。 ですからこれも、率直にいってぶざまな解決策になってしまいます。

    ではどうしたかというと、サーバプロセスの配置を入換えました。 これによって形勢を好転させつつあります。 ゆっくりではありますが、今やリザルトファイルが増えるよりも消す速度が上まわってきています。 このほか、ワークユニットとリザルトの消去をファイルデリータがするときに、奇妙なことに 同じ優先度で行っていることを発見したので、修正しました。 ワークユニット 1つに対して、 だいたい 4つのリザルトファイルがディスク上にありますから、 たくさんのワークユニットがあるからといって、リザルトの除去が阻止されては困ります。 あと、かなりの量の「見放された」ファイルがあるだろうということも問題です。 (これらは、 我々のデータベース上は消されたことになっているファイルですが、 いくつかの異常によって残ってしまっているファイルのことです)。 これらのファイルについては次回の停止のときに対処します。

  • データベース用の記憶装置は期待ほどの活躍をしていません:  BOINC の主データベース・サーバ(2 CPU を持つ Sun V40z で 16GB の RAM を積んでいます) に、 RAID 構成の記憶装置 (1 テラバイトの Sun 3510)を付けてあります。 本日の性能測定で、読み書きの処理が、期待していた速度で動いていないことが分かりました。 決してデータベースのスループットが現在時点の問題なのではありあません。 実際、平常時のデータベースへの処理要求量は今回のベンチマークで測定したデータベース・サーバの「限界性能」 に近くなってはきていませんから。 しかしそれでも、サーバ群からできるだけの能力を引き出しておきたいので、 このシステムのチューニングを進めています。

  • インターネット帯域幅の容量の件。  クラシック版 SETI@home と SETI@home/BOINC の両方が、世界へつながる 同一の100 Mbit 通信路を共用しています。 この通信路の上には、 ワークユニットの送出とリザルトの受取り以外のトラフィックは流れません。 2つのプロジェクトの通常運用時の送出トラフィックの総量は、ほぼ 50 Mbits/s です。 しかし、いずれかのプロジェクトが長引いた停止から復帰したときには、 仕事をもとめて 押し寄せる要求量はとても大きくなり、 この帯域幅を使い切ってしまいます。 現在は治まるまで待つほかに我々にできることはありません。 充分な数のクライアントを満足させて要求量が元にもどるまでは、 接続断が起こります。

    水曜の午後、停止から回復するときに、試験的に SETI@home クラシックの運用を 一時とめてみました。 確かに大きな帯域幅が要ることが分かりました。 このときに計測されたトラフィック量は最大 55 MBits/s でした。 クラシック版のサーバと一緒なら、100 MBits/s のパイプを使い切ってしまったでしょう。 このとき、 BOINC のトラフィックは上限を押え込まれなかったので、 平常状態に回復するまでの時間は最小となりました。 我々はもっと多くの帯域幅を得る計画を立てつつあります。

一方、内部ネットワーク通信と他のディスク入出力については、現状、隘路はないと分かりました。 何人かがより高速の CPU をもつ PC を買ったらどうかなど、 いくつかすぐに指摘してくれましたが、実は現在は CPU 能力が不足しているのでは決してありません。 (それを言うなら、メモリネックでもありません)。 結論は、例のディレクトリを掃除する必要があるということです。 現在このプロジェクトは 1日あたり 約 50 万個のリザルトを生成している一方で、 検証している数はそれより少しだけ少ない状況です。 かっての修正とこれからの修正が効果を上げていけば、 作る量よりも多く、検証をこなしていけるようになります。

週に一回の停止時間が今回、かなり長引いたのは、(定期的なパッチ適用作業の対象となった) 今回のパッチの中に、時間のかかる群がいくつかあったためでした。

 
August 4, 2005 - 23:30 UTC
参加者が増えるにしたがって、停止期間から「回復する」のが難しくなりつつあります。 悪い指標となる待ち行列は伸びてしまい、良い指標となる待ち行列は枯渇してしまいます。 現在の焦点はワークユニットとリザルトをすべて抱えているファイルサーバです。

停止期間が終わると、新しい仕事への要求量が途方なく増えます。 ダウンロード・サーバの 100M bit/s のイーサネットの口が主要なボトルネックになるほどです。 クライアントに仕事が供給されるに従い、結局、ボトルネックはファイルサーバに移動します。

送出準備済みの仕事を溜めていた待ち行列は、要求に応えた結果、枯渇します。 ということは、その待ち行列に仕事を再充填するために、 スプリッターが全速力で動作することになります。 これは、ファイルサーバにとても重たい書き込みの入出力操作が起こることを意味し、 今度はそれがすべての動作を緩慢なものにしてしまいます。 この暗雲は晴れるのに極端に長い時間がかかります。

我々は、このファイルサーバのスループットを増やそうとしてきました。 ファイルサーバは時間のかかるディレクトリ参照動作に多くの時間を費やしています。 (リザルトとワークユニットは大きなサブディレクトリに納められています)。 このサブディレクトリは、すでに数千の分離されたサブディレクトリに分割してあります。 この個数をさらに増やしたいのですが、そうするとまた、プログラムコードの修正と、 おそらくもう一度停止が必要になります。

今日の午後、ディスクに負担がかかるほとんどのサービス(スケジューラを含む)を停止し、 ファイル・デリータが少しは追いつけるようにしました。 90分かけても、25,000ファイルのうち、たった15,000ファイルを削除できただけでした。 そういうわけで、すべてを元に戻しました。 実際のところ大して役に立たなかったわけです。 今から、負荷の少ないマシンを何であれ見つけて、それらの上でファイルデリータを立ち上げてみて、 ファイル削除の待ち行列が減ってくれないか試してみます。 ファイル削除がすすめば、ディレクトリサイズが減るので、全般的に処理速度が向上するはずです。

 
July 26, 2005 - 19:00 UTC
先週、この BOINC プロジェクトのデータサーバはついに要求に追いつきました (それは、このサービスを走らせるマシンを、 D220 から CPU とメモリが3倍の E3500 というマシンに取り替えた後でしたが)。 それにもかかわらず、堰を切ったように要求が押し寄せてきた後、 このプロジェクトのスプリッターのほうは、 多量の要求の滞積に対応することができませんでした。

金曜のおしまいになって気づいたことがありました。 ギガビット・スイッチを介して SnapAppliance の装置とやり取りしているマシンはすべて快調であるのに、 LAN を介してやり取りしているマシンでは、定常的に NFS で落ちこぼれ現象を起こしていました。 スプリッターを走らせているマシンを 1つ、ギガビット・スイッチへ接続を変えてみたところ、 その NFSでの落ちこぼれ現象が消え去りました。 これで、 ワークユニットの待ち行列は増加に転じてくれました。 この週末を過ぎて、ワークユニットの待ち行列はほとんど満杯状態に戻りました (ほぼ 500K 個のリザルトが送出に備えて待機しています)。

こんな経験をしたので、SnapAppliance とやり取りをするすべての バックエンド・プロセスが、ギガビット・スイッチにつながるように各種ハードウェアを再構成する作業をしています。 これは厄介な仕事です。 というのは、ハードウェアが絡んでいますし (例えば、ギガビット・スイッチに繋ぐ各サーバには、追加のイーサネット・ポートが必要になります)。 さらに、物理的な配置が問題にもなります(というのも、 いくつかのサーバはギガビット・スイッチから離れたところにあるからです)。 ということは、いくつかのサービスをそのギガビット・ スイッチの近くにあるサーバマシンになんとか移動させる、と近くにあるサーバマシンになんとか移動させる、ということになりそうです。 そういうことになるでしょう。

しばらくの間、アシミレータが要求に追いついていませんでした。 最近、このプロセスを並列化するためにコードを書き加えました (トランジショナーやバリデータと同様に並列化したのです)。 このおかげで、滞積を解消する方向に向かっています。 ただし、わずかずつではありますが。 この状況は大きな問題ではないものの、次のような懸案があります。 (a) アシミレータが遅れると、ファイル・デリータ(ファイル削除処理)も遅れます。 (b) ほかでもないこのファイル・デリータは、 ギガビット・スイッチ経由でやり取りをしていません。 さらに、 (c) 空だったワークユニット待ち行列がこの週末にかけて満杯になりました。 以上が何を意味するかというと、SnapAppliance が、 新しいワークユニットと古い仕事の滞積とによって、 危険なほど詰まった状態になったということです。

では、どうするか・・・ 我々は実際には今朝スプリッター群を停止して、 アシミレータとデリータが少しは追いついてくれないかなと期待しました。 さらに、"古い" マシンである kryten を "penguin" に切替えました。 "penguin" ではより多くのアシミレータとデリータが走ります。 しばらく後に、これらのマシン切替えがサーバ状態のページに現れるでしょう。

さらに実施したことがあります。 このギガビット・スイッチ関連の大仕事の 1つとして、 スケジューラが占めていたポートを明け渡さねばなりませんでした。 このため、 DNS 情報の切替えを今朝実施しました。 これにより、スケジューラのすべてのトラフィックを、 Cogent リンクから切りはなし、Berkeley キャンパスネットへと移動させました。 スケジューラの占めている帯域幅はとても少ないので、 関係する誰にとってもこの切替えは影響がないはずです。 (スケジューラの占める帯域幅は、同様にキャンパスネットにつなげてある SETI@home ウェブサーバよりはるかに小さいのです)。 しかし、新しい DNS 情報のマップが伝播するまでの間、 いくらかの参加者はスケジューラに接続できないということが起こります。 この事態は比較的短い時間で解消されるはずです(世界のほとんどの地域では 数時間です。 気難しい DNS サーバを持っている少数の ISP ではたぶん数日かかるかもしれません)。

 
July 23, 2005 - 00:15 UTC
ワークユニット生成処理のボトルネックがどこにあるのか探しています。 一つは見つけたかもしれません。 アップロード・ダウンロードの記憶装置に 書き込み・読み出しをするたくさんのプロセスがあります(すなわち、 スプリッター、データサーバ、バリデータなどです)。 現在これらのやりとりは、プロジェクトのデータクローゼットにあるマシンと SSL 研究所の LAN を接続しているイーサネットスイッチを通過して行われています。 この 100Mbps のスイッチが過負荷状態なのかもしれません。

クローゼット内のマシン間のデータ量の多いやり取りを、上記とは別の 1Gbps スイッチを流れるように変更しようとしています。 本日は、 データサーバをこのスイッチにつなぎ換え、 スプリッターとバリデータの両方の役目をしているマシンの一つもつなぎ換えましたので、 アップロード・ダウンロードのトラフィックが新しいスイッチのほうを流れるようになります。 この新しいスイッチへの移動の前には、上記の両方のマシンで NFS (Network File System) のエラーが発生していたのですが、 今ではどちらのマシンでもこれらのエラーは出ないようになっています。

 
July 13, 2005 - 22:00 UTC
本日正午ごろ(現地時間)、当プロジェクトのマスター科学データベース・サーバが、 致命的なメモリ障害を検出して自分から再起動しました。 あるカーネルのバグのせいであったのかもしれません(それと示唆する形跡がログにあります)。 というわけで、再発を防ぐはずのパッチを適用しているところです。 再起動のせいでデータベースが破壊されていないことを確認するために、 とりあえずの検査はしてありますが、 スプリッターとアシミレータを再開できるようにするには、 パッチの適用後に、よりしっかりした検査をデータベース・テーブル群について行う必要があります。

今回問題を起こしたのはサイエンス・データベースですから、 一般の人達にはその停止がすぐには気がつかれません。 というのも、 この問題は新しくワークユニットを作り出すことと、 候補信号をそのサイエンス・データベースに取込む処理に影響をあたえるだけですから。 しかしながら、ワークユニットの現在の消化速度からすると、 このサーバを稼働状態に戻す前に、ワークユニットが足らなくなってしまうかもしれません。

さらに、我々のアップロード・ダウンロードサーバに接続しようとする参加者の滞積がまだあります。 このサーバは今週初めの停止のときから負荷に応えきれていません。 CPU 負荷でいっぱいの状態ですので、その負荷を軽くする方法を検討しています (おそらく、アップロードとダウンロードを別個の 2つのマシンに分けて処理させるという案になるでしょうが、 そのために割当てうるマシンは今のところ全く無いのです)。

 
July 12, 2005 - 19:30 UTC
故障の兆候のあった、かなり大きめのブレーカを交換するために、 昨晩、研究所まるごとの大停電がありました。 今年の初めごろに2回起こった突然の停電は、一部、 この故障ぎみのブレーカのせいでもありました。 追加調査の結果、さらに 3つのブレーカが潜在的な不良を抱えていると報告をうけています。 この報告が正確にどのようなことであるか分かりませんけれども、 いつかはそれらを全部修理するために、また停電を経験しなければならないことは確かでしょう。 しかし、近くにある MSRI ビルは大修理を終えようとしています。 (ちなみに、MSRI は Math Sciences Research Institute の意味で、misery と発音されています)。 ですから、この隣のビルを配電網に再接続するときには、 またこの研究所が停電となることは計画済みです。 8月になってすぐにこの停電があるでしょう。

昨晩の停電の間と今朝の再開の作業の中で、 BOINC の主データサーバ(および BOINC ウェブサーバ)用の smart UPS システムの再設定とテストを実施しました。 その両方の作業で、奇妙な振る舞いと混乱がありましたけれど、 最終的には解決されましたので、 これでこのシステムは停電がおきても安全にシャットダウンされる手筈が整いました。 この数ヶ月の間は回避策で凌いできたことを思い起こしてください。 (この回避策もテストされて役に立つことを確認済みでした)。 しかし、 smart UPS による方法に比べれば、この回避策は上品な手順ではなかったのです。

 
July 6, 2005 - 20:00 UTC
今朝の停止はデータベース・バックアップのためのものでした。 通常はバックアップに際して停止する必要はありません。 複製サーバのほうでスナップショットをとることができるからです。 しかし、参加者数が増えていくに従って、 複製サーバは主データベース・サーバにますます追いつけなくなっていました。 このため、毎週とっているバックアップをとるときには、すべてを停め、 静かな状態の主データベース上で、mysqldump を実行しなければならなくなっています。 今回の停止の間に、入出力能力が改善しないかと期待して、 複製データベース・サーバのほうに工夫を加えましたが、効果には疑念が残っています。 我々の案では、SETI@home クラッシックのプロジェクトを停止させた時点で、 そのデータサーバにしてあったマシンを複製データベース・サーバに使うというものです。

さらに実施したことは、のびのびになっていたいくつかの UPS の交換です。 これによって、主データベース・サーバに賢いバックアップ電源が装着されました。 プロジェクトのウェブサーバが交換する UPS の1つに繋いであったので、 停止しなければなりませんでした。 いくつかちょっとした作業の失敗があって、今回の停止は思っていたより 1時間余分にかかってしましました。 それでも今h、すべてが元に戻って稼働しています。

 
July 5, 2005 - 20:00 UTC
掲示板でどなたかが当プロジェクトのデータベース移行作業がどういう状態になっているか、 質問されていました。 6月初旬のクラッシュから回復後、2つの理由で進捗が遅れています。 ひとつには、スケジューラを旧データベース・サーバに移動したこと (これで移行に割ける CPU パワーが減りました)、2つめには、 とても長い IDL ジョブ(HI データ分析のためのもの)がたくさんのメモリを喰っているからです。 この IDL がついに終了し、我々は長めの週末を放り出して 移行処理をできる限り速く動作するようにして、 ついにはスケジューラと競合するところまでもっていきました。 完了までの時間を見積もるのは難しいところです。 というのも、 作業はテープごとに行っていて、 データベースからそれらのテープごとに書き込まれる信号の量が大きく異なっているからです。
 
July 1, 2005 - 18:30 UTC
castelli を今朝保守のために、再起動せざるを得ませんでした (castelli は、BOINC のマスター科学データベース・サーバです)。 つまり、新しい automount を拾い上げるようにするためです(これには、 再起動が必要です)。 このため、スプリッターとアシミレータ (取込み機能)をしばらく停止しなければなりませんでした。
 
June 29, 2005 - 23:00 UTC
昨晩アップロード・ダウンロードサーバが、プロセスを限界まで使いきってしまいました。 なぜこうなったかというと、負荷がとても重かったからです。 高負荷が apache に悪影響を与えました。 1時間ごとに apache が再起動するとき (ログローテーションのためです)、 それまで走っていたプロセスが消えてなくならず、 新しいプロセスがプロセスキューに溜まりました。 今朝までにこのマシンには、 7000を超える httpd プロセスが溜まっていました! apache に何らかのチューニングをするのことが明らかに望ましいです。

この事態は知らぬ間に進行していました。 サーバ状態ページの更新がなくなっていたことには気づいていたのですが。 このページは10分おきに更新されます( BOINC の内部で使われている状態ファイルの更新と同時です)。 このうち数時間に一回くらいですが、全システムが「更新を1回スキップ」してしまいます。 これは、cron との間の奇妙なある相互作用のためです。 しかし、たまには全システムが止まってしまい、だれかが 「刺激を与えるまで」(つまり、意味のなくなったロックファイルをいくつか消すまで)、 そのままになります。

上記の状態ページが古くなったままであることに気がついたので、 全システムに「刺激を与え」、ふたたびシステムは動きだしたかのように 見えました(一時的だったわけですが)。 すべては順調に見えましたので、 我々はベッドに向いました。 しかし朝になって、 問題の大きさに気がつくところとなりました。 (朝、 システムは動かない状態になっていました。 動かなくなったサーバと会話しようとして行き詰まったのでしょう)。

これらが起こっている間に、研究所全体で 2時間のネットワーク停止が起こっていました。 なにがそこで起こっていたかわかりませんが、我々の手には余ります。

 
June 29, 2005 - 23:00 UTC
前回の投稿へ追加:

停止期間は予想より少し長引きました。 というのも、データベースのダンプ処理を 2回、初めからやり直さねばならなかったからです (バックアップ方法を少々見直し要と分かりました。 「デバッグ」してやらねばなりません)。 UPS の試験をのぞいて、やると言っていたことはすべて終わらせました。 ですから UPS の試験は延期します。

マシン "gates" はスプリッターとしては成果がでなかったので、 代わりに "sagan" を当てました(このマシンは、SETI@home クラシックのデータサーバでもあるのでかなり忙しいマシンですが)。 ほんの少しの事でも役に立ちます。 最終的に、マシン "kosh" も追加しましたが、現時点では大して役にたっていません。

 
June 29, 2005 - 19:00 UTC
現在、停止時間中なので、一般的な更新を書く良い機会です。

バリデータ(検証機能)はまだ非活性化したままです。 皆さんへの影響といえば、功績(credit)の付与が遅れるということだけです。 プロジェクトのデータベースに存在しているリザルトにはいつも功績が認められるように、 それらの功績が失われてしまうことはないはずです。 それらのリザルトは検証され かつ サイエンス・データベースへ取込まれるまでは消されることはありません。 各種の待ち行列が長くなっていっていますが、それはそれだけのことでしかありません。

現在の状況は参加者にとって不便ではありますが、このプログラムを直すことは、 より高い優先度の仕事(我々がそう期待するもの、あるいは、 どこからともなく現れたもの)のために後回しにしています。

最優先は、昨晩異常停止した galileo をなんとかすることです。 まだ我々は原因が完全に診断できていません (なぜかといえば、忙しかったからです。 データベースのバックアップ、新しい automounts を拾い上げるためにサーバをリブートすること、 UPS をテストすることといった、月並みではあっても必須の仕事を 予定の停止期間を守って実施するのに忙しかったのです)。 現在のところ、この件の原因は CPU ボードの故障だろうと思っていますが、 このサーバは復帰しています(スケジューリング・サーバとして稼働していますが、それ以上のことは分かりません)。 以上が悪いニュースです。

良いニュースは、今日になって(ちょうどぎりぎりの良いタイミングで) galileo と同じ構成の中古の E3500 マシンが新しく届いたということです。 (Patrick Jeski からの寛大なる寄贈です。 Patrick、ありがとう!)。 そのマシンは私がこのメッセージを叩いているうちにも、 発送・納品センターに着こうとしているはずです。 ですからすでに、少なくとも交換部品を手許に持っているわけです。 これらの部品が必要になるかどうかはまだ分かりませんけれども、 余分なサーバをもっているということは、まったく心安らかな気分にさせてくれます。

galileo の停止と強まった負荷に他のスプリッター・マシンが応えられずにいることから、 プロジェクトはだんだんと送出する仕事が足らなくなりつつあります。 マシン "gates" を追加しようとしたのですが、その RAM 量が少ないこと (および、それがまだ SETI クラシックの cgi 要求をこなしていること) から、 あまり役にたちませんでした。 本日この停止時間が終わったら、 スプリッターの処理能力を増強することを試みます。

我々の現在の主務の1つは、SETI クラシックの残存するすべての構成要素を減らしていって、 最終停止に向けて準備することです。 この仕事はたくさんあります。 たとえば、大量のe-メイルを送出する仕事、 これからは変更操作ができないようにすべての cgi プログラムを変更する (アカウントの修正、チーム創成、チーム参加などなど)こと、 大量の負荷がダム決壊のように押し寄せる前に、できるかぎり BOINC サーバ群の 備えに磨きをかけること、などなどです。

おまけに先週から、プロジェクトのクローゼットの空調が再び故障しかけています。 かってのようにはマシン群は高温にさらされませんでしたが、 設備係が時間をかけて調べたところ、確かに冷却用ガス媒体 (フレオンあるいは、今ならフレオン以外が使われているでしょう) に漏れがあると分かりました。 ガスが追加されたので、問題が解決するまで、 数週間はこれで持ちこたえるでしょう。

 
June 27, 2005 - 22:00 UTC
一般的な更新: この週末にかけて何回か停止に近い状態が、短期間ですがありました。 それらは皆 BOINC のサーバ開発に関係したものでした。 計算機に関するデータベース・テーブルに2つの欄を追加し、 参加者にどれだけの仕事を送るかより正確に計算することができるようにしたのです。 (同時に、これによって、期限までに計算しおわらないほどたくさんは、 各計算機へ仕事を送りつけないようにもなります)。 この新しい欄の追加に適合させるため、 いくつかのサーバプロセスについて、プログラムのリコンパイルと再インストールが必要だったのです。

現在時点で、検証プロセスはすべて失敗してしまっています。 たぶんこの原因は日曜日に見つけた問題点とは関係がないと思われるので、 診断・デバッグ作業をしている最中です。 これはすべてを停めてしまうような問題では決してないのですが、 修正できるまでは、検証待ちキューが伸びつづけてしまいます。 (功績(credit)の付与が遅れるだけで、功績が消えることはありません)。 修正さえできれば、すぐにキューは消えていくはずです。

増え続ける参加者の方々と要求される仕事量の増大に追いつくため、 スプリッター群にもうひとつマシンを追加しました。 このマシンは、 Sun Ultra 10 で "gates" という名前です。 この名前で皆さんから質問されるのは確実なので、先に答えてしまいましょう。 我々の PC 群の中に "gates" という名前のマシンが1台ありましたが、 古くなってきてだんだんと使われなくなっていました。 ある日、Sun Ultra 10 1台をすぐにも運用に参加させる必要が出てきたので、 IP アドレスの付与権限者からの新たな アドレス割当てを待つようなことはせず、 その PC をこれを最後に電源を落として、IP アドレスだけ再利用してしまいました。 とういうわけで、面白い話は実のところなにもありません。

 
June 16, 2005 - 19:00 UTC
ほとんどの(99%以上) スケジューラアクセスが新しいスケジューリング・サーバに来るようになりました。 そこで、古いサーバのスケジューラを停止しました。 (この古いサーバではアップロードとダウンロードだけを扱うようになりました)。
 
June 14, 2005 - 19:00 UTC
昨日、スケジューラのバグを修正しました。 これは、fastcgi のプロセスがしばらく走った後に死んでしまう という症状を起こしていました。 修正するとすぐに現在溜まっていた仕事がはけてくれるという効果が出ました。 cgi プロセスをひっきりなしに再始動しなければならないという負荷がなくなったからです。 昨晩スケジューラは、先週の停止で滞積していた仕事を一掃し、今朝はとても快調に運用できています。

大事故が起こる前に、次のようにいくつか実際に改善ができました。 1つ前の記事で想定したように、 BOINC 側のスケジューラ・システムをアップグレイドしました。 もともとは、スケジューラとアップロード・ダウンロード機能は同じサーバにありました。 今朝、SETI@home クラシックのマスター科学データベース・サーバで使っていたマシンを BOINC スケジューラ用に使うよう構成変更をしました。 それでも、 ファイルの実際のアップロード・ダウンロードをする機能は元のサーバに残してあります。 DNS の変更がしだいに効果を発揮するにつれて、両方のシステムがスケジューラとして機能し始めました。 そのうち、きれいに役割が分離します。

 
June 13, 2005 - 19:00 UTC
昨週はたくさんの故障が続いておこりました。 アップロード・ダウンロード用ファイルサーバには、 リブートしなければ回復しない新しいバグも見つかりました (これにはすぐにパッチを当てました)。 これが回復したら、 今度はとても高い負荷が加わったことによって、 スケジューリング・サーバとウェブサーバの両方で別々の問題が発生しました。

まだ気がつかれていないかもしれませんが、最近このプロジェクトの URL を、 setiathome.ssl.berkeley.edu に変更しました。 この URL は以前は、 古い SETI@home "classic" プロジェクトを指していたものです。 この結果、参加者の方々は新しい BOINC を使った方のサイトへ導かれます。 想像していたとおり、この BOINC プロジェクトへの新しい参加者が大幅に増え、 バックエンド・サーバ群に加わる負担もその分 増えました。 近いうちに、 クラシック版のアカウントを新たに作ることが全くできないようにします。 そして、ついには、クラシックでの結果受け付けをすっかり止めてしまいます (前もって警告をします)。 これらのそれぞれの段階で、 我々のハードウェア設備の増強が要求される可能性があります。

種々のサーバがそれぞれ別の理由で故障した場合に、 今この時点では BOINC が使える新しいハードウェアはありません。 というのも、クラシックのほうのプロジェクトが依然として動いており、 我々のサーバ群の半分を使い切っているからです。 これは近いうちに変ります。

クラシックの方の 「マスター科学データベース・サーバ」(6 CPU の Sun E3500) が、利用目的を変更する最初のマシンになります。 我々はこのサーバのほとんどのデータを新しいデータベース・サーバ(8 CPU の E3500) へと移動させるのに忙しい状況です。 この移行は最近のディスク障害(回復可能な障害でした) のために歩みが遅くなっていました。 それでも、1ヶ月ぐらいのうちには終わるはずです。 しかし、我々はこの移行作業が終わるのを待たず、 BOINC 側のスケジューラをこのマシンに移動しようとしています。 実際にファイル・アップロード/ダウンロードを行うハンドラは、現在のマシンに残しますので、 スケジューラ・システム全体は2台のマシンにまたがって動作することになります。

できるだけ早く 2台めのウェブサーバを追加します(もしかすると 3台めも)。 BOINC のウェブサイトはクラシックのサイトに比べ、 動的に生成する内容がはるかに多いので、それを支えるより強力な処理能力を必要とします。 現実には余分なマシンがあるわけではないので、何台かのマシンには、 ウェブサーバの役と、現在果たしている役割の二役をしてもらうことにします。

これだけもまだ心配ごとには不足だろうと言わんばかりに、トラブルが起こっています。 BOINC の複製データベースは、主データベースの状態から遅れていくばかりなのです。 (なぜかというと、主データベースへの負荷が増えていっているのに、 複製データベースを支えるハードウェアのほうが比較すると非力なマシンだからです)。 そのような状況で、昨日、複製データベースは使い物にならない状態にあると分かりました。 主データベースの出すバイナリログが壊れてしまったからです。 訳注1  バイナリログが壊れても、主データベースそのものは大丈夫です。 複製がダメになっただけです。 そういう次第で、必要に迫られ複製を一から作ろうとしています(あるいは、 より良いハードウェアを複製データベース用に何らかの方法で手当てできるまで放置するかもしれません)。

事態が進んだらまたお知らせします。

 
April 19, 2005 - 18:00 UTC
最近、ヨーロッパの多くの参加者が SETI@home のサーバと接続できなくなっています。 これは、 ISP OpenTransit (France Telecom) が ISP Cogent との ピアリングを解除しているからです。 ピアリングを解除というのは、インターネット上の情報の流れを拒否するということです。 当プロジェクトのデータサーバは、 Cogent のネットワーク上にあるので、OpenTransit を経由してインターネットに接続している参加者は遮断されてしまったのです。

バークレー・キャンパスのネットワーク専門家が、このことを Cogent にただしました。 Cogent は、France Telecon 側が一方的にピアリング解除の決断をしたと報告しています。 コネクションを回復するという目標に関して、彼らは France Telecom と合意に達しようと試みています。

この問題についての短期的な回避策として、 プロキシをどのように使えばよいか示唆してくれるメッセージスレッド が、掲示板にありますので、それをご覧ください。

 
April 14, 2005 - 21:00 UTC
BOINC のサーバ側からの状況報告です。

何人かの参加者から、第三者の統計情報ページの内容の更新が遅れている という苦情をもらいました。 つまり、最新の情報がどんどん少なくなっていると。 どうしてそうなったのかというと、これらの統計情報ページが、 複製データベース・サーバから一日一回ずつ採取したスナップショットを使っているからです。 ほとんどのデータベース問合わせは、当プロジェクトのマスター・ データベースに対して行っていますが、 統計情報の取り出しの問合わせ処理はとても大きな処理であり、 入出力に強く負荷がかかります。 このため、 マスター・データベースに影響がないように、 統計情報の取り出しは複製データベースで処理しています。

そうです、我々はマスター・データベースから古いリザルトを除去することに忙しかったので、 複製データベースはマスターに追いついていませんでした。 覚え書き: この複製データベースは現在のところ、マスター・データベースを処理するマシンよりも、 かなり遅いマシンで動かしています。 ですから、最新の情報に追いつくのが辛い状況なのです。 (マスター・データベースになされるあらゆる更新処理が、 この複製データベースでも起こります)。 通常ならば、複製データベースは最新状態にかなり追いついており、 最繁時でも数分の遅れしかありません。

いずれにせよ、マスター・データベースから行削除を実施してきたので、 複製データベースに過剰な更新処理の負荷が追加されました。 この結果、最大で4日の遅れがでてしまったのです。 これはもちろん容認できない遅れなので、当面は統計情報の取り出し処理も、 マスター・データベースで行うようにするつもりです。 これで前述の遅れは解消されるはずです。 注意していただきたいのは、 この滞積が影響するのは統計情報のレポート表示だけだということです。 統計情報の内容そのものに問題があるのではありません。

また別のニュースとしては、昨日、予告なしに短い時間ですが停止をしました。 新しい UPS 管理カードをテストするためでしたが、テストの結果 このカードはうまく動作しました。 このカードを使う前に、 サーバに重要な構成変更作業をいくつかしてやらねばなりませんが、 このカードは予期できない電源断が起きたときに、 手順を踏んだ上品なシャットダウンをより確実にしてくれます。 現在すべての重要なサーバは保護された状態にあるものの、 その保護のしかたがしばらくの間は、 最高に理想に近いとも、洗練されたとも言えないやりかたにとどまります。

 
April 6, 2005 - 18:30 UTC
しばらく間が空いてしまいましたので、SETI/BOINC のサーバ側でどんなことが起きているか、おおざっぱにまとめてみましょう。

一つめは、当プロジェクトの冷房の調子が昨日、大きく改善されたということ。 我々のサーバクローゼットにあるエアコンは、フレオン量が少なくなってしまっていたため、 効いていませんでした。 原因を見つけて修理したら、 すぐにすべてのシステムの温度が下がり、最大では8度も下がりました。 これによって、ファイバチャネルで出ていたいろいろな警告メッセージが、 当プロジェクトのログから消えました。 よしよし。

SETI@home クラシック が終息にむかい、より多くの参加者が SETI@home/BOINC に加わってきています。 、 新しいデータベースサーバはこの状況に追いついているものの、 複製サーバのほうは厳しい状況になってきています。 今現在、複製サーバは稼働させておりません(バックアップ用にだけ使っています) から、まだ大きな問題ではありません。

当プロジェクトの(アップロードとダウンロードを扱う)データサーバも、 要求に応えられるぎりぎりのところまできていますので、 こちらも手当てをしようとしているところです。 比較的近いうちに、マスター科学データベースを galileo (CPU 6つ、メモリ 6 GB の Sun E3500) から castelli(CPU 8つ、メモリ 7 GB の Sun E3500に、より早くで大容量の RAID 記憶装置をつけたもの)に移動します。 そうしたら、 galileo は大きくて不格好なディスクの箱を捨てて、 上記のデータサーバ(現在、CPU 2つ、メモリ 2 GB の Sun D220R) の格好の代役になるでしょう。 さらに別の選択肢として、 アップロードとダウンロードを別のサーバに分けて運用するというやり方もあり得ます。

当プロジェクトのウェブサーバはとても快調です。 ただ、 より多くアクセス要求が来るとか、サイトの機能を増やすことを想定して、 積み上げた SunFire V100 をバックアップ用ウェブサーバ群として設定する作業をしています。 ひょっとして、もしワークユニット生成が要求に追いつかないようだったら、 これらのサーバはスプリッター用サーバにするかもしれません。

 
March 22, 2005 - 18:00 UTC
(現地時間で)今朝、研究所全体の計画停電がありました。 最近我々が遭遇した電気供給の事故について、 キャンパスの電気技術者が診断するためでした。 思っていたより少し長引きましがた、うれしいことに3つの重要な問題が検出され、 そのうち一つは見つかってすぐに修復されました。 他の2つの問題に手をうつには、 新しいブレーカーが必要です。 発注してテストしてから装着する必要がありますので、 ブレーカー交換のため同様の停止をするまでしばらく(何ヶ月か)時間があるでしょう。

ところで、下記で報告しましたが、当プロジェクトからインターネットへつながる回線が、 数日ダウンしておりましたが、(現地時間で)昨晩、突然復活しました。 ですから、SETI@home クラシック/BOINC への参加者は、 今朝の停電前にアップロードとダウンロードを、 少なくともその夕方だけはうまくできたでしょう。 まだ何が起こったのか、なぜそうなったのかは、通知がありません。

いつものことですが、長引いた停止の後ですので、 データサーバ群は要求の嵐のなかでもみくちゃにされています。 要求の待ち行列を解消するまで少々時間がかかるでしょう。

 
March 21, 2005 - 18:00 UTC
このプロジェクトをインターネットへつなぐ Cogent 社経由の回線が、UTCで3月18日から19 日にかわるころから動作しなくなっています。 このため、アップロード、ダウンロードのデータサービスは停止しています。 Cogent 社はまだ何が問題なのか調べ続けています。 我々が必要とするインターネットへの通信帯域を、 別の方法で得られないものかとも考え始めました。
 
March 7, 2005 - 18:45 UTC
サーバを安全に停止させる手順がやっと固まりつつあります。 当プロジェクトは稼働状態ですが、データサーバは、 もう少し仕事を生成するのを待ってからサービスを再開します。 あと少しで再開できるでしょう。 安全にサーバを停止させる手順をテストするため、 今日のうちに1回か2回短時間の停止をします。
 
March 5, 2005 - 01:00 UTC
当プロジェクトはこの週末の間、停止します。 調査をかなり進めたものの、 サーバはまだ UPS とのやり取りができていません。 このビルの電源はまだ信用がならない状態です。 キヤンパスの管理部門が悪いところを探し出すため、来週たぶん電源停止があります。
 
March 4, 2005 - 19:00 UTC
このプロジェクトは現在時点で稼働していますけれども、 UPS とサーバの間の通信が動作するように試みるので、 予告なしに停止します(その後、稼働状態に戻します)。
 
March 3, 2005 - 23:30 UTC
UPS の通信ケーブルが到着したので、かなりの時間をかけて UPS が思い通りに動作するように試みました。 しかし、うまくいきません。 何でも思いつくことはやってみました (ケーブルのピン配置が正しいことを確かめるために導通検査までやりました)。 あまりに時間を無駄づかいしてしまったので、 あきらめて今回はプロジェクトを再開しました。 夕方にはまた、数時間の停止をするはずです。
 
March 3, 2005 - 17:30 UTC
当プロジェクトは現在稼働しています。 UPS との通信用ケーブルが今日届けば、 停電時の自動立ち下げ手順のテストをするために、稼働を一時停止します。 それがうまくいったら、稼働状態にもどして維持します。
 
March 2, 2005 - 19:00 UTC
ビルの電源にはまだ不安が残っています。 診断のための計画停電が、 次週のいつかにスケジュールされようとしています。

状況を整理してみますと、我々のサーバは実際に全部 UPS の上で動いていますので、 今週月曜に起きた電源断でもデータベースへの被害は避けられました。 いま用意ができていないのは、電源が落ちたときに我々がその場にいなくても、 [自動的に] システムを安全に停止するしくみです。 [電源断が起きて、] バッテリバックアップの電源で動作する状態になったら、 それをサーバが検知できるようにするソフトウェアが必要ですが、 そのソフトは既にサーバにインストールしました。 今は、 サーバと UPS とをつなぐのに必要な専用の通信ケーブルが届くのを待っ ています。 このケーブルは特別に発注が必要で、明日には届くと期待しています。

この2日間プロジェクトは停止していましたが、 その代わり種々の保守作業をやってきました。 現在、データベースのバックアップを取っています。 それが終わったらすぐに、 半日程度の稼働を本日行うことを計画しています。 その後、01:00 UTC には再び停止します。

SETI@home クラシック プロジェクトは現在稼動中です(ですが、 これも 01:00UTC には停止します)。

 
February 28, 2005 - 22:30 UTC
すでにお伝えしているように、今朝再び、予期せぬ停電が研究所全体でおこりました。 今回は当 BOINC システムのデータベースはバッテリバックアップしてありましたから、 安全に停止することができました。 停電から回復した後、データベースを少しの間稼働させて、 検査をしました。 完全に問題なしでした。 Court さんには我々皆が感謝して良いでしょう。 新しい UPS を手に入れるまでの間、 BOINC のデータベース・サーバに装着するために 自分の UPS をもってきてくれたのは彼なのですから(しかも、 そのために自分のシステムを無防備にしたままにしています)。

それでも、この BOINC のデータベースをすぐに停止することにしました。 このプロジェクトの重要なサーバすべてを、smart-UPS の上で動かすまでは、 (つまり、バッテリを電源に動作しているとそれらサーバが気づいた時点で、 自分からすぐに停止するようになるまでは)、当面、 BOINC のほとんどのバックエンドサービスを停止状態のままにすることにしたからです。 いままでこの対策を打つことはずっと将来計画に入っていました。 (それだからこそ、今まで構築してきた運用構成のおかげで、 電源事故がおきたにもかかわらず、ほとんど最小のデータ紛失で済んだのです)。 しかし、今やこのように頻繁に気まぐれな停電がおこることが想定範囲に入ってきたので、 毎度、被害対策をしなくて済むようにするほうが、運用にゆとりがでるというものです。

実際のところ、今回の停止の時間を使い、追加の保守もしようとしています。 たとえば、 アップロード・ダウンロードのディレクトリを配置してある例のディスクアレイは、 98% の満杯に近い状態です。 この原因については、Jeff が file_deleter のコードに古いワークユニットをたくさん残してしまうという障害を見つけました。 というわけで、何をおいてもまず、この古いファイル群を取り除く必要があります。

 
February 25, 2005 - 20:00 UTC
当プロジェクトのデータベースは、停止直前の30分に処理した分のデータを失っただけで回復しました。 この短時間の最中に参加者の皆さんが獲得した功績(credit)は消えてしまいました。 一部の方々は、一時的にダウンロードがうまくいかない経験をされるかもしれません。
 
February 24, 2005 - 23:30 UTC
昨日の停止についての続報: まだ、データベースが受けた被害の手当てをしています。 SETI@home classic のシステムは、参加者にワークユニットを供給できるまでに回復し、 ほぼ稼働状態にもどったといえます。 しかし BOINC 側はまだまだで、 少なくともデータベースサーバを1つ稼働状態に回復させるまでは、 暗礁に乗り上げた状態のままです。

マスター・データベースがひどく壊れて修復できなかったので、 複製データベースのほうに全力を注ぐことにしました。 昨晩のうちに、 こちらのディスクの同期処理が終わりました。 ファイルシステムの検査をいくつか通過した後、 この計算機は起動に成功し、mysql も実にしっかりと動き始めました。 一連のデータ整合性テストは、データ破壊の検出なしに進んでいきました。 しかし、リザルト・テーブルのところで異常を見つけました。 もちろん、これがこのデータベースの中で最大で、かつ、最も重要なテーブルです。 今、このテーブルを修復しようと試みています。

この修復が僅少のデータ紛失のみで可能だとわかれば、複製データベースから マスター・データベースに全データをそのまま複写します。 運が味方してくれれば、この作業は明日の朝には終わり、 エンジン全開で稼働状態にもどることができます。

注意していただきたいのは、複製データベースの計算機は、マスターに比べて遅い計算機なので、 この複製は30分ほど実時間よりも遅れた内容を持っていることです。 両システムを並べて走らせて、複製データの内容がより近いものになるように努力してきましたが、 これ以下には時間差を詰められませんでした。 ですから、稼働状態に戻っても、 30分の空白期間の間にアップロードした計算結果は失われています。 (さらに、参加者プロファイルの更新や掲示板への投稿なども同様です)。 このデータ消失については、心からお詫びいたします。

[システム管理者の]Court Cannick が、自分のサーバ群のなかから UPS をもってきてくれました。 このおかげで、 UPS をもう一つ緊急購入するまでの間も、 当システムのマスター・データベースサーバは 電源断から保護されます。 このデータベース・サーバが昨日まで電源断から保護されていなかったのは、 UPS がまとめて置いてあるデータ用クローゼットの中に設置せずに、 研究室内に置いておいたからです。 ちょうど数週間前に、 このデータベース・サーバを置くスペースを作るため、 データ用クローゼット内の再配置を行ったところでした。

 
February 23, 2005 - 23:30 UTC
ブレーカが飛んでしまい、予期しない突然の電源断が起きたため、 BOINC プロジェクト全体が数時間停止しました (同じ研究室の他のプロジェクトも同じ目に会いました)。 恐ろしいことに原因はまだ分かっていませんので、電気系統の問題を見つけるために、 電源の計画停止が近いうちにあるでしょう。 よく分かったのは、 このあたりは安心して過ごせるところではないということです。

バッテリ・バックアップ(UPS)を付けていた多くのサーバでは、 電池を使い切るまでの時間のうちに、正常な手順にしたがって停止ができました。 しかし、全部のサーバでそうできたわけではありません。 新しい BOINC のデータサーバも例外のうちの一台でしたので、 格納しているデータはかき乱されてしまい、mysql が動いてくれなくなりました。 最後にテープにバックアップを取ったのは、1週間前でした。 今週のテープバックアップ処理は電源が落ちたときに、60%まで済んでいました (つまりは、マーフィーの法則というやつです)。

良いニュースは、最新の状況を保持しているべき複製データベースがあることです。 悪いニュースは、このサーバは起動時にディスク異常にぶつかるので、 そのディスクドライブがまだ同期処理をしている最中だということです。 同期処理が終わったら、この複製データベースの整合性検査をしなければなりません。 幸運に恵まれて mysql が動きだせば、複製データベースからマスター・ データベースへデータをごっそり複写することで、中断したちょうどその状態から再開できます。

今朝早く、このプロジェクトは定期保守のため停止しました。 (余分なエラーメッセージを抑止するという、データベースサーバのBIOSの修正をし、 データベース・バックアップのスナップショットをとるためでした)。 すべてを稼働状態に戻してから、1時間たったところで電源が落ちてしまいました。

 
February 22, 2005 - 01:00 UTC
前述の NAS 装置は現時点での負荷を受け止めています。 データサーバのコネクション が切れることはなくなりました。 未送出のワークユニットが不足するのではないかと、 少々心配になったので、トランジショナの処理が新しい送出前のリザルトをより多く産み出すように、 アシミレータを停止しました。
 
February 20, 2005 - 18:45 UTC
前の記事でデータサーバ用の NAS 装置でトラブルがおきていると書いた件ですが、 この装置に実稼働時の負荷量を与えてテストしてみたわけではないものの、 この NAS 装置は正常なのかもしれません。 現在、話題のデータサーバを停止し、 消去を待っているワークユニットとリザルトのファイルの巨大な滞積を、 file deleter が少しでも消化できるようにしています。 この滞積した仕事は、データベースが遅いマシンで動いていたときから引きずっている問題です。 検証(validator)と取込み(assimilator)は両方とも現在稼働させています。
 
February 19, 2005 - 15:15 UTC
今週、リザルトとワークユニットのファイルを格納している NAS 装置でトラブルを経験しました。 (つまり、ULDLと呼ばれているアップロード・ダウンロード用ディレクトリを格納している装置です)。 この装置は、数ヶ月の間完璧に機能していたのですが、機能停止するようになってしまいました。 理由は今のところ分かっていません。 問題を解決するべく、 この装置のベンダーは我々と一緒に働いています。 この ULDL はテラバイト級の大きさなので、 それを別のところに移せるようなサイズの格納場所は、一時的でよくてさえも、ありません。 回避手段がないかと探しています。 残念なことですが、この問題に取り組むために、 当プロジェクトは稼働・停止を繰り返します。
 
新しいほうのデータサーバは(現在トラブルの生じているデータサーバとは対照的に) 快調に動作しています。
 
February 10, 2005 - 21:30 UTC
主データベースを新しいサーバのほうに受け継がせました。 今のところすべてうまくいっているようです。 新しいマシンは現状では利用率はとても低く抑えられています。 これは素晴らしいことです。 我々はもっと規模を拡大していけるということです。

新しいシステムの構成は、 2つの 1.8GHz プロセサと 8GB の RAMをもつ Sun v40z opteron と、これに接続された Sun 3510 ファイバ・チャネル storage アレイから成っています。 後者のstorage アレイは、Sun社からの寄贈品です。 このプロジェクトからの需要が増えたときには、さらに 2つの CPUと、32GBまでの RAM を増設できます。

古いデータベース・サーバは、複製データベースとして今は動作しており、 バックアップ用途と管理のための問合わせ要求に使われます。

 
February 9, 2005 - 23:30 UTC
サーバの状況: 新しいデータベース・サーバはまだテスト中ですが、 なかなか良い状態で動作しています。 先週生じたクラッシュは、 (Unix のウィンドーステムの一つである)gnone のバグによって引き起こされたのだと、 我々は現在のところ信じています。 gnome はそれ以来動作しないようにしてあります。

新しいデータベース・サーバにひとたび切替えたら、元に戻すことは無理です (現在のデータベースよりも新しい方が速いものですから)。 そういうわけで、より注意深く仕事をすすめており、 データベース問合わせを一つテスト確認しては、 次の問合わせをテストに加えるというやり方で進めています。 移行の日時はまだ決めていませんけれども、大きな問題がおこらなければ、 今やどの日に移行をしてもおかしくない状態になっています。

 
February 3, 2005 - 23:30 UTC
本日 12:40 (UTC)ごろ、このプロジェクトの BOINC データベースはクラッシュこそしないものの、 何百ものスレッドが動いて空回りするだけで仕事を何もこなさないハング状態になりました (このため、新しいデータベースコネクションを受け付けません)。 何時間か問題を解決しようとしましたが、結局は乱暴に停止させざるを得ず、 リブートとデータベース回復処理をするために数時間かかってしまいました。 最終的には稼働状態に戻すことができ、 (みたところは)すべては以前のままのように動作しています。

それでも2つの問題が残っています。 現在のデータベースでは、 理由がわからない入出力処理が発生しつづけているということと、 全データを新しいサーバに移行する必要がまだ残っているということです (後者の作業は次の月曜の予定)。

 
February 1, 2005 - 01:00 UTC
今回のデータベース移行の処理が 1/3 くらいまで進んだところで、 新しいサーバが止まってしまい、この移行ジョブは止まってしまいました。 今、何が原因か診断しているところです。 移行作業の間、 以前の記事で少し触れた、内部入出力処理の多量発生が起こってもいました (これは、たぶんガーベージ・コレクションの類なのだと我々は思っています)。 そのため、新サーバへのデータ移動速度をとても落としていました。 なぜ、新サーバが機能停止したのかを解明するはもちろんですが、 そのガーベージ・コレクションが完了するまで待ってから、 移行処理を再開するつもりです。 少なくともそれは今日から一日以上後です。
 
January 26, 2005 - 19:00 UTC
短期間の停止をしました。 それは、サーバ群の中の1台からファイバ・ チャネルのカードを外すためでした。 そのカードは装着されていましたが、 何のためにも使われていなかったので、 すぐに使えるスペアとして手許に置いておく必要がありました。

別のニュース:予期せぬ妨害が不定期にあったので(不良 CPU を交換しなければならなかったり、陪審員の務めが回ってきたりで)、 新しい BOINC のデータベース・サーバはまだ本番に移れる準備ができておりません。 それでも作業は大幅にすすんでいます。 OS をインストールして、 RAID 装置は動く状態になりましたし、 mysql のディストリビューションもほとんど設定作業が終わっています。 一週間以上は試験をしてみてから、データの移行を開始するでしょう。

ところで、今使っているデータベースは、 まだ良く分かっていない原因で不自然に遅くなっています。 実際のところ、mysql の内部で何か起こって、 ディスクから急に毎秒 5 M byteの速度で読み出しが起こります。 この現象は先週の金曜に始まり、それから止みません。 データベースへの問合わせがない状況であってさえ、多量のディスク入出力が起きています。 すべての機能は動作しているのですが、本来の姿よりも少々遅いのです。

 
January 18, 2005 - 19:00 UTC
金曜の夕方遅く、電源の瞬断がおきました。 このプロジェクトの主なサーバ群はすべて無停止電源を装備しているので、 影響をうけませんでした。 他のシステムは影響を受けておりましたが、 被害の実態はこの週末の終りになるまで明らかではありませんでした。

もっともはっきりした事象は、スイッチングハブが機能しなくなったこと、 そして、マスター科学データベース用ディスクドライブがいくつか黙り込んでしまったことです。 (このデータベースは現在のところ無停止電源を装備していません)。 スイッチングハブは、リブートするだけで済み、いくつか遅れていた仕事は継続可能でした。 (たとえば、サーバ状態のページを定期的に更新する処理がその例です。 ) 我々は、マスター科学データベースの内容をきれいに元に戻す検討をしています。 現状では、新しいワークユニットを作ることはできても、 新しい科学的な結果データをサイエンスデータベースに追加することができません。

 
January 11, 2005 - 20:00 UTC
昨日のディスク故障の続報です。 データベース一貫性の検査が終了し、 通信を行っていなかったサーバも、今、起動されているところです。 念の為に記しておきますが、停電の最中、 これらのディスクアレイは電源を落としただけでなく、コンセントを外してありました。 かって、故障寸前だったディスク(とモニター)が、 まったく規定どおりの電源断と電源投入をしただけで、 とうとう死んでしまったということがありました。 その上、このディスクアレイはたまたま、RAID 構成にはまったくしていません。 この状況は最適なものではないとはっきり分かっていますので、 このディスクアレイをより大きな RAID 構成のものに置き換えようと、 我々はとても積極的に働いています。 もし昨日のディスク復旧がうまくいっていなかったら、 テープバックアップしておいた内容へとデータを戻さざるを得なかったかもしれません。 その場合、科学的な結果だけは失われますが、それらは再現しうるものです。 つまり、失った部分のデータをテープから分割し直して、 その仕事を送出しなおすのです。 そうです、この場合、 CPU 処理の純損失が起こったことになりますが、 参加者は最近のバックアップテープ以後についても、 計算完了した仕事の功績(credit)を依然として維持しています。
 
January 10, 2005 - 20:00 UTC
近くの建設工事の都合で、昨晩 長時間の停電がありました。 その間、我々の全マシンを停止しました。 全設備が電源を入れられて、 元に戻ったといいたいところですが、ただ1つだけ、 システムのサイエンス・データベースを構成するディスクドライブが、 立ち上げに失敗しました。 結果データの取込み処理と原データの分割処理を、 回復方法を見つけるまで停止しています。

更新:上記のディスクドライブを回路基板を取り替えることで 救うことができました(過去にディスクは正常だが、 回路基板が壊れていたことを思い出したのです)。 しかし、このディスクの1ページにわずかなデータ破壊がおきていました。 そのため、システムのデータベースはきれいに再稼働しません。 これを修復するのはたぶん簡単だと思われますが、 まず専門家の助言を待っているところです。

さらに更新: 上記のディスクは完全に修復され、 今はデータベースの一貫性検査処理を走らせています。 結果データの取込み処理と、原データの分割処理は、 明日の朝から再開します。

 
January 4, 2005 - 18:00 UTC
データベースの負荷増大(下記にある以前の記事で書いた件) の原因をつきとめました。 先週データベースに追加した 2つのインデックスが原因でした。 昨日の昼(20:00 UTC) これらのインデックスを取り去るため、 プロジェクトを停止したのですが、 この処理が1時間ほどで終わるという我々の予想に反して、 結局12時間もかかりました。 サーバ群を真夜中(08:00 UTC) に再起動し、今は最高速度で稼働する状態に戻っています。
 
December 30, 2004 - 00:00 UTC
以下に年末時点の諸事の状況を記しておきます。

月曜にこのシステムのデータベースに少々変更を加えたところ、 それが原因でかなりデータベースの速度がダウンしてしまいました。 (思っていたよりもはるかに遅くなってしまいました)。 しかし、今日になるまで気がつくような徴はありませんでした。 多くのデータベース問合わせが停滞しました。 その結果、 今朝のある時点で、問合わせの滞積のために、ひとつも仕事を送出できなくなりました。 現時点では、処理は遅いものの管理可能な状況です。 つまり今でも、システムのウェブサイトの動作がいつもよりのろいと感じるかもしれません。 この状況を解決するために取り組んでいる最中です。

2台の大きなサーバを稼働状態にするべく急いでいます。 その1台は新しい BOINC データベース・サーバとなるものです。 現在のデータベース・サーバは、2つの旧型 CPU に2GB のメモリを積み、 最大構成になっています。 新しいサーバマシンは、 現状より5倍速い 2つの CPU と 8GB のメモリとを初めから載せてあります。 さらに処理要求量が高くなれば、CPU を2台の増設し、 メモリ量も2倍に増やすことができます。 その上、より高速のディスク I/O のためにハードウェア RAID をこのマシンに接続します。 [新しいこのマシンが稼働したら]、 現在のサーバマシンはその複製データベース用のサーバにします。 SETI@home から BOINC に参加者が移行してくるに従って、 処理要求量は増加するので、この仕組みを動かす必要があります。

もう1台の大きなサーバは Sun E3500 です。 これは現在マスターデータベースを動作させている 我々の E3500(このマシンには、 検証を済ませたすべての科学的計算結果が蓄積されています) と似たものです。 現在のこのデータベースは遅くて、場所をとる上、ほとんど満杯状態です。 そこで、新しい E3500 には、 もっと容量が大きくて効率的なディスクアレイを付け、 現在のデータベースをそこに移動します。 これによって、 バックエンドの科学的な分析作業のスピードが非常に大きく改善されます。

 
December 7, 2004 - 19:00 UTC
昨日6日午後に、サーバ状態を表示するページがおかしくなり、 参加者に送り出す用意ができているリザルトが、0個と表示されるようになりました。 これはレポート作成処理の中の単純なバグだったので、もう直しました。 バックエンドのシステム本体は問題なく動作しておりました。
 
November 18, 2004 - 22:00 UTC
データベースのスナップショット/バックアップ採取のために、 われわれのプロジェクト群をデータベースから切り離す定常的操作をしていたところ、 そのデータベースサーバがデータベースボリュームとの接続を失ってハングしました。 リブートするため、しかたなくそのマシンの電源を落としてから入れ直し、 ディスクドライブのfsck(ファイルシステムの検査)をしてから、 再立ち上げしました。

元どおり動きはじめたので、データベースにデータ破壊がないことを確かめたくなり、 ほとんどのテーブルを検査しました。 検査したテーブルは全て問題ありませんでした。 このサーバがおかしい振る舞いをしたとき、データベースは静止状態だったので、 データ破壊がなかったことは驚くほどのことではありません。 今は全て稼働状態となっています。

 
November 17, 2004 - 20:00 UTC
アップロード・ダウンロード用のディスクアレイは、先週のあいだうまく動作していましたので、 我々は別のハードウェアプロジェクトに取り掛かることにしました。

アルファテスト・ベータテストプロジェクトを、新しい Linux システムに移動させている最中です。 これをやれば、我々の全サーバ群を Solaris 以外のシステムでテストできることになります。 同時に、他の設備とまったく切り離したものになるので、 公開しているプロジェクトがダウンしてしまっても、 アルファおよびベータのプロジェクトは稼働し続けます(その逆の状況も許されます)。

SETI@home クラシックの一部を規模縮小していくので、 その旧いオンライン・データベースを整理するので忙しくなっています。 (旧オンラインデータベースは、BOINC の仕組みには存在しない中間データベースです。 ) もちろん、クラシック版とBOINC 版、両方のデータを格納する新しいマスターデータベースを、 格段に大きく性能の高いシステム上に準備することでも仕事がたくさんあります。 さらに、BOINC 版の主データベースを、(ハードウェア RAID、複製データベースサーバなどの追加によって)、 より大きく、かつ、性能を上げることも計画しています。

しかし、旧 SETI@home の参加者をBOINC版に強制的に移させるには、 ほど遠い状況です。 BOINC が 50万人以上の参加者を受け入れる態勢が整ったら、 そのとき切替をします。

 
November 4, 2004 - 20:00 UTC
今朝こちらでは、アップロード・ダウンロード用ディスクアレイ装置の OS を更新しました。 というのは、ときどき出くわす問題が直らないかと期待したからです。 今のところ、なかなか調子は良いようです。 この週末ずっと状況を注視します。 本番システムをこのディスクアレイから移動させるという計画は、 問題がおこり続けないかぎり棚上げにしておきます。

別のニュースです。 このプロジェクトのサーバクローゼットに電源コンセントを増設する計画が進行中です。 私たちの活動には資金的な制約があるでけでなく、電源容量も使い切っており、 物理的スペースや空調も限界に近くなっています。 しかし、 電源プレーカーを 3つ追加しているところですので、 悩まなければならない制約条件が少なくともひとつは減ってくれます。

 
October 27, 2004 - 17:00 UTC
(現地の今朝)13:00 UTC にアップロード・ ダウンロード用ディレクトリがあるディスクアレイが完全に止まってしまいました。 BOINC のクライアントはこの種の問題がおきると、[サーバに] つながらなくなってしまいます。 実は、昨晩ずっとこのディスクアレイは調子がおかしくて、 ときどきは接続ができない時間帯があったかもしれないのですが、 毎回1〜2分で稼働状態に復帰していました。

SETI 関連の全 BOINC プロジェクトは (SETI@home だけでなく、アルファテスト、 ベータテストも含む)、このディスクアレイに依存しています。 しかし、アルファおよびベータテストについては、 この依存関係をなくそうとしていたところでした。 というのも、 このような事態になったときにこそ、 アルファおよびベータテストが完全に機能するようにしたいからです。

公開用の SETI@home プロジェクトについても、 このディスクアレイから別の場所へ移動する計画です。 しかし、 すぐというわけにはいきません。 なにしろ、どこかへ移すというデータの大きさは、1/4 テラバイトもあるのです。 そのようなスペースは今はありません。 (このデータ移動作業をしたとすると、 その間、当プロジェクトは動作できないので、 相当長い期間停止を覚悟しなければならないということはもちろんですが。 ) それにもかかわらず、この件は現時点で高い優先度をもつ問題です。

 
October 26, 2004 - 20:00 UTC
サーバ状態を表示するページで2ヶ所修正をしました。 (1) 送出準備済リザルトの数が、今ではより正確になり、 (2) 実際には splitter プログラムが走っていたのに停止していたと表示するバグを修正しました。
 
October 20, 2004 - 19:00 UTC
今朝、2時間の停止で実施した作業は、ほぼ成功のうちに終了しました。 この停止時間の中で2つの作業をしました。

1. このプロジェクトのアップロード・ダウンロード用ディスクアレイ装置に、 新しい NVRAM カードを装着しました。

(容量が大きい上に更新頻度も高い) アップロード・ダウンロード用ディレクトリは、 SnapAppliance 社のディスクアレイに置いてあります。 この装置で 2〜3週間前にいくつか問題が発生しました。 SnapAppliance 社の技術スタッフは、これらの問題を片づけるのにとても協力的でした。 彼らは、NVRAM カードがおそらく故障しているのだというところまで問題点を局所化しました。 今朝実装したのは、代わりに彼らが我々に出荷した新しいNVRAM カードです。

このプロジェクトのデータベース用ディスクアレイの物理的な装着位置は、 アップロード・ダウンロード用のディスクアレイの上に載せてありますので、 当然ながらこのデータベースサーバも停止しなければなりません。 というのは、SnapAppliance 社の装置に手を出すためには、 作業の邪魔になるデータベース用ディスクアレイを、 物理的に別の場所に移さねばならなかったのです。 これは、上記の作業の間このBOINCプロジェクト全体も停止することを意味しました。

時間がたてば、このディスクアレイに関する問題点がすべて片づいたかどうか分かります。 しかし、この1週間ほどは完璧に動作していました。

2. ディスクアレイを新しい複製データベースサーバに接続

ひとつ前の月曜日、11日に、 プロジェクトの Sun サーバ群にディスクを追加することによって、 新しい複製データベースサーバを作ろうとしました。 しかし、ファイバ・チャネルで誤動作があったため、 新しいディスクボリュームを作ることができず、 この計画はうまくいきませんでした。

先週の間に、このディスクアレイそのものを試験してみて、 完全に動作が確認できました。 そして今日、 役に立たないファイバ・チャネルカードを交換しようとしました。 ところが、良い話もでてきました。 ほんの1週間前にSun社から、 おそらく上記の誤動作を修正するだろうと思われるパッチが公開されていることに気がついたのです。 とういうわけで、このパッチをまた後日適用して、再挑戦します。

 
October 13, 2004 - 14:00 UTC
また、 validator の話です。 [ひとつ前の記事は勘違いで、] ひと山乗り切れさえすれば済む状況のようでしたので、 昨晩また稼働状態に戻したところ、12時間続けて待ち行列が減っています。 (その時間内に10%ぐらい減っています)

October 12, 2004 - 23:00 UTC
ご存知のように validator はまた稼働状態に戻りました。 どうやら、先週の週末からアップロードが失敗していた分を処理することができないようで、 回避策を組み込んだプログラム修正をする必要がありそうです。 しばらくの間、申し訳ないですが功績(credit)の伸びは遅いままです。 しかし、是非このやり残しの仕事も片づけたいと思っています。

さあ、 BOINC コア・クライアント 4.12 版を今、この公式プロジェクトへ公開しました。

 
October 12, 2004 - 21:00 UTC
新しい複製データベースで、予想外のディスククラッシュがおきました。 フォーマットをかけている最中でした。 ディスクがおかしかったのか、 あるいはケーブルのせいでしょうか。 わかっておりません。 複製データベースを作る活動は今のところ止めにしようという状況です。

別のニュース。 validator の待ち行列が長くなりつつありました。 validator が走っていなかったからなのです (いろいろデバッグをしていたためです)。 それも今、走らせたので待ち行列は短くなっていっています。

- Matt

 
October 12, 2004 - 18:00 UTC
今朝の停止後時点での、全体的な状況の変化分を書きます。

1. 新しいディスクアレイ(まだ、ディスクがならんでいるにすぎません。 これをソフトウエアRAIDで使います)を、現状の複製データベースマシンに装着しました。 新しいディスクをいれたのは、RAID5からRAID10に移行するためです。 RAID10はRAID5より格段に速いのですが、ディスクはたくさん要りますので、 ディスクを追加しなければならなかったのです。 プロジェクト全体を停止して、ハードウェアを切替えました。 今は、 稼働状態にもどして、 Court さんが新しい RAID10 のファイルシステムをフォーマットしているところです。 大して時間がたたないうちに、マスターからデータをコピーし始めます。

2. validator の待ち行列がまた伸びつつあります。 この週末のてんやわんやの結果こうなったのだと思います。 たぶん、リザルトの正常なアップロードがもっと起こらないと、 この待ち行列は短くならないでしょう。

3. 4.05版が計算に時間がかかる件について。 ここにいるプログラマ達は、 リリース版・デバッグ版の差とは関係ないと思っています。 でも、 どうしてこうなったか調べ続けております。

- Matt

 

(訳注1): バイナリログが壊れた
MySQLが異常時に回復のため、あるいは、複製へ更新分を伝えるために使うデータです。 これが壊れたので、遅れていた複製データベースは主データベースに追いつくのに必要なデータを失ったわけです。

 

Copyright © 2017 University of California, Translated by JE2BWM