[pve-devel] [PATCH v2 proxmox-backup-qemu 05/11] access: use bigger cache and LRU chunk reader

[Thomas Lamprecht]

On 03.03.21 10:56, Stefan Reiter wrote:
> Values chosen by fair dice roll, seems to be a good sweet spot on my
> machine where any less causes performance degradation but any more
> doesn't really make it go any faster.
> 
> Keep in mind that those values are per drive in an actual restore.
> 
> Signed-off-by: Stefan Reiter <s.reiter at proxmox.com>
> ---
> 
> Depends on new proxmox-backup.
> 
> v2:
> * unchanged
> 
>  src/restore.rs | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/src/restore.rs b/src/restore.rs
> index 0790d7f..a1acce4 100644
> --- a/src/restore.rs
> +++ b/src/restore.rs
> @@ -218,15 +218,16 @@ impl RestoreTask {
>  
>          let index = client.download_fixed_index(&manifest, &archive_name).await?;
>          let archive_size = index.index_bytes();
> -        let most_used = index.find_most_used_chunks(8);
> +        let most_used = index.find_most_used_chunks(16); // 64 MB most used cache



>  
>          let file_info = manifest.lookup_file_info(&archive_name)?;
>  
> -        let chunk_reader = RemoteChunkReader::new(
> +        let chunk_reader = RemoteChunkReader::new_lru_cached(
>              Arc::clone(&client),
>              self.crypt_config.clone(),
>              file_info.chunk_crypt_mode(),
>              most_used,
> +            64, // 256 MB LRU cache

how does this work with low(er) memory situations? Lots of people do not over
dimension their memory that much, and especially the need for mass-recovery could
seem to correlate with reduced resource availability (a node failed, now I need
to restore X backups on my <test/old/other-already-in-use> node, so multiple
restore jobs may run in parallel, and they all may have even multiple disks,
so tens of GiB of memory just for the cache are not that unlikely.

How is the behavior, hard failure if memory is not available? Also, some archives
may be smaller than 256 MiB (EFI disk??) so there it'd be weird to have 256 cache
and get 64 of most used chunks if that's all/more than it would actually need to
be..

There may be the reversed situation too, beefy fast node with lots of memory
and restore is used as recovery or migration but network bw/latency to PBS is not
that good - so bigger cache could be wanted.

Maybe we could get the available memory and use that as hint, I mean as memory
usage can be highly dynamic it will never be perfect, but better than just ignoring
it..

>          );
>  
>          let reader = AsyncIndexReader::new(index, chunk_reader);
>