RAM usage is incredibly high in 1.9.0(21)

/263/d0/98472/2.html#post977365 describes what I found at first glance.

Now I have 912 MB virtual, 844 MByte Res for the second life linux alpha client.

Is this just me?

--- EDIT ---

going to the same two places in wine, I got the following memory usage (also top):

937 MByte Virtual, 271 MB Resident.

Wine shows load 2 (as opposed to 1 for the native client) in Xosview.

--- END EDIT ---

Interesting. Nice find! I must say I thought 1.9.0(21) was considerably snappier with downloading textures and reloading etc. Perhaps this is because of the enhanced use of RAM. Since I have 1GB RAM in my system this is not a problem, but I can see that as the linux client is not detecting system RAM correctly it could easily lead to those nasty crashes that have been described as it runs out of RAM and swap.

I will try to really stress my system to see if I can reproduce it. Any suggestions for good ways to use up system RAM without physically unplugging it? Also is there a way to stop the system using swap space?

With SL, simply go to places in world with LOTS of textures

Any dense shopping area will do...

And then the next one....

And so on

And to stop the system using swap, disable it But that would just crash you sooner. The other better way, is put about 10 GB Ram in your system

Let me check... (glad I have 2 gigs in this rig)

At start: 61 megs resident
First login, landing at the poker table floor of Hydrangea (69,196,79): 180 MB and rizing.
Walking downstairs: 200 MB and dropping... to 195 MB
Going to The Forest (via Find), transporting to the pub, entering, and sitting down in the glass area alcove: 218 stablizing to 210.
The Forrest's store area: same.

My guess is that it's related to how detailed the area is. I can't abuse it much, because Furnation's Skymall (the most laggest area I know of) isn't online.

Interesting!

The two places I tried were secondlife://Simcoe/229/224 and secondlife://DarkWood/107/38.

When I turned shadows off, the resident memory dropped a bit. My resolution is 1152 x 864.

Are you using the original secondlife script, with URL enabled? or with libaphafy patch? or completely standard?

I must admit, I lied in the settings.ini, and said my graphic card had 512 MB, it actually has 128

When I set it back to 128 MB (GraphicCardMemorySetting 3 in settings.ini), I get a MUCH more reasonable 589 MB Virtual 536 MB Res value, with shadows off.

It is still very high, though... Is that the textures, as you suggested? Strange though, that wine gives me similar values to what you get with the SL Alpha Client ...

Values that I SEEM to remember from previous SL Linux Alpha client versions.

I am running the standard secondlife script, plus the full URL extension, but not loading libalphafy libs.

And the memory is not in cache, of buffers, according to xosview; it is in the application...

--- EDIT ---

I still have shiny on, tho it doesn't work (and isn't supposed to work yet). Maybe that, like shadows, is nailing memory into RAM? I will take it out and see what happens.

--- END EDIT ---

--- EDIT 2 ---

Well, windows does it too - 675 MByte after landing at both locations, and waiting for textures to rez.

It may be my hardware, but I cannot see how...

--- END EDIT 2 ---

OK, tests done.

New computer, same two locations, same thing.

With less heavily textured areas (where I normally am), no problem, 250 MB or so being used.

This MUST be a bug One is a meeting area, where you can listen to live music, apparently, and the other is DarkWood Market.

I find it difficult to believe that this was always the case, and I certainly remember slow load times and lag, but not to this extent.

Is memory being used for prims, and not getting freed up? The texture console does not show THAT much in those two places, but my client goes dead and memory is REALLY full!

PS.: This is windows and linux, no difference.

All versions have had memory leaks at least since there have been linux clients (according to a windows user I ran into). I have personally been experiencing this since the old 1.8 series linux clients (I only have 256MB RAM in the same machine as my GeForce). I usually just kill-restart whenever it starts swapping... hrm, maybe I should just write a script for that... In any event, they've probably just made their bandwidth usage more efficient so you get overwhelmed much faster. Has anybody tried turning their gfx memory back down to 16mb? That might have some sort of useful effect...

Good point, that with the graphics memory. I got some improvement going back to my REAL 128 MB.

I feel it is something else, though: I get this behaviour with windows native, and with linux native. When I use wine, the behaviour is perfectly normal.

It looks to me like wine is doing its OWN memory management, bypassing that from SL, and the two native clients have a problem with that: they are managing memory badly.

Maybe its my AMD's?

It only works with the two locations I mentioned above. I cannot say if that happens anywhere else, cos those are all I tried.

I have submitted a bug report, naming the two locations. If anyone else can confirm it, maybe we will see a pattern?

Does wine allow you to restrict the amount of system RAM it uses? I know VMware does, but that's a horse of a different color...

I have tried it again, on my One and Only Intel Computer, and guess what? on THIS computer (Celeron 2.2 GHz), there is No Such Problem!

This seems to be an AMD problem only. On both my AMD Durons, Windows and Linux go crazy.

On the Celeron, I get exactly what I always got before: and exactly the figures that Vinci gets. 220 odd MBytes for the client, even after visiting both locations in succession.

I hope that this little niche group is also being catered to in SL

Maybe we need an AMD Linux Alpha Users Group?

Mh ... I'm on AMD, too, and here it works, even the wine version now works without the crashes I have experienced earlier...

AMD64 1GB Ram, Gentoo amd64, Nvidia drivers 8178

I have seen SL using a lot of ram and have restarted it for that very reason before now. However try as I might I am just unable to get the memory usage over 300MB. Maybe I am just not going to the right places :]

I've got an AMD Athlon 2500.. and RAM usage is around the 300MB mark.

Yes. I think I am alone here, with my sorrows

It happens to me regularly, but I guess thats somehing I have, and everyone else doesn't.

