Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fetching archive indexes is extremely slow - is network usage inefficient? #6121

Closed
callegar opened this issue Jan 11, 2022 · 0 comments · Fixed by #8332
Closed

Fetching archive indexes is extremely slow - is network usage inefficient? #6121

callegar opened this issue Jan 11, 2022 · 0 comments · Fixed by #8332

Comments

@callegar
Copy link

callegar commented Jan 11, 2022

For reasons outlined in the FAQs, having a client side chunk cache may be inconvenient because it can end up taking a huge amount of space wrt the client storage abilities that may be limited. Furthermore, in many situations it only rarely occurs that the local “chunks” index needs to be rebuilt. On the other hand, in these rare occasions, not having a cache means that one spends a huge amount of time fetching archive indexes.

Now, I understand that there is a space-time trade off here and that borgception is meant to relax it one day. However, I wonder if there is something that I could try until borgception arrives. Specifically, I would like to understand if the huge amount of time needed by the index fetching may be due to some unfortunate setup in my systems and could be reduced by modifying such configuration.

What strikes me is that during this fetching:

  • the client (the machine being backed up) appears to be mostly unloaded;
  • the server (the machine storing the back up) appears to be mostly unloaded too;
  • the network appears quite loaded, but so to say in an inefficient way: differently from what would happen with a large file transfer on the net, the network graphs do not go up and stay up, but appear to be made of quick bursts, so that the average download rate on the client stays relatively low (~ 250-500 kiB/s on a 5 GHz wifi network where this is substantially the only activity and the throughput could be much larger). At the same time, I see a non-negligible (some tens kB/s) upload rate from the client.

Is this expected? Is this the sign that there is something unfavourable on my setup? Is it the sign that the protocol involves lots of small transfers and bidirectional exchanges? Could something (e.g. in the protocol) be improved to better exploit the network throughput (e.g., by putting more CPU at use either on the client or the server or both in this procedure)?

Have you checked borgbackup docs, FAQ, and open Github issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

Question possibly revealing an issue/inefficiency.

System information. For client/server mode post info for both machines.

Your borg version (borg -V).

1.1.17 (both client and server)

Operating system (distribution) and version.

Ubuntu 20.04 (both client and server)

Hardware / network configuration, and filesystems used.

Client is a laptop. Server is a mini desktop. Both intel (client is way more recent and powerful, but it is my understanding that requirements on server are low). Client and server communicate via wifi (it is unfortunate that the server is temporarily on wifi too) via a wifi router/access point.
Wifi "published" connection speed is 780 Mbit/s for the client and 390 Mbit/s for the server.
Filesystem: ext 4. Client on SSD, server on rotating disk with disk on USB3 attachment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant