crontab、インスタンス、メモリの問題+スパム

crontab、インスタンス、メモリの問題+スパム

ウェブサイトを更新するために、1 分ごとに php5 wp-cron.php を実行する cronjob があります。

しかし、何かが起こり、インスタンスが 30 個以上存在しました (この 1 つのダンプでは 31 がマークされていますps aux)。これにより RAM が消費され、メモリ不足のために追加のインスタンスが終了し、ボックスに ssh できなくなりました。

インスタンスが 30 分以上存続していた理由がわかりません。通常は数秒しかかかりません。それが起こった日は、ジョブの計画はありませんでした (ただし、wp キャッシュがそれを使用していた可能性があります。以前は問題がありませんでした)

cronjob がスパムしてメモリを破壊するのを防ぐにはどうしたらいいですか? インスタンスが生きている場合は起動しないようにする方法はありますか? また、インスタンスが 5 分以上生きている場合はそれを終了する方法はありますか?

同じようなことが起こらないように自分を守る方法はあるでしょうか?

答え1

最初にすべきことは、そのジョブの 31 インスタンスを引き起こした可能性のある原因を突き止めることだと思います。通常、プログラムがどこかの時点でハングしている可能性があります。Web サイトを正常に更新したくない場合は、この問題をデバッグして修正する必要があります。

「インスタンスが生きている場合は起動しないようにする方法はありますか」という質問に対しては、はい、いくつかの方法があります。そのうちの 1 つは、pgrep yourprogramnameインスタンスがすでに存在するかどうかを確認することです。存在する場合は、pkill -x yourprogramnameそれらすべてを強制終了するように呼び出すことができます。

答え2

複数のコピーが実行されないようにするには、flock (Linux)、lockf (FreeBSD)、shlock (一部のシステムで提供されるが、信頼性は低い) を使用します。これにより、実行時間は制限されませんが、1 つのプロセスのみが実行されることが保証されます。その後、ハングした場合に、その状態をオンザフライで分析できます。

ulimit シェル組み込みを使用して、生成されたプロセスの CPU 時間を制限できます。

ウォールタイムを制限するには、プロセスの終了を待機し、タイムアウト後にプロセスを終了するスクリプトを記述します。これは Python/Perl などで簡単ですが、シェルでもこれが可能です (trap や on background children を使用)。

cron のように、呼び出しの開始ではなく、呼び出し間の固定時間 (つまり、前の呼び出しの終了から次の呼び出しの開始まで) を指定すると便利な場合があります。通常の cron ではこれが許可されていないため、特別なスクリプトを実行する必要があります。

関連情報