我有一个以(10MB /小时)的节奏记录的LogFile,这个程序需要运行10年以上。我需要决定在哪个尺寸创建一个新的日志文件!
我将10KB文件中的写入时间与1GB +文件的时间进行比较,时间几乎相同。
文件的大小是否会影响写入速度, 是否建议保持日志文件的大小相当小?
我的C#记录功能:
//LOGGING FUNCTION
public static void Log(string LogInfo)
{
//FILE SIZE LIMITATION 50 000 000 Bytes, 50MB
MaximumFileSize = 50000000
long FileSize = 0;
if (File.Exists("../Log/EventLog.txt"))
{
FileSize = new System.IO.FileInfo("../Log/EventLog.txt").Length;
}
if (File.Exists("../Log/EventLog.txt") && (FileSize > MaximumFileSize)) NewLog();
if (!System.IO.Directory.Exists("../Log/")) System.IO.Directory.CreateDirectory("../Log/");
using (StreamWriter s = File.AppendText("../Log/EventLog.txt"))
{
s.WriteLine(DateTime.Now.ToString() + " -- " + LofInfo);
s.Close();
}
}
//FUNCTION TO ARCHIVE LOG
public static void NewLog()
{
if (File.Exists("../Log/EventLog.txt"))
{
File.Move("../Log/EventLog.txt", "../Log/EventLog_" + DateTime.Now.ToString("yyyyMMdd_HH_mm_ss") + ".txt");
}
}
答案 0 :(得分:2)
还要考虑如何使用这些日志文件。它们通常在记事本或类似工具中打开,随着文件变大,这会花费更多的时间。祝好像打开这样的1GB文件好运。我会坚持更多,比如,每个文件10兆字节(即使这不会立即打开)。如果需要的话,提出一个排序文件名命名逻辑来保持文件易于相互关联是微不足道的。
更好的是,在日期更改时创建新的日志文件(并在文件名中加入yyyy-mm-dd格式以便更好地排序)。为了进行比较,请查看IIS-logging提供的与旋转日志文件相关的选项。毕竟,确定当前日志条目需要转到哪个日志文件要容易得多(如果每日/每小时架构,文件名将是确定性的)那么它将确定当前当前日志文件的>大小(也认为多个线程/ app-instances同时访问)。换句话说,使用当前系统时间来确定目标日志文件要容易得多。如果你期待健谈的日志,那么每小时一次;否则每日计划可能就足够了。它们的大小各不相同,但也许没问题(即使你使用固定大小,也无法实现精确的字节等效)。
否则,你必须编写代码只是为了读取那些相同的文件,在这种情况下,这就引出了一个问题:为什么不使用数据库来存储那些日志信息,因为它将更容易用来呈现在未来观看者。
答案 1 :(得分:0)
我们有一个记录小二进制文件(几KB)的应用程序。我们每天写入大约10倍的数据,即使文件非常小,即使是2000年的旧笔记本电脑硬盘也能够保持正常运行而没有任何问题。这可能回答了你的主要问题。
然而:当我们移动这些文件的GB时,传输速度非常慢。 SSD比HDD要好,但仍然非常慢(小于1MB / s)。
在碎片化硬盘上,小文件可能适合整个磁盘上的小型可用磁盘空间,而大文件更可能放在一个大块中。由于每次不读取连续数据流时硬盘驱动器可能旋转一圈,因此传输速度将受到影响。
每个文件的最佳大小可能因磁盘而异,但每天或每周日志(10-70 MB)文件似乎是在您需要复制一年的日志文件时轻松发送文件和传输速度之间的良好折衷。