自動停止と再開

runlot は、一定時間リクエストがないプロジェクトのワーカープロセスを終了して、メモリ使用量を減らします。内部の状態名は park で、データは削除しません。

自動的に停止する条件

既定のアイドル時間は 5 分です。次の条件をすべて満たすと、ワーカープロセスを終了します。

• 最後の HTTP リクエストと最後のデータベースアクセスから 5 分が経過しています。
• 開いているデータベース接続がありません。
• バックアップ、復元、移行の処理が進行中ではありません。

維持されるデータと設定

終了するのはワーカープロセスだけです。データディレクトリ、デプロイバンドル、データベースファイルは維持されます。計測では、プロジェクトあたりの常駐メモリ使用量が約 125 MB からゼロに減少しました。

ダッシュボードのプロジェクトの状態や配置情報は変わらず、プロジェクトは引き続き「アクティブ」と表示されます。自動停止はノードの内部で処理します。

新しいリクエストが来たとき

最初のリクエストが届くとワーカープロセスを起動し、準備が完了してからそのリクエストを転送します。以下の数値は計測結果であり、すべての環境で保証される応答時間ではありません。

プロセスを起動した後は、実際に接続を受け付けられるかを確認します。準備が終わる前にリクエストが転送されることを防ぐための手順です。

停止中のプロジェクトのバックアップ

バックアップの時刻になると、プロジェクトを一時的に起動してバックアップを作成し、完了後にあらためて停止します。使用していないプロジェクトも、定期バックアップをスキップすることはありません。

料金

自動的に停止している間は、コンピュートの使用量は発生しません。現在の無料プランでは特に違いはありませんが、有料プランが導入された際には、アイドル期間のコンピュート費用を抑える基準になります。

この機能は、管理者がプロジェクトを停止する suspend とは異なります。自動停止したプロジェクトは新しいリクエストが来ると再び実行されるため、ご自身で再開する必要はありません。

ノードのディスク容量が不足している場合

ノードのディスク容量が不足すると、アイドル状態のプロジェクトのデータベースを暗号化して外部ストレージへ移すことがあります。このときコールド状態になり、次のリクエストではまずデータベースを復元する必要があります。計測では、この処理に約 6〜7 秒かかりました。詳しくはコールド状態と再開を参照してください。