Vint going to scripting office hour with Babbage Linden? Did
the Virtual World Linden Lab’s server parks just got turned upside down? Do not panic (yet), Miss Nock told me to read the transcript. That’s all I did, read the transcript, I swear! ;) As it’s about Openspaces & script limits, I figured the rest of you should read it too:
Babbage Linden on Openspaces & Script Limits
… on the mono front we’ve fixed an important security issue this week, which i can’t talk about, but it should be in 1.25 server. That’s about it for new scripting code in the works. We’ve been doing a lot of thinking about whether we can apply script limits to open spaces too.
The framework is currently being used to limit public urls# in http in on the preview grid. We’re looking at extending it to limit script memory so the region would have a pool of script memory that would be divided between parcels in the same way that prims are allocated and would exhibit the same behaviour as prims when the limits are met. You might not be able to rez an object because there aren’t enough prims available, or because there isn’t enough script memory available for the scripts inside.
It’s been needed in second life for a long time as currently you can keep adding scripts until the simulator starts swapping. Which badly impacts the performance of all the regions on the host. As regions move between hosts you can have your region run fine one day and then badly the next when it happens to be running on a host that has too many scripts and is causing the host to swap.
It’s even easier to have this situation with open spaces as you have 16 regions on the same host. So the memory is shared between more regions and there’s a greater chance that someone on your host will be using too much memory. This is something we’ve been planning for a long time, but we may give it a higher priority now that we’re having even worse problems with open spaces.
A nice benefit of script memory pools is that mono scripts would be able to use as much memory as is available: if you have a large parcel you could have a single script which requests a large amount of memory instead of being limited to 64KB. Which I know a lot of scripters would like to see. Really large scripts wouldn’t be easy to move around, as they would create a lot of network traffic and serialized data, but if you have a static script that sits in the region it wouldn’t be a problem.
We’re currently running some analysis of the current memory usage: we want to know the 50th, 95th and 99th percentiles, so we can pick values that won’t impact many people on full sims. Then we’ll work out good limits from there and the available memory. Full regions on class 5 sims get about 800MB each for everything, including scripts, physics and object transport and updates. We also need to work out how the script memory budget would impact the other systems. There’s lots of measurement and discussion to be done before we come up with numbers, but that’s most of the work at this point as the framework exists for http in public urls already.
Regions have different hosts/servers over time? How often is the swapping done? Is this done to balance loads or usage issues or? (by RAND0M Destiny)
Regions normally stay on the same sims, unless they get restarted due to a rolling restart or a crash or other problem. They can’t be tied to a host as we have hardware failures fairly regularly with ~6000 hosts. When a software or hardware failure happens, a watchdog notices and starts the region on a different sim host. The changing combinations of hosts makes it difficult to manage performance problems manually, although you could have a word with your neighbour if they were running many scripts on a parcel. It’s difficult if you don’t know who your neighbours are if they keep changing.
I think this work will be a big benefit: it will improve performance of simulators as they will swap less often and it will allow large scripts down the road.
As well as dividing some of the script memory by parcel for scripts in world, we will allocate some script memory for avatars on a per avatar basis. The avatar pool will be constant, you will be able to keep your scripts running wherever you go. If you can tp in to a region, then your attached scripts will be able to run there.
There will be ll* calls to find the available memory. If you’d like to see how this is likely to work, play with the http in beta on the preview grid… (going on about C# in Mono inSL. Or something like that! ;))