[Opensim-dev] Threads, threads, threads and more threads

[Teravus Ovares]

On a side note,

If I did attempt to do this, I'd definately want to tag a stable
before I started..   or else there will be chaos :)

Best Regards

Teravus

On Thu, Jul 30, 2009 at 10:44 PM, Nebadon Izumi<nebadon2025 at gmail.com> wrote:
> Sort of a side note on this topic, we still have child agents rezzing as
> Root agents in the region your in..  since you poking around in this area
> you might see if you can take notice at to why this is happening, if you do
> not have a telehub installed you might not notice all child agents that are
> rezzing in your region up around 128/128/100..  These avatars seem to effect
> the physics scene as well.  no doubt generating even more threads.
>
> Neb
>
> On Thu, Jul 30, 2009 at 7:35 PM, Teravus Ovares <teravus at gmail.com> wrote:
>>
>> Hey there
>>
>> I was just thinking..    does the child agent of an avatar actually
>> /need/ a full thread?    I ask this because we're running up against
>> the default thread limits of mono in situations where an instance is
>> servicing your root agent and 8 additional child regions.     The
>> LongPoll fix took the number of threads down by almost half, but,
>> we've still got a lot more work to do to make it reasonable.     Would
>> anyone object to having child agent worker threads that process more
>> then one client on the LLUDP side?     This would reduce thread usage
>> by at least 1/3rd over top of the savings that we already have from
>> the long poll fix.    I also note that textures are always served from
>> the region the avatar is a root agent in..  including textures in
>> neighbor regions that the avatar sees into.
>>
>> A Scenario:
>>
>> An instance serves a 9 gridspace set of regions.  The avatar logs into
>> the middle one and creates 1 root agent and 8 child agents on the
>> instance.
>> --------
>> Before the LongPoll fix:
>>
>> Each avatar created 9 threads for LLUDP processing, 9 threads stuck in
>> eventqueue processing, and several timer/threadpool threads.   This
>> added up 'really' fast.
>> For example..     at 14 users, there were 252 threads(14 root, 112
>> child, and 126 in eventqueue) in use processing the udp stack and the
>> eventqueue of the users.
>>
>> -----------
>> After the LongPoll fix:
>>
>> Each avatar creates 9 threads for LLUDP processing.  There are a total
>> of 4 threads dedicated to eventqueue processing total.
>> For example..   at 14 users, there are 130 threads(14 root, 112 child,
>> 4 in eventqueue) in use processing the udp stack and the eventqueue of
>> the users.
>>
>> ------------
>> If we set up worker threads for child agents:
>>
>> Each avatar creates 1 thread for LLUDP processing, There are a total
>> of 4 threads dedicated to eventqueue processing.  And, there are (for
>> this example, we'll say 2 threads per region to process child agents),
>> 18 threads to process child agents.
>> For example..   at 14 users, that's 36 threads in use processing the
>> udp stack and the eventqueue of the users.
>> ----------
>>
>> Can anyone think of issues with doing this?     I would /really/ love
>> to reduce the thread usage down to 'reasonable' levels here.   36
>> threads is WAY less then 252 threads!
>>
>> Regards
>>
>> Teravus
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> --
> Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>