Tape Backup very slow with more than 1 thread

[Tesla2k]

Hello,
I tried doing tape backups with more than one thread. But it did dramatically decrase the speed. Datastore is ZFS on SSDs, PBS Version 3.4.1
(I stay with 1 thread, just wanted to report this behavoir, though it seems odd to me)

1 Thread:

2025-04-30T11:19:16+02:00: Starting tape backup job 'Test:Quarterly:LTO6:Test'
2025-04-30T11:19:16+02:00: update media online status
2025-04-30T11:19:16+02:00: media set uuid: 15817fb1-744c-4b61-938c-799314318131
2025-04-30T11:19:16+02:00: found 1 groups (out of 1 total)
2025-04-30T11:19:16+02:00: backup snapshot "ct/125/2025-04-30T09:03:32Z"
2025-04-30T11:19:16+02:00: allocated new writable media 'Q2-1'
2025-04-30T11:19:16+02:00: Checking for media 'Q2-1' in drive 'LTO6'
2025-04-30T11:20:48+02:00: found media label Q2-1 (d207dc28-4638-4519-b2e6-62c651cc8cfd)
2025-04-30T11:20:48+02:00: moving to end of media
2025-04-30T11:22:16+02:00: arrived at end of media
2025-04-30T11:22:49+02:00: wrote 1126 chunks (3580.62 MB at 109.84 MB/s)
2025-04-30T11:22:49+02:00: end backup Test:"ct/125/2025-04-30T09:03:32Z"
2025-04-30T11:22:49+02:00: percentage done: 100.00% (1/1 snapshots)
2025-04-30T11:22:56+02:00: append media catalog
2025-04-30T11:22:57+02:00: queued notification (id=959711d9-1bdd-4f92-8e01-7429a9431746)
2025-04-30T11:22:57+02:00: TASK OK

2 Threads. (Aborted after the first chunk)

2025-04-30T11:09:49+02:00: Starting tape backup job 'Test:Quarterly:LTO6:Test'
2025-04-30T11:09:49+02:00: update media online status
2025-04-30T11:09:49+02:00: media set uuid: 15817fb1-744c-4b61-938c-799314318131
2025-04-30T11:09:49+02:00: found 1 groups (out of 1 total)
2025-04-30T11:09:49+02:00: backup snapshot "ct/125/2025-04-30T09:03:32Z"
2025-04-30T11:09:49+02:00: allocated new writable media 'Q2-1'
2025-04-30T11:09:49+02:00: Checking for media 'Q2-1' in drive 'LTO6'
2025-04-30T11:11:06+02:00: found media label Q2-1 (d207dc28-4638-4519-b2e6-62c651cc8cfd)
2025-04-30T11:11:06+02:00: moving to end of media
2025-04-30T11:13:34+02:00: arrived at end of media
2025-04-30T11:18:48+02:00: wrote 1126 chunks (3580.62 MB at 11.39 MB/s)
2025-04-30T11:18:49+02:00: queued notification (id=45b56d9c-c1ff-4288-b814-83f2bf90d0e4)
2025-04-30T11:18:49+02:00: TASK ERROR: abort requested - aborting task

 

[dcsapak]

Hi,

just to make sure: the base load of the system was the same during the two tests? (so no garbage collect/verify/sync/backup running ?)

but yes, I can imagine that depending on the cpu/disk adding more thread to a possibly already loaded system will make things worse, that's one of the reasons why it's configurable and the default is 1

Would be interesting to see the cpu/io pressure during those two backup runs, but it would be only to satisfy my curiosity

thanks anyway for the report!