So I have hopes a) it will go away by itself, and b) I will never see it again

I am now suspecting some kind of junk getting to SL because of bad packets, but I am DELIGHTED that is is not a general AMD problem!

Thanks, everyone, I am relieved.

I just hope it goes away, see above

If you want someone to log on with you, do a little tour of a few locations and comp. mem. usage at the end give me a shout

I would like to take you up on that, just to see the difference

I will get in touch, thank you

Thanks, ninjafoo

We tested the two Bad Places, and I defintely use MUCH more RAM than ninjafoo, around double as much.

I would like to blame the Alpha Client, but it's the same in the windows client.

It seems to be related to bad packets, though. So I guess if my RAM usage gets too high, I can relog and hope my connection is better.

In the one area where I had LOTS of bad packets, my client got the most bloat. When the connection was good (realtively), I had almost as little memory usage as ninjafoo, in the same place.

Also thanks to Zi, who debugged my connection and settings on the network side. I hard set my MTU down to 1464 instead of relying on MTU path discovery, unfortunately not with any miraculous difference. I also set the kernel parameter "tcp_reordering" from 3 to 255, which helps a lot to get the bad packet rate to drop fast.

The ping -f on lindenlabs had a loss of 1%, which is better than Zi had, so that is also OK.

I would LOVE to get my bad packets down, but it seems very much to be pot luck , and after a TP my connection is bad again, even if I got a No Bad Packet connection when I log into SL.

Another suggestion was to use a different provider, but I have done that (I borrowed my daughter's for a minute), and the bad packets were still there.

Now I will wait & see if my proposed upgrade from a Duron 1800 GHz to an Athlon XP 2200 GHz changes anything...

Thanks again, everyone! It is GREAT being in such a supportive group!!!

Your very welcome, its just a shame we don't seem to be getting anywhere!

I found it!

Apparently 1.9 uses a different method for Far Clip etc than previous versions did.

I have set my draw distance to 128 M instead of 512 M, with far clip still at 5 fps, and its all OK.

Following results:

Starting point: Virtual 204, Res 164. Some bad packets, but only briefly.

Therafter Simcoe, with everything rezzed using the edit/select all trick: Virtual 302, Res 247, some bad packets, but only very briefly.

Then Darkwood, same as above, Virtual 396, Res 316, some bad packets, but only very briefly.

It seems my hardware/software was getting overwhumped!

Thanks all, for helping

Wooooo !!!

As I mentioned in another thread, you're using two completely useless metrics of memory usage. Virtual set size is a measure of the program's virtual memory, and has almost no correlation to how much RAM a process is actually using. The resident set size measures the number of frames a process allocates which is a little closer, but Linux doesn't allocate physical RAM (or swap space) until a process actually uses it, with a malloc() call for example, so this isn't a very good measurement either. In fact a program having too small of a resident set is a bad thing since it can increase page faults. The OS is responsible for dynamically adjusting the resident set size to try and compensate for the needs of the application without wasting too many extra cycles. This is why a more intense app like Second Life will quickly be given a large RSS; if the kernel adjusted it's RSS every time a new object was malloc()ed you'd have a huge amount of overhead. Fortunately the amount of memory the app is using is much smaller than both these numbers. What you are interested in is the actual amount of memory being used by a process, if we're talking about performance issues of a piece of software. pmap -d [pid] will show you all the code segments and data segments mapped by an application and it's dynamically loaded libraries. Subtracting the memory usage of the shared libraries, you're left with what pmap calls the "writeable/private" metric. An example on my system is gnome-pane. ps shows it using a VSZ of 112120, that's 112MB! An RSS of 17580, or 17MB, and pmap reports the actual usage at 5296K, or 5MB. Much better.

Holy crap MC, that was in-depth! Good overview of memory management, except that you didn't explain much about frames and paging. Not that that's very useful information on this forum

Three cheers!

Thanks!

However, the only metric that interests me, is if the game stops cos it is out of memory, or gets dead laggy.

This seems to happen in diect relation to the top/xosview values, so that is good enough for me.

The usage has also dropped since is set the draw distance to 128. This is true in windows and linux.

Wine somehow never even had this problem, even with draw distance at 512 on 1.9...

It would be fun to debug this and do a detailed memory analysis etc, but I want SL to run - I am not a systems debugger...

If the displays from top and xosview are helpful in warning me that my SL is going hog wild, especially when xosview tells me 90 MB has been paged out, then I am happy to use these Very Rough and Innacurate Guidlines to manage my SL setup

The question also arises, how much memory does linux think it has over? Cos that is what chokes the system...

However, since I have given you the means of reprducing this (just crank draw distance up...), I would be delighted to see a comparison of nmap/pmap/top and xosview, done by a Real Professional

--- EDIT ---

By the way, my impression is that the system got an overload, and tried to do things with broken data. It certainly behaved very insanely, as far as vast amounts of bad packets and huge memory usage and a very bad "overfly" problem is concerned

And the top/xosview displays were really used as indicators of WAY too much memory usage, which is in any case true.

--- END EDIT ---

I should have clarified, I didn't mean that using top or ps were useless, just that they weren't as accurate as other measures. It will still give you an indiciation of whether or not a process is out of control, as an increasing RSS shows that the kernel is having to compensate for a growing process for whatever reason.

If you were to plot the memory usage of all the processes on your system, using RSS as the x-value and writeable/private as the y-value it wouldn't be a linear graph. That's why I was recommending the other methods, but for basic indications of growth top should be fine. It's just annoying when people see a top/ps output of gedit and say "My text editor is taking up half my memory!!!!!!"

Angel, are you running with your video memory setting artificially inflated to make up for the lack of texture rezzing, compared with WINE? I find that this can eat a lot of memory.