Arne Welzel

Ah, so that's even happening when not providing a test-case at all: ``` $ ../../build/src/fuzzers/zeek-smb-fuzzer Standalone fuzzer processing 0 inputs Processed 0 inputs in 0.000000s (1.105059s w/ initialization), avg =...

> I'm not convinced that this is a good route for a distributed system with loose coupling like Broker. At the pub/sub layer, we don't know how many responses we...

> We have already disabled central collection by default again, right? Yes, it's disabled.

> How much is a "large number of workers"? I suppose well below 1k? The configuration was 9 worker nodes with 16 workers each which triggered the error. Less than...

The following supervisor setup starting 80 workers, 12 loggers and setting `Broker::log_batch_interval` down to 0.25, doing artificial logging to a single stream does provoke some overhead in the caf thread,...

On Slack, the user provided a new flamegraph that looks promising: There's ~55% time spent in `std::max_element()` within `mcast::max_buffered()`. https://github.com/zeek/actor-framework/blob/b50e2249761c2db5d28f94b64a6df92d0c3d0cc2/libcaf_core/caf/flow/op/mcast.hpp#L137-L147 Can probably be assumed that `_states` grew large and the...

I can somewhat reproduce this on a bigger machine with the original reproducer, but also trigger a high percentage of `native_queued_spin_lock_slowpath` on that system and don't have great symbols for...

I've re-tested master with 196-workers, 16 loggers and a log_batch_interval of 0.10sec. The workers script was tweaked to write nlogger messages every `log_batch_interval` to two log streams. This results in...

External user has reported that logger CPU usage decreased significantly: > Single logger(16c64g) cpu usage decreased from 76% to 24% . However, they have observed two occurrences were worker memory...

From Slack, suspicion is that loggers stop accepting log messages causing workers to run OOM. User reports this is not happening with their vanilla 5.2.0 deployment. > Thanks for the...