ジョブコントローラ

メッセージがチャネルキューに入れられるたびに、ジョブコントローラはメッセージを配信するためのジョブが実行されていることを確認します。これには、新規ジョブプロセスの開始、スレッドの追加、実行中のジョブの確認などの操作が含まれます。チャネルまたはプールのジョブ数が制限に達したためにジョブを開始できない場合は、ジョブコントローラは別のジョブが終了するまで待機します。ジョブ数の超過が解消されると、ジョブコントローラは別のジョブを開始します。

チャネルジョブは、ジョブコントローラ内の処理プール内で実行されます。プールは、チャネルジョブが実行される「場所」であると考えることができます。プールは、プール外のジョブとリソースを奪い合うことなく処理できる計算領域です。プールの詳細は、「ジョブコントローラファイル」および 「チャネル実行ジョブの処理プール」を参照してください。

チャネルのジョブ範囲は、maxjobs チャネルキーワードで決定します。プールのジョブ範囲は、プールの JOB_LIMIT オプションで決定します。

通常 Messaging Server は、すべてのメッセージの配信を即座に試行します。最初の試行でメッセージを配信できない場合、メッセージの配信は backoff キーワードに指定した時間だけ遅れることになります。メッセージは、backoff キーワードに指定した時間が経過するとすぐに配信できる状態になり、必要に応じてチャネルジョブがメッセージの処理を開始します。

ジョブコントローラのメモリ内における処理中メッセージおよび処理待ちメッセージのデータ構造は、ディスクの MTA キュー領域に保存されているすべてのメッセージファイルを反映しています。ただし、ディスク上のメッセージファイルのバックログが大きくなり、ジョブコントローラのメモリ内データ構造のサイズ限界値を超えると、ジョブコントローラはメモリ内でディスク上のメッセージファイルの一部だけをトラッキングします。ジョブコントローラはメモリ内でトラッキング中のメッセージだけを処理します。メモリ内ストレージを解放するのに十分な数のメッセージが配信されると、ジョブコントローラは MTA キュー領域をスキャンしてメッセージリストを更新し、メモリ内ストアを自動的に更新します。その後、ジョブコントローラはディスクから取り出したばかりの新しいメッセージファイルの処理を開始します。ジョブコントローラは、MTA キュー領域のスキャンを自動的に行います。

サイトに大量のメッセージバックログが頻繁にたまる場合は、MAX_MESSAGES オプションを使ってジョブコントローラをチューニングすることもできます。MAX_MESSAGESオプションの値を大きくすると、ジョブコントローラが使用するメモリが増え、メッセージのバックログがジョブコントローラのメモリ内キャッシュでオーバーフローする回数が減ります。これにより、ジョブコントローラが MTA キューディレクトリをスキャンするための負荷が低減されます。ただし、ジョブコントローラでメモリ内キャッシュを再構築する必要がある場合は、キャッシュが大きくなるので処理時間も長くなる点に注意してください。ジョブコントローラの起動時または再起動時には必ず MTA キューディレクトリをスキャンする必要があります。このため、メッセージのバックログが大量にある場合は、そのようなバックログがない場合に比べて、ジョブコントローラの起動や再起動に大きな負荷がかかります。

ジョブコントローラの設定とプールの詳細は、「ジョブコントローラファイル」および 「メッセージの処理と配信を設定する」を参照してください。

ジョブコントローラを起動および停止するには

ジョブコントローラを起動するには、次のコマンドを実行します。

start-msg job_controller

ジョブコントローラを停止するには、次のコマンドを実行します。

stop-msg job_controller

ジョブコントローラを再起動するには、次のコマンドを実行します。

imsimta restart job_controller

ジョブコントローラを再起動すると、実行中のジョブコントローラが終了し、その後すぐに新しいジョブコントローラが起動します。