Justin

> but RAM remained static at 29G. That's probably normal if you are not using jemalloc. I think the glibc allocator doesn't return freed memory back to the OS. jemalloc...

@zrobinette12 that does look like it's mostly from the logger not being able to keep up. It may help to have jeprof generate the SVG output, or try running ```...

Interesting, the allocated memory is almost all from strings and vectors, which matches what the dns log would be writing. > It has 22 cores, 44 threads. It has 376g...

@zrobinette12 None of the `list` stuff there is helpful, but the `top` stuff is. It would still be better visualized using the `svg` output that jeprof can generate. Both of...

The svg view definitely makes it easier to see. The `when` stuff is accounting for 9.4%, but the real use is log writes. This point is where you can see...

Pretty sure this is your problem: ``` 1645083001.509154 sip/Log::WRITER_ASCII in=261613 out=40575 pending=101855/0 (#queue r/w: in=159758/261613 out=40575/40575) ``` that pending number is ``` pending_in; //! Number of messages sent to the...

CPU of the logger process alone doesn't mean much as it's multi threaded. What you want to do is look at the threads individually. You can do this in top...

What does perf top -F199 -C 10 show? The extra load is all `system` time. Could be related to something like https://github.com/zeek/zeek/pull/2039

Interesting. I bet that's all from FindReadySources. Can you do a flame graph instead? that will make it easier to see what ends up calling that. something like perf record...

Yeah.. ``` >>> s=5643649511441653571 >>> hex(s) '0x4e5245544e495f43' >>> ss=hex(s)[2:] >>> binascii.unhexlify(ss) b'NRETNI_C' ```