プロセスの CPU とメモリの状態を 1 分ごとに保存するログ ファイルを実装しました。ファイルの最大サイズを 3MB に制限しました (私の目的には十分です)。
スクリプトは 1 分ごとに cron ジョブによって呼び出され、スクリプトはその分の詳細をログに記録し、ファイルの名前を "Log_.log" に変更します。
サイズが「3MB - 100 バイト」に達したら、ファイル ポインタを先頭を指すようにリセットし、ログ ファイルの最初のエントリを上書きして、ファイルの名前を「Log_<0+some offset>.log」に変更します。
ファイルポインターの位置を更新するために毎分ファイルの名前を変更しているので、それは良い/効率的な方法ですか?
この目的のために複数のログ ファイルを維持したくありません。
私にとっての別のオプションは、ファイル内のファイルポインターの位置を維持することですが、....別のファイル!! このオプションが良い場合、それを維持することに興味はありません:)
前もって感謝します。
あなたはエンジニアですか？これは、完全に機能しているが過度に複雑なソリューションによって解決された、いくつかの単純なタスクの良い例です。
入力したコンテンツが取り出したコンテンツとまったく同じバイト数を使用しない限り、ファイルに「書き込み」を行うと、実際には、書き込み位置の後の後続部分全体がディスクに再書き込みされます。追加ははるかに安いです。
ポインタを格納するためにファイルの名前を変更することは機能しますが、あまり洗練されておらず、作業がより複雑になります（たとえば、プロセスにはファイルが存在するディレクトリへの書き込み権限が必要です。それ以外の場合は、2つのファイルへの書き込みアクセスで十分です）
ディスク容量が問題にならない限り（そして実際にはそうなることはめったにありません）、あなたのアプローチは言うよりも効率的ではなく、すべてをファイルに追加し、ファイルが最大サイズに達したときにファイルを回転させます。このようにして、常に最後の3MBのログを使用でき、現在のファイルには最大3MB多くのログがあります。ポインタ位置全体を再計算する代わりに、ファイルの解析も非常に簡単になります。
1分ごと（または1秒ごと）にファイルの名前を変更しても、システムの速度が大幅に低下することはありません。心配する必要はありません。
私たちの懸念は主に「ファイルの名前を変更する必要があると思う理由」です。技術的には良くありませんし、論理的な観点からも良くありません。他の多くの（将来の）タスクを難しくします。ファイルポインタを別のファイルに保存することも、ファイルの最後に保存することもできます。ファイルポインタをまったく必要としない、より優れた^ H ^ H ^ H ^ H ^ H^Hのより単純なソリューションがあります。
ファイルの名前を変更する理由がわかりません。これは何を達成しますか？
ログエントリは固定サイズですか? それとも可変サイズ？
エントリが固定サイズである場合、既存のファイルを最初から書き直すことに問題はありません。ファイルに不完全なエントリが含まれることはありません。ファイルにカウンタまたはタイムスタンプを書き込む場合は、次のようにする必要があります。 「カーソル」がどこにあるかを明確にしてください。
エントリが可変サイズの場合、ファイル内のどこに「カーソル」があるかを何らかの方法で明確にすることなく、最初からファイルを書き直してはならず、切り捨てられたログ エントリを読み取っても回復力のあるコードを記述する必要があります。
RRDtoolなどの既存のツールを再利用できますか?