That's a good point - these problems can have many causes including the state of the underlying operating system.
Basically, if you're in swap viewer or sim-side then it's game over for any kind of responsiveness.
OpenSimulator does record client stats information in the WebStats module. Unfortunately for historical reasons this
only records to an sqlite db and requires one to enable the web stats ajax functionality too (these functions need to be
separated). Also, OpenSimulator 0.7.3.1 contains a long-standing bug where the recording doesn't work properly for sims
with multi-regions - this is fixed in master, 0.7.3.1-post-fixes and 0.7.3.1-extended.
On 23/04/12 00:51, Dahlia Trimble wrote:
I was able to re-create the "slow get" error. In my case I had a region with
many unique textures. As my viewer was
downloading them I was apparently running short of memory and the computer
started swapping and thrashing the disk and
the viewer would momentarily freeze. During the freezes the OpenSimulator console would
show several of the "slow get"
messages. Apparently the viewer was not able to receive and process the
requested textures as fast as the simulator
wanted to send them and this is when the messages appeared. I reduced the draw
distance and graphics quality level in
the viewer and the messages stopped. Given this experience I suspect some of
the users at your parties may be having
similar viewer issues and the problem may be mitigated by suggesting they lower
their draw distance and graphics quality
settings.
I believe most viewers send information back to the simulator about memory use
and graphics performance but I'm not
aware if OpenSimulator is collecting and making these data available for
analysis.
On Sun, Apr 22, 2012 at 3:43 PM, Akira Sonoda <[email protected]
<mailto:[email protected]>> wrote:
Hi Justin,
I am still investigating the Slow GetTexture problem and the resulting
instability under high Load.
What i did so far:
1. I'm still using opensim-0007711 ( i didn't have the time to upgrade,
the first upgrade was not so good due an
error on my side and since then i did not look too much into it)
2. I've created a Windows Instance in the Amazon cloud in order to be able
to connect some profiling tools.
3. I've run the last two Friday Parties from there the first Party was
quite okay ( MaxPoolThreads=90 in the
SmartPoolThreads settings, but i saw more on peaks, strange )
4. The second party from the 20. April went crazy after 3 hours here's a
picture:
http://farm9.staticflickr.com/8017/6957771466_4412ee83c4_b_d.jpg
Most of the threads had a stack trace like this:
http://farm9.staticflickr.com/8155/6957875232_0203631ed0_b_d.jpg
Wondering why this increase started after approx 3 hours. We had at max
about 18 avies on the region/sim with
various different viewers. Because I did not attach this amazon Cloud
instance to my splunk server i have no
statistics about the viewers during the party ... i probably should do that
in future.
I will upgrade to a more recent version next week ...
Thanks a lot!
Akira
Am 19. März 2012 01:57 schrieb Justin Clark-Casey <[email protected]
<mailto:[email protected]>>:
It's quite possible the 3rd party HTTP server doesn't use the
threadpool though I've never looked in detail.
You could supply any other http address in the GetTexture cap (e.g. the
asset service directly with a suitable
handler). However, I'm not sure that asset serving is such a
bottleneck at the moment compared with scripting
and physics issues.
On 17/03/12 21:10, Dahlia Trimble wrote:
I've done a bit of tracing through the code and I can't seem to
find where the http server in OpenSimulator uses
threadpool threads. I did find them used in the LLUDP server and in
asyncronous requests from the asset
service, but I
have yet to find any other uses. is it possible that the http
server is still using system threads,
bypassing the
threadpool? I'm rather curious as I use the built-in http server in
a few personal applications and I'm
concerned about
performance.
On another note, I believe part of the impetus behind LL designing
the texture fetch capability was to allow
a separate
service from the simulator to supply assets to viewers, thereby
reducing load on the individual simulator
processes.
Perhaps this is something OpenSimulator can take advantage of?
Probably some kind of asset proxy cache could
do a much
better job of serving textures and other assets to viewers than the
existing monolithic process? I believe
it could even
be moved to a separate server with a different IP address.
On Fri, Mar 16, 2012 at 8:36 PM, Justin Clark-Casey
<[email protected]
<mailto:[email protected]> <mailto:jjustincc@googlemail.__com
<mailto:[email protected]>>> wrote:
Hi Akira. I have now updated the "show threads" method to show
threadpool statistics for the main
threadpool.
Please note that each XEngine script engine will also have
it's own threadpool (which can be seen
using the
"xengine status" command). Might need to improve this further.
"show threads" will also show all in-use threads. However, at
least on mono 2.6.7 this isn't reported by
the VM so
won't be shown.
I'm not sure whether this will help you or not in tracking down
performance issues. In some situations
it could
help (e.g. if threads are encountering deadlock the number of
'in use' threads will leap up, though
you've probably
already noticed deadlock by the long-running threads reporting
monitoring failures and the sim locking up).
So I'd be happy to hear suggestions for additional data and
I'll implement them if I can, since I think
this is
going to be a growing area of concern. Unfortunately pinning
down performance issues with a system as
complex as
OpenSimulator (with massive numbers of threads and user
generated scripts) is likely to remain a significant
challenge for the forseeable future.
On 11/03/12 19:15, Akira Sonoda wrote:
Am 10. März 2012 03:25 schrieb Justin Clark-Casey
<[email protected]
<mailto:[email protected]> <mailto:jjustincc@googlemail.__com
<mailto:[email protected]>>
<mailto:jjustincc@googlemail. <mailto:jjustincc@googlemail.>____com
<mailto:jjustincc@googlemail.__com
<mailto:[email protected]>>>>:
I'm sorry to say that you'll have to take the
ThreadPool numbers with a very very very large
pinch of salt. I
believe they only refer to the built-in mono thread
pool and not the SmartThreadPool which is
the one
actually used
(and beyond that the core simulator and xengine use
separate pools). I will try and improve
this situation
soon.
Thank you Justin!
Would be nice to have some meaningful statistics for all
those ThreadPools! Maybe there is a
possibility to
write those
statistics to the log from time to time ( e.g. every 30
seconds). Together with some documented
"best practices"
from
those who operate Sims, with lots of avatars on it - I'm
thinking mainly the OSgrid Plazas are good
references -
this
could be highly valuable information for those who operate
Sims for similar purposes ( meeting
points, parties,
concerts
etc. )
___________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
<mailto:Opensim-dev@lists.__berlios.de
<mailto:[email protected]>>
https://lists.berlios.de/____mailman/listinfo/opensim-dev
<https://lists.berlios.de/__mailman/listinfo/opensim-dev>
<https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>>
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
___________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
<mailto:Opensim-dev@lists.__berlios.de
<mailto:[email protected]>>
https://lists.berlios.de/____mailman/listinfo/opensim-dev
<https://lists.berlios.de/__mailman/listinfo/opensim-dev>
<https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>>
_________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
_________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
