 |
|
 |
| |
 |
「導入後の製品FAQ」セレクション
ここではふだん「サポート２」に収録されている「導入後の製品FAQ」の記事の中から、毎週火曜日に週替わりで３つの記事をランダムにセレクトしてご紹介いたします。E-Postシリーズ製品の機能に対する定番的な質問やより習熟するための使い方だけでなく、製品を取り巻く解決ノウハウの豊富さなどを感じ取っていただければ幸いです。
|
2025年2月第4火曜日分
|
 |
|
 |
|
Outlookが作成するフォルダ「削除済みアイテム」内に大量のデータを残したまま運用しているとIMAP4サーバ負荷が高まる
Outlookがデフォルトで作成するフォルダ「削除済みアイテム」内に大量のデータを残したままの状態で運用している場合、メールクライアントのOutlookからメールを削除する際には「削除済みアイテム」にデータが格納されるのですが、このときIMAP4サーバ負荷が高まる可能性があります。サーバ負荷が高まること自体、即危険な状態ではありませんが、「削除済みアイテム」フォルダ内に大量のデータが残っている状態をそのまま放置しておくと、やがて危険な状態に陥る可能性があります。
実はユーザーからの報告で、大量のメールが格納されている「削除済みアイテム」フォルダに大量のデータを格納しようとすると、CPU使用率が30〜40%を超える状態になってしまうという相談を受けたことがあります。大量のメールが格納されている「削除済みアイテム」フォルダに、大量のデータを格納しようとするとCPU負荷が高まるというこの報告現象には整合性があります。「削除済みアイテム」フォルダ内に万が一、大量のファイルが残っているままの場合は、メールクライアントからではうまく操作できない可能性があるため、直接サーバ側から拡張子.MSGのメールデータファイルを削除して格納されているファイル数を減らす必要があります。
Outlook側で表示されている「削除済みアイテム」フォルダは、メールサーバ側では UTF7拡張 でエンコードされたフォルダ名となっており、"&UkqWZG4IMH8wojCkMMYw4A-" と表示されています。該当ユーザーのメールボックスフォルダ配下にあるこのフォルダ内にメールデータファイルがどの程度たまっているかを確認し、格納されている［ファイル数］を確認してください。「削除済みアイテム」フォルダにメールデータが大量に溜まっていて、ファイル数が千を超え万単位に及んでいる状況であれば、CPU負荷が高まるのは当然の結果となります。対応策としてはとにかく拡張子.MSGのメールデータファイルを削除し、格納されているファイル数を減らすようにします。
負荷が高まる理由について説明します。
- E-PostのIMAPサービスがIMAP命令にもとづいて、数件分のファイルを大量のファイルが格納されている状態の「削除済みアイテム」フォルダに移動しようとするとき、Windows ServerのNTFSファイルシステムに依存しています。
- このときのパフォーマンスの低下や負荷の増大は、Windows ServerのNTFSファイルシステムの仕様によるものです。万が一、フォルダ内直下にファイルが１万以上、仮に数万あった場合には、当然の結果としてサーバの負荷が上がり、ファイルシステムのパフォーマンスが極端に低下することになります。しかもサーバ全体に与える影響がきわめて大です。
- この要因は、あくまで１フォルダ内に格納されているファイル数です。ファイルサイズは基本的に関係ありません。また、フォルダに小分けして管理されている形であれば、パフォーマンス低下は防ぐことができると考えます。
このことは、大量にメールが残っている「削除済みアイテム」フォルダの件と同じように、たとえば「受信トレイ」に格納されたメールをサブフォルダに小分けせず、そのまま大量になった状態で運用を続けていると、パフォーマンス低下・負荷増大する結果となります。これも同様の理由です。
ちなみに、これまで経験した内容で言うと、CPU負荷が30%程度まで上がるレベルでは、「動作している」からこそであって、早めのチェックが必要な注意喚起状態と言えます。30%程度に負荷が上がったままの状態が続くなら一種の警告信号ととらえ、もし60%程度に上がったままの状態が続くなら、かなり劣悪な危険信号としてとらえることを薦めます。ただし、この数字はあくまで目安であり、絶対的な指標ではありませんので留意してください。
実は、１フォルダ内にもっと多いファイル、たとえば10万ぐらいのファイルが格納された状態になると、CPU使用率の負荷はあたかも正常値の範囲でほとんど上がっていないのにもかかわらず、パフォーマンスが極端に低下、数字上はなんとか動いているようにも見える一方で、実はまったく動いていない（動けない）ような状態に陥ります。これを比喩で言いますと、泥沼に脚を取られて、まったく動けないような状態に近いと言えます。
CPU使用率上昇は一種の注意喚起として考え、メールサーバとしては、各種フォルダを含めたメールボックスフォルダなど、１フォルダあたりの直接置かれるファイル数が1000を超えないよう、運用管理に気を配ることが大事になります。メールクライアントにOutlookが使われる環境では特に「削除済みアイテム」内の格納データ数過剰には気を付け運用管理してください。
（関連FAQ）
●1フォルダ当たりのファイル数が膨大になるとファイルシステムのパフォーマンスが劇的に落ちるとは？
●IMAPサーバで扱うメールデータ数や同時接続数、運用パフォーマンスとの関係について
●deadやmxcashなど特定フォルダに膨大な数のファイルが蓄積されたときのパフォーマンス低下現象について
| |
 |
