User:Becky Pippen/Memory Limits FAQ

I won't be updating this page any more. If anyone would like to take ownership of it and maintain it, please do so. Otherwise this page will disappear soon. -- Becky

FAQ - Script Memory Limits

For the most official announcement so far, see here.

Q: Why do we need script memory limits?

A: In some regions, the simulator uses so much script memory that it has to swap virtual memory to disk. That causes major lag, and lag is among the top complaints about Second Life.

Q: How can I tell if I'm a heavy script user?

A: Starting with server version 1.38 and viewer version 2.0, we can now see our individual script memory usage, similar to how estate managers can see top scripts in a region. Also scripters can use the function llGetFreeMemory() to get an approximate idea of memory usage.

Q: Will this break content?

A: Yes, some. The limits are specifically designed to limit the worst 5% of memory consumers so that the remaining 95% can continue to run freely without causing the simulator to swap virtual memory.

Q: When will all this happen?

A: Script memory reporting and the new memory-efficient LSL functions are now available on the main grid using server version 1.38 and version 2.0 of the SL viewer. Server version 1.40 or later will have "Small Scripts" capability (see below). Memory limits will not be enforced until later in 2010 after these features have been deployed on the main grid for some time.

Q: Will the limits be per avatar or per region?

A: There will be limits on avatar, parcel, and region in a way that parallels how URL resources are managed.

Q: Will Linden Lab pay for all the scripted products we bought that will no longer work?

A: Most products are reasonably scripted and will continue to work just fine. The only problematic products will be unusual ones that are scripted in ways that use unreasonable amounts of RAM. Try to get the product creator to make a new version that uses less memory.

Q: Will we see a reduction in lag across the grid?

A: It won't have a major impact on most regions. However, it will make a huge improvement on the 5% of the regions that use so much script memory that the server has to swap virtual memory to disk. It is also expected to improve performance on any other simulators running on the same server host using the same disk resources.

Q: How much RAM are we talking about?

A: In the 95% of the regions that run smoothly, the simulator uses less than 800MB of RAM for everything except scripts, and up to 300MB for all the scripts in the region, and that's ok. In the worst 5% of the regions, simulators use up to 2GB of RAM on the server, and that's not ok.

Q: Why not just add RAM to the servers? RAM is cheap.

A: Several thousand Xeon server boards at, say, US$100 each to upgrade, comes out to a bunch of money, even for Linden Lab. Moving forward, new simulators (class 7) will have more RAM.

Q: Who will be affected?

A: All scripts, old and new, will be subject to the new memory limits. When planning for the memory limits, Babbage Linden said, "[2009/11/25 3:43] Babbage Linden: ideally we'd like to have 95+% of people use scripts as they currently do while still having 95+% of simulators running without swapping".

Q: What's the difference between "Small Scripts Project," "Big Scripts Project," and "Efficient Scripts Project?"

A: The Efficient Scripts Project is the overall effort to reduce the memory consumption of Mono-based scripts, including limits on memory usage. The Small Scripts Project and Big Scripts Project both refer to a refinement where each script can request the specific amount of memory it anticipates using instead of being charged with a constant 16KB for LSL or 64KB for Mono scripts. So, for example, a simple Mono sit script might request only 3KB while another data-intensive Mono script might request several megabytes. Since the average Mono script in SL needs only about 9KB, this could help reduce overall script memory usage in a typical region. In Office Hours, Babbage Linden said, "I would like to ship script usage, then small scripts, then script limits, then big scripts... so it would be nice to have mono scripts be able to reserve a lower memory amount before script limits enforcement happens."

Q: What's the "LSL Penalty?"

A: At one time, LL considered charging LSL scripts with more memory than they actually consume as an incentive for scripters to use Mono. That idea has been dropped, and the current plan is to charge all scripts with the actual memory they reserve — currently 16KB for LSL, and 64KB for Mono scripts. In the future after the Small Scripts and Big Scripts Project have been implemented, Mono scripts can be charged for only the amount of memory they reserve, which could be more or less than 64KB. Discussion of this can be found in the opensource-dev mailing list.

Q: What can I do as a content creator to prepare?

A: Be kind to your customers and give them product updates using the new efficient LSL functions. Learn more about how to measure memory usage and the scripting techniques for reducing memory.

Q: What can I do as a customer?

A: 95% of scripts are just fine and you don't need to do anything. If you are wearing hair, shoes, or other attachments with a script in every prim, then you can contact the creator and ask if there is a product update that uses the new LSL memory-efficient functions.