2006/06/30

サーバーエージェントの検証

今日、うちのワカモノからもらった質問:

Q:「不在通知の検証をしたいのですが、今すぐ動かす方法ってないでしょうか?」
A:「うーん、 tell amgr run mail\test.nsf 'OutOfOffice' でどう?」
Q:「おおー、動きました」

Domino 6から、サーバーコンソールからサーバーエージェントを実行することが出来ます。
上記、mail\test.nsfはファイル名で、 OutOfOfficeはエージェント名です。
通常運用で使うのはちょっと変ですが、検証などで待ちきれないときなどは便利でしょうか・・・。

2006/06/28

整合性のチェックとは

こちらもTechnoteの斜め読みから。

What does the message 'Performing consistency check' mean?

「整合性のチェック」はFixupと同義です。サーバークラッシュ後の起動時などによく見かけますが、実はこれには3つの種類があります。
  • unknown state : DBが正常に閉じられなかったとき(クラッシュの後や、開いている最中のOSコピーしたものなど)
  • corrupt state : どこかで破損が起きている場合
  • Questionable integrity : データベースのヘッダやインデックスがおかしいようなとき
整合性チェックが走るのを止めることは出来ません・・・。必要だから行っているという位置づけです。

NotesDBのサイズ

これもよく聞くお話です。

Understanding Notes database size

Notesのデータベースサイズを理解しましょう、というTechnoteより。
Technoteでは、以下の3つの観点でまとめています。
  1. 文書
  2. ビュー(インデックス)
  3. ホワイトスペース
文書というのは、当然ながら、設計要素なども含んだものです。ここらへんは、NotesPeekを使うとよくわかると思います。

データベースの文書数は、DBプロパティから確認可能ですが、サーバーコンソールを使える環境なら、「show database DBファイル名」と入力すると、各設計要素の数や、削除スタブ数も表示されるし、ビューのインデックスのサイズも表示されます。

ビューインデックスについては、上記コンソールからも把握可能ですが、Domino管理クライアントからも実はビュー情報は確認可能です。(「ファイル」タブより、「データベース」→「ビューの管理」)

DBのサイズを最も小さくするためには、compact -d がよいのですが、これは全ビューインデックスが削除されるため、ある意味非常な危険なコマンドです。というのも、次回のユーザーアクセス時にビュー索引を構築する必要があるからです。ビューの構築というのは、非常に負荷の高い操作であり、1つや2つのビューならまだしも、多数のDBに対してビュー構築の動作が同時に行われると(例:サーバー上全てのDBにcompact -dをした場合)、その後のユーザーアクセスピークの間はサーバー負荷は大変なことになります。
ということで、上記Technoteのcompact -dに興味を持った場合も、いきなり週末に本番サーバーで実行・・・というのはお勧め出来ません。

ちなみに、compact -dは、-cスタイルの圧縮になります。

Notesアプリケーション開発時のパフォーマンス考慮

同じくTechnote斜め読みより。

Are there any guidelines regarding performance when developing a Notes application?

細かいお話は、Related Informationというところに入っていますが、基本的には「Performance Considerations for Domino Applications」というRedbookを参照せよとのことです。これはR5における情報ですが、基本アーキテクチャは大きく変更していないので、現在でも利用可能です。

以前のエントリの中でも触れたのですが、上記Redbookは日本語訳もされています。他にもいくつか参考になるのもあるかもしれないので、こちらもどうぞ。

アプリケーションのパフォーマンスが・・・

暗号化されたデータベース

Technoteの斜め読みから見つけたトピックより

Can you find out who encrypted a database?

少し前に、データベースの暗号化 というエントリを書いたのですが、その関連項目です。

暗号化されているデータベースを、「どのID」を使って暗号化したかがわかりますか? というお話。
当然ながら、これはわかりません。

よくある話としては、
  1. サーバー上のDBを直接ファイルコピーした場合はサーバーIDで暗号化されている
  2. ローカルにコピー or 複製したファイルをコピーした場合は、そのコピー、複製オペレーションをしたユーザーIDで暗号化されている
