File 0105-Clarify-burst-mode-protection-and-non-file-based-log.patch of Package erlang
From 1913013e49796b6065c870f6a32ac7dc9e6a9cb3 Mon Sep 17 00:00:00 2001 From: Tobias Pfeiffer <pragtob@gmail.com> Date: Tue, 24 Sep 2024 11:40:11 +0200 Subject: [PATCH] Clarify burst mode protection and non file based logging Reading the docs my impression was that the reasons mentioned for burst mode protection do only apply to file-based logging or at least the examples only do. Locking to the console is fairly common in cloud-based environments. I have deactivated the burst mode protection (that had swallowed about 2/3s of our log messages) and the system is running fine without any impact on CPU or memory that I could spot. So, this is part me wanting to clarify this in the doc but also part me checking in about my understanding of the interplay of this. --- lib/kernel/doc/guides/logger_chapter.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/lib/kernel/doc/guides/logger_chapter.md b/lib/kernel/doc/guides/logger_chapter.md index 1d809b5766..1932c70cc7 100644 --- a/lib/kernel/doc/guides/logger_chapter.md +++ b/lib/kernel/doc/guides/logger_chapter.md @@ -1082,6 +1082,10 @@ period of time - can potentially cause problems, such as: - Circular logs wrap too quickly so that important data is overwritten. - Write buffers grow large, which slows down file sync operations. +Note that these examples apply to file-based logging. If you're logging to +the console the protections discussed below should be safe to disable or +tweak, as long as your system can handle the load of them. + For this reason, both built-in handlers offer the possibility to specify the maximum number of events to be handled within a certain time frame. With this burst control feature enabled, the handler can avoid choking the log with -- 2.43.0
