cronジョブの数が多すぎますか？

基本的なメンテナンスのためのcronジョブがいくつかありますが、リソースをあまり消費しません。

私はカスタムタスクスケジューリングも持っています（これは.phpファイルを呼び出し、GETを介して情報を渡すだけです。つまり、cronjob.php？param1 = param ...）。これらはすぐに加算されます。

これらは、システムコマンドを呼び出して外部プログラムを実行するだけです（Nmapはその1つです）。彼らは通常、それほど時間もかかりません。

とにかく、誰に教えてもらえますか、おおざっぱに何が多すぎるのでしょうか？どのジョブがどのくらいの頻度で実行されているかによって決まるため、言うのは難しいことですが、crontabプログラムはどの時点で「苦労」し始めますか？誰かが何か考えがありますか？

ありがとう。

「crontabプログラム」（cron）自体の負荷については心配しません。これは、注意を払う必要のあるシステム全体の負荷です。ジョブの実行中にメトリック（CPU使用率、IOレート、Webクエリの応答時間）を確認します-顕著なスパイクはありますか？システムの実際の使用を妨げるほど悪いのですか？

プログラムに「時間がかからない」場合は、問題がないことを示しています。

それでも心配な場合は、負荷を制限するために他のことを実行niceできます。優先順位を下げるためにジョブを実行したり、同時にではなく順次実行したりするなどです。

私たちのプロダクションシステムを検索するだけで、最大のジョブには862のcronジョブがあり（すべてのユーザーで、最大の1つはrootが117です）、それほど多くはありません。

24時間365日、毎分60個のジョブを開始し、それらすべてが完了するまでに2秒かかる場合、おそらく苦痛の世界に陥ることになります。ただし、ワークロードが（静かな時間などで）バランスしている限り、回復するはずです。ピーク時のシステム負荷（CPU％、ディスクI / Oなど）に注意し、実際のジョブの数よりもそれについて心配してください。

この質問は、「問題が発生する前にいくつのプロセスを実行できるか」に似ています。それはあなたのシステムに依存するので、最善の策はそれを試すことです。Cron自体には、私が見つけたいくつかの制限がありますが、何万ものジョブをスケジュールしようとしている場合は、私がこれまで以上に緊張していることになります。

測定してください、推測しないでください！

Cron自体は本質的には闘争を開始しません。それが発生するずっと前に、システムはワークロードで完全に行き詰まります。

ここにあるすべての答えに同意します。少し異なる見方でそれを理解するには、cronjobsをあなたのプラットフォームのユーザーと考えてください。

ユーザーがCPUの1％を使用しているとしましょう（CRUD操作/ネットワークなど）。このようなユーザー（cronjobs）が同時に100人いる場合、CPUがしきい値の制限に達し、サーバーが処理できず、最終的にクラッシュする可能性があります。

では、「cronジョブの数が多すぎる」という質問に戻りましょう。- リソースに突然のスパイクがない可能性があることが分析で示されている限り、100のcronjobでも問題ありません。