開発者ツール · Crontab ジェネレーター
重複する cron ジョブ: 長いタスクに flock が必要な理由とその追加方法
· なぜそれが重要なのか
クロン 同時実行数 オペレーション
Cron は、前の実行が終了したかどうかに関係なく、スケジュールに従ってジョブを開始します。この投稿では、それが破損や負荷のスパイクを引き起こす理由を説明し、実行を排他的にするフロックのイディオムを示します。
同じテーブルを書き込む 2 つのインポート — 時間単位のジョブが 1 時間より遅くなり、cron が新しいコピーを開始し続けました
時間ごとの式を使用すると、以前の候補に関連付けられた作業がまだ実行されている間に、新しい候補を識別できます。 `0 * * * *` には、期間、プロセス ID、または完了状態は記録されません。 ToolAcre は 1 時間ごとに分ゼロを展開し、将来の時刻をリストできますが、それらの時刻の間のアクションは決して観察されません。
つまり、頻度と独占性は個別に検討する必要があります。タスクがその間隔を超えて持続する可能性がある場合は、まずターゲット システムでの継続時間を定量化します。次に、そこでサポートされている同時実行制御を選択します。正しいスケジュールを編集しても、それ自体では既存のプロセスの情報を追加したり、2 回目の呼び出しを防止したりすることはできません。
式には実行中のジョブの状態が含まれていません
パーサーは呼び出し間でステートレスです。テキストを並べ替えられた値の配列と警告に変換し、`nextRuns` はプロセス テーブルを使用せずに日付を検索します。 UI は現在の式から再計算され、ジョブのライフサイクルは保持されません。そのモデルでは、以前のアクションがアクティブなままであるかどうかではなく、いつであるかを尋ねます。
これは、記事タイトルの背後にある正確な証拠です。すべての cron デーモンがフォークまたはキューを作成する方法についてのクレームは必要ありません。式言語自体にはオーバーラップ フィールドがなく、ジェネレーターにはランタイム モニターがありません。排他性の保証は、その動作が独立してテストされる別のレイヤーから得られる必要があります。
考えられる重複の症状はコマンドによって異なり、ジェネレーターによって予測されません。
オーバーラップは、重複した作業、ロック競合、または負荷と相関関係がある可能性がありますが、それらの結果はコマンドの動作によって異なります。読み取り専用の冪等チェックとステートフル インポートでは、同じ時間単位のスケジュールであっても異なるリスクがあります。 ToolAcre には、それらを予測するためのコマンド パーサー、データベース接続、またはリソース モデルがありません。
一般的な失敗予測を式に添付するのではなく、アクションの同時実行プロパティを文書化します。通常の継続時間と観測された最悪の継続時間を測定し、共有状態を特定して、実行のスキップまたは遅延が何を意味するかを判断します。これらの運用上の事実によって、独占性が必要かどうかが決まります。 5 つのフィールドは候補時間のみを決定します。
flock の構文と動作はこのリポジトリの外にあります
ワークブックでは、ロック パスと終了動作である `flock -n` が規定されています。このリポジトリには flock の実装やテストが存在しないため、このモジュールはその構文を検証しません。プラットフォームの可用性、ファイルシステムのアクセス許可、ロックの有効期間はすべて、ブラウザーのスケジュール コードの外にあります。
flock がターゲット上で適切な場合は、インストールされているドキュメントを使用し、そこで無害な競合シナリオをテストします。プレフィックス付きのタイミング フィールドが ToolAcre を通過するため、成功を推測しないでください。正しいロックが別の方言用に書かれたスケジュールを保護できるのと同じように、有効な式を無効なロック コマンドの前に置くことができます。
作業境界: ロック セマンティクスを主張せずに 1 時間ごとのタイミングを検証する
`0 * * * *` を稼働スケジュールとして使用します。説明には、毎時 0 分が記載されており、プレビューは開始瞬間以降、連続する時間の境界に進む必要があります。これは、ToolAcre が計算するケイデンスを証明します。コマンドの継続時間がこれらの境界のいずれかを超えたときに何が起こるかは証明されていません。
時間ごとの期待をターゲット側の同時実行テストに反映します。無害な長時間実行インスタンスを 1 つ開始し、次の候補に到達し、選択されたコントロールを観察します。結果を実行の証拠として式のレビューとは別に保管します。これにより、後でタイミングまたはロックが変更された場合でも、クリーンな診断が維持されます。
代替の独占性メカニズムにはターゲット固有の証拠が必要です
スクリプト内のロック、スーパーバイザー ポリシー、およびサービス マネージャーの動作はすべて排他性を提供する可能性がありますが、それらのセマンティクスはこのソースからランク付けできません。また、ToolAcre は、1 回の実行の欠落が許容されるかどうか、作業をキューに入れる必要があるかどうか、または 2 回目の試行を終了する必要があるかどうかも知りません。
メカニズムを選択する前に、これらの結果を定義します。 「決して重複しない」はポリシーの 1 つにすぎません。合体、キューイング、分割された状態での並列処理なども含まれます。ジェネレーターは、ポリシーの議論で使用される候補のリズムを提供できますが、実装の選択は実際の実行時に基づいたままになります。
分散ロックはスケジュール解析とプレビューの両方の範囲外のままです
ホスト間でロックを共有すると、ローカルのカレンダー計算を超えた調整が行われます。ホスト ID、ネットワーク ストア、リースはパーサーに表示されません。したがって、この記事では、ローカル ファイルまたはブラウザのプレビューが分散型同時実行性を解決するという示唆を避けています。
マルチホスト作業の場合は、障害モード、所有権、回復動作が文書化され、テストされている調整設計を使用してください。 5 つのフィールドのスケジュールをそのシステムへの 1 つの入力として保持します。エクスプレッションは完全に移植可能ですが、排他レイヤーは環境に深く依存します。
要点: スケジュールと独占性は別の問題です。ジェネレーターが最初のものを処理し、フロックが 2 番目のものを処理します。
別の試行が適格になったときに回答をスケジュールします。独占性はそれが始まるかどうかに答えます。 ToolAcre は、フィールド拡張とウォールクロック プレビューを通じて前者のみを実装します。プロセス状態の欠如はアーキテクチャ上の境界であり、隠れたデフォルトではありません。
頻度を構築して検証し、アクションの時間を測定してから、ターゲットでサポートされている同時実行ポリシーをテストします。これらを個別のコントロールとしてレポートすると、両方がレビュー可能になります。ジェネレーターはジョブをスケジュールしません。コピーされた式は、重複した実行に対する保護として記述されるべきではありません。