您如何管理日志记录性能？答案

【问题标题】：How do you manage logging performance?您如何管理日志记录性能？
【发布时间】：2010-11-04 21:45:47
【问题描述】：

我们有一个消息处理系统，其中低延迟至关重要。最近，我发现虽然我们在系统中保持高比率，但我们看到了一些“异常值”。（消息花费的时间比他们应该的长得多）当我们删除日志记录时，我们的系统不会显示这些异常值。

现在我们的日志基本上只是一个封装的 ostream，具有一些类似于 log4j 的日志级别功能（调试、致命、调试等）。

我想知道，其他人如何管理日志记录性能，特别是在消息处理活动中？您如何管理这些 I/O 绑定活动？你把它去掉吗？您是否改用数据库？

感谢任何有关优化日志记录的建议。

注意：我认识到我们的系统可能存在其他问题导致异常值，但为了这个问题，我只对日志优化感兴趣，谢谢。

另外：我们的系统必须进行日志记录。

【问题讨论】：

如果日志记录是强制性的，是否也必须等待日志 I/O 成功完成才能报告操作成功？如果不是，那么如果日志的重放始终必须与系统的任何外部可见状态匹配，那么您就有很多不存在的缓冲选项。
即使 I/O 失败，系统也必须继续运行。从理论上讲，可以让系统正常工作而不正确记录它，但是，始终发生记录是一个非常高的优先级。
那么“非常高”的日志准确性优先级低于“关键”的低最大延迟优先级？在这种情况下，我给罗迪+1。如果他们都是批判的，那么答案就会不同。但请记住，在他的系统中，日志记录失败的时间是应用程序或机器发生灾难性故障的时候。如果这不可接受，您可能必须提高日志记录准确性的优先级。

【解决方案1】：

我猜它在某种程度上依赖于操作系统。

在 win32 上，我们的日志子系统只是将消息排队等待处理磁盘 I/O 的日志线程。

这将磁盘 I/O 性能与时间关键线程分离，并让我们能够准确控制队列锁定的方式和时间。

【讨论】：

+1：当我阅读原始问题时，我的脑海中浮现出同样的想法。但我认为这也是其他操作系统的解决方案！
在对这个问题进行投票之前，我正在等待我的问题的答案：如果日志记录是强制性的，那么将其信任给另一个线程来执行“一段时间后，或者如果我们先崩溃，也许永远不会” ，可能接受也可能不接受。
另外，如果要最小化最大延迟，也许日志应该转到不用于主要操作的卷。如果它们在同一个磁盘盘片上（如果您的吞吐量足够高，甚至在同一个总线上），那么即使进程优先级较低，您也可能会发现日志记录操作偶尔会延迟“实际工作”。我不知道这种可能性，因为我从未测试过。

【解决方案2】：

与 Roddy 所说的类似，我们也在线程安全队列中对消息进行排队，并有一个单独的低优先级线程来执行实际的磁盘 I/O。

在后台线程中，我们还对可以一次写入（出列）的消息数量进行了限制，因此除此之外，我们将后台线程重新置于睡眠状态。

【讨论】：