-
Notifications
You must be signed in to change notification settings - Fork 212
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
[Question] Slow performance of sync - Local File to Blob #81
Comments
From the copy log. As you see very slow response times per file checked..
|
Hi @Kapanther, thanks for reaching! To clarify, you said that it took a long time for the job to start. How did you observe this? Was it low throughput? And also, how many files did you have? |
~10000 files. 1.4GB. An azure copy took less than 2 minutes. Basically azcopy accepts the command and prints nothing for about 30 minutes. How can i check if low throughput is a problem? throughput = files/sec? I posted the log above |
Hi @Kapanther, thanks for the additional info! Just to confirm, this is a reproducible problem, right? @prjain-msft could you help to confirm this behavior? |
Hey Kapanther, |
Well i tested two scenarios. The local file empty and the blob empty. (definitely reproducible) When syncing from the localfile to blob (with blob empty) it took 31 mins before the job even started. But syncing back down to the local file from the blob was lightning fast. see below. 10000 files on local file (source) – empty on blob (destination) - 31mins to start job seems like its taking a long time to queue the transfer to the blob when syncing, |
Hi Kapanther, |
Localfile to Azure Command
Azure to Localfile Command
|
Hi Kapanther, |
C:/gcds_dev is a directory.. This is a blob.. no virtual folder. It goes straight into the root. |
Compare to gsutil sync the azcopy sync performance are really very bad. Using macOS Mojave. Related to slow performance extra observations:
|
Hi @VelizarVESSELINOV, thanks for the feedbacks! We are actively working on this tool to improve the performance. To clarify, we do perform concurrent operations and chunk up large files. What were the failures that you saw? |
Hi @zezha-msft, thanks for the quick answer. In my process explorer, I saw a lot of threads running but the CPU usage was limited. Are there an option to control parallel execution or not, maybe the user interface is not showing enough what is currently done in parallel and/or chunked. For failures, I have often this error
The CPU is often low (3%), but obviously using a lot of some resources so few minutes after start execution VSCode and other applications switch to not responding mode, which is annoying. |
@VelizarVESSELINOV take into account sync is a new feature thats only "in preview" right now. The guys are still testing it and optimizing its performance. This thread is focused on an issue with the sync command's initial comparison between source and destination been slow. Not the file transfer operation itself. Can i suggest you post issues with multi threading performance as a separate issue? |
Hi @VelizarVESSELINOV, which command were you running exactly? Was it If you don't mind, please open up a new issue and fill out the issue template so that we can have a bit more info. Thanks! The concurrency is indeed configurable, please refer to this guide. Our ultimate goal is to adjust the concurrency based on the environment&network; we are still working on this. |
Hi @Kapanther |
@prjain-msft
I guess I will leave it for you guys to interrogate, when you get a chance. In the mean time I'll use Rclone and see if i get similar results. |
@zezha-msft the answer to your question is Eventually, I will open a new ticket, for now, stopped using The default |
Hi @VelizarVESSELINOV, thanks for your feedbacks. To clarify though, if you only wanted to copy files, you should use the |
Hi @Kapanther, @prjain-msft has improved the sync command's performance significantly. Could you please give it another try? Thank you!! |
@zezha-msft and @prjain-msft .. jsut got back from holidays.. will check now... im excited |
@zezha-msft and @prjain-msft .. holy crap guys.. azcopy sync must now be using weapons grade plutonium.. because that is FAST! what was taking about 2 minutes before is taking less than a second. Using that 10.0.0,5 preview... |
Consider this issue closed!! |
V10.0.2 Preview - Win 7
.\azcopy sync "C:\GCDS_dev" "https://azgcdsdevst1.blob.core.windows.net/gcdstest2?--Key Retracted--" --recursive
When syncing larger amounts of data >1GB (local file to Blob) sync seems to take a long time to even prep the job. (i.e syncing 1.4gb of data seems to take greater than 30 mins to even srart the job)
While copy function seems to start almost straight away.
I know the sync command obviously has some file comparison work to do before it can do anything, but it still seems extraordinarily slow to begin.
Any idea what could be causing delay?
Is it possible to report file conflict check progress to the command line with a flag?
The text was updated successfully, but these errors were encountered: