Copy File/Folder Crashes When Selecting Too Many Hosts

[jsira7]

Hello… I need to copy numerous files down to approx. 100 desktops from a file share. It appears that I can only do up to 6-8 at a time before Batch Patch crashes. I have increased the resources on the server Batch Patch is running on, but it still crashes. It displays Not Responding about a minute or 2 after I start the job. Any ideas? Here’s the specs of the server Batch Patch is running on:

OS: Server 2012 VM

RAM: 12GB

Procs: 4

Space: 80GB

[doug]

In ‘Tools > Settings > General > Miscellaneous’ there is a setting called ‘Concurrent File-Copy Operations Maximum.’ The default value for this is 6. What do you have yours set to?

I would not recommend raising the default value by very much above 6. This value controls how many rows BatchPatch will execute a file copy for simultaneously. If the value is set to 6 and then you highlight 100 rows to execute a file copy, 94 of the rows should immediately go to a status of ‘Queued’ while the first 6 copies execute. Each time one of the executing 6 copies completes, one of the remaining 94 will begin executing. If you set the value too high then you run the risk of causing the app to hang. Also, setting the value very high won’t necessarily speed things up. Having more copies running concurrently will mean that each copy runs more slowly than if you had less copies running concurrently.

If BatchPatch stops responding, I would leave it until it starts responding again. Don’t kill the app. If you leave it be, it will continue working, even if it’s too overloaded to update the GUI successfully.

-Doug

[jsira7]

Thanks for the quick reply… I currently have 6 set. Should I reduce it to 5?

[jsira7]

I went ahead and changed it to 5 and selected about 20 systems. It started copying and almost went immediately to Not Responding. I will do as you suggested and not kill it and check back after some time.

[doug]

Hmmm. That’s definitely a bit strange. I don’t think you necessarily need to reduce it to 5. The “not responding” that you are experiencing sounds like it’s not related to the actual concurrent file copies. The “not responding” might instead just be occurring while BatchPatch is going through the queueing process for the systems. “Not responding” typically only really occurs when BatchPatch is writing to the grid. It’s the interface thread that gets backed up and causes “not responding” to occur. We have gone through great lengths to code BP so that the interface thread is left as free as possible, but there are certain times where it unavoidably gets a bit clogged up. What you’re seeing, however, sounds odd. It’s certainly not expected. I think for now it makes sense to just leave it be. Let it go for a minute (or longer) and see what happens. I suspect it should go back to responding quite quickly, but let me know what happens.

Thanks,

Doug

[jsira7]

Thanks Doug… As of right now it still states as Not Responding. It’s been about 10 minutes. Should I let it go or kill it and reduce the number of targets?

[doug]

Very peculiar. The ‘Concurrent File-Copy Operations Maximum’ is likely *not* the issue here.

First, I would monitor the target systems. Are they getting the files copies even though BP appears “not responding” ? You can also monitor the network connection on the BP computer to see if BP is actually copying. I suspect it *is* actually copying. If it’s copying, then you might as well let it go to completion, but that’s up to you.

Even though I don’t think the issue is related to the number of concurrent file copies, I think it’s worth setting the value to 1 and then testing to see what happens.

Also, how big is the file the you are copying?

What happens if you put the that file on the BP computer instead of on a network share? Does anything change when you execute the copy using the BP computer as the source instead of the network share?

[jsira7]

So I let it go and it looked like it completed. hanks for that advice 🙂

I always copy the files to Batch Patch before I deploy.

[Author]

Posts