mirror of
https://git.proxmox.com/git/proxmox-backup
synced 2025-08-12 10:52:09 +00:00
320ea1cdb7
Using a single thread for reading is not optimal in some cases, e.g. when the underlying storage can handle reads from multiple threads in parallel. We use the ParallelHandler to handle the actual reads. Make the sync_channel buffer size depend on the number of threads so we have space for two chunks per thread. (But keep the minimum to 3 like before). How this impacts the backup speed largely depends on the underlying storage and how the backup is laid out on it. I benchmarked the following setups: * Setup A: relatively spread out backup on a virtualized pbs on single HDDs * Setup B: mostly sequential chunks on a virtualized pbs on single HDDs * Setup C: backup on virtualized pbs on a fast NVME * Setup D: backup on bare metal pbs with ZFS in a RAID10 with 6 HDDs and 2 fast special devices in a mirror (values are reported in MB/s as seen in the task log, caches were cleared between runs, backups were bigger than the memory available) setup 1 thread 2 threads 4 threads 8 threads A 55 70 80 95 B 110 89 100 108 C 294 294 294 294 D 118 180 300 300 So there are cases where multiple read threads speed up the tape backup (dramatically). On the other hand there are situations where reading from a single thread is actually faster, probably because we can read from the HDD sequentially. I left the default value of '1' to not change the default behavior. Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> [TL: update comment about mpsc buffer size for clarity and drop commented-out debug-code] Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> |
||
|---|---|---|
| .. | ||
| ChangerEdit.js | ||
| DriveEdit.js | ||
| EncryptionEdit.js | ||
| Erase.js | ||
| LabelMedia.js | ||
| MediaRemoveWindow.js | ||
| PoolEdit.js | ||
| TapeBackup.js | ||
| TapeBackupJob.js | ||
| TapeRestore.js | ||