Update Sept ‘09: We’ve started offering OpenSim Hosting to the public – you can read the announcement here.
This is modelled somewhat after the same guide for wordpress. Running an OpenSimulator instance is a challenging prospect for many – there are a number of important criteria you should be looking at before purchasing, but the single most important question is “Will I be managing this myself?”.
“Do it yourself”
DIY Hosting OpenSim while relatively easy by comparison to most hosting software, is still not something that should be done by the technically uninitiated. OpenSim requires a healthy amount of maintainence in the form of updates, backups and patching.
Virtual or Dedicated?
For DIY hosting you have two choices in terms of hosting – Virtual Private Servers (VPS) or Dedicated Servers. Virtual Servers are a percentage of a physical server provided inside of a virtual machine. Virtual servers are often significantly cheaper than a dedicated server, however come at a heavy cost in performance.
Virtual server pricing starts at approximately US$15.00 per month. Dedicated servers will start at approximately US$50.00 per month. Virtual servers are appropriate for low performance private sandboxes, Dedicated servers are a must for public or regular usage.
A final note on dedicated servers – the most inexpensive dedicated server will often outperform the most expensive VPS. If you are on the price border between the two, I recommend switching to the lower performance, but dedicated server – than the higher performance but shared VPS.
Linux or Windows?
Unless you have significant investments in using Linux for your hosting, I recommend using Windows 2003 or 2008, especially if you are not familiar with running hosting environments. The reasons for this are fairly simple – Mono has memory management problems, memory requirements under Mono are often doubled or quadrupled.
Unfortunately Windows server is not always availible – especially at the lower price ranges. Microsoft charges hosting companies a $10/month per cpu fee for Windows Server, so this will always be passed on in the form of higher prices. In the highly competitive VPS industry this price increase makes good Windows VPSs a rare niche.
What processor?
OpenSim will very rarely peg your processor – I would not bother investing too much into the processing capacity of your instance or server. (Whether a VPS or Dedicated machine).
My own experience says that “off the shelf” desktop processors are more than adequate. Here at DeepThink we have standardised on Xeon 3220 based machines (Quad Core, 2.4Ghz) and we find these are more than suitable for our higher-end clients. For an average user, a off-the-shelf Core2Duo is more than sufficient.
How much memory?
This is a much more relevant question for OpenSim. If you are running on Mono, I recommend no less than 1GB of memory per region (512MB if it is mostly empty). If you are running Windows/.NET you can use a rule of thumb at approximately 384 to 512mb per region.
A more precise metric is to total up the following: A base cost of 200mb, total size of all textures in the region + 30% in megabytes (average region is around 50mb), 30mb per 1,000 primitives, 50mb per concurrent user and double the sum if you are running under Mono.
So a region with 5,000 primitives, an average number of textures (50mb) and ten concurrent users you should allocate approximately 900MB of memory for .NET and 1.8GB for Mono. Leave at least 100mb on top of this sum for the operating system itself; if the machine runs out of memory page file access will cripple the performance of your region.
Memory should be as fast as possible – the faster you can get the better.
How much hard disk?
None. OpenSim rarely uses more than a few gigabytes of space unless you are operating a large grid (OSGrid.org is only about 120GB of assets currently). Anything over 10GB is sufficient.
How much bandwidth?
This is a slightly tougher question to answer – it depends a lot on your sim, the complexity and texture detail, the number of visitors. We at DeepThink sponsor the servers running the OSGrid.org Plaza’s, which I believe are the six most visited OpenSim instances running. The Plazas are broken up over two physical machines – each uses about 240GB of bandwidth each month – or approximately 80GB per region per month.
In pratice your region should come in significantly under this – but I recommend making sure you have at least 100GB of traffic per region in the event that you create a popular space. Most hosts provide at least 1TB of transfer on dedicated servers, so this should in most cases be a non-concern.
The other side of bandwidth is connectivity – how fast your server can speak with the outside world. I recommend having at least 200kbit per concurrent user. So for a standard ‘10 concurrent’ situation, you should have at least 2mbit of connectivity.
Backup Space
Make sure to have some kind of external backup system – most hosting providers will sell you SFTP access to a backup server, however make sure that they in turn provide good backup policies on your backups (offsite backup, etc.). OpenSim can be very fickle software, so make sure you have a good backup routine setup.
Latency
If you are a non-american user or cater to a foreign crowd, Latency is a very important issue. Latency is the “lag” between when you do an action and when it occurs on the simulation server – unfortunately latency is often best fixed by changing the geographical location of your servers.
If you cater to an audience in a specific country – I would recommend searching for servers in countries nearby. Often localised hosting is several times more expensive than in the US due to higher prices for local bandwidth, however most of the time there is a cheaper alternative nearby. For example, Japan has very high local server costs – but Korean or Singaporean servers are cheaper and have similar latency characteristics.
Who?
Dedicated Servers
CariNet (San Diego, CA, USA)
CariNet have been a popular choice for people running regions on OSGrid thanks to great pricing and astonishgly quick setup times. Their live support is pretty good and tends to fix most issues within 30 minutes of reporting. Cari have a highly flexible pricing system – so make sure to remember to include additional RAM and the Windows operating system with your purchases.
CariNet are also an official sponsor of OSGrid.org, providing regular free upgrades to the official servers that are hosted there (Currently the two plaza machines and the one welcome machine). They have also provided some special pricing for OpenSim users – see the italics below.
Pricing: Minimum $50.00 per month (special offer at time of writing).
I spoke with CariNet’s sales department, and we have worked out a few “OpenSim Optimized” configurations -
- High Performance – Windows, 4 Core Xeon, 4GB configuration is US$200.00/mo with no setup fee.
This configuration is ideal for a “SL-replacement” style region host, you could probably get a couple of regions off this hardware, but the exact number will vary as above. I would estimate approximately 2 “Full Regions” could be run on this hardware configuration.
If you want this server for only $160/month (but with a $120 setup), contact Cari.net sales via their Live Chat with the discount code “OSGRID”. (Speak with Mike or Shawn) - Mid-Range – Windows, Core2Duo, 2GB configuration is US$140/mo with no setup fee.
Expect to get one heavy region out of this configuration (or quite a few “homestead-esque” regions) – as always, this varies based on consumption.
As above, if you want this server for only $120/month (but with a $60 setup), contact Cari.net sales via their Live Chat with the discount code “OSGRID”. (Speak with Mike or Shawn) - Low-End – Windows, Celeron 2 Core, 2GB configuration is US$125/mo with no setup fee
Consider this a homestead replacement, you should be able to get a small number of “homestead-equivilents” running off of this – obviously you dont have primitive limits or things like that, but you will notice degrading performance if you rely on a lot of scripted functionality.
As above, if you want this server for only $105/month (but with a $60 setup), contact Cari.net sales via their Live Chat with the discount code “OSGRID”. (Speak with Mike or Shawn)
Annual and quarterly discounts are availible for paying more than one month at a time.
Website: http://www.cari.net/
OVH (Paris, France, EU)
OVH are the largest dedicated server host in Europe and provide unbeatable pricing on European servers. English pricing is expensive, however the same servers ordered from their French or German language sites are 10-20% cheaper.
OVH provide large amounts of memory and disk space by default, so very little customisation is required on their default servers. Windows 2003/2008 is an additional EUR 15.00 per month. Their RPS low-end machines may be a suitable mid-way point between a VPS and a full machine, but I haven’t tested one myself.
Pricing: Minimum EUR 49.95 per month. An OpenSim optimized configuration will start at EUR 114.00 per month (fully equipped).
Website: http://www.ovh.co.uk
Virtual Servers
Tektonic (Dallas, TX, USA)
Highly recommended by one of our employees, Tektonic provide good quality Linux VPS solutions – while they only offer Linux based VPS instances, their pricing is affordable and do not appear to oversell their servers in any noticable capacity.
Pricing: Minimum $15.00 per month. A “workshop” quality VPS is US$28.00 per month.
Website: http://www.tektonic.net
Slicehost (St Louis, MO, USA)
Slicehost guaruntee a minimum level of performance on their virtual servers which makes them more expensive than other hosts, however have a solid customer service reputation and a high quality control panel.
Pricing: Minimum $20.00 per month. A “workshop” quality VPS is US$38.00 per month.
Website: http://www.slicehost.com
FsckVPS (Atlanta, LA or Texas)
FsckVPS is often recommend on the OSGrid forums as a potential host – their slices are of a reasonable configuration and have plenty of memory availible. Processing time is more limited and some users have complained about running into processor limits, so their higher end packages are recommended.
Pricing: Minimum $9.95 per month. A “workshop” quality VPS is $19.90 per month, however I recommend the $34.90 plan if you plan on concurrent users.
UPDATE 9 June 2009: These guys dropped the ball badly on an exploit, while it does look like their upstream provider gets the lions share of the blame, they had an unacceptable amount of data loss that could have been avoided by doing some simple backup precautions when an exploit becomes known.
Website: http://www.fsckvps.com
“Someone host it for me”
As an alternative to setting up and managing your own OpenSim instance, you can pay for someone else to manage it for you. Often this is simply bundled with a grid – however a number of companies (including DeepThink) offer managed hosting services for OpenSim.
On average, an OpenSim instance will take around four hours of maintanence each month – at an average industry salary this is around $80.00 per month to the hosting company in engineering costs. You should expect the margin per-server to be about this size.
OpenSim hosting companies will charge based on one of two methods – the first method is Second Life(r) style limits – Primitive, Avatar and Script limitations. The companies that charge this way are generally those providing regions within a grid.
The second method is charging for the underlying service used – Processor time, RAM usage and Bandwidth. The companies offering this tend to be fairly agnostic as to where your regions will connect.
An important distinction between the two methods is that you will often get more ‘bang for buck’ on the underlying capacity. For instance if you need multiple low performance regions – you will come out significantly ahead by purchasing server time rather than regions. Likewise if you need a single high performance region you can tailor your requirements more specifically.
A final note – many simulators are sold as ’supporting 45,000 prims’. This is not reflective of actual usage – the 45,000 number is the largest number the Second Life(R) client will display, however on the backend there is often no limit. That however does not mean the region is capable of supporting 45,000 prims.
We often find that simulator performance degrades rapidly past the 10,000 primitive limit per region and it requires a significant amount of work to get more than 15,000 prims into a region while the region itself is stable, especially when scripts and multiple users are factored into the equasion.
As an addendum to the above – the per region count is not reflective of the per-simulator count. OpenSim can host multiple regions per simulator instance and we have found that the simulator instance itself can host in excess of 100,000 primitives as long as they are distributed between multiple regions.
A note on SLAs and Uptime
OpenSim is still alpha software. If you expect 99%+ uptime, you will also expect to pay for it. Keeping a region running with guarunteed uptime requires active maintainence and attention by an engineer. This means it is impactical to expect 99%+ uptime unless you can afford a technician 24/7.
Our experience with client projects is between 97.6% and 99.2% uptime over the course of a month. (including scheduled and unscheduled maintainence) – this will vary slightly depending on the version of OpenSim used, number of users and other factors.
If someone claims to offer bug-free and stable deployments of OpenSim, they are probably lying or are very naieve. OpenSim will occasionally run into bugs. If you have a specific project in mind that requires a production deployment it is strongly recommended to hire a consultant who is familiar with the OpenSim project (eg DeepThink, IBM, 3Di, Tribal Media, etc.).
List of companies providing OpenSim hosting (note this is incomplete – there are likely to be others)
Customized OpenSim Hosting Providers
The following companies provide customisation services and will tailor your OpenSim install to your specific needs. These companies all provide pricing on a per-server basis rather than per-region.
DeepThink (Managed OpenSim hosting and Customisation services): http://www.deepthink.com.au
ReactionGrid (Managed OpenSim hosting): http://www.reactiongrid.com
3Di (Customisation services, hosting. Tokyo based.): http://www.3di-opensim.com/en/
Not listed here, but likely to offer these services are IBM, Tribal Media and Genkii.
Grid Hosting Providers
These companies provide hosting within the context of a grid. Most of these companies use very similarly specced hardware, however many of them share multiple clients per server – to use Second Life as an example, Linden Lab charges $295 per “island” which is stacked at 4 per server (or $1,180 per server per month).
While I did attempt to compile an exhaustive list of companies here – finding pricing and stacking ratios for many of them proved a difficult and time consuming process. You can find a more comprehensive list of grids (most of which offer region hosting), here:
http://opensimulator.org/wiki/Grid_List
Stability Remarks
As noted all over the OpenSimulator website – OpenSim is alpha quality software. To quote our downloads page
Please note: As OpenSim is still at an alpha code maturity stage, there is absolutely no guarantee that functionality works or is stable, even in the numbered releases. Certain features may not work either because the code is in rapid evolution, or because functionality expected by the Linden Labs Second Life viewer has simply not been implemented yet. However, constructive feedback is still welcomed.
If you are putting OpenSim into a production environment, make sure to speak with your hosting provider about what you plan to do – many of them may be able to make recommendations or tweaks to better suit your demands. If you have clients involved – it is often better to stick to an older more stable release as all releases are not nessecarily equal (eg 0.5.8 was somewhat stable, whereas 0.6.3 had appearance bugs).
If you are planning on using the ‘bleeding edge’ version of OpenSim in production, expect to get cut, or again quoting the downloads page:
There Be Dragons Beyond This Point
If you are truly feeling dangerous, adventurous, or want to help us test the next version of OpenSim you are welcome to grab the latest unstable code out of our subversion trunk. Any warnings previous expressed about the alpha nature of the code go double or triple if you are running directly off of trunk. Never, ever, ever, never run this in production environments, it is not suitable for that unless you are very familiar with the source code, and can hot fix any piece of it (that probably means you are an OpenSim core member). Feedback and testing on the unstable tree is appreciated, as that helps us make the next release better. If this scares you from using trunk, that was intended.
If it breaks, you get to keep both pieces.
Final Remarks
Running an Opensimulator instance can be a perfect fit for your organisation or person as long as you respect the limits. OpenSim can provide fantastic discounts to other commercial virtual worlds software, however it is worth remembering that it is still new and experimental – often this can be an advantage in customisability and features, but at the same time you need to respect the limitations of the software.
If you are unsure about whether to put OpenSim into production or how to do it in a way that fits what you need to do – like every Open Source piece of software, there are a lot of developers and organisations who can provide consulting services. Check the Core Developers List on the OpenSimulator wiki for a full list.
Excellent to have this available for everyone. It most certainly will help people to figure out how to plan for scaling their systems and to prepare themselves.
I did a little “Quick Math” using your data here for a Windows Server Installation;
[ 1 full Region (15,000 prims + 40 avatars)]
Base Ram: 200 Meg
15k Prim: 450 Meg
40 Avies: 2.0 Gig
Total Ram: 2.65 Gigabytes
Bandwidth Requirement/Support
8 mbit outbound for 40 users (more = better)
This calculation does not take into account running / active scripts and other relative functions which would increase load on the server.
As an “aside” I would like to see the Hardware Spec that LL has for their “Class-5 Servers” which would be, in my opinion should be considered a Minimum Baseline System and a good reference point to start from. Is this information published anywhere so that it could be accessed ?
Thanks Adam for EVERYTHING you and the rest of the Teams are doing!!!
WhiteStar
7 May 09 at 4:12 pm
Concurrent user demands actually have gone down since I started writing this article (Apr 15th or so); but I haven’t worked out by exactly how much.
I don’t think using LL’s baseline as a recommend minimum is a good idea myself; since it varies between underperformance and overkill depending on user demands. A lot of their benefits come from being able to oversell capacity (eg; a single ‘class 5′ cannot handle 4 regions at 15K prims + 40 avs – but in theory it could be loaded with such tasks)
It is also worth keeping in mind OpenSim has a fairly different performance profile to LLSim – so hardware optimized for one may not be ideal for the other.
That being said, if you are curious; I believe the following are the machines LL order.
Class 4: 4GB RAM, Opteron 265 x 2 (2×2 cores at 1.8Ghz) ordered via Silicon Mechanics.
Class 5: 8GB RAM, Xeon LV (1.6 to 2.0 Ghz, 2×2 cores) – I believe may be supplied again by SM.
If you heard people say that Class 5 wasn’t much faster than Class 4 you would be mostly right, the only real improvements came from faster memory and more of it.
Adam Frisby
7 May 09 at 11:31 pm
Agreed & understood… LL has a different profile, no doubt about that and how OS being being redone with “Lessons Learned” being applied we certainly won’t suffer the same issues, similar and some different, but that is the nature of the beast.
The Class 5 you describe is a pretty respectable machine but there is most certainly better than that out there for a reasonable price.
I think it should be pointed out too, that if one single individual wants to run a couple of regions then one good box will do the trick. But it is another matter completely if you want to operate a grid… but I suppose that is another discussion/topic altogether because of the DB systems and other dependencies.
Thanks for the enlightenment Adam.
WhiteStar
8 May 09 at 3:09 am
Great article! We’ll run that one
Saves me having to write a similar one *grins*
SP
Simon Probert
8 May 09 at 1:50 pm
Great article.
Leaning towards the Cari.net US$50 choice.
Q – Cari.net offer Windows OS in 32 & 64 bit varieties. I run XP Pro 32 bit at home. What complexities / differences is there running the server and OpenSim in 64 bit compared to 32 bit at home? Which variety should I choose?
Dene Sparta
13 May 09 at 10:14 am
Either is fine – but 64bit will give you a lot more bang for buck when it comes to RAM. Windows will only use up to 3GB in a 32bit environment for a single application; 64-bit Windows will let you use up to 4GB in a 32-bit app, and 16TB[?] in a 64-bit one.
That being said, in a 64-bit environment, you should use the ‘OpenSim.32bitLaunch.exe’ to run OpenSim unless you feel like recompiling all the OpenSim dependencies (such as ODE) under 64-bit mode.
Adam Frisby
14 May 09 at 4:40 am
Regarding the claims on Mono’s memory problems. I would like to know what exactly you claim that is larger in Mono than it is on .NET.
I can understand a small percentage increase in memory consumption in Mono, but not a 3x or 4x increase in memory usage.
Could you provide a sample “set” that I could use to test various versions of Mono across a number of operating systems and compare it to Windows?
Miguel de Icaza
14 Jun 09 at 6:10 pm
I did some testing and downloaded opensim-0.6.4-release on both Windows and Linux.
I accessed a remote Windows system to do the build and run the simulator and I used my local Linux machine with Hippo to test the memory usage. Sadly, Hippo kept crashing on me, so I could not do a very extensive test.
A fresh virtual world with Mono/32-bit vs Vista/32 bit has Mono using 51 megs of RAM on startup on Linux vs 55 megs of RAM on Vista (50 megs plus 5 megs of the OpenSim.vhost.exe)
If you run Mono/64 (which is what I initially did) the size of 64 bit pointeres has a strong effect on Mono and increases the process size by 11 megs.
So at least starting up, Mono ends up with a 5 meg advantage. Perhaps the objects loaded after that make a difference, but without the actual data that you used, it is hard to find out exactly what it is.
I suspect though, that you might have compared the memory usage report from taskmanager on Windows versus the VSIZE memory usage, this is a common mistake.
It is also worth pointing out that the VSIZE reported by ps aux is usually very large and is the *wrong* metric to measure memory usage of OpenSim on Mono. The VSIZE reports the VM address space used by Mono and it happens to include all sorts of things that are not actually using memory.
The RSS size is what you want to look at in both cases. There are a few hundred blogs that explain why you should not use VSIZE when computing memory usage and why you should look at RSS, for instance:
http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html
Miguel de Icaza
14 Jun 09 at 7:59 pm
A third follow up.
With the help from the guys on #opensim on irc.freenode.org I got myself a sample virtual world from:
http://opensimworlds.com/index.php?part=worlds
I used “Nu Athens” a free download and loaded it up on 3 configurations:
Vista, running 32 bit OpenSim
Linux, running 64 bit OpenSim
Linux, running 32 bit OpenSim
And then I loaded all the four files provided in the zip file using the command:
load oar FILE.tar.gz
The results are as follows:
Vista/32: 115 megs + 5 meg helper process (OpenSim.vhost.exe)
Mono/32: 92 megs, after a few minutes of inactivity, it goes down to 87 megs.
Mono/64: 122 megs, after a few minutes of inactivity, it goes down to 89 megs.
The garbage collector is responsible for the difference in memory usage between the load finished and waiting (I ran into this problem because I came to measure again after a few seconds and the size had been reduced).
The Vista system remains at 120 megs total for the same world.
So Mono on Linux on both 32 and 64 bit configurations is consuming less memory than Vista, some 40 megs out of 120, or one third less memory.
Perhaps the difference is in the version of Mono that we are running. I am running with Mono 2.4, and the OpenSim documentation implies that OpenSim can work with systems like Mono 1.2.6 which is primitive by our standards (that was released more than two years ago).
In Mono 2.0, Mono 2.2 and Mono 2.4 we introduced many memory reduction features. From using precise collection for the HEAP, to reducing the size of generics-heavy code to reduction in code size generated and runtime metadata tables.
I would appreciate if you could post a correction to your data in the main article, as it seems to have spread and this could negatively impact the perception of the Mono’s community work towards making a great .NET implementation for Unix.
Miguel
Miguel de Icaza
14 Jun 09 at 9:59 pm
Hey Miguel,
The problem isnt really visible until you start getting users involved. OpenSim wont use nearly any memory until you have regular users and a reasonably complex scene.
The problem appears to be leak related – we recycle a lot of classes internally; which results in a lot of objects to track in the GC, however, when memory is allocated in Mono – it is never reclaimed back later. We’re not sure why – memory dumps dont indicate much (if and when they run at all.)
Under .NET – it does get reclaimed. Memory use for a Windows machine isnt one directional – after 12 or so hours, Mono can be consuming 2+ GB, while .NET is still chugging along at 400mb. (Although they will have both started out similarly.)
Our test servers for OSGrid are probably the best demonstration of the problem – you can see the memory charts here: http://plaza02.osgrid.org/stats/detail.php?graph=3&tree=&filter= for Mono. For Windows, I’ll need to get in contact with you and arrange some kind of demo. Do you want to send me an email: adam@deepthink.com.au
Adam Frisby
14 Jun 09 at 10:04 pm
Hello Adam,
Thanks for the extra information.
Many objects is not a problem for the GC. It just means that the GC will take longer, but it does not mean that it will give up on collecting them.
Mono has one important difference when it comes to memory management when compared to .NET, it does not have a compacting collector (yet) and older versions of Mono used too many resources (generics caused vtables to bloat out of proportion, megabytes of tables at a time).
Compacting collection can become a problem if allocations have a pattern like this: allocate large object, wait for it to be collected, allocate objects that fit in the previous hole, allocate the same large object (triggering a new heap expansion).
It would help if you guys could provide information as the configuration that you are using (Mono version, Linux version, architecture).
Miguel de Icaza
14 Jun 09 at 10:21 pm
Adam,
I have a final question.
It seems to me that OpenSim must have some sort of system to snapshot the system and resume execution from a snapshot to ensure that it can recover from a crash.
A crash could be caused by all sorts of events, like operating system crashes, power failures, bugs in OpenSim itself, the underlying libraries, or any other source of problems.
If this is the case, I assume that OpenSim would support some mechanism to serialize its state, and resume execution from a serialized state.
If that is the case, and running OpenSim on Mono does have leaks, what is preventing admins from recycling OpenSim instances (this is common in server scenarios, for example Apache recycles processes after certain number of transactions).
And this is also how Google ensures operations: they assume that there will be failures, and write the code to recover from failures.
Miguel.
Miguel de Icaza
14 Jun 09 at 10:30 pm
We use a mix – but the experience is fairly consistent.
1.9/2.0 did give us some benefits, and the newer 2.5 builds have improved things – we’re now able to keep some of the regions up for up to 2 days between restarts.
I can tell you that the problem is visible on both x64 and 86 architectures, for at least the following versions; 1.9.1, 2.0, 2.2, 2.5. The problem does not appear to be unique to any distribution or kernel version; and is fairly reproducible under any test conditions.
Adam Frisby
14 Jun 09 at 10:30 pm
Recycling instances is quite possible – it’s easy enough to do.
The problem is mainly resuming user sessions; in the process of resuming – we lose all the user socket connections (they get disconnected, etc).
Startup time can also be a problem; initialising user scripts by the truckload (not uncommon to have 1000+ user scripts running simultaneously.) and other things can prevent a very quick resume.
The big issue is that unlike apache, we’re maintaining a multiuser session environment – that means that each user is experiencing the same data being updated in realtime; if we split users across processes, we could end up with a horrible amount of duplicated data in memory; along with the woes of interprocess communication.
Right now, we do restart the process regularly – but it’s by force rather than choice (ie we hit swap and everything stops).
Adam Frisby
14 Jun 09 at 10:34 pm
Hi Miguel,
I can tell you this is a persistent issue with Mono – whether or not the issue has spread is not my concern, the issue is primarily that Mono does have serious memory management problems – as I outlined before, the issue is mostly visible with scripts, users and time. Any tests you do need to have concurrent users (you can use some of our demo bots such as pcampbot to see the problem) and it needs to run for at least 24hrs.
I would suggest contacting ‘nebadon’ on #opensim-dev on irc.freenode.net and asking him to take a look at Wright Plaza, which is the best example – this server needs to be restarted daily due to this memory issue.
Adam
Adam Frisby
24 Jun 09 at 3:09 am
Adam,,,,,according to your earlier, estimated calculations, quote “So a region with 5,000 primitives, an average number of textures (50mb) and ten concurrent users you should allocate approximately 900MB of memory for .NET and 1.8GB for Mono.”, this means for Mono, and 16 regions, a server WILL need (not forgetting scripts) approx 40GB RAM, and I don’t think there’s a computer system in existence that can access that amount of RAM. Quad cores can only access a max of 32GB, so for the everyday Joe, with 16GB, Duel Core, would only be able to run 5 regions, 5,000 prims, 10 concurrent avatars, 50MB of textures, and approx 100 active scripts (script memory usage depends on type of length of script).
Dr B the Master
3 Oct 09 at 12:26 pm
hi Adam,
would you have any idea why there would be some kind of warning on the opensim folder that i downloaded as a binary installer, the 0.6.6 version. it looks like a red, round circle with a little exclaimation mark inside the red circle, and this is on the folder itself. also, the whole folder is read only and when i try to change that, it wont, and i cant change anything about the opensim i created, everytime i try to modify the external host name in the regions.ini file, it wont allow the change. i do have a brand new 8gig pc with that nasty windows vista 64 bit, and there is no way to even run anything in this folder as administrator to even get any permission to change anything the way it needs to be done.
if you have any suggestions about what i could/should do about any of this i would so much appreciate it.
Marilyn Hill
17 Oct 09 at 5:22 pm
Not a clue, sorry Marilyn – you might want to try the normal support route of the opensim-users mailing list.
Adam Frisby
18 Oct 09 at 8:04 pm
hey thanks, adam, i really love that chat facility i went into from osgrid, i got lots of questions answered there already, and i have 6 regions going good now so far because of the chat answers. its awesome, cheers!!! nowto work out the hosting, lol thanks for that great info here, too.
Marilyn Hill
5 Nov 09 at 6:44 pm