Patch resolving the "bug".
SMW_refreshData.php takes a delay parameter that is supposed to slow the progress of the refresh for each SMW ID. However, for some reason the delay time is multiplied by 100 and then applied only for blocks of 100 ID's. That causes 100% server load while the 100 ID's are being processed, even while idle. In most cases we tested, it caused otherwise idle servers to be sluggish to respond to even a single HTTP request.
If other refresh operations are in progress, or the MediaWiki job queue is running, the problem can compound until the server grinds to a halt, and the refresh on the block of 100 ID's never completes. Then, the server won't even respond to SSH connection attempts for a reboot command, and it must be manually power-cycled. This was tested on a variety of servers. We tested a 2.5 GHz dual-core server with 8 GB RAM before we realized it was a flaw in SMW, not the server.
I don't know why the code prevents the delay from applying to each SMW ID, and the comments do not explain. The fix was simple, and I have attached a patch. This is my first patch, so go easy on me if something isn't correct. It appears my text editor removed some superfluous white space too, but that shouldn't matter.
I tested my changes on SMW 1.7.0.2, but supplied a patch for the version of SMW_refreshData.php that is included in SMW 1.7.1. We haven't upgraded to test 1.7.1 yet, but these changes are so trivial, I doubt they would make any difference. It appears SMW_refreshData.php has no changes in SMW 1.7.1 that would produce different results from what we tested.
Version: unspecified
Severity: critical
Attached: