Open ballard26 opened 1 year ago
{tmp/libexec/redpanda} 0x62c742f: seastar::memory::small_pool::add_more_objects() at /v/build/v_deps_build/seastar-prefix/src/seastar/src/core/memory.cc:1300
Sounds like it was busy in the allocator, possibly either finding free pages or reclaiming some?
It's possible, any idea how long finding/reclaiming pages could take? Another possibility is the loop here https://github.com/redpanda-data/redpanda/blob/dev/src/v/cluster/controller_backend.cc#L642-L645 as deltas can grow arbitrarily large depending on user input.
It's possible, any idea how long finding/reclaiming pages could take?
Not entirely sure, haven't looked at that code path all too much yet. However, the reclaimer stuff calls back into redpanda to clear stuff out of the chunk cache, right? So that might come on top of that.
Not entirely sure, haven't looked at that code path all too much yet. However, the reclaimer stuff calls back into redpanda to clear stuff out of the chunk cache, right? So that might come on top of that.
yes, that is inline with reclaim. I think the reclaimer is amenable to bailing out early if there were a way to figure out if we were eating up too much time provided we'd met the requested amount of memory being free. the other thing that could be costly is if the allocator is running cross-core memory frees. I'm not 100% sure if that is synchronous as well, but it might be.
This issue hasn't seen activity in 3 months. If you want to keep it open, post a comment or remove the stale
label – otherwise this will be closed in two weeks.
In: https://ci-artifacts.dev.vectorized.cloud:443/vtools/7317/0187c1bf-8e3c-401e-bda2-49c5fa727564/vbuild/output/ducktape-release-clang-amd64.tgz
Backtrace:
JIRA Link: CORE-1291