From: "Kamil Trzciński" <ayufan@ayufan.eu>
To: Christian Ebner <c.ebner@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] Further improvement to GC
Date: Wed, 11 Jun 2025 08:11:39 +0200 [thread overview]
Message-ID: <CAJ-UffmB96ZoEmNz9WnkaaA09J=CuWXmNrq05ORdgthseBYxZA@mail.gmail.com> (raw)
In-Reply-To: <9f04a76b-3e90-4eec-a206-bee07167462d@proxmox.com>
Thanks. I created in https://bugzilla.proxmox.com/show_bug.cgi?id=6452.
Kamil
On Tue, 10 Jun 2025 at 09:20, Christian Ebner <c.ebner@proxmox.com> wrote:
>
> Hi,
>
> thanks for sharing your ideas!
>
> On 6/8/25 16:25, Kamil Trzciński wrote:
> > Thanks for introducing LRU Cache.
> >
> > I have another suggestion that we further the sweep phase could be improved:
> >
> > 1. The sweep_unused_chunks could use LRU cache to avoid lstatat if
> > object is found in cache.
>
> That is indeed true and a good further potential optimization, given
> that cached chunk digest can be considered to have an atime newer than
> the cutoff time. Cached items must and could be accounted differently in
> the GC stats then.
>
> > The lstatat would only be required for potential objects that might
> > have been added while running GC cycle, or that might have been
> > evicted from LRU cache.
> > For big enough LRU caches and the fact that only small amount of
> > objects are usually removed this should make the GC almost in-memory.
> >
> > 2. The process could add a warning that LRU cache is too small, and
> > propose the value big enough to avoid cache eviction based on number
> > of chunks observed.
>
> The number of in use chunks can be rather volatile, so just defining a
> suggested cache capacity based on that does not seem to be that ideal to
> me. Also, memory usage by the cache must be taken into account.
>
> But I agree with your points for further improvements and kindly ask you
> to open a new issue for this in our bugtracker [0].
>
> As side note: please use the PBS developer mailing list [1] for
> discussions regarding Proxmox Backup Server.
>
> Best regards,
> Chris
>
> [0] https://bugzilla.proxmox.com/
> [1] https://lore.proxmox.com/pbs-devel/
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2025-06-11 6:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-08 14:25 Kamil Trzciński
2025-06-10 7:20 ` Christian Ebner
2025-06-11 6:11 ` Kamil Trzciński [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ-UffmB96ZoEmNz9WnkaaA09J=CuWXmNrq05ORdgthseBYxZA@mail.gmail.com' \
--to=ayufan@ayufan.eu \
--cc=c.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.