|Anonymous | Login | Signup for a new account||2021-10-25 06:06 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006537||opensim||[REGION] OpenSim Core||public||2013-02-09 13:22||2013-02-10 11:34|
|Platform||AMD X86_64||Operating System||Fedora Linux||Operating System Version||17|
|Product Version||master (dev code)|
|Target Version||Fixed in Version||master (dev code)|
|Summary||0006537: [PATCH] Additional ThreadPool worker and IOCP thread startup logic|
|Description||On startup, my system reported:|
2013-02-09 09:23:12,377 INFO - OpenSim.Application [OPENSIM MAIN]: Runtime gave us 600 worker threads and 24 IOCP threads
2013-02-09 09:23:12,377 INFO - OpenSim.Application [OPENSIM MAIN]: Bumping up to 500 worker threads and 1000 IOCP threads
|Steps To Reproduce||mono OpenSim.exe -physics BulletSim|
|Additional Information||I reviewed OpenSim/Region/Application/Application.cs|
There was a single check that said:
"if workerthreads < 500 OR IOCPthreads < 1000, set BOTH to a number"
From the startup log messages, you can see this bumped the IOCP threads up from 24 to 1000 which is the default used in other CLRs.
However, this also caused my system to drop from 600 starting workerthreads to 500, as an unintended side effect of the need to raise IOCP.
I split the single if/then check which set both settings into separate if/then checks for minimum and maximum bounds checking for both settings.
These two settings are closely tied to the System.Threading.ThreadPool and Microsoft has changed the default minimums several times in .NET so reasonable starting minimum and maximum values were used based on the table described in comments.
I considered whether these should be made admin-configurable in an INI file, but they were not exposed that way before now, and seemed like an easy way for an admin to accidentally get themselves into unexpected trouble.
|Tags||No tags attached.|
|Git Revision or version number||0a297a0e52b673427ff61b254f6065c217b1375d|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||Mono / Linux64|
|Viewer||Cool VL Viewer 188.8.131.52|
|Attached Files||0001-Additional-ThreadPool-worker-and-IOCP-thread-startup.patch [^] (3,807 bytes) 2013-02-09 13:22 [Show Content]|
Allen Kerensky (reporter)
|Marking patch included...|
Whether or not reducing the thread count for any given category if the default of the CLR is greater than some maximum is wise remains to be seen.
Generally, it's a beneficial patch.
Allen Kerensky (reporter)
I almost submitted it with the > max checks commented, to leave it up to wiser heads than mine.
Ultimately, commentary from a project manager in charge of ThreadPool when the defaults were being raised pushed me to leave it in.
His comment was that excessive thread counts could/would have increasing performance impacts.
I figure the note that the limit had been hit, combined with the earlier report of what the runtime defaulted to, will be the warning needed to re-assess this in the future.
Applied, Thanks for the patches.
Note: It might be good to add some config options for these later if they would be useful for tuning.
|2013-02-09 13:22||Allen Kerensky||New Issue|
|2013-02-09 13:22||Allen Kerensky||File Added: 0001-Additional-ThreadPool-worker-and-IOCP-thread-startup.patch|
|2013-02-09 13:23||Allen Kerensky||Note Added: 0023554|
|2013-02-09 13:23||Allen Kerensky||Status||new => patch included|
|2013-02-09 15:07||melanie||Note Added: 0023559|
|2013-02-09 15:56||Allen Kerensky||Note Added: 0023561|
|2013-02-10 11:34||BlueWall||Note Added: 0023566|
|2013-02-10 11:34||BlueWall||Status||patch included => resolved|
|2013-02-10 11:34||BlueWall||Fixed in Version||=> master (dev code)|
|2013-02-10 11:34||BlueWall||Resolution||open => fixed|
|2013-02-10 11:34||BlueWall||Assigned To||=> BlueWall|
|2013-02-10 11:34||BlueWall||Status||resolved => closed|
|Copyright © 2000 - 2012 MantisBT Group|