C++ 如何管理日志记录性能？

我们有一个消息处理系统，低延迟是关键。最近，我发现虽然我们在系统中保持较高的速率，但我们看到了一些“异常值”。（需要更长时间的消息）当我们删除日志记录时，我们的系统没有显示这些异常值

现在，我们的日志记录基本上只是一个包装好的ostream，具有一些类似于log4j的日志记录级别功能（debug、fatal、debug等）

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

任何关于优化日志记录的建议都将不胜感激

注意：我知道我们的系统可能还有其他问题导致异常值，但出于这个问题，我只对日志优化感兴趣，谢谢

---

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

我想这在某种程度上取决于操作系统

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

---

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

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

---

在后台线程中，我们对可以一次写入（退出队列）的消息数量也有限制，因此，如果超出此限制，我们会将后台线程重新置于睡眠状态。

+1：这与我阅读原始问题时脑海中出现的相同。但我认为这也是其他骨质疏松症的解决方案！在对这个问题进行表决之前，我正在等待我的问题的答案：如果日志记录是强制性的，那么相信另一个线程来执行“一段时间后，或者如果我们先崩溃，可能永远不会”可能是可接受的，也可能是不可接受的。此外，如果要最小化最大延迟，可能日志应该发送到不用于主要操作的卷。如果它们在同一个磁盘盘上（如果吞吐量足够高，甚至是同一条总线），那么即使进程优先级较低，您也可能会发现日志记录操作偶尔会延迟“实际工作”。我不知道发生这种情况的可能性，因为我从未测试过。如果日志记录是必需的，那么在报告操作成功之前，是否也必须等待日志I/O成功完成？如果没有，那么您就有大量的缓冲选项，如果日志的重播必须始终匹配系统的任何外部可见状态，那么这些选项就不存在。即使I/O失败，系统也必须继续。从理论上讲，系统正常工作而不正确记录是可能的，但是，记录总是发生是一个非常高的优先级。因此，“非常高”的日志准确性优先级低于“关键”的低最大延迟优先级？在这种情况下，我给Roddy+1。如果两者都很关键，那么答案就不同了。但请记住，在他的系统中，当应用程序或机器发生灾难性故障时，日志记录会失败。如果这是不可接受的，您可能必须提高日志准确性的优先级。