お世話になります。
上限(行数)の決まったログファイル出力について教えて頂けないでしょうか。
上限を1000行とし、1000行まで書き込んだら、1001行目の書き込みでは、1行目を削除して最後尾に書き込むという処理を考えた場合どのような方法がベストでしょうか。
リアルタイムではなく、あるトリガがあってログ出力します。1行は、256byteです。
考えた案としては、メモリに一旦全て読み込んで処理するというものですが、1000×256 byte分は、メモリに保持しても一般的に問題ないレベルで
しょうか。(もちろん、環境によるかもしれませんが）
どうかご教授ください。
よろしくお願い致します。
> 1000×256 byte分は、メモリに保持しても一般的に問題ないレベル
であると思う(現代 Windows マシンなら)
が、普通にファイルを取り扱う限り
・１行目を削除する＝全部の行を書き換える
わけで、１行の追加があるたび毎回 256KB の書き込みが入ることになる。
これでは仕様としてあまりおいしくないと思う。
１０００行まで達したら無条件で過去ログが失われるのも適切かどうか怪しい。
俺ならば
・アプリケーション側は単にログを出力するだけ
・ログファイルの取り扱いは syslog なり logrotate なりにお任せ
とするだろう。責任分担も設定も簡単になるし。
# Windows か・・・ syslog ではなくて eventlog ではダメ？
いつも画像を扱っている身としては
例えばVGAサイズ(640*480[pixel])のカラー画像を１枚読み込んだだけでも
640*480*3byte(=900k) のメモリを要するわけで，
それに比べれば全く問題ないサイズに感じます．
このケースの場合、自分ならメモリーに保持はしませんね。
理由1.ログファイルが固定サイズ(構造が簡単)。
理由2.ファイルへのIOはOSがキャッシュするので、
結局(OSの管理する)メモリーに書き込むのと同じ。
理由3.しかも、書き込んだ時点でファイルに保管されることが、
OSによって保障されている。
従って、この場合は１行分(256Byte)を1ブロック、全ブロック数
を1000とする「リング」型のファイルを設計すると思います。
最後尾(又はカレント)のブロックインデックスと、有効ブロック数
を管理するだけですよねぇ。
皆さんありがとうございます。
仲澤さんのおっしゃるリング型が考えているものに
近いかなとは思います。カレントインデックスを管理して
、書き込みが発生する度にカレント行を更新する方法
で実現してみたいと思います。
OS的にはやってる事は同じかもと思いますけど
固定長なら先頭行にでも4バイトの現在行を持っておいて
読込&カウントアップして
seek関数で位置指定でwrite書き込みすればいいのでは?
普通のランダムアクセスだと思いますけど。
て
>仲澤＠失業者
の方法と同じでした。失礼しました。