Performance
From OpenSimulator
(→Performance studies) |
(→Performance studies) |
||
| Line 9: | Line 9: | ||
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSim. Some of these issues are still valid (e.g. ODE issues). | * [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSim. Some of these issues are still valid (e.g. ODE issues). | ||
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate. | * [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate. | ||
| + | * [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse). | ||
==Specific performance hints== | ==Specific performance hints== | ||
Revision as of 15:22, 24 August 2010
Contents |
Introduction
OpenSim performance is a very complex issue. Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.
Performance studies
- Improving Performance - An old page from July 2009 detailing some performance issues on OpenSim. Some of these issues are still valid (e.g. ODE issues).
- NHibernate Performance Testing — SQLite and MySQL performance tests with NHibernate.
- LibSecondLife performance problems - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).
Specific performance hints
Here are some specific things you might be able to do to improve performance
Running Squid on your region server as a reverse proxy to the asset server
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/
2. Create your squid.conf configuration file.
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/
4. Start everything up!
Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.
GC_NO_EXPLICIT
Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.
$mono-svn-root$/mono
mono/metadata/boehm-gc.c
Index: boehm-gc.c
===================================================================
--- boehm-gc.c (revision 105684)
+++ boehm-gc.c (working copy)
@@ -107,6 +107,10 @@
void
mono_gc_collect (int generation)
{
+ static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv("GC_NO_EXPLICIT")) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {
+ g_print("\n --------GC_NO_EXPLICIT \n");
+ return;
+ }
MONO_PROBE_GC_BEGIN (generation);
GC_gcollect ();
Not only this, but I recompile the mono runtime:
--with-large-heap=yes
Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:
export GC_NO_EXPLICIT=1
and
unset GC_NO_EXPLICIT
What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (>3GB), it is possible might keep mono less apt to do stop world complete collections as often.
