技術ニュース(〜2007年1月まで)
技術ニュース(〜2007年1月まで) |
|
| HOME(訳| 原文) | 参加するには | SETI@homeについて | コミュニティ | アカウント | 統計情報 |
|
(2007/05/5) この技術ニュースの翻訳ページに
追加の記事を入れるのは現在止めております。 2007年の2月から、技術ニュースの原文が 掲示板の１つへと形態を替え、Matt氏以外の投稿も含めて記事がかなり増えました。 量と形態をどうするかが問題で訳しきれなくなっております。 |
| 下記のニュースは、技術的に細かいことにまで言及しています。 これらは、技術的すぎるので、 入り口のページにある通常のニュース欄に載せずにここに載せてあります。 |
|
January 9, 2007 - 22:00 UTC
新しい BOINC 複製データベースをどのようにするかについて、 毎週の定期停止時間にテストを実施しています。 いまのところ問題は生じていないのですが、最繁時間帯にも耐えられるところまでは、 まだ到達していません。 ほとんどの場合もっと多くの検査(たとえば、そのサーバが使う RAID が、ディスクドライブの故障にも耐えうるなど)をしますし、 フル稼働させる前には全システムをプロジェクトのサーバクローゼットに移動します。 残念なお知らせもあります。 このプロジェクトでほぼ3年働いてくれた、 すばらしきシステム管理者 Court Cannick さんが、 より大きくて良い仕事へ移ると最近宣言しました。 実は、本日が彼が居る最後の日です。 彼が我々とやった仕事には、 数多くのシステムを稼働状態にしたこと、そして、プロジェクトの UPS を制御できる状態にしたこと、ルータの設定、新しいコンソールサーバの設置といったものがあり、 さらに我々を助けてくれたことがらとして クラシックのプロジェクトから BOINC ベースへの難しい移行、 データストレージ用の DLT テープを活性挿抜できるハードディスクドライブへと移行させた作業がありました。 彼の良い今後を願い、SETI 関連の集まりでこれからずっと逢えることを期待しています。 技術ニュースの下記項目に追加情報があります。 最近生じているワークユニットのダウンロードがうまくいかない件は、 データベース・テーブル（リザルト)に壊れた部分があることに関係がありました。 毎週の定期停止時間の間に、この部分をきれいに直しました。 この週末は実質的に 2日以上の停止があったので、当然ながらサーバが需要に追いつくのに少し時間が要ります。 ワークユニットはプロジェクトの能力一杯のスピードで送出されています。 Happy new year! 気忙しい休日の期間が過ぎていきました。 数週間前に、プロジェクトのサーバクローゼット用の空調設備が故障し、 全システムを包む気温がすぐに10度上昇しました。 もちろんこの故障は週末に起こったもので、 高温値は警告システムの設定値のほんの少し下にとどまったので、 警告のメイル等を我々が受取ることはありませんでした。 この故障は、ベイエリアを襲ったまれな寒波が原因でした。 この休みの期間に、アップロード・サーバを何回か再起動せざるをえませんでした。 アップロード・サーバが重要なマウントを不定期に失ったからです。 この問題は SETI@home 拡張版が公開される前はより頻繁に生じていました。 (SETI@home 拡張版がプロジェクトのバックエンドサーバの負荷を大きく下げたので頻度が落ちたのです)。 しかし、参加者が増え、コンピュータが速くなるにつれ、同じ問題が再発しつつあります。 なぜこれが発生するのか、そしてどうやって直すかについて 我々はブレインスト-ミングをしてアイデアを出そうとしています。 リザルト・テーブルへの問い合わせが遅いことがあるという問題がありましたが、 それは今までたまに一時的しか起こらないものでした。 ところが、 この数日をみると発生頻度が許容範囲を超えつつあるようです。 サーバからサービス群を別のところに移動して負荷をさげたり、 サーバ群を再起動し、MySQL をリブートしたりしましたが、効果がありませんでした。 そこで今はテーブルの整合性検査を(毎週の定期データベースバックアップ時間に)実施しています。 おそらく、インデクスが壊れているのが見つかるでしょう。 何か新しいことが見つかったらお知らせしましょう。 今週末の最新情報をお届けします。 いつもながら、 皆さんに普通は伝えるまでもないような裏方の仕事で手一杯でした。 新しい例のマルチビーム用スプリッターは仕上がりが近づいており、 まもなくベータテストに入るでしょう。 ということは、 採取したてのデータで新しい解析をする処理が現れてくるということです。 Astropulse プロジェクトも、大きく前進しています。 Arecibo でのデータ採取は現時点ですべて自動化されています。 データでドライブが満杯になると、運用者に警告がだされて、 空のドライブとの交換をするようになっています。 データで一杯になったドライブが十分な数になると、運用者はここにドライブを送ってきます。 そしてここでは、インターネットを通じてそのデータを HPSS へコピーし、ワークユニットに変換することができるようになるまでの間、保存されます。 ここしばらく、参加者の経験という領域に深く注意をむけていました。 この領域へは今まで開発するための資源がなかった （そしてこれからもない）ところでした。 とりわけ、 新しい申請フォーム(原文) を使えば、クラシック版 SETI@home のころに獲得したけれど、 新しいアカウントに結びつけることができずにいた功績値(credit)を、 参加者の皆さんが再び手にすることができるようにしました。 さらに今週から、インターネット電話 (つまり Skype)を使って 技術サポート(原文)をしてくれるボランティアの方々のプールが用意できました。 このボランティアの人数は増えつつあります。 最後に、一つ前の技術ニュースの追記にまた追記事項があります。 それは、Intel 社の寄付は 実は、 デュアル・コア Xeon プロセサを 4つもつシステムであるということです。 4つのプロセサのうち、2つしか稼働状態でなかったのですが、 それでも hyperthreading のおかげでプロセサが8つあるように OS からは見えていました。 このシステムの BIOS をいじくって、ついに残りの2つのプロセサも認識させました。 今では hyperthreading の効果を入れると、OS によれば 計16個の 3GHz プロセサがあるということになります。 今日、定例のデータベース停止をいつもより少し遅れて実施しました。 (いつもこの作業を担当している人物が病気でお休みしたからです)。 それにもかかわらず、我々が主張している 4時間枠の中におさまるほど短い時間で終了しました。 一つ前の技術ニュース記事に追加情報があります。 最近の Intel 社からの寄付は、クワッド・デュアルコアの Xeon プロセサシステムではありません。 それは、クワッド・シングルコア Xeon プロセサのシステムで、 ハイパースレッディング機能を持っているものです (OS からみると、それは 8 プロセサを持つように見えます)。 昨晩、ほんの短い間でしたが停止していました。 これは、 ワークユニットを保持しているファイルサーバへのマウントを データ・ダウンロードサーバが失ってしまったからです。 この現象はまさしく確率的に生じるものです。 サーバ自身は自分の仕事をしっかりこなしています。 同様の現象を、かってシステム全体に負荷が重くかかったときに見たことがあります。 サーバが、ワークユニットとリザルトとをやりとりする頻度は、 拡張版クライアントでは大幅に少なくなっています。 ですから、 上記のような負荷が原因で発生しやすくなる問題も発生することが減りました。 ムーア則と恒常的な参加者増加は有り難いことなのですが、 それゆえに、この問題をまたいつか解決しなければならなくなるでしょう。 もうひとつ残っている問題で、不定期に起こる問題があります。 それは データベースへのアクセスが「異常になる期間(rough periods)」に関係しています。 (詳しくは昔の記事を見てください)。 基本的に起こっていることが何かを説明しましょう。 あるプロセスが24時間に1回くらいの頻度で、参加者/計算機/チームに関する有用な情報を XML形式のファイルに書き出しています。 このファイルは、 他のサイトでリーダーボードやグラフ表示等を公開できるようにするためのものです。 これらの統計情報を納めたデータベースのテーブルは、 大きくなりつづけています。 一旦、上記の処理が走りはじめると、このテーブルが リザルトのテーブルをメモリ上からはじき出してしまうということはあり得ることです。 そこで、我々はこのデータベース問い合わせを効率化する検討を行っています。 また、我々は新しい BOINC データベース・サーバを立ち上げることを考えているところです。 (SETI@home 用の科学データベースはこれとは別もので、 既に新しいサーバハードウェアの上で快調に動作しています。 ) 最近 Intel 社がいくつかのハードウェアを寄付してくれました。 その中には、 デュアルコアの Xeon プロセサを4つ備えた(つまり、3GHz のプロセサが合計8つある） システムがあります。 現在我々はこのシステムの奇妙な振る舞いをいくつか経験しており、 それらを解決しようとしています。 まだその最中ですが、 このシステムを信頼できるようになったら、 これをプロジェクトの BOINC データベース・サーバにして、 現在のデータベース・サーバは複製サーバにします。 これができれば、 必要なときに即時のバックアップが可能になりますので、 毎週恒例の停止をしなくて済むようになります。 まだほかにもあります。 Intel 社の別のシステムは既に設定が済んでおり、 バックエンドの科学 CPU サーバの一つとして使われています。 (このシステムは、アレシボから送られてきたハードディスク・ ドライブから新しいデータを読むことにも使っています)。 クラシックの頃のデータテープで、未着手だとわかっているテープが残っていました。 先週、その最後のテープが読み込まれて、 プロジェクトのスプリッタへの待ち行列に追加されました。 このテープの次は、何らかの形でこの作業の流れを通ったことがあるものの、 何か理由があってこのプロジェクトの主データベースには反映されなかったテープを対象に、 読み込みをしていきます。 そうなってしまった理由としてあり得るのは、 まず、データ不良(こうではないことを祈ります)、あるいは、 テープドライブの故障が理由で読まれずに残されたもの (これが想像以上にかなり多い)、粗末な初期解析のためそうなった、 あるいは、重複検査中の失敗につながったデータベース破壊のため、 といった理由が挙げられます。 ですから、90年代末のテープが待ち行列の中に現れても、 驚かないでください。 1998年に採取したデータは、2006年のものと同じ価値があります。 というのも、探している地球外知性体は何光年もかなたから信号を送ってきています。 時間がたっても信号が継続しているという一貫性を探し求めるに当たって、 この数年の差は問題になりません。 プロジェクトのダウンロードサーバが昨日午後から仕事の送出を停止していましたが、 それを検出できず、今朝やっと修正しました。 われわれはネットワークのアップグレードの大仕事の最中です。 (これについては別途ニュースで流しますので注目しておいてください)。 その作業の中で、新しいネットワークの取り回しをテストするために行った設定変更が、 長い暗号のようなシンボリックリンク連鎖がたどれなくなるという 潜在していた問題を表面化させてしまいました。 言い換えると、しまった！というやつです。 今朝早く、いつもの BOINC データベースのバックアップのため、 システムを停止しました。 大したことではありませんが、このとき、 プロジェクトのサーバクローゼットを少々掃除する時間を取りました。 すると、絡み合ったイーサネットケーブルがたくさん見つかりました。 これらは取り回しを直さねばならないでしょう。 より本格的な掃除をするには、 サーバ群を一時停止しなければなりません。 計画停止がこのために必要です。 新しいデータレコーダは完全に機能する直前まできています。 今日まで一週間ほど動いていますが、 (種々の問題がおきるたびに人間の介入が必要になる状態から脱して)、 もう少し自動化した運用ができるようになると、 より速くデータを収集できるようになります。 新しいデータからワークユニットを作り出すようにスプリッターを直すことや、 そのデータをクライアントが処理できるようにする作業もしていますが、 今は主に上記のデータレコーダを完全稼働させるために時間を割いています。 最近まで当プロジェクトの科学データベースとして稼働してきた サーバ castelli を本日の定期保守時間に最終的に停止させました。 この科学データベースは、現在 thumper 上で稼働しています。 上記は外からみるかぎりは正しい話です。 しかし実態としては、本日電源を切ったマシンは galileo という スケジューリング・サーバでした。 サーバ castelli は複数の CPU と数ギガバイトの RAM、さらには更新したての OS を載せているマシンでしたので、実は古いマシンである galileo を停めて、 サーバ castelli の名前を単に galileo に変更したのです。 わかりました? いずれにしても、新しいスケジューラが既にコンパイルされている状態なので、 早晩それが実装されます。 当プロジェクトは稼働状態に戻りましたが、 スケジューラ・ソフトウェアを交換してテストするために、短期間はシステムを停めるでしょうから、 今後、荒波を航海する期間がある程度生じると思ってください。 また、先週と同様、バックアップ処理後に BOINC データベースの性能の暴れが起きています。 これは落ち着くまで数時間かかります。 現在データベースの診断を小規模に開始しました。 最近の問題 (一つ前の記事を参照)を調査するためです。 どういうことかというと、 いままでリザルトは処理が完了した後、すくなくとも 1日はデータベースに残しておいたのですが、 今回その代わりに、処理が完了したらすぐにデータベースから削除しています。 ということは、リザルトのデータが当プロジェクトの科学データベースに取り込まれるやいなや、 参加者のデータベースから消えますから、皆様のアカウント・ページからは完了したリザルトが見えなくなります。 この状況は見た目のものだけであり、しかも一時的なものです。 データベースの中に他とつながりがなくなってしまった「孤児」状態のリザルトがないことを期待しています。 また、上述したリザルトの行の削除処理は、孤児状態のリザルトが無いことを確かめる助けとなるでしょう。 2つ前の記事で書いたの同様に、先週のサーバ問題とは全く相関なしに 「異常な期間(rough spots)」が生じています。 今朝もこれが発生し、 バックエンドサーバ群を停止・再起動するまでずっと継続しました。 通常1秒で終わるデータベース問いあわせが、いったいどんな原因で 1000秒もかかるようになってしまうのか？ 奇妙な点が以下のようにいくつかあります。 (a) 他の似た問い合わせは同じような影響を受けません。 (b) 「異常な期間」においてさえ、同じマシンで全く同じ問い合わせをコマンドラインから発行すると、 応答は1秒以下で戻ります。 そのサーバのログをみても、おかしなところはまるでありません。 これでは調査はお手上げです。 たぶん、mysql をアップグレードするのが順当なところでしょう。 忙しい週末でした。 木曜の午後にこのプロジェクト用のメイルサーバが一度は立ち上がったものの、 動かなくなりました。 いずれこのサーバは取り替える計画だったのですが、 この事件で実質強制的に取り替えることになりました。 まだこのサーバの回復作業は終わっておらず、 設定の複雑さに取り組んでいます。 メイルサーバの振る舞いは 現在だいたいは まともですが、 ときたま思わぬ動きをして手当てを要しています。 日曜には、プロジェクトのアップロード・サーバ(kryten) が他のマシンに NFS マウントをすることができなくなりました。 この異常が他のバックエンドサーバ全体に 将棋倒しのように波及してしまいました。 以前からこの NFS マウントが突然うしなわれる件が起こっていましたけれども、 これほど痛ましい結果にはなったことはありません。 しかし、対処方法は昔と変わらず単純です。 つまり、そのマシンを再起動するのです。 それでも、再起動の際には、 アップロード済みリザルトをたくわえる RAID 装置で 再同期処理が走るのを止めることはできないので、 それがうまく完了するようにプロジェクトを数時間停止しました。 稼働状態へ戻したところ、滞積しているトラヒックをかなり素早くこなしていきました。 全体的にみると、昔に比べてこの 6-12ヶ月のサーバ稼働時間の成績はすばらしいものです。 そこで最近活動していない参加者に復帰のお誘いメイルを一斉に投げたのですが、 そのとたんに、数台のサーバがダウンしてしまったわけです。 なんとタイミングの悪いことでしょうか。 まあしかたありません。 一昨日、新しいスケジューラをインストールしたところ、参加者のプレファレンスに関して小さなバグが見つかりました。 これはすぐに修正を作りましたので、更新された版をまもなく適用します。 今日は上記とは別のスケジューラの問題が見つかりました。 この数日の間、仕事がそれほど高速に送出されていない時に、2回の異常状態の期間がありました。 フィーダプロセスはスケジューラ経由で送出するリザルト用の待ち行列の長さを 100個以上に維持しようとします。 そのために その待ち行列を満杯にするリザルト生成処理が必要かどうか、 データベースへ問い合わせを出して継続的に調べています。 このデータベースへの問い合わせは通常は1秒以下で処理が終わるのですが、 何らかの理由で 1000秒ほどもかかるようになりました。 その時間の間に、 上記の小さな待ち行列は空になり、送出する仕事がなくなったのでしょう。 この現象が2〜3時間生じていました。 その時間の間、 フィーダプロセスが出す上記のデータベース問い合わせは、 ほとんどの場合は即座に結果が返っていましたが、たまに1000秒かかっていたようです。 結局は正常な状況に戻り、現在は安定しています。 これがどういうことだったのか調査しています。 今のところ新しい科学データベースはうまく動作していますが、 突然の不都合が起きた場合を心配して、古いほうの科学データベースサーバも稼働状態にしてあります。 数週間運用してみて、新サーバの状態に満足したら、古いサーバをお役御免にします。 データに関しては、新しいマルチビームデータ(1TB を越えるほどになりました） を収集している状況ですが、このデータが公式に用いられるまでには、 新しいスプリッタを作る作業や、クライアントに小さな表面上の変更、 そしてそのテスト作業をベータサイトで行う必要があります。 最近しばらくは、まだ処理されたことのなかった古いクラシック版のデータについて作業をしています。 今まで我々は、主に RFI によるデータ破壊がおきている可能性のある日のテープは処理を後回しにしており、 その時点では優先度の高い、よりきれいなデータの入っているテープが手に入っていましたので、 処理するものに不足はなかったのです。 ワークユニット生成のためこの週末に準備したテープの山が、 実はデータが壊れて読めない状態であることがわかりました。 そこで、今朝から正常なテープをできるだけ速く読み込んでいますが、 ちょうど今、溜めていた仕事が底をつきました。 今この文章を打っているうちに、新しいテープイメージがネットワーク上ですぐにも使えるようになるので、 そうしたらしばらくのうちに需要に追いつきます。 昨晩までで、科学データベースのすべてのデータを、古いデータベースサーバ (castelli) から新しいサーバ(thunper)へ移しきりました。 そこまでは良い話です。 しかし、まだベータプロジェクトのデータも thumper へ移動させなければなりません。 それまでは、ベータプロジェクトは停止させたままになります。 新しいデータベースには細かいチューニングがまだ必要ですが、 この作業は毎週の定期停止時間(あるいはごく短時間の停止）の中で行います。 いずれの停止時間で実施するにせよ、通常のリザルトとワークユニットの流れには影響はありません。 ところで、thumper というサーバの名前は、Sun 社が新しい Sun Fire X4500 システムの新シリーズに付けた愛称から単純にもってきたものです。 もう 1台手に入ったら、bambi と名づけるでしょう。 新しい科学データベースが動きだしました。 しかし残念ながら、 実用に供するにはまだ思わぬ性能チューニングが必要とわかりました。 現在このデータベースは、とても長い時間のかかるインデクスの構築処理の最中です。 なぜこのように時間がかかるのか正確に理解して、チューニングする必要があります。 しかし同時に、現在処理中のインデクス構築を途中で中止したくはありません。 ですから笑顔で耐えて、終わるのを待つしかありません。 うまくいけば、 今夜のうちに稼働状態にできるかもしれませんが、おそらくは明日の朝になるでしょう。 この大都会の中の生活とはこんなものです。 追加情報: 上記のインデクス構築処理はこれを書いたすぐ後に完了しました。 今、新しい仕事を送出しています。 この記事を書いている今、当プロジェクトの科学データベースの最終移行ステップを忙しく進めているところです。 この作業のため、スプリッターとアシミレータは現在停止させています。 科学データベースへのデータの追加と更新が今はできないからです。 したがって現在は新しい仕事を生成していません。 明日には稼働を再開する計画ですので、 それまでに仕事が不足することにはならないはずです。 追記: ベータプロジェクトの科学データも当然移行の対象ですので、 そちらのプロジェクトを今は完全に停止させてあります。 新しいドライブ筐体は(アレシボから送られてきたデータ一杯のドライブを読むためには) 使いものになりませんでした。 書くと長くなりますので結論から言うと、 原因はわかっていません。 しかし、新しい科学データベース・サーバを決めるのにさらに時間をかけるのはうんざりです。 そこで、計画を少し修正することにしました。 基本は、 このドライブ筐体を別のサーバに取りつけます。 どのサーバに付けるかはっきり決めていません (まず、データ転送帯域幅の要件や、PCI カードのサポートなどを確定させる必要があります)。 なんとかして近いうちに上記のデータをネットワークへつなぎ、その後、ワークユニットへの分割をすることにします。 結局こうすると、新しい科学データベースへの移行の最終段階実施を待つ必要はなくなりました。 それはつまり、1日程度の部分停止(その間スプリッタとアシミレータを停止します) で、残りの全てのデータを新しいサーバに移動するということになります。 その次に、完全な停止(しかし、より短時間です)期間を設けて、 新しいデータベースを使うように全ての設定を切り替えて、 プロジェクトが適切に動作することを確認します。 この作業は、来週火曜の定期停止時間の中で行うかもしれません。 大きな作業が近づいたら、ウェブの入り口のページに表示します。 1ヶ月ほどまえについに SETHI プロジェクトを立ち上げて再開したことを書いておくべきでした。 我々が Arecibo で集めているデータを使って、すくなくとも何らかの科学研究が行われています。 このデータは、近傍の星間物質に含まれる水素の詳細分布図になります。 しかし、再観測にむけた SETI の候補信号のほうはどうなっているでしょうか。 何が起こってきたでしょうか。 実は、候補信号の絞りこみ作業は(とても長い間)止まっておりました。 優先する他の大仕事があったからです。 (たとえば、プロジェクト全体の BOINC 移行、 新データレコーダの開発・導入・試験・稼働、新データベース・サーバへのデータ移行とそのサーバの立ち上げ、 無数のトラブルへの対処などなど)。 上記の新データベースが稼働し始めたならまず、時間を食う解析とデータ修正を行う必要があります。 そのあとで、テラバイトもあるスパイク、ガウシアン、パルス、トリプレットのデータの中に 潜む E.T.を探す作業を行うことができます。 先週金曜に発生した科学データベースの故障から、ほぼ稼働状態に回復しました。 今では新しい仕事を生成することができており、アシミレータは滞積してきたリザルトを解消しつつあります。 しかし、危険な状態から決して脱したわけではありません。 古い方のデータベース(故障中)からは、データのアンロードが未完です。 データ破壊はなかったものの、現在は RAID 10 ミラーの片側半分だけを使って運用しています。 ということは、もう一台だけでもドライブが故障したら、 データベース全体が失われてしまいます。 いったい何が起きたと思いますか。 上記のミラーディスク１組は、2つの独立したドライブアレイで構成されていますが、 この2つのドライブアレイの片方が死んでしまったのです。 これが昨週の金曜日に起きた大きな悩みの種であり、週末ずっと警戒体制をとることになってしまいました。 古いデータベースに残っているデータは、24時間以内にアンロードされるはずです。 そうしたら、そのデータを検査し、新しいサーバにロードします。 次に、両方のデータベースに載っているデータが等しいことを確かめます。 これが終われば、プロジェクト全体を1日停止して、 1週間前にこの計画を開始してから今までの間に生成したワークユニット・ 受信したリザルトをすべて新しいサーバへ移動します。 最後に、新しいデータベースを使うように全ての設定を切り替え、このプロジェクトを再開します。 万事うまくいってくれれば、新しいサーバへと完全に乗り換えられるでしょう。 そして、古いサーバをすっかり引退させることができるでしょう。 一方で、データレコーダについては良い知らせがあります。 DLT ドライブに多くの問題があったため、 この新しいマルチビームレコーダでは少しのデータしか採取できていませんでした。 この DLT の技術的問題を回避する試みの一つとして、交換可能な SATA ドライブに対象のデータを格納する方法に取り組んだところ、 実装もテストも含めてうまくいったのです。 今朝時点で、アレシボ側ではデータレコーダの全部分が稼働しています。 これに合わせるため、研究室においても部品の注文、設置、テストをしますが、 近いうちに終えることができます。 最終的には、テープでデータの移動をする代りに、 500GB ドライブ群をまるまる持ち回ることになるでしょう。 このプロジェクトで送出するべき仕事が足らなくなってしまいました。 おそらく週末までこの状態がつづきます。 なぜそうなっているか説明しましょう。 最近、Sun 社から寄付を受けた新しいサーバがあります(詳細は後を見てください)。 これを我々は新しい科学データベースのサーバにすると決めました。 現状の科学データベースはしっかり動作しています。 しかし、古くて(遅い)システムで動いており、 付けてある中古のファイバチャネル接続ディスクが異なる原因でしばしば故障しています。 先週ようやく我々の望むようにこの新しいサーバを設定し終えました。 今週は、旧システムからデータベースの全テーブルをアンロードし始めました。 ディスクの動作負荷が増えたので、前述のディスクが昨晩完全に異常を呈しました。 というわけで、今朝このデータベースをたち下げなくてはなりませんでした。 現在まだこのシステムの復旧作業中です。 BOINC のバックエンド機能のほとんどはこの科学データベースに依存していません。 しかし、スプリッターとアシミレータは依存しています。 アシミレータが停止状態になることは大きな問題ではありません。 ただ、 計算結果を科学データベースに組み入れるのが遅れるだけです。 しかし、 スプリッターが稼働しないと、新たな仕事を作り出すことができません。 このため、このプロジェクトの送出待ちの仕事をためる待ち行列が、 本日の午後にすでに空になってしまいました。 データベースの復旧は、とても今日や今週末のうちには終わりそうにもありません。 たとえ週末のうちに復旧できたにしても、最優先の仕事はスプリッターを稼働させることではありません。 まずは、まだアンロード作業が残っている少数のデータベース・テーブルを、 問題のディスクがまた故障する前にアンロードすることになります。 あなたのコンピュータを忙しく保ちたいなら、いつでも 複数のプロジェクトの仕事をする ことができます。 本日、いつものデータベース・バックアップのための停止を行い、 その時間の中で、UPS バッテリ一式の交換と、ファイルサーバの OS アップグレイド、種々のサーバプロセスのソフトウェアのバージョンアップ を実施しました。 仕事が不足する事態になったことを除いては、全てうまくいきました。 なぜ不足したかというと、どうも現在扱っているデータのノイズレベルが高いためのようです。 つまり、普通より計算処理にかかる時間が大幅に少ないのです。 送出待ちの待ち行列が現在は空ですが、それは特定の時点で送出するために余裕としてあるワークユニットの数が 0 であるということだけです。 現状の仕事の需要に対してわずかに追いついていないというだけです。 テープイメージをオンラインにもっとするにつれて、現在の傾向は持ち直すはずです。 状況の変化はというと・・・ 毎週の定期停止の時間に、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にあるデータをファイルに落とし、新しいデータベース・サーバに格納する必要があるので、 長い停止が必要になります。 しかし、この作業のほとんどは「楽屋裏」で行われ、 普通の参加者の活動にはたいして中断がおこりません。 すなわち、この作業手順の間、スプリッターとアシミレータが停止状態になるだけです。 アップロード用サーバをリブートするために、このプロジェクトを短時間停止しなければなりませんでした。 時たま、アップロード用サーバは科学データベース用サーバへの NFS マウントの うちのどれかを気まぐれに失うことがあります。 今回その結果として、 アシミレータが科学データベースに計算結果を追加できなくなり、 結果のアップロードも普通はできない状態になりました。 先週末の電源の瞬断によって、このプロジェクトの科学データベースが壊れました。 ミラー構成の RAID の一つが故障したものの、最終的には被害を受けたすべての ディスクドライブのデータを同期させることができ、それ以上のトラブルにならずに稼働状態似戻すことができました。 しかしながら、当プロジェクトはより速くて信頼性の高い 新しい科学データベース用のサーバがぜひほしいと願っています。 Sun 社は最近 Thumper (X4500) システムを我々にベータテストを目的に寄付してくれました。 これをデータベース・サーバとして使うことも許してくれています。 そこで我々はこのシステムの設定の最中です。 このシステムには、 デュアルコアの opteron が2つ、8 GB の RAM、500GB の SATA を24個 （これは搭載可能台数の半分で、合計12 TB ) が付いています。 我々の科学データベース自身には、約 1 TB の格納容量しか必要としません。 ということは、新しいデータレコーダが毎日 最大で 300GB データを記録するようになれば、 残りの容量を一時的なテープ・イメージの格納に使えるわけです。 (新しいデータレコーダについては、科学ニュースレターが近々出ます)。 今朝、5:00AM ごろから(12:00 UTC)、 研究所全体に渡って停電となっていました。 これは、 近くにある Lawrence Hall of Science というビルで電気設備の問題を調査することになったためです。 なぜ我々の研究所まで停電にしなければならないのかよくわかりませんが、 とにかく停電してしまいました。 停電直前の3:00AMまで待ってシステム全体の立ち下げ作業をしたい人は誰もいなかったので、 平日であった昨日の終わりに立ち下げを行いました。 いくつかの依存関係で問題があったほかは、今朝の再立ちあげですべての システムとサービスはきれいに再開されました。 (依存関係というのはつまり、あるサーバが稼働状態に戻るまで別のサーバがハングしてしまうということ)。 結局、電気設備の保守をしている人たちがやったことは、問題点を探し出すことだけでした。 聞かされたところによると、問題を解決するには将来もっと長い停電が必要になるということです。 本日、ハードウェアの再構成のために一度停止しました。 ケーブルの引き回しに問題があったので、思った半分程度しか仕事は片づきませんでした。 2時間ほどで再開したのはこのためです。 今回作業が完了したのは、当プロジェクトの BOINC データベース・サーバに搭載した メモリを倍増させる作業（8G から 16Gバイトへ)です。 ところが、 40z サーバのサービスプロセッサが出力する誤解を招くメッセージ群が、 この単純でかつ平凡な作業をおくらせてしまいました。 サービスプロセッサのイベントログから、昔の「重大エラーメッセージ」を消しておかないかぎり、 DIMM を追加しても、追加したことを認識しないのです。 スループット改善のデータを採るため、実は新しいメモリの全部は使わずに再起動しました。 まずは新しいメモリの半分だけを使いました。 その結果、I/O待ち状態の時間がはるかに少なくなりました。 これは我々が望んでいたとおりの結果です。 明日、毎週恒例のデータベース保守 (バックアップと圧縮)の後で、新しいメモリをすべてデータベースのために使うようにする計画です。 さらに、db_purge を設定しなおして、リザルトをより長い時間残すようにします。 BOINC のデータベースサーバと ウェブサーバ boinc.berkeley.edu を守っている UPS の動作が昨晩からおかしくなり始めました。 これでデータベースのほうが影響をうけることはありません。 というのも冗長電源構成を別に持っているからです。 しかし、BOINC ウェブサイトのほうは その晩 2、3回見えなくなってしまいました。 30分ほど前にこのプロジェクトを短時間停止して、上記の2つのサーバを 信頼がおける電源につなぎ換えました。 しばらくはそのままにします。 うまくいったようです。 これで難所を通り抜けました。 プロジェクトの BOINC データベースの大きさを格段に小さくしました。 どんな方法を使ったかというと、リザルトの削除待ち行列を消し去ること、 さらに db_purge 処理を加速することにより、リザルトの中身がディスクから 消えたらすぐに、プロジェクトのデータベースからもすべて消すようにするという 方法をとりました。 普通の状況では、少なくとも 1日は、古いリザルトの行をデータベース内に保持しており、 それによって、参加者の方々が最近計算を終えたリザルトを自分のリザルト一覧表示で 見ることができるようにしています。 この週末の間は、様子を見るためと、 遅れを取り戻すために、古いリザルトの保持を抑制します。 翌週になれば、以前のように db_purge パラメタを緩めて、 計算が終わったリザルトの行が生き残る期間を長くするかもしれません。 いずれにしても、データベースの大きさを圧縮できたので、 そのほとんどの部分がメモリ上に載るようになりました。 これで、 今ではとても性能が改善されています。 この状態は、もちろん、 サイズが大きくなり(同時にテーブルがディスク上で断片化する） のにしたがって、すぐに変化していきます。 しかし、追加のメモリ( Sun v40z 用メモリー 2GB DIMM 4つ) が今すぐにも得られる見込みなので、それを心待ちにしています。 つけ足しですが、以前の SETI@home クラシック用データサーバだった (古くて大きな Sun E450) は、昨日のサーバクローゼット再構成の仕事の中で、 まだとても有用であると判明しました。 それはかなりの大きさがあり、頑丈な車輪が ついているおかげで、研究室からサーバクローゼットへと 重いラック仕立ての機器を運び込むときに、台車として完璧に用をなすのです。 本日の停止時間のうちに、新しい(しかしとても音の大きな)ハードウェアを サーバクローゼットの中に移動しました。 それは、なにをおいても、 この1年かそこらの間 BOINC 主データベースを動かしている Sun v40z と、boinc.berkeley.edu 用の ウェブサーバ および alpha 版プロジェクトを 動作させている Dell linux サーバの 2つです。 一方、クローゼットの中から運び出したマシンは、 クラシック版 SETI@home の サブ科学データベースを受け持っていた cyclops (Sun 450)です。 まもなく、その古いデータをバックアップしてから、 落とし直します。 当プロジェクトは、また別の良くない症状におちいっています。 リザルト/ワークユニットの待ち行列が、時間がたつにつれ大きくなりすぎました。 これらの待ち行列がすこしでも短くなるように、システムの活動を停める必要があります。 あまりにも多くのリザルトレコードを保持するがゆえに余分に生じた負荷を、 プロジェクトのデータベースが処理できなくなってしまい、その間に ワークユニットを格納するディスク領域が足らなくなってしまったのです。 というわけで、新しい仕事を送りだすことは、そのための領域が確保できるまで行えません。 手短な状況報告: お気づきかもしれませんが、今、現時点で 当プロジェクトのデータサーバ群への接続の具合が不安定です。 これには2つ理由があります。 1つには、毎週定期的に実施しているデータベースの圧縮とバックアップの 前日に至っているので、データベースの状態が一番良くない日であるからです。 (データベースは断片化が進み、1週間のあいだに脹れ上がっているので、 物理的により小さな領域にきっちり詰め込まれているときに比べると、 データをその中から見つけ出すのにより多くのディスク I/O を必要とするのです)。 2つめの理由は、新しいコンソールサーバに接続するために、 スケジューラを手早く再起動したばかりだからです。 上記の状況のほかは、この数週間は並の忙しさでした。 新しいデータレコーダが完成して試験もしました。 拡張版の SETI@home クライアントはほとんど完成に近づきました。 その後、長時間かけて綿密な RAID 再同期処理を行ったところ、 マスター科学データベースのディスクアレイには、ドライブ故障が 3つあることがわかりました。 我々の持っている予備のディスクは、ホットスペア用のディスクが 2つ、取り置きが 1台あります。 ということは、このアレイは RAID 10 なので、データ内容の紛失はないはずだということになります。 しかし、これらの故障したディスクを取り扱うために、再同期の処理には追加の時間がかかったのでした。 しかし、なぜこれほど多くのディスクが故障したのでしょうか。 この装置は少し前に当プロジェクトに寄贈された古いディスクアレイでしたから、 そのディスクはかなり疲労していたのです。 このシステムでも、 すでにいくつか他のディスクが故障した経験がありましたから、 大きな驚きではありませんでした。 ひとたび再同期がすべて終わると(この記事を書いている時点から、だいたい 20分後の予定ですが)、 マスター科学データベースを再開して、そのテーブルを検査します。 (この検査には 24時間かかるかもしれません)。 そして、他のハードウェア検査もします。 それで全部正常なら、アシミレータとスプリッターを再開させます。 なにか異常が見つかれば、その対処のためにまた 1日余分に停止するかもしれません。 本日予定していた停止時間には、サーバクローゼットからさらに 2、3台の装置を運び出すはずでした。 (クラシック SETI@home のデータサーバと、古い科学データベースが入っている大きくて重い ディスクアレイが対象です)。 それを安全に遂行するため、つまり、移動する装置を何台かの重要なマシンにたまたまぶつけてしまって、 正常でない停止をさせないように、あらかじめ重要なマシンの電源を落としておきたいと思っていました。 プロジェクトのある湾岸エリアは現在荒々しい冬季にあり、今日の嵐がもたらした雷が キャンパス全体の停電を引き起こしました。 もちろん、この研究室も 朝8時に巻き添えになりました。 サーバ群の多くは支障なく停止しました。 この停電のもとで、とにかく我々は予定の仕事を進め、 クローゼットの整理を終わらせました。 これで、辛い姿勢をとらなくても、ラックの後ろに回ることが再びできるようになりました。 ネットワーク全体の立ち上げはつらい仕事になりました。 というのも、サーバ群はあらかじめ決めた順番で停止・回復をする必要があるからです。 ですから、隠れていたマウントの問題が数多く現れてきました。 (これは、 再起動することでしか解消されません)。 さらに、いくつかのディスクドライブは、 fsck をかける必要がありました。 それでも、プロジェクトのマスター科学データベースを 除いては結局きれいに再起動されました。 マスター科学データベース用のマシンでは、ファイバチャネルのループの1つが生き返りませんでした。 ケーブル不良でしょうか？ GBIC がおかしいかな？ まだよく分かっていません。 というのも、 その端末装置がブート時診断メッセージの全てを取り出せるほど上手く動かなかったからです。 ラップトップのマシンを接続して、診断メッセージを見ようと hyperterm を使って格闘しました。 今のところ分かっているのは、そのマシンは動いているということです。 説明できる理由はないですが再起動はうまくできました。 それでも、すべての メタデバイスは再同期が必要でした。 この再同期処理には、最大 24時間かかるかもしれません。 その間、マスター科学データベースは停止します。 ということは、 スプリッターとアシミレータは動作できないということであり、 そのかなり長い停止が終わるまでに、おそらく送出する仕事に事欠くでしょう。 なんともはや、そういうことなのです。 我々がどこかに消え去ってしまったと思われないように、手短に記事の更新をしておきます。 我々は、大がかりな後片づけの期間に突入していました。 つまり、 プロジェクトのサーバ用クローゼットに新しいマシンを入れる準備として、たくさんのマシンを移動しました。 システム全体をばらばらに分解していましたので、この際、全サーバの /usr/local 以下を 掃除し、古い版のソフトウェアを更新するなど、色々のことを我慢してやっても良かろうと判断しました。 当然、どこもかしこも動かなくなりました。 この二週間ほどの間、小さな不具合をあっちで直し、次はこちらという具合の もぐら叩きゲームに時間を費やしていました。 これらの不具合のいくつかに、気がつかれたかもしれません。 例えば、日替わりのはずの「参加者の紹介」は、パスの設定がおかしくなって、 1週間ほど変化しなくなっていました。 それ以外にもいくつか小さな問題がありました。 アシミレータの1つは、 エラーメッセージも出さずに異常終了しつづけました。 デバッグに少々苦労した後、やっとそれはデータベースの中に壊れたレコードが 1つ あったためだと分かりました。 しかしそれ以外は、ゆっくりとですが着実に進捗しました。 新しいデータレコーダはもうすぐ用意ができます(現在、ストレス・テスト中です)。 さらに、明日は古いサーバをもっとたくさんクローゼットから追い出す計画をたてています。 本日、もう一度データベースのバックアップと圧縮を素早く実施した後、 MySQL の版を再びアップグレイドしました(最新の 4.1.x になりました)。 このアップグレイドで問題は発生せず、いくつかの問題が解消されたようにみえます。 もっとも顕著なのは、参加者の皆さんが、"merge computers" の機能を再び このプロジェクトのウェブサイトで使えるようになったことです。 この機能が発行していた問合わせが、このシステムを動かない状態にしていたことがありました。 この数日のうちに2回ほど停止をいたしました。 一つは意図せぬものでした。 前にも書いたように、プロジェクトのウェブサイトが持つ "merge computer" 機能に関連して、データベースのロックに問題が残ったままなのですが、 うっかりしてこの機能を有効な状態に戻してしまったために、停止させてしまいました。 昨日は、いつも実施しているデータベースのバックアップと圧縮を行いました。 処理能力の問題をなぜ抱えているのかを解明する作業を続けるあいだ、 このような停止を週に2回実施しようとしています。 本日は、ワークユニットを格納しているディスクアレイの一部であった ディスク筐体を1つ交換しました。 再起動してもシステムが古いディスクを認識しようとしなかったことを除けば、 この作業は面倒を起しませんでした。 ついにこの問題の原因が突き止められました。 システムの qlogic 製 ファイバチャネル・カードの設定を「リフレッシュ」 してやらねばなりませんでした。 このために必要だった操作は、 コンソールを装置につないでBIOS画面に入り、なにもせずにすぐに終りにする というだけのことです。 いずれにせよ、このシステム全体は稼働状態にもどり、 走っています。 SETI@home 拡張版が使えるようになると、このプロジェクトのサーバ負荷は大きく軽減されます。 というのも、拡張版でのワークユニットは処理するのに時間がかかるからです。 (処理量が多くなりますから、ワークユニットあたりの功績(credit)も、 それを反映して大きな値になります)。 しかしそれまでは、このプロジェクトのサーバにかかる負荷状況はしだいに 悪化していきます。 具体的には、毎水曜日に稼働を停めて 実施していたデータベース・テーブルの圧縮・バックアップ処理は、 一日前にずらさざるを得ませんでした。 もしかすると、この大きな トラフィックをなんとかするまでの間に、停止時間を週2回とる スケジュールに移行するかもしれません。 先週はその他にもサーバに関する問題がありました。 ディスクのリモートマウントのゴミ(stale mounts) を掃除するために、いくつかのサーバを 再起動しなければならなかったとか、そういう諸々のことです。 空調の聞いたクローゼットへ新しい本番マシンへ押し込むため、 クラシック用バックエンドサーバを停止・転用させる仕事を精力的に進めています。 新しい本番サーバの温度が上がりすぎて、もう長く待っていられないほどの量の警告が 表示されるようになってきているからです。 現状では、 BOINC のバックエンド サーバの半分が、人間のためのスペースである狭い研究室にまだ置かれて います。 そこは、うるさいマルチ CPU のシステムを置くようなところではないのです。 本日の停止時間はいつもより少し長くなりました。 古いマスター科学データベースの マシンを停止させていたからです。 これで、おおきな筐体をもつ A5000 ディスク 4台がお役御免になります。 明日には、 前述のクローゼットからこれらを追い出せます。 現在のマスター科学データベースの候補信号テーブルには、 いくつか新規のフィールドを追加しなければなりませんでした。 この影響で、この記事を書いている時点でアシミレータ群は稼働させていません。 新しいテーブル構成にあわせてアシミレータをリコンパイルし、テストしている最中だからです。 この月曜に起きたデータベースのクラッシュ事件を、我々は MySQL を本当にアップグレイドするべき時期にきたことの警告として受け止めました。 今まで走らせていた MySQL は 4.0 です。 本日、定期停止時間の最中に 4.1に 上げました。 通常のデータベース・バックアップが済んだ後に作業を開始しましたが、 この種のアップグレイドは手順が単純であったことなどありません。 基本的には、新しい版を tar で展開し、あるべき場所へシンボリックリンクの指す先を変更してから 再起動するわけです。 バックエンドのプロセスを１つずつ個別に試験していきました。 それぞれは皆上手く動作しましたので、全部一緒に動かしましたが、 とたんにデータベース・サーバが行き詰まりました。 新しい innodb テーブルのロック問題に何らかの関係があると推測して、 関連するパラメタを手直ししました。 同時に、いくつかインデクスを再構築も したのですが、結局、効き目がありませんでした。 ついに、ある特定のクエリが出た後に全ての問題が積み上がってしまっていることを 発見しました。 そのクエリは、"merge hosts" の update 操作でした。 この機能は当プロジェクトのウェブサイトのためのものです。 いくつかの理由で別々のものとしてデータベース上は見える 参加者の計算機が生じることがあるのですが、それらを同じものとして束ねて 見せることが参加者にできるようにする機能です。 これが問題を引き起こすなど誰も予測していませんでした。 それで、この機能は問題の詳細が理解できるようになるまで使えないように することで対処しました。 これでうまく行くはずという論理はどんなものかというと、 この機能だけが php 経由で innodb テーブルへの更新をするものであり、 新しい MySQL ライブラリを使う php はリコンパイルする必要があったのかもしれないから、 というものです。 いずれにせよ、このプロジェクトは今は稼働状態に戻っています。 きっと 今晩はこのまま動きつづけてくれるでしょう。 また別の マシン sagan の話です。 このマシンは今は何も仕事をしているわけではなく、 サーバ・クローゼットは暑苦しくなってきていたので、 sagan を本日からずっと停止することにしました。 このマシンは SETI@home 用のデータ・サーバ役を果たしていたマシンでした。 ですから、クラシックで送出された全てのワークユニットと、 受信されたすべての計算結果は、このマシンのイーサーポートを通過しました。 このマシンをこれからどうするか、特に計画は持っていません。 オークションにでも出してみますかね？ 正午ごろ(現地時間)に、 BOINC のデータベースが止まりました。 。 不整合のある状態になってしまったので、正常な動作をしなくなりました。 こうなるとデータベースは自動的に稼働をやめて、時間のかかる回復処理を始めます。 それが終わった後で我々はこのプロジェクトを稼働状態に戻しました。 このプロジェクトにかかる負荷が増え続けているために、 上記の事態が以前より頻繁におこるようになってきています。 そこで、おそらく今週の後半に MySQL の版をアップグレードしようと計画しています。 お知らせしていたように、本日はいくつかのディスクを入換える作業をするために停止しました。 ワークユニット格納用のサーバエンクロージャの代わりの装置が到着しており、 交換は簡単な作業のはずでした。 ところが爆発のようなことまで起こって、それどころではありませんでした。 ワークユニット格納用のサーバを停止するため、スプリッタとダウンロード処理をする 全てのマシンでまずそれをアンマウントせねばなりません。 しかし、 koloth と kryten の 2台であらゆる種類のマウント関連の問題が起こりました。 結局、データの通るパイプを掃除するために、kryten を再起動せねばなりませんでした。 それでも、kryten のシャットダウンには、45分もかかりました。 なぜそんなにかかったのかは、 わかっていません。 リザルト格納用のディスク群が kryten に接続しているのですが、 それらがとても忙しく何かのために動いていたので、電源を強制的に落としたくはありませんでした。 とうとう、そのディスク群が静かな状態に落ち着きました。 ところが、 その後もまるまる 15分 なにも動きがないのです。 我々はとうとう諦めて、 電源を落としました。 そして電源スイッチを ON にもどしたら、こんどは電源がはいらないのです。 もう一度、OFF、 ON と操作してみました。 すると今度は電源ケーブルあたりから煙が立ち上り、 火花が吹き出しました。 うわ〜ぉ。 電源コードはすこし溶けてしまったようでした。 それは捨てて、 新しい電源コードともっと良いサージ保護回路をそこに直接つなげて、 kryten の電源を入れました。 ところが (プシューと音がして) 15 秒もたたないうちに死んでしまいました。 明らかに、電源供給回路が悪いのです。 とても幸運なことに、我々は 予備の E3500 電源供給装置 を地下室に眠らせていました。 それと交換するのは簡単な作業でした。 そして kryten の電源を入れ直して しっかり上手く動きだしました。 これで、とてもほっとしました。 というのも、現時点では kryten のためのバックアップとなる良いサーバマシンはまったくないからです。 慎重にチェックした後、すべてを再マウントして、とうとう稼働状態にもどすことができました。 (訳注。 やれやれ)。 プロジェクトのマスター科学データベースの合併処理が完了しました。 SETI@home の クラシック版および BOINC 版の両方のクライアントから戻ってきた 検証済の候補信号のすべてが、1ヶ所のサーバにまとめられました。 これで、我々は次の段階の科学分析プログラミングを開始するかもしれません。 合併処理の最後の段階は月曜に開始しました。 それは予想より長くかかり、 送出する仕事が足りなくなってしまいました。 仕事がなくなった状態は、 まる 1日におよびましたが、今、仕事を提供するように稼働状態に戻しました。 合併処理は実は昨日のうちに終わっていました。 しかし、新しいスプリッタとアシミレータ のコンパイルに問題が発生したため、新しい仕事の生成が今し方までできなかったのです。 もちろん今までの長引いた停止の後と同様に、サーバ群全体が「遅れを取り戻す」 までにしばらくはかかるでしょう。 データベース合併処理の最後の大段階が今朝始まりました。 アシミレータとスプリッターを現在停止させているのはこのためです。 要するに、先月(合併処理を始めた時点からの期間に） 集約されたデータを全て今、合併させています。 この処理には2日ほどかかるはずです。 この長さに渡って送り出す仕事が蓄えられている分で 充分であることを願っています。 長い週末の間、接続の問題がいくつかありました。 負荷が高くなったときには、 アップロードとダウンロードのサーバの両方で、オートマウンタに問題がおこり、 突然マウントした先のいくつかが不規則にはずれてしまいました。 これが生じてもアップロードとダウンロードのサーバは機能しつづけますが、 いくらか格落ちした状況で動作することになり、結局は再起動が必要になってしまいました。 また、フィーダ・プログラムにはまだ、共有メモリーセグメントで行き詰まるというバグがあるので、 送出する仕事を充分にはキャッシュできません。 これら両方の問題は調べている最中です。 さらに、研究所のファイアウォール/ルータには解決がのびのびになっている問題があり、 研究所の管理者が担当しています。 だいたいのところ、事態はかなり改善されて現在にいたっていますが、 いつものように残務を消化するための期間が2〜3日必要かもしれません。 良い話としては、クラシック版のデータサーバを停止しましたから、 Cogent が提供する 数少ない貴重な IP アドレスの 1つを空けることができました。 そこで、プロジェクトのスケジューラを我々専用の Cogent 回線 のほうに移そうとして作業をしています。 そうすれば、研究所のルータからその分の 帯域幅を外せるので、上記の問題があっても影響をうけずにすむようになります。 今朝、手早くデータベースの圧縮とバックアップをもう一度行いました。 2時間しかかかりませんでした。 というのも、プロジェクトのデータベースは、 今や現運用が必要とする最低の大きさになっているからです。 追加でデータベース用サーバマシンの BIOS 設定の変更のためにリブートする時間をかけました。 (この BIOS 設定変更は、それ自身無害ではあるものの、このサーバのログをいっぱいにしてしまう うるさいメッセージを消すために行いました)。 作業を早めに始めたのは、だめになった UPS 用バッテリーの 交換用のバッテリーが到着していることを期待してのことニでした。 しかし、今朝までには到着していませんでした。 もし到着していたら、 この停止時間のうちに UPS を使いまわして交換する作業をしたはずです。 多分次回に実施することになります。 いずれにせよ、もう全てがきちんと動作していて残務も消化しましたから、 データベースの圧縮とバックアップのための停止時間は、定例の毎水曜に戻します。 注目すべきことに、このプロジェクトでは 1日ごとに 120万個の リザルトを処理できています。 この数値は、当初我々が期待していた 処理可能能力である 100万個/日 をかなり上まわっています。 しかし、明らかにプロジェクトのサーバ群は無理をしており、 何かが起きたら 1ヶ月におよぶバックエンドの沈滞症状におちいる可能性があります。 将来の SETI@home アプリケーションは、計算処理に今より長い時間がかかるワークユニットを採用しますから、 それが助けになるでしょう。 また、いつかはハードウェアを新調できればと思っています。 データベースの複製サーバを新調したいです。 そうすれば、現在のような定期的な停止をしなくて済みます。 マスター科学データベースの合併処理は、主な部分が完了しました。 合併処理の最終段階を実施する停止期間について、その形態と停止機能範囲の計画を行っています。 以前の技術ニュースで述べた予想とは異なり、この作業のための停止は 1日以上必要かもしれません。 この停止期間を我々は「部分的な」停止にしたい (つまり、参加者はその期間、 アップロードとダウンロードができるようにしたい) のです。 そのためには、 「完全停止」する期間がほとんどなくなるくらい最小化できるように、 慎重に計画しなければなりません。 その他の愉快なニュース: クラシックプロジェクトで 「いんちき」をした明白な兆候のある参加者について、 その功績(credit) の値を調整する作業を最終的にやり終えました。 クラシックのプロジェクトでは、 実際の仕事をせずにシステムを騙して功績を得ることがとても簡単にできました。 最終的に、上位 10000名の参加者のうち 約 900名から、功績の一部または全部を除去することになりました。 (これらの全ての参加者は、だいたい 20000 以上の功績(credit)を獲得していました)。 それ以下のところでは、ひどい「いんちき」の兆候を明らかにするには、データが充分ではありませんでした。 (もちろん、残りの数百万の参加者について検査をするためには、時間もディスク領域も充分にありません)。 この調整が済んだ功績値のデータは、まだであれば近いうちに BOINC データベースに反映されるはずです。 これで事件は解決。 この週末、キャンパス全体に渡ってインターネットへの接続にいくつもの問題が起こりました。 接続が不定期の間隔で失われ、通信できない期間が数分続くということがおきました。 これについてはすでに解決されたと考えています。 BOINC データベースをさらに圧縮しバックアップするために、もう一度短い停止を本日実施しました。 連続しておこなった圧縮処理によって、データベース・サーバのスループットは大幅に改善されました。 技術ニュースの中で以前に書いた理由によって、 プロジェクトのデータベースは 31GB まで脹れ上がっていました。 それはすべて、 BOINC バックエンドシステムの少数の待ち行列に＊最近溜まったリザルトのせいです。 1月2日に 25GB まで縮み、5日には 19GB になりました。 今日の圧縮で、とうとう 大きさは 13GB しかなくなりました。 これでバックエンドサーバ群はとてもうれしい状態になりました。 80Mbits/s の速度でデータを送出できており、コネクションの切断も起こっていません。 初めに起こる混雑状態を抜け出したら、サーバ状態の計数を再開することができるかもしれません。 一方、マスター科学データベースの合併処理は終盤に差しかかっています。 スパイク信号とガウシアン信号のテーブルはすでに合併を済ませました。 残っているのは、パルス信号とトリプレット信号のテーブルです。 さらに、12月中旬ごろから送られてきている リザルトと候補信号の整理を 最終的に実施しなければなりません。 この作業のための停止期間と停止機能範囲(あるいは停止しなくて済む可能性も含めて) については、これから決定するところですが、それほど劇的なものにはならないでしょう (つまり、おそらくは 1日以下の停止、もしかすると数時間で済むかもしれません)。 一日半の長い停止の後、このプロジェクトを稼働状態に戻しました。 この停止の間に、12月初旬と同じレベルにまで BOINC データベースを掃除しきりました。 もちろん、BOINC クライアントが一斉に仕事の要求をこのプロジェクトのサーバに投げてくるので、 サーバの動きはのろくなり、痛みを伴う期間が生じることになります。 今までいつもそうだったように、結局はこの期間を乗り切ることができるでしょう。 一方で、マスター科学データベースの合併処理はとても順調に進んでいます。 リザルトと候補信号のテーブルの複写が予想以上に速く進んでいるのです。 今は、データの流れる「パイプ」を掃除するため自ら課した停止時間のただ中です。 BOINC のデータベースに圧縮処理を月曜に施したおかげでかなり良くなりました。 最後まで残っていたやっかいな残務の待ち行列がなくなるほどにまで改善されたのです。 しかし、我々が望んでいたほどには速くなっていません。 いくつか数字をあげてみましょう。 BOINC のデータベースは、全体をアンロードして圧縮なしの ASCII ファイルにすると、 大きさは通常だいたい 17GB になります。 これほどの大きさになるのは、 主に膨大な数のワークユニットとリザルトのテーブルが含まれているためです。 アシミレータとファイルデリータの問題のせいで、12月 21日までにデータベースの 大きさは 26GB に達しました。 12月 28日 には 31GB でした。 古いワークユニットと リザルトを消せないために、プロジェクトのデータベースは通常の大きさの約2倍までになってしまいました。 まったく酷い状態にありました。 新年に入って少し回復し、月曜に行った圧縮処理で大きさは 26GB にまで戻りました。 それでも、百万個のワークユニットと四百万個のリザルトの残務を抱えていましたから、 それを消し去るまではそれ以上データベースのサイズは小さくなるはずもありません。 今朝、プロジェクトのスケジューラを停止し、溜まっている待ち行列が最終的に消えるようにしました。 これがすっかり済むには明日の朝までかかります。 今後数週間に渡って改善しないかと見守っていくよりも、 ぐっと我慢してこの症状を消し去ることを選びました。 待ち行列群の長さがすべてゼロになったら、 もう一度すばやくデータベース圧縮とバックアップを行い、稼働状態に戻します。 この数日小さな騒動がたくさんありましたが、全般にわたって概ね順調に運用されています。 ワークユニット用のディスクが満杯に近づいてきていたので、ワークユニットの生成を 金曜日には抑えなければなりませんでした。 領域の空きをつくろうと作業している間に、 そのディスクの 1つのパーティションが故障して短時間の停止を引き起こしました。 (さらにその修理のため今朝も短時間の停止をしました)。 その上、土曜には当プロジェクトが使っている ISP 接続で 2時間ほど、 一種のルータ循環問題が起こりました。 今日は、スプリッターに食わせるためテープを待ち行列に置いたのですが、 そのいくつかは結局中身が空でした - そのため、スプリッターはそれを処理しても何も生成しませんでした。 ですから一晩は送出するリザルトが少々乏しくなるかもしれません。 しかし、明日には回復します。 昨日、SETI@home クラシック プロジェクトを停止しました。 しかし実際のところは、 すべてのサーバがまだ動いたままです。 新しいワークユニットを送出するのを止めて、古いクライアントに対して 送るメッセージを BOINC へ切替えるよう促すものに変えた、これだけの変化です。 この切替えを実施したとき、幸にも BOINC のバックエンドサーバ群は完璧に動作してくれました。 上手くいっているといっても、それはマスター科学データベースの合併処理の最中に我々がまだいるという 事態は除いての話です。 合併処理は現時点で、25% まで済みました。 この処理のおかげで、 アシミレータによってまだデータベースに組み込まれていない「遅延した」ワークユニットが、 今まだ、ぼぼ百万個あります。 それらは、サーバ状態ページの「取込み待ちのワークユニット (waiting for assimilation)」 キューには現れません。 これらのワークユニットは、合併処理を始めた最初の数日間に溜まったものです。 しかし、そこでデータベースを切替えたので(以前の記事参照)、今になって 取込みを行う前にいくらかのデータベースの後片づけを必要とします。 1テラバイト容量の記憶装置がこのプロジェクトには1つしかなく、遅延させられた ワークユニットはそのうち、350GBを占めています。 さらに、新規参加者の流入が続いており、 (それらがワークユニットを要求する量が増えているため)、このプロジェクトの ワークユニット用記憶装置はほとんど満杯です。 前回、満杯の事態に陥ったときには、長さゼロのワークユニットがクライアントに送出してしまい、 結果的には害のない悩みで済んだものの、まずいことになってしまった経緯があります。 本日、短い時間の間スプリッターを停止して、アシミレータとデリータがすこしばかり追いつくようにし、 新しい仕事のための空き領域ができるように仕向けました。 より多くの記憶領域をあけるため、遅延させられたワークユニットを別の記憶装置に移動させてしまうよう手を打っています。 この処理は新しい仕事をスプリッターで作るのと同じ速度で動くようにしていますから、 問題の記憶装置を近いうちに満杯まで使い切ってしまうことは決してないでしょう。 (現時点で、その記憶装置の使用率は 98%。 その値は下がりつつあります)。 よし、当面のサーバの問題に関してはジャングルから抜け出しました。 このプロジェクトでは多くの場合そうなのですが、本当の問題点は現象の陰にうまく隠されていただけだったので、 最終的な解決策は基本的には単純でした。 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週間たまっていた残務を消化してしまいました。 もちろん、これによって、アップロードに成功したクライアントプログラムは追加の仕事を求めますから、 プロジェクトのスケジューラには新しい圧力がかかります。 明日の朝にはすべてが元どおりになってくれるのではと、我々は想像しています。 ただ念のために、数個のバックエンド・プロセスを今夜はずっと止めておきます。 その一方、バックグラウンドでは、 マスター科学データベースの合併作業がゆっくりとではありますが、滞りなく進んでいます。 この数日、当プロジェクトのアップロード・ダウンロード用サーバで、 接続が切れてしまう現象が続いていました。 このため、巻き込まれた方々皆さんをイライラさせておりました。 また、我々はマスター科学データベースの合併作業の第一段iii階を完結させようとして手一杯でした。 アップロードとダウンロードを別のサーバに分担させたおかげで、 現時点では仕事を取りに来れば誰でも取れます。 この状態はまだサーバ状態の表示をするページに反映させていませんが、 現状は、両方の仕事をこなせるマシンをなんとか手に入れるまでの仮の解決でしかないかもしれません。 そうです、クラシック版のプロジェクトの処理量が減るに従って、 より多くのサーバ入換えがあるかもしれませんから。 今のところ、アップロード用サーバで接続切れがまだ生じています。 けれども、 良いニュースとして、ワークユニットのダウンロード 1回に対し、 4回のリザルトのアップロードの処理をこなしているということが分かっています。 ということは、アップロード・サーバは順調に残務を消化しつつあるということです。 この記事を書いている時点では、毎秒 約 35個のリザルトを受信し、毎秒 約 8個のワークユニットを送出しています。 マスター科学データベースの合併作業では、思わぬ障碍に数回つきあたってしまい、かつ、 元の状態にもどるには作業を進めすぎていました。 作業スペースが不足してきたので、 予備の計画を使うことにしました。 つまり、3つめのデータベースを作るのです。 新しいワークユニットとリザルトはこの新しい 3つめのデータベースに追加されるので、 今までの 2つのデータベースの間でデータを移動する作業をゆっくりと、 時間的切迫感を感じることなく実施することができます。 こうした結果、合併作業の計画は少々複雑化してしまいますが、 当座の緊張を大いに減らしてくれます。 新規参加者の流入によって、データの流れが滞ったのは致し方ないところです。 二日ほど前に、アップロード・ダウンロード用のサーバ(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 にはワークユニットのアップロードとリザルトのダウンロードの仕事が滞積しており、 これらを消化中です。 ここへの書き込みはこれからも増えていきます。 サーバで起きている現在の問題で発見があれば載せますし、 データベースの合併処理が進めばそれも。 マスター科学データベースの合併はまったく作業がとまってしまいました。 突然の幸運で全てがうまくうごいてくれないかぎり、 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 接続からインターネットへ出ていっています。 もちろん、クラシックのほうの活動は来週以降には大きく減りますから、 帯域幅の制約が問題になることはないはずです。 昨日から、SETI@home の参加者に大量のメイルを送りはじめました。 このメイルで 古いプロジェクトを 12/15 には閉鎖することを警告しています。 今朝時点で活動していると認められる２０万人のクラシック版参加者に送信しました。 活動していない参加者には、今、メイルを送っている最中です。 BOINC へ新しく参加者が流入しているため（さらに、タイミングが悪いことに、 googlebots や 他のウェブスパイダーの影響で）、当プロジェクトのウェブサーバの負荷が、 この 12時間ほど異常に高くなっていました。 これを解消するため、結局我々はは 2台めのウェブサーバを増設し、 負荷を分担させることにしました。 DNS 情報の更新がインターネットに広がっていくにつれて、 マシン klaatu (これが1台しかなかった元々のウェブサーバ）にかかっていた負荷が減っており、 一方、マシン penguin (2台めの新ウェブサーバ) の分担する負荷が増えつつあります。 両方のマシンとも、Sun D220R です(2 x 440MHz Sparc, 2 GB RAM)。 この高負荷問題がおきた一つの理由は、ウェブサーバの設定で、必要以上に多くのプロセスを作るようにしてあったことです。 これらが消えずに残り、仕事をしていないスレッドがデータベースをオープンしていました。 その結果、データベースのコネクションが不足してしまったのです。 この状態を示すメッセージを見た参加者も、 負荷が一番高くなったときにはいらっしゃいました。 一見これはデータベースの問題に見えたのですが、実のところ今はこのデータベースで、 10% の性能向上を享受しています。 先週のことですが、 myisam というデータベース・テーブル群から(このテーブルにはウェブ掲示板の他には大したものは入っていません)、 少々メモリを innodb というテーブル群へ移動しました。 （こちらには、 参加者、計算機、リザルト、ワークユニット などの表が含まれます)。 myisam に割り当てていた余分のメモリは要らなかったのです。 ところで、例のマスター科学データベースの合併については(先日の記事参照)、 来週初めを念頭に作業を継続中です。 マスター科学データベースの合併（一つ前の投稿を参照)については、再び延期しなければならない模様です。 少なくとも次週、おそらくもっと先へ延期されます (ご存知のように来週は休日 Thanksgiving Day があり、実質は短いですから)。 データ移動のための C++ で書かれたツール群の開発は継続中であり、そのソフトウエアが完全にテストできる前には 拙速に何もしたくありません(もしそうしたら、科学データベースをだめにしてしまうかもしれませんから)。 一方で、この合併作業と、全クラシック参加者へ出す BOINC への移行依頼の大量メイルとは、 組合せて実施しなければなりません。 このメイルの送出を今週開始できたらいいなと思っていましたが、合併処理の遅れで全てがずれ込んでしまいました。 (長い停止期間を必要とするかもしれませんし、 新しい大量の参加者がこのプロジェクトに最初にアクセスを試みたときに失敗することも避けたいので、 当然こうなりました)。 たぶん、大量の依頼メイルの作業は来週初めに開始します。 合併処理はもっと後に始めます。 本日は、水曜定例の停止時間にプロジェクトのデータベースおよびアップロード・ディレクトリの バックアップを行い、さらに、この機会をつかっていくつかの装置の移動を行いました。 我々は、別途資金を得て活動している天の川銀河内水素サーベイのプロジェクトと、 親密な関係をもって活動しています(多かれ少なかれスタッフの顔ぶれも重複しているところがあります)。 このサーベイプロジェクトは、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++ を使って、合併のための処理に加える修正にずっと取り掛かっていました。 明日には(本日の停止による遅れを取り戻した後で）、再びマスター科学データベースの合併処理を 試みることができるように、この修正の作成とテストが出来上がることを期待しています。 (更新 22:45 UTC - 後述の追加部分をご覧ください) 本日、マスター・データベースの大合併の作業を開始しました。 この処理段階の本質は単純です。 つまり、 SETI@home クラシックと SETI@home/BOINC で得られた 科学的データをまとめて、大きなデータベース一つにするということです。 しかし、今回の作業がこの数ヶ月実施してきた作業の頂点となります。 この数ヶ月はなにをしてきたのでしょうか。 まず初めに、 1つのサーバにある全てのデータを別のサーバに移動しなければなりませんでした。 そして、冗長なデータを削除し、以前からのレコードにあたらしいフィールドを追加して内容を入れました。 さらに、データベースを合併させるソフトウエアを書いてテストしました。 これらは、 全てデータベースの関係制約を維持したまま実施しなけばなりませんでした。 要するに、たくさんの整理作業、たくさんのテスト、データベースの全データを主要な処理段階ごとに 毎回バックアップすることでした。 この合併処理が走っている最中は、マスター・データベースへの更新はなにもできません。 このプロジェクトのスプリッター(データベースへ新しいワークユニットを追加します）を停止しましたし、 アシミレータ(これは新しい候補信号を追加します)も停止しました。 この前の週末に、約200万個の未処理のリザルトを生成しておきましたので、 クライアント群をこの停止期間のほとんどのあいだ、仕事に不足させることはないはずです。 アシミレータの待ち行列はもちろん、たいへん大きくなります。 候補信号のデータを除いた他の全ての合併処理が終われば、スプリッターは稼働状態に戻せるでしょう (この時点で、スプリッターが新しい仕事を合併したデータに追加しても、 関係データベースの制約条件を逸脱することは起こりません)。 合併処理がすべて完了すれば、プロジェクトの全機能も稼働状態に戻します。 そうすれば、アシミレータの待ち行列も素早く短くなっていきます。 現在、SETI@home クラシックで行われている科学活動は、 SETI@home/BOINC で行われているものと重複しています。 今回の処理が科学データの最後の合併作業になります。 クラシック・プロジェクトは年内には停止します。 いつかは、このマスター科学データベースをより高速のマシンの上で、 大きくて早いディスクを付けて運用したいと強く希望しています。 そのときがくれば、また停止期間が必要ですが、その作業は 単純にデータを unload/reload するものになります(それに対して、 今回の作業は、unload/reload/correct/merge という作業です)。 追記 (22:45 UTC): ユーザ定義型のカラムをもつ行をマージしようと試みたら、 思いがけない大きな問題に突き当たりました。 とりあえず、合併作業のための稼働停止からいったん復帰して、全機能を今晩は稼働状態に戻します。 おそらく明日の朝から合併作業を初めからやり直します。 最近、 BOINC バックエンドのサーバーのプログラムを少々変更しました。 使われていないディレクトリハッシュ関数に関係するコードを取り除きました。 さらに、sah_validator プログラムにあるメモリーリークを見つけようと試しました。 性能劣化にすぐに結びつく効果はないものなので、 このメモリーリークはどちらかといえば無害なものです。 しかし、 それでも直しておくべきものです。 本日 あるテストを BOINC データベースサーバーで行うために、 プロジェクトを 1時間ほど停止しました。 すこし前に書いたように、このデータベース・サーバーはよりいっそう速く動作できるはずです。 (すでに今では、必要とされている速度より速くなってはいるのですが)。 いったい何でこの性能にとどまっているのか、Sun 社が調べるのに必要な詳細データを集めるため、 プロジェクト全体を停めました。 これを書いている時点では、毎水曜に行うデータベース・バックアップを実施している最中です。 実は今日の停止は 3時間よりすこしばかり長くなってしまいます。 というのは、アップロード用ディレクトリもテープに吸い上げているからです。 このアップロード用ディレクトリは、RAID 化された記憶装置の上にあります。 それでも、破滅的な大故障に遭遇する可能性を考慮すれば、 このディレクトリの内容をデータベースと同期したタイミングでバックアップしておくことは良いことでしょう。 もし、このディレクトリ内のファイルを、特定できないある時点で失ってしまったら、 その後片づけをするのは悪夢のような作業です。 というのは、 データベースの中を調べあげて、ディスク上にもはやないファイルのエントリを見つけ出さなければなりませんし、 それらがいったいどんな状態であったのかを見抜かねばなりません。 さらに次に、 それぞれの場合ごとに適切な対処をしなければなりません。 おまけにもちろん、多くの功績(credit)と科学的計算の結果が失われることでしょう。 しかし今では、全ての待ち行列は健全な状態にあり、処理は追いついていますから、 この2ヶ月の間に滞積していたすべてのリザルトを消化することができました。 この1週間でディスク上のファイル数は、1100万個から350万個にまで減りました。 このサイズになれば、テープにバックアップするのに、2.5時間で済みます。 もちろんそうしないわけはありません。 最初に、それらのファイルを tar ユーティリティを使ってアーカイブしようとしましたが、これはあまりに速度が遅すぎました。 ufsdump を使ってバックアップするほうが格段に速いのですが、 そうし始めたのは停止予定時間内のかなり後ろのほうになってからでした。 というわけで、今回の停止は 30分ほど延長されているのです。 もう一つの話題: サーバー状態 のページ末尾にある用語集を整理し、改善しました。 何週間もの間、追い詰められた状態のサーバー群を相手にし、つらい思いの停止期間を経験した後、 このプロジェクトは稼働状態に戻りました。 溜まった仕事を片づけつつあります。 解決策を実施するまでに1ヶ月がかかりましたが、結局はいつも同じことが問題でした。 すなわち、何十ものプロセスが、1つのファイルサーバーに載っている 何千ものディレクトリ内のそれぞれ1万個を超える個数のファイルへ、 不規則なアクセスをする、さらにそのファイルサーバーには、 これらのディレクトリ情報をすべて保持するには充分な量の RAM がないときている、 ということでした。 このファイルサーバーにはすでに最大限まで RAM を搭載してあるので、 すぐに可能な選択肢は、我々の研究室にある部品から2つめのファイルサーバーを作ることだけでした。 そういうわけで、アップロード用とダウンロード用のディレクトリは、 今は物理的に異なる装置に載っており、お互いにもう競合することはありません。 アップロード用ディレクトリは、実際のところアップロード・ダウンロード用サーバーに直結しています。 ですから、結果のリザルトの書き込みは、ローカルな記憶装置になされます。 ということは、システム全体を大きく助けることになります。 これはとても良いニュースではあるのですが、この姿が最終形態ではありません。 新しいアップロード用ファイルサーバのディスク群は古いものなので、 近日中のどこかの時点で、このシステムを全部取り替えたいのです( より大きくて新しくより速いディスクと、より速い CPU のものに)。 (この記事は昨日の投稿の更新です)。 システムのアップロード・ダウンロード用ファイルサーバーから、 別のファイルシステムへ、全てのリザルトを移動しているところです。 (この別のファイルシステムは、アップロード・ダウンロード用サーバに直結しています)。 できる限り高速な方法で複写を行っています。 とりあえずの推定では、24時間ぐらいかかります。 済んだら、全てのバックエンドサーバーを稼働状態に戻し、(現地時間の) 一晩中かけて全ての待ち行列を解消します。 明日の朝(同、現地時間)、全てを稼働状態に戻します。 アップロード用ディレクトリはローカルディスクにあるのですから、 アップロードのトラフィックがあっても、ダウンロードディレクトリの動きが鈍くなるはずはありません。 とても大きな性能改善がなされるはずです。 現在の苦悩を解決する一時的対策が、もう目の前にあります。 実際、すでに半分は実装済みです。 毎週定例になったデータベース・バックアップのための停止の際に、 古い複製データベース・サーバ(すでに数ヶ月使っていなかったもの)のディスクボリュームを取り外し、 現在アップロード・ダウンロードを全て処理している E3500 マシンに接続しました。 今ちょうど、新しい 0.25TB の大きさの RAID 10 ファイルシステムが、 作成・同期処理の最中です。 この処理には 1 日かかるでしょう。 この領域には、アップロード用ディレクトリを全部納めることができますが、 それ以上は入りません。 従いまして、アップロードとダウンロードのディレクトリを、 別々の2つのファイルサーバに分割中です。 このアップロード用のディスクは、 リザルトファイルを書き出すサーバに直結しています。 システムの用意ができたら、アップロード用ディレクトリを新しい場所へ移動します。 これに、ほぼ半日かかると推定しています。 移動の最中、全てのサービスを停止します。 もう、すぐにでもこの移動作業が始まるかもしれません。 気をつけていただきたいのは、この処置が恒久的な修正にはなっていないものの、 新しいクライアント(あるいは新しいハードウェア)が到着するまでに、 できるだけ早くなにかの対策を打たねばならないということです。 できれば、アップロードのほうだけでなくて、ダウンロードも含めた両方のディレクトリを、 サーバー直結の記憶装置へと移動させるべきだったのでしょうが、 それに充分なディスク領域を我々は持っていないのです。 さらに、使おうとしているディスクは古いものなので、潜在的に故障率は高いといえます (この RAID システムには、数個の活性交換が可能なディスクがついています)。 しかし、待ち行列を消すことが上手くいっていないために、空き領域は減りつづけており、 もう我々には他の選択肢はありません。 ご想像のとおり、リザルトとワークユニットを置いてあるファイルサーバが、 なぜか分かりませんが読み書き動作が遅いので、まだ苦しんでいます。 かっては、このサーバはもっと良く働いてくれていたのに、 何が変ってしまったのか我々には分かっていないのです。 たぶん、新しい参加者が押し寄せてきたため？でしょうか。 本日、いくつかの設定変更を試してみましたが、どれも効果がありませんでした。 たとえば、いくつかのサービスを Solaris 9 マシン群から、 Solaris 10 マシン群へと移動しました。 Solaris 10 マシン群は、 初めはそのファイルサーバへのアクセスがとても速いように見えましたが、 実際の負荷をかけてみると速くはありませんでした。 Linux マシン群もこれらのマシンより大して速くアクセスできません。 我々が試したことがどれも役に立たなかったのは、基本的に、 そのサーバ上の nfsd デーモンがいつもディスク待ち状態になっているからです。 たとえ世界最速のマシン上に、バリデータやアシミレータなどのプロセスをいくら追加したとしても、 このディスク群が処理保留状態であるなら、何の改善もありえません。 しばらくの間、待ち行列群はほとんど変化がなく、 バックエンド・サーバ群はそのうちの一部しか走っていなかったので、 再びこのファイルシステムは満杯に近づいていっています。 ということで、大問題は、「これに対してどうするつもりなのか?」です。 当プロジェクトの掲示板で、何人かの方が示唆したのは、 アップロード・ダウンロード用ディレクトリを、異なるサーバに分割して置くことでした。 これはいままでもずっと、我々の計画にあったのでですが、 ハードウェアが不足していて実施できないのです。 私たちの周りには、すぐに使える 1テラバイトのストレージは転がっていません。 ある程度の空きを用意するために、 多くの資材をいろいろな場所に整理・移動する計画を立ててはみましたが、 結局のところ、新しい領域にアップロード・ダウンロードディレクトリを複写するためには、 きっととても長い停止期間を必要とするでしょう(ぞっとしますね)。 より良い一つの解決法は(同時により早い解決法でもあるのは)、 科学計算をより多く実施するような、 新しい SETI@home/BOINC クライアントを公開することです。 (チャープ・レイトの分解能を大きく上げて計算します)。 すると、ワークユニットの計算により長い時間がかかります。 この策は参加者の功績(credit)量に影響を与えません。 (BOINC の功績の値は実際の計算量を元にしており、 もっと恣意的なワークユニット数を基準にしていないからです)。 それでも、プロジェクトのサーバにかかる負荷量は、この方法で 75% も減ります(もっと減るかもしれません)。 それはもちろん、処理対象のワークユニットとリザルトが、 より少なくなるからです。 こうすると、我々のバックエンド・サービス群すべてに、良い効果がすぐに現れるはずです。 そして、よりストレスの少ない状況で、ディスク待ちの問題を診断することができるようになります。 我々はまだこの新しいクライアントをテスト中ですけれども、 この仕事を主務としている科学者とプログラマが、近いうちに休暇から戻ってきます。 また別の方々からは、SETI クラシックを単に停めるという方法を取るべきだと言われました。 追加のハードウェアをそこから得るためです。 この方策を採用するとしたら、 それはすくなくとも BOINC のユーザインタフェースを改良し終えて、かつ、 前述の新クライアントを公開した後でなければ、あり得ません。 その上、クラッシックのプロジェクトが停止した後も、すぐにそのサーバを流用できるわけではありません。 プロジェクトの後処理として、最善の場合でも、1ヶ月間のデータ管理の仕事の後でしか、 クラシックのサーバ群を使うことはできません。 その後で、OS アップグレードや、 ハードウェア設定などに最善でも一週間かかるでしょう。 早い話が、選択肢にならないのです。 現状報告の更新: 1週間という長い期間停止したので、その分、回復にとても長くかかりました。 (現地時間の) 今朝、やっと TCP コネクションの切断が起こらなくなりました。 (つまり、今はこのプロジェクトのスケジューラやアップロード・ダウンロード用 ハンドラに要求を出せば、それら全てを処理できるということです)。 しかし、しばらくのあいだは、新しい仕事送出のための待ち行列は空になってしまっています。 これは必ずしも仕事がなにもないということではありません。 新規の仕事を蓄えておけるほど速く仕事を生成できない、ということを意味しているだけです。 同様に、検証待ちリザルトの待ち行列は長くなっていっています。 (従って、待ち状態になったリザルトを提出した参加者へ功績(credit)を付与するのが遅れるということを意味します)。 それでも、これらの待ち行列はどちらも近いうちに状況が好転し、 良い方向に向かう兆しがあります。 この状況を週末にかけて我々は注視します。 もし全てうまくいけば、リザルトの取込みを行うアシミレータも稼働状態にするかもしれません。 気をつけていただきたいのは、 SETI@home クラシックのデータサーバをこの数日停止していることです。 これしているのは、 定期的な OS のパッチあて作業と、 奮闘している BOINC のサーバ用に帯域幅を確保するのを助けるためです。 昨日、公開用サーバ群を稼働状態に戻しました(戻したのは、スケジューラ、 アップロードおよびダウンロード・サーバ、バリデータです)。 アシミレータとデリータの待ち行列は全部消えてはいなかったのですが、 そうしました。 一週間は充分に長かったと感じています。 他に残っている問題を見つけるための診断データをより多く取れるはずです。 期待どおり、別の問題をみつけだしました。 アップロード・ダウンロード用の サーバがとても忙しい状態にあり、NFS のマウントが不規則にはずれていました。 はずれるマウントの中には、/usr/local のように必須のものも含んでいます。 このため、 file_upload_handler はその晩ずっと、 ふらふらとした動作を続けていました。 今朝、 (データベースバックアップのため実施している毎水曜の停止の後で)、 この問題が automounter の問題であったことを突き止めました。 必要なパーティションについて ハードマウントをいくつか設定しました。 その結果、このサーバは大変良い状態で動作しています(それでもまだ、 遅れを取り戻すには、ほど遠いのですけれども。 毎秒、何百ものコネクションが切れており、 幸運な 20から30個/秒の量の RPC だけが通過できています)。 1ヶ月ほど前に上手く稼働していたのと比べてみると、 当プロジェクトは、全般的な性能不足のために、 まだ少々滞りがちです。 この問題を解決するために多くの時間を費やしています。 さらに、説明をしておきます。 期限を過ぎたファイルに関して、 功績(credit)を付与する動作について、私は間違った内容を知らされていました。 正しい仕組みは以下の通り。 標準のリザルト(canonical result)がディスクに残っている限りは、 (つまり、ファイル消去のためのデリータによって消されないうちは)、 功績が付与されます。 長い停止からの回復中ですので、功績が失われる危険を最小にするため、 できる限りファイル・デリータを動かしません。 これはとても難しいことではないはずですが、 古いリザルトをかかえているディスク群の空き領域は、かなりの速度で埋まっていきつつあります。 この 1週間そうであったように、まだこのプロジェクトは止まったままです。 明日で実に まる 1 週間の停止になります。 私たちは、あと一晩サーバ群を停めて、 残っている取込みと削除待ちの行列を消し去ろうと決めましたが、 何があっても明日のどこかの時点で稼働状態に戻します。 この長い停止に関して、良いニュースと悪いニュースの両方があります。 良いニュースのほうは、検証待ちの行列が全部なくなったということ。 ですから、滞積していた功績(credit)が決して付与されないのではないか、と心配していた人は、 これでとても安心したでしょう。 同様に、 自分の行った計算結果が本来勘定にいれられるべきであるのに、 サーバに届く日時が期限を越えてしまうと危ぶんでいた方々も、 もう心配しなくて済みます。 それぞれのワークユニットがデータベースに残っている限りは、 功績(credit)は付与されるからです。 しばらくの間、 db_purge の処理を停めておきますので、長い停止の後で期限超過した扱いにならずに、 皆さんはワークユニットの計算結果をサーバに返すことができます。 加えて注目すべきなのは、不要リザルトの消去処理は数日前にすでに仕事を終えており、 すでにリザルトを置いてあるディレクトリの大きさが、40% も小さくなっていることです。 次に悪いニュースのほうです。 リザルトを置くディレクトリの大きさがかなり小さくなり、 いくつもの待ち行列が消え去ってくれたので、大方のサーバが暇な状況になっています。 しかし、それにもかかわらず、 取込み処理のアシミレータと ファイル消去のデリータは期待よりとても処理速度が遅いのです。 この 1週間でかなりの処理速度向上が成し遂げられたのですが、まだ充分ではありません。 以前はそれほど明白でなかった NFS の奇妙な振る舞いが発生し続けています。 そこでこれを解明すべく調査を急いでいます。 明日になる前に何に問題があるのか見つけられれば、 と期待しています。 もうひとつ書いておくべき話題があります。 サーバ状態の表示ページに、 小さな間抜けなバグが見つかりました。 スケジューラが走っていなくても、稼働中の表示が続くというバグです。 これは修正しました。 古い不要リザルトを消去するデリータおよび バックエンドシステムが、 その遅れを取り戻せるように、 プロジェクト全体を停めて、それらをまる一晩走らせつづけました。 ただ今、全ての努力は古いファイルのデリータに注がれています。 というのも、その処理がもう少しで完了するからです。 (一時間のうちには決着が付きます)。 それが済んだら、バックエンドシステムを立ち上げなおし、 どのくらいの速度で仕事をこなせるようになったか調べます。 (このときは、スケジューラと古いファイルのデリータとの競合はなしで測ります)。 これで待ち行列が素早く短くなるようなら、本日が終わる前に全てを稼働状態にもどせるかもしれません。 さもなくば、明日の朝でしょう。 停止している時間がある長さを超えると、 再開後の結果返却のために当システムのサーバへ押し寄せるであろう要求の量は、 おそらくそれ以上悪化することはありません(というのは、ある時点から 参加者だれもが 新しい仕事を待つ状態になるからです)。 という言い訳で、少なくとももう一晩、スケジューラを再び停止します。 この時間で、現在の問題とその他の課題に取組みます。 もう一度、現在の問題点を述べてみます。 (a) 検証まちの仕事が大変多く滞積していること。 (b) リザルトとワークユニットを保持している ディスクアレイが満杯状態に近いこと。 昨晩ずっと、「古い不要リザルト」を削除するデリータを走らせつづけました。 今のところ、古い不要リザルトのうち、70% まで消しました。 (より細かい話については、前回の投稿が下記にありますので、ご覧ください)。 通常行っているデータベースのバックアップを終えたのち、 バックエンドのプロセスを全て動かしました(検証、取込み、および通常のファイル消去のプロセスです)。 これによって、それぞれの待ち行列が短くなるはずです。 実際は、検証をするバリデータの待ち行列だけが隘路になっています。 しかし、その待ち行列が短くなるには、取込み(アシミレータ)と ファイル削除(デリータ)のプロセスが追いついて動作しなければなりません。 (現地時間で)今朝、停止する前に、 不要ファイル削除の第1回め(後述)の効果が、 大して現れていないということに 少々困惑させられました。 そこで調べて気がついたのが、昨晩 アップロード・ダウンロード用 ディレクトリを置いてある RAID システムに障害が起こっていたということでした。 このRAID システムは再構成処理を開始しており、そのために低性能なモードで動作しつづけていました。 データは失われていません。 そこで本日の停止で実施する計画内容を白紙に戻し、 ファイルの掃除をする代わりに、その RAID の再構成を早く終わらせるよう、 BOINC の全システムを停めることにしました。 この RAID システムが低性能モードのままでは、プロジェクトは効率的に動きません。 再構成処理が終わる前に、ゆうに晩(現地時間) になってしまうので、 まる一晩は当プロジェクトを停めておきます。 なぜそれほど長くかかるのでしょう？ あのアップロード・ダウンロード用ディレクトリは、 1 テラバイト一杯の大きさがあり、その RAID 装置についている別の 1 テラバイト級のボリュームが再同期処理をしているからです。 再構成処理が終われば、不要ファイルの削除処理を起動して、 眠っている間じゅう走らせておきます(辛抱強く待っていても良いのですが、 これはどんなタイムゾーンに住んでいるかによりますね)。 以上に加えて、我々は待ち行列を解消するための、より攻撃的な計画を立てつつあります。 当初我々が感じていたのは、古いファイル消去と待ち行列の解消のために、 二日以上の停止を伴う作業をしたとすると、参加者の方々に辛い思いをさせるだろうということでした。 特にシステムを稼働状態に戻したあと、 要求に追いつこうとして システム全体がのろのろとしか動かないのは辛いだろうと。 しかしながら、それどころではなくなりました。 アップロード・ダウンロード用の ディレクトリが置いてあるディスクアレイは、危険なほど満杯に近くなっています。 ですから、つらいところですが、すぐに行動を起こさねばならなくなりました。 明日、稼働状態に戻したら、どのような具合であるか調べます。 たくさんの「不要な」リザルトファイルを消すために、3時間の停止計画実施しています。 現在、その第一日めの作業中です。 本日の停止期間が終わったら、この投稿の末尾に結果の数値を付け加えます。 それまでは、現状について良く聞かれる問いとその答えを面白く書いておきましょう。 問: 不要なリザルトというのは何処から生まれたのですか？
問: それで、この状況のどこが問題なんでしょうか？
問: そのディレクトリがそれほど肥大化した理由は他にはありませんか？
問: 百万個ものリザルトが検証待ちで滞っている状況にどうしたらなりえるのでしょう？
この状況は SETI@home/BOINC のシステムは完全に破綻しているということなのでは？
問: 不要の古いファイルを消すために、なぜシステムを停める必要があるのですか？
昨日、古いリザルトファイルを全て削除するには、プロジェクトを だいたい 24 時間停止して処理をする必要があると判明しました。 この停止は 3時間ごとの長さに分けて数回かけて実施します。 というのは、この処理の様子を監視しながら実施したいということと、 長時間の停止をすると遅れを取り戻すための厳しい期間が必要になってしまうからです。 この削除がすっかり終わる前の段階でも、きっと効果が現れて、 バリデータの待ち行列が縮小し始めるのではないかと期待しています。 前述の記述ニュース項目で不明確だった点を説明します。 我々は以下の条件が満たされるまでは、 ファイルの消去とデータベースの項目消去にとりかかることはありません。 その条件とは、あるワークユニットに対して標準のリザルトを選択して取込みを行い、 そのワークユニットに関する「全ての」リザルトが、受信され(て検証成功す)るか、 あるいは、締め切り期限を超過してしまうかのどちらかになるということです。 バリデータが遅れている主な原因は、アップロード用ディレクトリに ファイルがたくさん有りすぎるということです。 これらのたくさんのファイルは、 削除を待って行列をなしているのですが、デリータのほうも同じ原因、つまり、 ディレクトリが大きすぎるために処理が遅くなっているのです。 さらに、アップロード・ディレクトリにはデータベース中に関係付けうる行を持たないような、 たくさんのリザルトファイルがあります。 これらの関係が切れてしまったリザルトファイルは、 ファイル消去のプログラムによって消されることは決しておこりません。 このようなリザルトができてしまうのは、ワークユニットに対して返却されたリザルト数が 定足数に達して、検証および取込み、ファイル消去(ワークユニットとリザルトの両方)と 最終的なデータベース上の記録の消去が終わった、その後で、1つ以上のリザルトが 到着したときです。 (おそらく、これらのリザルトはラップトップマシンで 間欠的に計算されたがゆえに遅くなったのでしょう)。 関係が切れてしまったリザルト群は、消さねばならない大きなお荷物です。 本日の停止の間に、両方の種類の古いリザルト・ファイルを高速消去する作業を始めました。 まず第一に、データベースに対して、まだ検証作業が残っているワークユニットで最も古いものを 見つけ出す検索をさせました。 次に、そのワークユニットの最古のリザルトの受信日時を データベースで検索しました。 そして今度は、安全を見込んでその日時から １ヶ月過去の 時点に戻り、その時点よりも古いリザルトファイルを全て消す処理を開始しました。 ところが、上手いこといきませんでした。 予測していた数の 約 25% しか削除の対象にならなかったのです。 詳しく調べたところ、これら消去して良いファイルの 75% は、 安全のために見込んだ １ヶ月の期間のなかで受信したものと分かりました。 このプロジェクトはこんなにも速く成長しているのです。 しばらくしたら短時間また停止して、消去してよいファイルの全てを消すための 時刻を求めます。 そして、それらのファイルを全て片づけるために、 長時間の停止または何回かの停止を計画します。 停止してこれらの作業をしなければならない理由は、それらのファイルを置いてある ファイルサーバに削除処理がかける負担を考慮しているからです。 我々はこの作業を加速する方法を探しつづけています。 そして、もちろん、 このようなファイルが再び溜まることを避ける方法も探しています。 お気づきではないかもしれませんが、米国太平洋側時間帯で水曜の 10:00am ぐらいに、 毎週定期的な停止をしており、この時間にデータベースのバックアップと、 当プロジェクトがダウンしたときだけ必要となる管理上の仕事を片づけています。 本日もそのバックアップを取ってから、現在の処理上の隘路がどこにあるのかを見つけるため、 色々なマシンで一連のベンチマークを流しました。 すでにあたりは充分に付けていたのですが、我々の仮説を具体的な数値で裏づけることができたのは幸いでした。 基本的には、当プロジェクトのサーバ群は期待されている仕事を「こなす」ことができています。 しかし、資源の割当てをいじくると、たとえばあるサーバプロセスを他のマシンで走らせたり、 他の処理が追いつくようにあるプロセスを停止したりといったことをすると、 予想外の結果になります。 バックエンドにあるシステム全体が、 非常に複雑な依存関係の固まりになっているのです。 ともあれ、今日の心配ごとのリストは以下のとおりです。
一方、内部ネットワーク通信と他のディスク入出力については、現状、隘路はないと分かりました。 何人かがより高速の CPU をもつ PC を買ったらどうかなど、 いくつかすぐに指摘してくれましたが、実は現在は CPU 能力が不足しているのでは決してありません。 (それを言うなら、メモリネックでもありません)。 結論は、例のディレクトリを掃除する必要があるということです。 現在このプロジェクトは 1日あたり 約 50 万個のリザルトを生成している一方で、 検証している数はそれより少しだけ少ない状況です。 かっての修正とこれからの修正が効果を上げていけば、 作る量よりも多く、検証をこなしていけるようになります。 週に一回の停止時間が今回、かなり長引いたのは、(定期的なパッチ適用作業の対象となった) 今回のパッチの中に、時間のかかる群がいくつかあったためでした。 参加者が増えるにしたがって、停止期間から「回復する」のが難しくなりつつあります。 悪い指標となる待ち行列は伸びてしまい、良い指標となる待ち行列は枯渇してしまいます。 現在の焦点はワークユニットとリザルトをすべて抱えているファイルサーバです。 停止期間が終わると、新しい仕事への要求量が途方なく増えます。 ダウンロード・サーバの 100M bit/s のイーサネットの口が主要なボトルネックになるほどです。 クライアントに仕事が供給されるに従い、結局、ボトルネックはファイルサーバに移動します。 送出準備済みの仕事を溜めていた待ち行列は、要求に応えた結果、枯渇します。 ということは、その待ち行列に仕事を再充填するために、 スプリッターが全速力で動作することになります。 これは、ファイルサーバにとても重たい書き込みの入出力操作が起こることを意味し、 今度はそれがすべての動作を緩慢なものにしてしまいます。 この暗雲は晴れるのに極端に長い時間がかかります。 我々は、このファイルサーバのスループットを増やそうとしてきました。 ファイルサーバは時間のかかるディレクトリ参照動作に多くの時間を費やしています。 (リザルトとワークユニットは大きなサブディレクトリに納められています)。 このサブディレクトリは、すでに数千の分離されたサブディレクトリに分割してあります。 この個数をさらに増やしたいのですが、そうするとまた、プログラムコードの修正と、 おそらくもう一度停止が必要になります。 今日の午後、ディスクに負担がかかるほとんどのサービス(スケジューラを含む)を停止し、 ファイル・デリータが少しは追いつけるようにしました。 90分かけても、25，000ファイルのうち、たった15，000ファイルを削除できただけでした。 そういうわけで、すべてを元に戻しました。 実際のところ大して役に立たなかったわけです。 今から、負荷の少ないマシンを何であれ見つけて、それらの上でファイルデリータを立ち上げてみて、 ファイル削除の待ち行列が減ってくれないか試してみます。 ファイル削除がすすめば、ディレクトリサイズが減るので、全般的に処理速度が向上するはずです。 先週、この 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 ではたぶん数日かかるかもしれません)。 ワークユニット生成処理のボトルネックがどこにあるのか探しています。 一つは見つけたかもしれません。 アップロード・ダウンロードの記憶装置に 書き込み・読み出しをするたくさんのプロセスがあります(すなわち、 スプリッター、データサーバ、バリデータなどです)。 現在これらのやりとりは、プロジェクトのデータクローゼットにあるマシンと SSL 研究所の LAN を接続しているイーサネットスイッチを通過して行われています。 この 100Mbps のスイッチが過負荷状態なのかもしれません。 クローゼット内のマシン間のデータ量の多いやり取りを、上記とは別の 1Gbps スイッチを流れるように変更しようとしています。 本日は、 データサーバをこのスイッチにつなぎ換え、 スプリッターとバリデータの両方の役目をしているマシンの一つもつなぎ換えましたので、 アップロード・ダウンロードのトラフィックが新しいスイッチのほうを流れるようになります。 この新しいスイッチへの移動の前には、上記の両方のマシンで NFS (Network File System) のエラーが発生していたのですが、 今ではどちらのマシンでもこれらのエラーは出ないようになっています。 本日正午ごろ(現地時間)、当プロジェクトのマスター科学データベース・サーバが、 致命的なメモリ障害を検出して自分から再起動しました。 あるカーネルのバグのせいであったのか� |