Eric Wong <[email protected]> wrote:
> Is it high for anybody else? I'm not seeing it for small
> instances (e.g. the instance that's powering
> public-inbox.org/{git,meta} is fine, but with lots of entries my
> lore mirror @ https://yhbt.net/lore/ the main sbrk heap seems to
> be growing slowly without bounds.
I suspect it's long-lived SQLite connections and associated
caches/etc (and having short-lived allocations mixed in with
long-term ones).
Anyways, I'm testing the below on yhbt.net/lore, but
there's other SQLite knobs worth investigating...
Preloading all DBs isn't realistic, either, due to the
potential number of inboxes.
diff --git a/lib/PublicInbox/Inbox.pm b/lib/PublicInbox/Inbox.pm
index 1d5fc708..8fcf6e81 100644
--- a/lib/PublicInbox/Inbox.pm
+++ b/lib/PublicInbox/Inbox.pm
@@ -43,7 +43,7 @@ sub cleanup_task () {
for my $git (@{$ibx->{-repo_objs}}) {
$again = 1 if $git->cleanup;
}
- check_inodes($ibx);
+ delete @$ibx{qw(over mm)};
$next->{"$ibx"} = $ibx if $again;
}
$CLEANUP = $next;
> I think I'll need to finish porting mwrap over to Perl/XS
> (from Ruby/C)...
Yeah, still on my TODO list. But right now lei IMAP(S) on
high-latency links is a terrible...
--
unsubscribe: one-click, see List-Unsubscribe header
archive: https://public-inbox.org/meta/
