solaris に UFS パーティションがあります。
ボリュームがいっぱいになります。私たちはまだそれに書き込もうとしています - 当然 open() はすぐに -1 を返します。
一括削除を行う cron ジョブが起動すると、open() がタイムリーに返されないように見えます。ウォッチドッグがプロセスを強制終了するまでに少なくとも 6 秒かかるためです。
さて、明らかな考えは、削除がファイルシステムをビジー状態に保ち、open() が永遠にかかるということです...しかし、この動作について具体的な知識はありますか?
おそらく、「一括削除」を行うプログラムを変更して、問題のあるファイルシステムでよりスムーズに動作するようにすることができます。削除するファイルを見つけるためにクエリを実行する場合、タイムアウトになっているのは open 呼び出しではない可能性があります。理論をテストするために、ディスクがいっぱいの状態で既知の名前を持つ単一のファイルを単純に削除する cron ジョブを設定する方法はありますか? 「大量削除」プログラムは、どの「開く」呼び出しを行うかをどのように決定しますか?
書き込みが機能しなくなる前に、ディスク使用率を制御することもできます。これをより低いパーセンテージに設定することもできます。ファイル作成ステップが -1 を返すまで待って「ディスクがいっぱい」の状態を検出している場合は、コードに明示的なチェックを追加して、ファイルシステムが一定の割合を超えた場合に修正アクションを実行することを検討する必要があります。
一括削除はランダム IO の嵐を引き起こし、パフォーマンスを大幅に低下させます。nologgingそして、コミットするジャーナル/ログ トランザクションをできるだけ多く作成します (オプション ?を試してください)。さらに、fs がほぼ満杯の場合、open は新しい inode 用のスペースを見つけるのに時間がかかります。
ファイルを削除する回数を増やし、一度に削除する回数を減らすと、応答時間が短縮される場合があります。または、単にゆっくりと削除し、rm の間でスリープ状態にします。