|
 |
|
|
|
|
|
メールボックスに放置されている大量のメールデータを削除するときの注意点
万が一、特定ユーザーのメールボックスに残されている大量のメールデータ、たとえばざっと1000を超えるようなデータファイルが放置されていることがわかった場合、メールサーバを安定して動作させるために、メールデータである.MSGファイルを削除していただくことが必要になることがあります。
このとき、削除してよいメールデータは拡張子.MSGのファイルです。.MSGファイル以外の.dat、.CTLなどのファイルは設定や制御系のファイルですのでそれらは残しておくようにしてください。
ただし、サーバ側でメールデータを削除するときは、該当ユーザーがアクセスしていないときに行うべきであり、万が一にもユーザーがPOP3受信中の最中に、そのような操作をすることは、少ないとはいえファイルの取り合いを起こす可能性もありますから、予期せぬ結果を招くことも心配されます。念のため、メールサーバ側のPOP3サービス（EPSTPOP3S）を停止した上で行った方がよいでしょう。
ちなみに、メーラー側の「x日残す」設定は、「POP3受信時にx日以前のものについて削除命令を出す」という意味ですから、その設定が全ユーザーに徹底されるのであれば、サーバ側のメールデータをわざわざ削除するような特別対応は不要で、基本的な運用はそれだけでよいと考えます。メーラー側から出されるDELE（削除）命令にしたがって、メールサーバ側は該当するメールデータを削除していきます。
（関連FAQ）
●メールボックスにメールデータを残す運用をしているときの注意点
●POP3メールボックスでメールデータ残存数が多いとパフォーマンス低下による logon overlap エラーが起きるおそれ
|
|
|
|
|
|
|
|
|
|
メール送信時に1メールあたりの添付ファイル数上限は設けられているか
メール送信時に1メールあたりの添付ファイル数上限がE-Post側で設けられているかどうか質問されたことがあります。
E-Post自体には1メールあたりの添付ファイル数上限は設けられていません。
メールクライアント（メーラー）種類によっては、添付ファイル数より添付ファイルを含めた1メールのサイズ（容量）の制限が仕様上設けられているものがあるようです。メールクライアントの制限内容をご確認ください。
ちなみにE-Post側で添付ファイルを含む含まないに関係なくクライアントからのメール送信時に1メールのサイズ（容量）を制限する場合は、E-Post Mail Control画面の「中継の制限」タブにある「メール受信時のサイズ制限 (byte)」で設定が可能です。デフォルトでは"0"になっており、この設定状態では無制限です。
この「中継の制限」タブにある「メール受信時のサイズ制限 (byte)」は、インバウンド方向のSMTP受信（受領）時だけでなく、アウトバウンド方向のSMTP配送前段階であるSMTP受領時にも共通して適用される設定です。
|
|
|
|
|
|
|
| |
|
|
|
|
|
