large amount of tasks = boinc and boincmgr hogging all CPU time

boinc taking up 50% of resource share

Boinc manager with list of large tasks taking up 50% of CPU time.

Task manager after removing 90% of tasks.

This also can cause BOINC and the BOINC manager to become completely unresponsive.

Well, that's a huge list of tasks! It would need some profiling to know what piece of code is being the bottleneck.

An idea:

• Add a GUI RPC to get details of a single result (or better: a specific list of results).
• Make the manager update every second only the results in "Running" state, and refresh the whole list using get_results on longer periods, like every 10 seconds.

If a new manager connects to an old client not supporting the RPC, it should notice the RPC is missing and avoid it. After connection, the first time the manager refreshes the result list, try the new RPC. If it fails with "RPC unrecognized", fallback to the current method of getting all results every second, and don't retry the new RPC during the rest of that connection.

An addition to my previous suggestion: because of the way the <get_results> tag is parsed, we don't really need a new RPC. Just more parameters to the existing RPC. It would be even better from a backwards compatibility standpoint. Sending an RPC like the following:

<boinc_gui_rpc_request>
<get_results>
<filter>scheduler_state eq 2</filter>
</get_results>
</boinc_gui_rpc_request>

currently sends back the whole list of results without any error. A future version of the client could actually parse that tag to send only results that match the expression, and a future manager could take advantage of it, without any compat. problem. If the manager sends a filter, but gets the full list anyway, no problem, just update whole list on the GUI as it does now.

Probably such a generic <filter> expression is too complex to implement. That's just an example; any filter syntax would work.

I just did some profiling of the manager. Unfortunately I don't have access to a client with more than 5 results at the moment, therefore I did not profile in the same situation described here.

However, my first results show that a lot of CPU time is used for memory management and string manipulation. Most of this seems to come from internal wxWidgets functions. A particular function of the manager than seems to be expensive is RESULT::parse in gui_rpc_client_ops.C. This would be consistent with the observation described in this ticket. Unfortunately I don't see any easy way to optimise this function, except Nicolas'. But this seems to be a quite big change to the manager and the core client.

I think I will run another profiling session as soon as I am able to persuade my core client to fetch a larger amount of work.

Another solution came to my mind: What about turning the static refresh frequency into a dynamic one? The delay between two refresh-cycles could be proportional to the number of results (or more abstract: proportional to the number of elements in the current view). That should help to keep the CPU usage of the core client and the manager on a constant low level.

If there are no objections against this proposal I would like to write a patch for it.

Patch implementing the dynamic refresh rate