Performance

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(Hardware Requirements)
(Add Opensim version for Condensation Land, correct some typos, add a link.)
Line 82: Line 82:
 
|Home machine
 
|Home machine
 
|Windows XP SP3
 
|Windows XP SP3
|Unknown
+
|Diva r13558
|3GB / 30-40% incl. Opensim and MySQL
+
|3GB / 15-40% incl. Opensim and MySQL
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-3%
+
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%
 
|11 regions
 
|11 regions
 
|1-6 users
 
|1-6 users
 
|Many scripted objects (1934 scripts)
 
|Many scripted objects (1934 scripts)
|@condensationland.com
+
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ @condensationland.com]
 
|38,065 prims
 
|38,065 prims
 
|}
 
|}

Revision as of 01:44, 26 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.

Hardware Requirements

Unfortunately, this is a very difficult question in light of all the factors mentioned above. Below are some examples of hardware people use/have used. Please feel free to add to the list, or to add any reports to the performance studies and blog posts section. These are examples to help you in your selection, not necessarily recommendations.

Object Parts ~= # prim

Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.

Description Operating System (please add Mono version if appropriate) OpenSim version RAM/AVG_USE_% CPU #/type of regions # simultaneous avs #scripts/timers/Sensors Location #objectparts
hosted Xen VPS Ubuntu Intrepid (8.10) Unknown 540MB/? 1x quad-core 2.5GHz Xeon (L5420) 1 region + 9 voids generally 1-2 few Knifejaw Atoll & surrounding on OSGrid ?
hosted Xen VPS Ubuntu Jaunty (9.04) Unknown 360MB/? 2x dual-core 2.0GHz Xeon (5130) 1 void generally 1-2 none Knifejaw Road on OSGrid ?
Dedicated Server from A+ Windows Server 2003 Unknown 1 Meg 1x single-core 2.8GHz Celeron 2regions per server 6 at once with no issues Waterfalls, texture anims, window texture switchers, lots of sound loops Pleasure Planet Welcome center & Region Pleasure Planet in OSGrid 20000 prims per region
Amazon EC2 "high-CPU medium instance" (Xen VM) Windows Server 2003 Unknown 1.7GB 1x dual-core 2.3GHz (Intel E5345) 1 region with sailing race course 7 avs, 4 in boats scripted start line Castle Rock, OSGrid
Dedicated Server from simhost.com SuSe 11.2 x64 Unknown 8gb / 50% 4x Core2Quad Q9300 2.6ghz 1 region (Wright Plaza) uses approx 4gb ram 20-25 users Freebie Stores / Meeting Center / Video Theater @osgrid.org Heavy Use Sim 17500 prims aprox 1500 scripts
Home machine Windows XP SP3 Diva r13558 3GB / 15-40% incl. Opensim and MySQL 4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10% 11 regions 1-6 users Many scripted objects (1934 scripts) @condensationland.com 38,065 prims

Performance studies and blog posts

These provide some interesting data on the performance limitations of OpenSim at various points in time.

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.

Personal tools
General
About This Wiki