"Batchpatch.exe" 100% CPU usage during copy of "WsusScn2.cab"

[booster]

Hi folks,

When checking the targets for update, first a copy of the file “WsusScn2.cab” is copied on servers. At this time, the CPU usage of the server hosting the BP application is constantly at 100% CPU. The minimum target number I tried with is 4. Nothing comparable

during the copy of the KB on the host (cached+offline mode enabled).

The exact moment when the problem appears is during the action “Copying WsusScn2.cab file from local cache to target working directory”. I have the last BP version

The BP server itself has 4 CPU’s (tried with 2,6, same thing), the process involved is “Batchpatch.exe”

Is is a normal behaviour? The server becomes almost unresponsive at this time, creating a issue feeling for the operator

Regards

Booster

[doug]

Thank you for making us aware of this issue. We are looking into it. I will report back here when I have more information.

For the time being it seems that limiting the concurrent file copies to just 1 will prevent this from happening. See ‘Tools > Settings > General > Concurrent File-Copy Operations Maximum.’ Setting this value to 1 should both prevent the CPU from pegging at 100% and also dramatically speed up the copy. The overall benefit should be positive, even though less concurrent copies are taking place.

Thanks,

Doug

[booster]

Hi Doug,

I guess this setting limits the concurrent copies in cached+offline mode enabled (KB copies to targets)? I will try to play with the setting a bit

The odd part is it never occur during the KB copies to targets. Only during the WsusScn2.cab. I tested during a copy of for about 60 KB to 4 targets, the problem never appeared.

Regards

Booster

[doug]

Yes, the setting will limit the number of rows that can copy files simultaneously from the BatchPatch computer to the target computer. This applies to cached mode as well as for software deployments.

The reason you don’t experience the issue with the KB copies is because we use a different underlying method for the WsusScn2.cab file copy. We are able to reproduce the problem that you encountered. As soon as there is more than one WsusScn2.cab copy happening, the CPU hits 100% and the copy rate decreases drastically by 100x!

We have isolated the cause of the problem, and we expect to have it fixed in the next release of the software. In the meantime, I think your best bet is to set the concurrent copies to 1. Even though it will only do one copy at a time, the overall copy rate should still be much faster. Also, once you’ve done one check for updates using the latest WsusScn2.cab file, BatchPatch will not re-copy that file to targets until Microsoft releases a new WsusScn2.cab file. So, after the first run, you could switch the concurrent file copies value back to 6, if you want, so that the KB files can be copied simultaneously to more than 1 host.

-Doug

[booster]

Hi Doug,

thanks for the explanations, I’ll proceed your way up to the next release.

Regards

Booster

[booster]

Hi Doug,

A small update about this topic: “Settings > General > Concurrent File-Copy Operations Maximum.’ Setting this value to 1” does not make any change on the 100% CPU problem. I change it, rebooted the server (and BP so), and the copies start on multiple servers at a time what ever the set value.

Following my tests changing this value does not affect the behaviour, 100% only for this steps then all fine

Regards

Booster

[doug]

Thanks for the update. This setting does not require a reboot or a restart of BatchPatch. I’m not sure how it’s possible that the concurrent file copy maximum is being ignored for you. I could certainly believe that the CPU is still spiking even with just one file copy taking place (my CPU still spikes but only to about 12% with 1 active copy, so it’s possible that yours still spikes to 100%), but I can’t figure out how it’s possible that the setting is being ignored and more than one row is executing the wsusscn2.cab copy at the same time even while the concurrent file copy maximum is set to 1. What *should* happen is only one row copies while all other rows say “queued file copy” or similar. Then when the first row finishes copying, the next row begins, and so on. In any case, we have fixed the CPU utilization issue. It should be published within the next month or two.

-Doug

[booster]

Hi Doug,

I restarted the BP server for this purpose: the setting seems to be ignored, the full reboot was not a problem so I proceeded. When starting the checks, I don’t see 1 copy+ all the other with “queued” status but well at least 10 copies (hard to catch during the process). However it will no more hurt my setup when the new update will come.

Thanks for the support/update

Regards

Booster

[doug]

We published an update today (2015-02-10) that should resolve this issue.

-Doug

[booster]

hi Doug,

I confirm it’s solved.

thank you!

booster

[Author]

Posts