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<[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > -- > Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