というかんじでしょうか。よく、サーバー移行集約などで、OSコピーなどでファイルを移動してしまった場合、上記「1」のケースがあったりします。旧サーバーのサーバーIDで暗号化されたファイルを新サーバーに移動しても当然暗号化されているため新サーバーはnsfファイルにアクセスすることは出来ません。この場合、旧サーバーID(をノーツクライアントから使って)復号化する必要があります。

2006/06/24

クラッシュとハング

Dominoサーバーのハングとクラッシュに関する英語記事の日本語翻訳が公開されたようです。

Lotus Domino のハングとクラッシュのトラブルシューティング

一言でDominoサーバーの問題といっても、ハングやクラッシュから、パフォーマンスが遅いなど、いろいろとあるのですが、この記事はクラッシュやハングを理解する手がかりになりそうです。

私の個人的な意見では、まず、「クラッシュ」と「ハング」の違いを認識し、情報伝達をするときに、この2つの用語を正しく伝える、というだけで、最初のすれ違いを防止するのに非常に有効だと思います。上の記事では、「ダウン」という言葉も同義で使ってるようです。(私の)日本語的には「サーバーが落ちる」も同義としてよく使います。ハングは「フリーズ」とも言ったりしますね。
よくメールで「サーバーがハングしました・・・」と連絡を受けたりするのですが、多くの場合話を聞いてみると意図したいことは「クラッシュ」だったりするんです・・・。

この記事の中では、いろいろなことが書いてあるのですが、以下のところをきちんと読むのがよいかと思ってます。
  • サーバークラッシュと何か、と、一般的な症状。
  • クラッシュの原因として箇条書きに書かれていること
  • サーバーハングとは何か、と、一般的な症状。
  • サーバークラッシュのトラブルシューティングに書いてある「次の点を考慮します」の箇条書き
これに加え、「クラッシュの調査にはNSDというファイルを調べるのが有効」ということを覚えておけば、わりと遠回りすることなく、問題判別、調査が出来るのではないかと思います。

問題発生時には、いろいろな人が関わる都合上「伝言ゲーム」が多いのですが、少なくとも技術者が関わる部分では誤解のないように伝達しあいたいというのが私個人の希望です。

で、この記事ですが、残りの部分も、読めば面白かったり、役に立つこともあるかもしれませんが、幅広くいろいろと読まされることになるので、まずは上記のとこだけでも最低限読むとよいかと。

2006/06/20

タブの切り替えショートカット

Windowsでアプリケーションを切り替えるときに、「Alt」+「Tab」を使ってる方は非常に多いと思います。私も1日に100回以上使ってると思います。(左手親指+薬指)
それに似た技がNotesの中でも使えますよ、というお話です。

TABbing between Notes windows

Notesクライアントでは、新規ウィンドウをタブ形式で開いていきますが、このタブの切り替えはマウスを使わなくても、「Ctrl」+「Tab」で出来ます。とのこと。

私は10本の指をかなり器用に動かすことが出来るので、「Ctrl+W」のショートカットも左手の小指+薬指で普通に押すことが出来るのですが、ホームポジション・手首固定のタイプ打ちにとって、少なくともThinkpad Tモデルのキーボードでこの「Ctrl」+「Tab」は厳しい・・・。

ということで、マウスを使わなくともウインドウ切り替えられるのは嬉しい反面、自分のタイプ癖からは絶対に使わないショートカットのご紹介でした。 使う人・・・いますかね。

2006/06/15

データベースの文書数

答えがないとわかっていながらも、何かよい答えを言ってくれる人がいるのでは・・・と回答を期待してしまう質問の1つに「Notesのデータベースは何文書まで大丈夫ですか」というのがあります。
でも、きっと本当の意味での正解は、「it depends」でしょう(つまり正解は存在しない)。

そこで、1つの指標として、事例として存在する巨大DBを参考にしてみる、というのが考えられます。残念ながら、私の周りはわりと平和的な使い方をしているため、無謀なケースはあまり知りません。知っている限り最も文書数が多いデータベースは、developerWorks上のフォーラムです。

