Campaign: web@defaultでのゾンビプロセスの数が多い

モニタリングアラートで、Adobe Campaign インスタンスのゾンビプロセスの数が異常に多いことが報告されました。 カウントは23に達し、モニタリングインジケーターは最大値2を表示しました。 調査では、プロセスが正常なバックグラウンドのオーディエンス読み込みアクティビティによって作成された無害なオペレーティングシステム レベルの機能停止シェルヘルパーであることが確認されました。

説明 description

監視システムは、web@defaultの親プロセスに関連付けられている複数の[ sh] <非機能> プロセスを識別しました。 報告されたカウントは、表示された最大しきい値よりも大きかったです：

現在のカウント：23のゾンビのプロセス
監視しきい値：2つのプロセス
親プロセス：web@default
プロセスパターン：短期間有効な/bin/sh ヘルパープロセスのバースト

web@defaultを再起動すると、プロセスが一時的にクリアされますが、後続のバックグラウンドジョブが完了した後に、同様のプロセスが再度表示される可能性があります。

調査では、ジョブの停止、プロセスのループ、オーディエンスの同期の失敗、機能の低下の証拠は見つかりませんでした。

解決策 resolution

根本原因

Adobe Campaignは、以下のような短期的なシェルヘルパーを起動することで、特定のバックグラウンドジョブやアウトプロセスジョブを実行します。

/bin/sh -c “nlserver ジョブ …”

調査では、機能停止したプロセスを、nms:groupLoadJob オーディエンス同期ジョブを含む通常のCDP/AEP オーディエンス読み込みアクティビティにトレースしました。 これらのジョブはインスタンス上で頻繁に実行され、短期間で複数のヘルパープロセスを作成する場合があります。

複数のヘルパーが同時に終了すると、web@default子プロセスのリーパーは、終了ステータスの収集を断続的に見逃す可能性があります。 その後、完成した子プロセスは、処理されるか親プロセスが終了するまで、ゾンビとしてプロセステーブルに残ります。

表示される値2は、ゾンビのプロセス数に厳しい制限はありません。 これは、サーバー監視スクリプトで設定された警告しきい値です。 2を超えるカウントは、モニタリングインジケーターを赤に変えます。

影響

ゾンビのプロセスは良いものでした。

彼らはCPUを食べた。
彼らはメモリーを消費しませんでした。
これらは、オペレーティングシステムのプロセステーブルにプロセス識別子のみを保持していました。
配信、ワークフロー、オーディエンスの読み込み、web ユーザーインターフェイスには影響しませんでした。
観察されたカウントは、ホストプロセステーブルを使い果たすことの現実的なリスクをはるかに下回っていた。
したがって、アラートは表面的なもので、Campaignの処理の失敗を示すものではありませんでした。

解決策

エンジニアリングは、手作業による修正が必要ないことを確認しました。

web@default プロセスは、毎日約06:01に自動的に再起動するように設定されています。 この再起動では、親が終了したときに子プロセスがオペレーティングシステムによって再び処理されるため、残りのゾンビプロセスは消去されます。

ゾンビのプロセスは既に終了しており、意味のある殺しやタイムアウトすることはできません。 親プロセスが終了ステータスを収集するか、または終了したときに削除されます。 この場合、スケジュールされた毎日の再起動は自動クリーンアップを提供します。

この問題は、通常の大量のオーディエンス読み込みアクティビティの無害な副作用として解決されました。 オーディエンスの同期、キャンペーンワークフロー、顧客設定に変更は必要ありませんでした。