Oddly it is pretty much a fact that when over 10 avatars enter my region and script time goes up far enough for spare time to remain at zero the sim starts lagging. Lagging as in rubber banding, getting pending downloads rising, etc. Not sure what sort of sims you guys are looking at but it is rather obvious to us that actually use Second Life and have to monitor this daily and then have to restart the region daily or so to get the sim under control seem to have a totally different experience than what you describe.
Once upon a time we could get 100 avatars in a sim. Sure there would be lag. Lag like you now get with more than 20 in a sim. I do see the stats in the viewer go nuts from time to time. Perhaps that is related to some other sim on the same host causing the swap problem? Because it happens from time to time even when there are only a couple of avatars in the sim. Personally I think the observations made over more than a year that prove the sim lags when script time consumes so much time there is no spare time left in a frame is rather accurate. Because the lag happens every time the saturation occurs. If you guys want to really help then give us the ability to disable scripts by attachment creator name. There are certain products that cause problems. Made by people LL props up as shining examples of how creators should be BTW lmao. Sorry but it doesn't appear to me like you guys are monitoring islands with even low to medium traffic too much. Oh and are you running 8 private islands to a host now? Or is the service that tries to let you know who all is on the same region simply incorrect? Thanks for clearing that question up if possible. ________________________________ From: Kelly Linden <ke...@lindenlab.com> To: Joel Foner <joel.fo...@gmail.com> Cc: opensource-dev@lists.secondlife.com Sent: Tue, March 9, 2010 3:57:13 PM Subject: Re: [opensource-dev] Script memory limit vs server CPU utilization as a key metric Hi Joel. This is an interesting issue. You would think CPU would be the big issue, but really it isn't. * We actually do a decent job of time slicing scripts. You add a lot of scripts and in general just the scripts run slower, sim performance isn't that impacted. * WAIT! Before you yell at me for that statement read this one: most of the script sources of lag are *specific* and actually caused by LSL triggered non-LSL events. For example temp-rezzers can kill sim performance. It isn't the script that kills it though, it is the rezzing of the object, and the derezzing. Yes the script causes that, but it isn't script CPU type that is hindering the performance. (BTW we are working on reducing the impact of rezzing! ssshhh) * ALL RIGHT! Yes there are other exceptions, scripts with high script time that effect the sim. But these are generally exceptions. The summary is though, that script CPU time is relatively well handled, though I admit it could be better. * Yes better allocating script CPU time so that one user can't impact the scripts of everyone else is also a great goal - it just isn't as high a priority as script memory right now. moving on.... * Sim's going in to swap is one of the biggest issues with sim peformance we have right now. It is significantly more of a problem than script CPU time. And when it happens all stats tank. * The fact that script memory is unbounded, that you can have a single prim object with thousands of scripts (technically unlimited, but the viewer behaves weird after a while) is a real problem. Someone built a GoogleFS-like system in SL that could in theory hold many gigabytes of data. They thankfully never deployed the full system. * When sims use too much memory they don't just affect themselves they affect their neighbors - the other regions running on the same host. So yeah, it is kind of weird, but memory is the bigger performance issue so we have chosen to address it first. - Kelly PS - nice to chat with you again, feel free to contact me directly if you wanna chat more. Hope things are going well. On Tue, Mar 9, 2010 at 10:49 AM, Joel Foner <joel.fo...@gmail.com> wrote: Many apologies if this has been discussed at length in a place that I've missed... > > >I'm a bit baffled by the continuing strong focus on memory utilization of >scripts rather than CPU load on the host servers. If (maybe I'm missing an >important issue here) the issue is to avoid a resident or scripted item from >causing performance problems on a region, wouldn't the relative CPU load >imposed by that script be a critical item? > > >I understand that if the total active memory size for a server goes above it's >physical available RAM, then paging would increase and potentially create >issues. Is there some objective analysis of servers with the Second Life >simulator code on to show that they go into continuous swap mode in this case, >or is it occasional "blips" of performance degradation on a slower interval? >It seems to me that having continuing excessive CPU load would generate an >on-going low simulator frame rate, which would be more frustrating than >occasional hits from swapping. > > >This line of thinking makes me wonder if a better metric for managing the >user's perception of performance would be script CPU load rather than memory >size. > > >Thanks in advance, and again if this has already been addressed please feel >free to point me at the thread so that I can read up. > > >Best regards, > >Joel > >_______________________________________________ >>Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >>Please read the policies before posting to keep unmoderated posting privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
