みなさま、こんにちは!!
いよいよ今年もあと1ヶ月を切ってしまいました。
クリスマスやお正月が楽しみな反面、年末の繁忙期を乗り越えなければなりません。
さて本日はタイトルの通り、Travelerサーバーのデフラグについて書かせて頂きます。
まず弊社の環境ですが、社内にDominoサーバーがあり、DMZ上にTravelerサーバーがあるというごく単純な構成になっています。
Travelerサーバーは定期的に再起動を行っております。
さて今回の背景です。
数ヶ月前までは、社内で使用しているノーツクライアントにメールが着信するのが早いか、Travelerを経由してiPhoneに通知が出るのが早いかというほどでした。
ところが最近になりiPhoneへの通知が遅れたり、場合によっては通知がない(正しくは通知前にクライアント側で閲覧したため、通知されない?)という状況になってしまいました。
一番にTravelerサーバーの再起動やサーバーそのものの再起動を試してみたのですが、改善されませんでした。
そこで弊社のパートナー様へ情報提供を依頼したところ、以下記事のリンクを送っていただけたのです。
(参考) IBM Notes Traveler データベースのデフラグによるパフォーマンスの改善について
詳細はリンク先を見て頂きたいのですが、要は
「IBM Notes Traveler のインストールサイズが大きくなり、稼働時間が延びるにともない、IBM Notes Traveler の内部データベースのサイズが増加してシステムのパフォーマンスに影響を及ぼしうるケースが見られる」ようになるそうです。
この対策として、データベースを圧縮・最適化するデフラグコマンドを追加頂けたました。
またシステムを良好な状態に維持するため、1ヶ月に1回程度はこのコマンドを実行することが推奨されているとも記載されております。
恥ずかしながらこの情報は全く知らずに使い続けていたことが原因のようです。
ということで、早速Travelerサーバーのデフラグを行い、また今後のために30日に1回実行するように設定してみたいと思います。
手順もすべて先のURLに書かれているのですが、実に簡単です。
サーバーの notes.ini に以下の1行を追加するだけ・・・。
- NTS_DEFRAG_INTERVAL_DAYS=30
保存して、Travelerサーバーを再起動すると、前回のデフラグより30日が経過されている場合(弊社では1回も実行していないため、もちろん該当)、起動時にデフラグが実行されます。
デフラグの時間を計り忘れたのですが、1～2分程度ではなかったかと思います。
恐らく次回以降はこの時間も短縮されるのではないかと推測します。
なお手動で実行する場合は、Traveler タスクと HTTP タスクをシャットダウン
tell traveler quit
tell http quit
した上で、以下コマンドを実行します。
load traveler -defrag
以上、本来ユーザーが知っておかなければいけない情報かと思いますので、掘り起こさせて頂きました。