こちら、2006年6月15日現在のステータスは以下の通り。
Notes/Domino 4 and 5 Forum (Notes1/NotesWeb)
文書数:885,938文書
DBサイズ:9,986MB
全文索引サイズ:1,573MB

実体はこれです。
http://www-10.lotus.com/ldd/46dom.nsf

大量文書を持ちながらも、わりと快適にWebでサービス提供が出来ていることを考えると、データベースの環境次第(DB設計、サーバーの環境)では、100万文書も十分にありえると思います。


さて、「文書数」というのは、ある意味「DBサイズ」よりもパフォーマンスにとっては重要で、特に文書数が多い場合「ビューの数」や「ビューの複雑さ(選択式、列の数、列式、ソートの有無、カテゴリ展開の有無、索引更新の頻度など)」には細心の注意を払わないと、ビューが開かなかったり、サーバー全体のパフォーマンスへ影響があったりします。
また、いかにビューをシンプルにしたとしても、文書数が非常に多い場合、破損時や移行時などのビューの再構築には、それなりの時間がかかるので注意が必要です。


なお、私個人の感覚では、「削除スタブ」の数もパフォーマンスに影響するのではないかと思っています。このため、新規にアプリケーションをデザインするときは、表面的な文書数だけでなく、削除運用を含めた上で、考えたほうがよいと思っています。

既にパフォーマンスに問題のあるDBを調査するときには、文書数のほかに削除スタブの数も知っておきたいところです。削除スタブの数え方はいくつかあるかと思いますが、私はサーバー上で「show database データベース名」を叩いて確認しています。

削除スタブの削除の仕方は、こちらをどうぞ。
How to purge document deletion stubs on the server immediately
もちろん、削除時は複製運用などに注意が必要です。


以上、よく問い合わせを受ける話なので、私個人が持っている意見などを書きましたが、この考えは絶対ではないと思いますし、もっと参考になる事例などもあると思います。あくまで1つの参考としてご参照下さい。またよい事例はシェアさせて頂けると幸いです。

2006/06/10

[雑談] 数独

Notes/Dominoとは全く関係ない話なのですが、IBM Lotus Notes/Domino Hints and TipsSu Doku for Notes - Coming Soon を見て思い出しました。

ニコリ系のパズルといえば、私も若い頃、数独とカックロだけは結構やったのですが、去年 Codestoreを読んでいて、The Soduko Crazeのエントリを見たときに、初めてこの遊びが海外でもブームになっていることを知りました。Wikipediaの英語版にも、Sudokuという形で詳細が記述されています。
確かに昨年末東海岸に行ったときも、空港やB&Nで大量に積んでありました。きっとテトリスが流行したように、シンプルなとこがウケてるのでしょうか。

私自身は最近は空き時間は読書や勉強などに使いたいと思っていますが、一昨年入院していたときは、暇つぶしに結構やっていました。それほど得意ではないんですが、9x9(3x3x9コマ)は時間をかければだいたい解けた気がします。25x25 (5x5x25コマ) は結局1度も解けませんでした。

別にNotes/Dominoの技術者がというわけではないんでしょうが、IT系の技術者はこの手のものはわりと好きなんでしょうね。

2006/06/07

データベースの暗号化

本日、某所から頂戴してきた(つもりの)データベースを開こうとしたら、「指定したデータベースはローカルでのアクセスが制限されているため、アクセスできません。」 というエラーで開くことが出来ませんでした。 折角悲しい思いを経験したので、少しこれについて書いてみます。

Notesのデータベースは、暗号化をすることが可能で、これは、データベースプロパティから操作します。この操作をクライアント上にあるDBに行うと、その時に使っていたユーザーIDファイルで、サーバー上にあるDBに行うとサーバーIDで暗号化が行われます。(もちろん、そのIDのみが復号可能です)

こうして、暗号化されたDBを、ファイル転送など何らかの手段で別のところに移動させても、移動先では暗号化したIDファイルがない限りはDBを開くことは出来ません。
ローカルのDBのセキュリティを考えた場合はデータベースの暗号化は非常に有効なのですが、デフォルトで新規複製を暗号化してしまう設定(にすることが多いと思いますが)にすると、このような落とし穴が時々あったりします。

今回私が経験したように、nsfファイルをWeb上などで公開したり、別の人に渡すときなどは注意が必要ですし、もしくは、データベースを別のサーバーに移動したりする場合は注意が必要です(複製を利用して作成した場合は問題ありません)。

「共通のアクセス制御リストを利用する」オプションでも同様な現象を経験することがありますが、こちらはHackする方法は一応あります。一方、当然のことですが、暗号化には抜け道はありませんので注意が必要です。

2006/06/06

Hannoverのデモ

音声付きの動画として、Hannoverのデモが公開されています。

Hannover demo

メールやカレンダーを中心に新機能が紹介されていますが、私個人は、ここで紹介されていないけれど画面にちらっと見える、Google Desktop Searchという文字列や、AtomのSubscribeとかそういうところも気になりました。

Hannoverの開発状況については、日々Mary Beth Raven のBlogで報告されています。まだまだ固まっていないところや、開発途中のところもあるかと思います。以前、R5でワークスペースがなくなる危機があり、ユーザーの声で勝ち残ったことがありましたが、Hanooverの開発はわりとユーザーからの声の影響が大きいのかな、と思いながらブログを眺めています。

2006/06/03

Lotus Notes on Web 2.0

こっそりと購読していたブログなのですが、codestoreで紹介もされたようですし、ここでも参考程度にご紹介してみます。

Lotus Notes on Web 2.0

私もこの手の話は好きなので、AjaxやRSSについて、時々このブログでもキーワードを並べていますが、「Lotus Notes on Web 2.0」ではもっと実践的に、Ajaxを中心に、prototype.js などスタンダードなライブラリを含む JavaScript の話が展開されているので、Web開発者の方には面白いと思います。私個人もここのアップデートを楽しみにしている人の1人です。

Dominoでなくて、何故Notesなのかというのは名前付けの問題だけと思いますが、このブログがマレーシア発だというのも、個人的には興味深いところです。

2006/06/01

ServerTasks行に関する思い

いつものごとく、RSSリーダーにて、英語版サポートページ(Knowledge Base)を超斜め読みしていたところ、反応してしまった1件。

Maximum character limit in notes.ini is 256 characters per variable

ServerTasks行の文字は255文字までが有効ですよ。というお話。
この話は、NAMES= で旧来よりよく聞いた話で、そのためにファイル名を長くしないように努力する例も聞いたことがあります。いよいよこのネタも ServerTasks行へ突入したのか・・・と思いました。

ところで、この行に255文字も詰め込むということは、それなりの数のタスクがロードされるわけですが、本当にそれだけのタスクが必要なのかな、と思わないわけではありません。

以前、アプリケーション開発を専門としている知人が、

「私のPCはメモリが不足していて、サーバーが完全に起動しないんですよ」

と言ってましたが、実際に設定を見てみると、ServerTasks行に、POP3やらIMAPやら、当時のテストには全く不要そうなものを含む、大量のタスクが書いてありました。必要程度までこの行のエントリを削除したら、無事にサーバーが立ち上がったのを覚えています。


パフォーマンスに問題がある本番サーバーの設定を見る機会も多いのですが、一応必ずここの設定は確認するようにしています。もちろん、実際のサーバー環境ともなると、不要タスクを落とす程度では微々たるものかとは思いますが。
例えば、Statsタスクとかは、通常不要です(STATS サーバータスクは何を行うのですか)。個人的にはmapsタスクもあまり好きではないです。


さて、リソースが制限されるテスト環境では、この設定の見直しはお勧めです。テスト環境では再起動をする回数も多いと思いますが、そういう時、このタスクの数によって、再起動が非常に楽になります

私の現在のテスト端末では、
ServerTasks=Update,Router,AMgr,AdminP
という設定にしています。AMgrとかAdminpは消してもいいのですが、今のところ何故かついていました(消そうかな)。本当はHTTPもよくテストするのですが、結局毎回手動でloadしています。ここらへんは好みによると思います。

あと、深夜にテストするときに、ServerTasksAt1とかで時々悲しいことになるので、ここらへんの行は私のテスト環境ではコメントアウトしています。