为什么日志文件不切分会影响性能?
只是追加写入,并不读,应该是完全不影响性能的吧?
为什么配置apache以及nginx的日志功能时,都有资料表示要超过几兆就分割文件?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
只是追加写入,并不读,应该是完全不影响性能的吧?
为什么配置apache以及nginx的日志功能时,都有资料表示要超过几兆就分割文件?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(3)
不能一概而论。这种策略只是为了在常用文件系统中达到性能最优化的最简单方式。
不同硬盘、不同文件系统、不同的磁盘IO调度算法……都会对日志文件读写产生很大的影响。
比如适用数据是被整体访问场景的 HDFS。日志文件采用追加写,可以做到最小化硬盘的寻址开销,只需要一次寻址即可,这时寻址时间相比于传输延时可忽略。
还有知道文件明确的偏移量的 Kafka。采用分段和索引的方式来解决查找效率问题。Kafka 把一个 patition
大文件又分成了多个小文件段,每个小文件段以偏移量命名,通过多个小文件段,可以使用二分搜索法很快定位消息。
而 HBase,LevelDB 等 NoSQL 数据库的存储引擎则使用了日志结构的合并树LSM(The Log-Structured Merge-Tree)。Log-Structured 的思想是将整个磁盘看做一个日志,在日志中存放永久性数据及其索引,每次都添加到日志的末尾。LSM-tree 牺牲了部分读性能,以此来换取写入的最大化性能。
对于大文件的读写,不同文件系统的性能差异非常大。
你煮一锅饭(一个日志),吃的时候端起整个锅来吃(日志不分割),还是分到碗里吃(日志分割)来得方便呢?
分割的目的:
1、日志太大导致磁盘空间占用大,如果分割,则可以定期清除以前的日志
2、日志太大,不好查看,不太好快速定位日志,且日志太大查看时影响服务器IO