-
Notifications
You must be signed in to change notification settings - Fork 340
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
bug: restoring from gdrive on gui: rate limit exceeded with 64 threads #123
Comments
Error 403 should be retried. Sorry, just found out the FindChunk function doesn't retry on any error at all -- will fix that. |
waiting for the fix. will close after it's fixed and i can restore properly (and yes, need more than 30 threads to fill up my 1Gbit connection). |
I was wrong. Although FindChunk doesn't retry, it calls listByName which does retry. So I think the issue could be that the maximum number of retries (8) had been reached and the 403 error was returned as it was. Can you try to run the CLI version from the command line to see if this is the case? I'll run my own tests too. |
I ran in cmd, and i can say that the rate limiting happens only sometimes there. It's rather inconsistent. |
With 64 threads i also got 403 during backup, not only restore
|
It failed (during backup) even with 24 threads:
|
'-d' instead of '-v' will show retry messages. |
Restore with 24 threads of linux kernel source. Look at the speed there :(.
|
It's a Google issue really isn't it, read how you can possibly solve it on their api page: Here. Although I guess it would be good if Duplicacy could deal with this problem somehow. |
Unsure if it's a google issue. In the API docs it just sais that google doesn't want to be DOSed which i can totally agree. Either way i feel duplicacy should handle this gracefully, no matter whose (english: is it just whos?) fault is. |
|
I agree if Duplicacy could deal with the error and retry. There are 3 quotas I think for Google Drive, the likely one you are hitting is the per user one which for me is: 1000 Queries per 100 seconds per user. I would presume Duplicacy would need to ensure it didn't use more than that, not sure if this limit can be changed in the Google Drive API. |
From what i know, a user can request for a specific project/licence to have said limits increased, and google will check (afaik this raises some questions on usage -- maybe some other code enhancements will come out) whether they want to increase the limit. @gilbertchen wanna check this? |
There is a bug in the GCD backend -- the variable backoff is shared by all threads so it will reach the maximum too quickly (that is why the backoffs were all less than 1 second in your log). I also found out the web page to request more quotas. This is definitely needed, as 100 queries per 100 seconds means only 500 chunks per 100 seconds which is about 20MB/s. |
This is fixed by 6f70b37. Let me know if you need a Windows binary. |
Please giver me one, so i can test this. |
Note: is this fixed both for backups and restores? |
this is the Windows binary: https://acrosync.com/duplicacy/duplicacy_win_x64_2.0.8a.exe Yes, both backup and restore are fixed. |
I think google really doesn't like me:
This is backup with 128 threads however, so i may be of fault here. With 64 threads however i did not get any 403s either on up or down. Do you want to check 128? or that is not a normal value? |
And of course i talked too soon: with 64, (and 40, 32) threads i still got 403:
|
Also: i got 403 while restoring revision 1, and doing backup 2, both with 32 threads, on the same VM, in 2 different folders (and cmd-s). This means that if i am backing up from multiple PCs in my house at night, i could get 403 for each, and my backups won't finish? |
Are you sure you gave me the right version? , there seems to be no difference. |
I'm pretty sure I did. If you turn on the -d option you should be able to see more retry messages and it may take a few minutes for it to finally give up and return the error. |
There are more messages now, i did see that. Here's an example of retries:
|
64 threads, upload in clean folder (everything deleted in gdrive)
I see there an 11 second wait time. Is that why the transfer failed? What i am thinking (i could be wrong) is that maybe google tracks all the threads somehow? And that when a thread gets a 403, some others will also get, and maybe in that case we should delay all the threads/requests with 0.1-0.5s (more?) instead of retrying so hard? Somehow serialize the threads, so that each one starts a new upload/download request 0.5 seconds after the previous one started? In other lines: can't you just increase the timeout even more? (lets say 100 seconds of wait before failing? Another request: in the debug (-d) log could you also print the number of the thread which does whichever task it does? (for example this way we could see because of which thread the transfer has died, and which was its last wait time/which was the total wait time, etc). Could that help us debugging? |
Facing the same issue:
|
I'll have some time next week to work on GCD improvements. |
May I close this as it seems that google rate limiting is just too much of a beast with all its hidden rate limiting? |
You can close this issue for now. I'll try to contact Google to see if they can increase the rate limits for Duplicacy. |
Nice to hear. Hope they will accept it! |
I'm assuming this hasn't happened because it's still really easy to run into this rate limit https://forum.duplicacy.com/t/googleapi-error-403-user-rate-limit-exceeded-userratelimitexceeded-maximum-number-of-retries-reached-backoff-64-attempts-15/2500. What I'm curious about is if @gilbertchen would be open to implementing the Google Cloud Platform Drive v3 API, as it seems to have much more relaxed limits. |
I was testing the gui version (2.0.8) in a vm, trying to restore with 64 threads some 20+ GB of stuff, 30k folders, 77k files (linux kernel, photos, videos + duplicates of those -- all the general file sizes), and a few minutes after starting restore i got an error about rate limit exceeded, and the restore stopped.
"error failed to find the chuck : googleapi: error 403: user rate limit exceeded, userRateLimitExceeded."
From what i remembered this error was fixed in 2.0.6, right?
The text was updated successfully, but these errors were encountered: