none
Azcopy: The client could not finish the operation within specified timeout

    Question

  • I've been trying Azcopy 3.1.0 (and later 4.1.0) to copy a roughly 2.5GB file up to Azure. I know the command is sound, since it works for a few smaller files I've tried.

    Azcopy starts uploading but then quits within several minutes. Anywhere from 20-30 minutes later (once close to two hours), the command prompt is returned with news of the timeout. The sum total of useful information in the log is:

    Transfer FAILED: ... The client could not finish the operation within specified timeout

    The command is (changed for the forum):

    azcopy /source:"c:\dir" /Dest:https://fdf43434fdfdfdfd.blob.core.windows.net/ingestiondata/20150710 /DestKey:fdfdfdfdfdfdfdfd5454554== /Pattern:"*.pst" /S /V:"c:\dir\azure.log"

    While my UL is only 1Mb/s, it's solid, so while slow I don't see why a timeout would happen repeatedly like this (again, it works for small files).  Anything to be done to make Azcopy more resilient, or any other way around this?

    Sunday, July 12, 2015 12:42 AM

Answers

  • AzCopy default will use 8*core threads to transfer data.

    But for this scenario, the connection speed is  too low (1 Mb/s), so big threads count will cause part of the threads fail to connect to server.

    I would suggest use /nc:[thread count] parameter to decrease the thread count, such as /nc:2.

    Then the issue might not repro.

    Thanks!

    • Marked as answer by rseiler Thursday, July 16, 2015 3:40 AM
    Thursday, July 16, 2015 3:26 AM

All replies

  • Hi,

    Thanks for reaching out to us!

    Within a Windows Azure datacenter (i.e., between a compute instance and a storage account within the same DC), users should be able to achieve 50MB/s upload and download speed for uploading and downloading large amounts of data using an extra-large compute instance. Transfers to and from a Windows Azure datacenter will be constrained by the bandwidth available to AzCopy.

    Sometimes, the upload/download my be interrupted or time-out, especially if transferring a large file that takes hours or days. A timed-out transfer may produce output like: 

    e:\vhd\v2012R2-AZ1-v2012R2-AZ1-0906-2b.vhd: The client could not finish the operation within specified timeout.
    To resume the transfer, just run the same .\azCopy.exe command or use a script as shown here.

    Also, you might want to increase the default timeout from 90 sec to 600 sec or so which might be helpful.

    Refer :http://blogs.msdn.com/b/avkashchauhan/archive/2011/02/22/handling-quot-an-unexpected-error-occurred-server-operation-did-not-finish-within-user-specified-timeout-90-seconds-quot-with-csupload-in-windows-azure-vm-role.aspx

    Hope this helps!


    Best Regards

    Sadiqh Ahmed

    ________________________________________________________________________________________________________________

    If a post answers your question, please click Mark As Answer on that post and Vote as Helpful.

    Sunday, July 12, 2015 3:25 AM
    Moderator
  • That link is for an old program called CSUPLOAD, not Azcopy.

    I did try restarting Azcopy any number of times, but it just wouldn't go for long at all (in other words, there was very little accomplished that could be resumed).

    Yes, no doubt Azure datacenter is capable of high speeds, but the question here is what minimum speed Azcopy needs, particularly given that it seems to massively multithread the upload.

    I found a 5Mb/s connection instead of 1Mb/s connection, and it worked fine there, luckily.

    The 1Mb/s connection is a good connection, however, as I've used it for any number of extensive FTP and HTTP uploads (one immediately after I gave up on Azcopy).  Azcopy apparently require a faster connection though, which makes it unique among the services that I've tried.

    Monday, July 13, 2015 12:05 AM
  • AzCopy default will use 8*core threads to transfer data.

    But for this scenario, the connection speed is  too low (1 Mb/s), so big threads count will cause part of the threads fail to connect to server.

    I would suggest use /nc:[thread count] parameter to decrease the thread count, such as /nc:2.

    Then the issue might not repro.

    Thanks!

    • Marked as answer by rseiler Thursday, July 16, 2015 3:40 AM
    Thursday, July 16, 2015 3:26 AM
  • Yes, I have no doubt that will fix it. Somehow, I completely forgot to explore other available  switches. Thanks.
    Thursday, July 16, 2015 3:40 AM