Unsolved
This post is more than 5 years old
2 Intern
•
261 Posts
0
2492
November 7th, 2012 05:00
tweak EMCopy
hello all, I am having to run EMCopy via copy host whos network speed is terribly slow ( migrating netapp cifs to VNX ) .I am copying 4 shares all at a time , but because of the speed the increment copies are taking 6 -7 hours to complete .
Estimated copy bitrate : 12.257 KB/s
Elapsed time: hours: 05, mins: 44, secs: 26..
I am using the following syntax Is there a way I can speed up the EMCopy to some extent in this already slow moving traffic ?
emcopy64_v4.14.exe \\knx-netapp2\Shared \\knx-fs1\Shared /purge /lg /lu /s /a /r:2 /w:15 /tee /xd .snapshot .etc lost+found .ckpt /sdd /th 16 /de /o /c /preserveSIDh /secfix /log:emcopy-Shared-incremental.log
comments highly appreciated .thanks !
Peter_EMC
674 Posts
0
November 7th, 2012 05:00
depending on the type of migration:
use the /nosec switch till the last incremental copy. It will then copy only the data not the security, but this is much faster
bergec
275 Posts
0
November 7th, 2012 09:00
Notice also that if you do not specify /secfix or /nosec then permission will be applied only when file is created
Claude
deeppat
2 Intern
•
261 Posts
0
November 7th, 2012 10:00
will changing thread to /th 128 help? i do not want to use the /nosec switch at this point because the customer is doing a data /permission validation on the target shares in advance to be on the safer side before the cutover .
Rainer_EMC
6 Operator
•
8.6K Posts
0
November 7th, 2012 14:00
Depends on your copy client, the performance of the src and destination and the file size
Using too many threads can actually decrease the performance just as well
dynamox
11 Legend
•
20.4K Posts
•
87.4K Points
0
November 7th, 2012 14:00
I crank it up to 64
christopher_ime
6 Operator
•
2K Posts
0
November 17th, 2012 00:00
Just curious, are you seeing many retries and errors in the logs? Even though you are changing the retry and wait values much lower than the defaults (100 and 30 seconds respectively), it could be possible that some/much of the time may be spent (unnecessarily) retrying failed copies.
During the initial and up to the final incremental, I will at times on a case-by-case basis, consider values even lower than what you have specified and even have set them to zero. On the final incremental then I will increase the values just in case; however, since the source is made unavailable to users (or at least set to read-only), chances of retries are reduced.
Then again, ignore if you aren't seeing any indication of this in the logs.