!!みなさま、こんにちは!!いよいよ今年もあと1ヶ月を切ってしまいました。クリスマスやお正月が楽しみな反面、年末の繁忙期を乗り越えなければなりません。本日はタイトルの通り、Travelerサーバーのデフラグについて書かせて頂きます。弊社の環境ですが、社内にDominoサーバーがあり、DMZ上にTravelerサーバーがあるというごく単純な構成になっています。Travelerサーバーは定期的に再起動を行っております。数ヶ月前までは、社内で使用しているノーツクライアントにメールが着信するのが早いか、Travelerを経由してiPhoneに通知が出るのが早いかというほどでした。ところが最近になりiPhoneへの通知が遅れたり、場合によっては通知がない(正しくは通知前にクライアント側で閲覧したため、通知されない?)という状況になってしまいました。一番にTravelerサーバーの再起動やサーバーそのものの再起動を試してみたのですが、改善されませんでした。そこで弊社のパートナー様へ情報提供を依頼したところ、以下記事のリンクを送っていただけたのです。内部データベースのサイズが増加してシステムのパフォーマンスに影響を及ぼしうるケースが見られる」ようになるそうです。この対策として、データベースを圧縮・最適化するデフラグコマンドを追加頂けたました。システムを良好な状態に維持するため、1ヶ月に1回程度はこのコマンドを実行することが推奨されているとも記載されております。恥ずかしながらこの情報は全く知らずに使い続けていたことが原因のようです。いうことで、早速Travelerサーバーのデフラグを行い、また今後のために30日に1回実行するように設定してみたいと思います。手順もすべて先のURLに書かれているのですが、実に簡単です。以下の1行を追加するだけ・・・。NTS_DEFRAG_INTERVAL_DAYS=30保存して、Travelerサーバーを再起動すると、前回のデフラグより30日が経過されている場合(弊社では1回も実行していないため、もちろん該当)、起動時にデフラグが実行されます。デフラグの時間を計り忘れたのですが、1~2分程度ではなかったかと思います。次回以降はこの時間も短縮されるのではないかと推測します。quitした上で、以下コマンドを実行します。-defragデフラグが完了すると、自動でTravelerサーバーが起動し(httpタスクも含む)、完了です。以上、本来ユーザーが知っておかなければいけない情報かと思いますので、掘り起こさせて頂きました。Hagihara当ブログの記事は、私個人の経験談を中心とした見解・判断に基づく内容となります。記載内容や、ダウンロードコンテンツ等については、恐れ入りますが利用者様の自己責任でお願い致します。注)外部サイトへのリンク切れについては、先方の都合によるものとなりますので、ご了承ください。