Waylon Blackthorne Posted October 29, 2013 Share Posted October 29, 2013 Hi all,I have been using viewer 3.6.9 (282553) since it's release a week or so ago and can't help but notice how greedy it actually is. When I first log in it will average around 1.1GB then as soon as there are around 15 avatars nearby it will shoot up to a whopping 2.3GB RAM usage!!It's actually getting to the point where the viewer is unusable as my frame rate drops to about 1 and the screen going pitch black every 4 or 5 minutes as it freezes. I dare not look how much video RAM it's consuming.......it wouldn't actually surprise me if it was using the whole 3GB available. It's absolutely terrible and has me tearing my hair out!Has anyone else had any experiences like this with the latest release or do we know whether it's a reported issue? Link to comment Share on other sites More sharing options...
Sassy Romano Posted October 29, 2013 Share Posted October 29, 2013 Are you saying that you have 3GB available as the maximum ram? If that's the case then your PC is almost certainly swapping memory to disk and back which is causing the very poor performance. Try setting the following debug setting "MaxHeapSize" to something that works for you. Link to comment Share on other sites More sharing options...
Waylon Blackthorne Posted October 29, 2013 Share Posted October 29, 2013 Max heap size is currently set at 1.6GB........we are talking normal RAM aren't we? What is the recommended setting and best way to prevent the viewer from using the disk paged memory? Link to comment Share on other sites More sharing options...
Cincia Singh Posted October 30, 2013 Share Posted October 30, 2013 Firstly, I don't see anywhere near this much RAM usage with the current LL viewer. Mine starts out around 0.65 and slowly creeps up to about 1.8 in a couple hours. That said, the best way to prevent swapping to HDD is sufficient RAM. This can be a problem for older computers running Win XP or most any 32-bit OS. I'm running Win 8.1 with 8GB RAM. Link to comment Share on other sites More sharing options...
Freya Mokusei Posted October 30, 2013 Share Posted October 30, 2013 Waylon Blackthorne wrote: I dare not look how much video RAM it's consuming.......it wouldn't actually surprise me if it was using the whole 3GB available. To clear up this point, SL is limited to 512Mb capacity for Video RAM. Link to comment Share on other sites More sharing options...
Nova Convair Posted October 30, 2013 Share Posted October 30, 2013 The viewer can use max. 3GB if running on a 64bit windows and max. 2GB if running on a 32bit windows. It uses max. 512MB for textures so a 1GB graphics card is always sufficient. But where is the problem? What makes you think the viewer should not use available memory? It's plain stupid not to use available memory so everything seems ok here. Only reason to think about that is if there are crashes. Don't know about the others but I don't crash so nothing to worry here. Link to comment Share on other sites More sharing options...
Sassy Romano Posted October 30, 2013 Share Posted October 30, 2013 Nova Convair wrote: But where is the problem? What makes you think the viewer should not use available memory? It's plain stupid not to use available memory so everything seems ok here. Only reason to think about that is if there are crashes. Don't know about the others but I don't crash so nothing to worry here. The problem would be that since it's using all memory to the exclusion of all else, then it's not really available memory but is forcing swapping. What is the viewer doing with all that memory? Caching textures that it used 2 hours previously? That sort of use isn't helpful nor necessary and since the OP has problems, then yes there's a problem The fact that the viewer just continually grows its memory use suggests a memory leak rather than effective use of RAM, again, THAT is a problem. Adding more RAM to avoid memory use like that, while it's a fix, isn't addressing the actual cause. Shrugs. Link to comment Share on other sites More sharing options...
Perrie Juran Posted October 30, 2013 Share Posted October 30, 2013 Just tagging your post for convenience. I'm not 100% certain this is related but I think this comment by Bao Linden is relevant to this discussion: "512MB is the [GPU Texture Memory] cap. But we do not think it is a bug. Here are the reasons why we set this cap: 1, this cap is a soft cap. It tells viewer it is good to make the total amount of textures to follow this cap. But if this cap needs to be overflown to make all necessary textures sharp enough, and viewer has resource to overflow the cap, viewer will do it. Of course viewer will immediately remove unneeded textures to follow the cap if the situation changes. 2, vram is used to hold all stuff for GPU. Textures are just part of it. VRAM needs space for VBO, render targets, and other necessary stuff. 3, When a texture is created, it has a copy in the vram and a copy in the main memory. Normally when vram can not hold all textures for rendering, drivers should do texture swapping between the main memory and vram. This is why we reserve 1.5 times of texture memory cap in the main memory. So say if the cap is 512MB, 768MB is reserved in the main memory. SL is built with 32-bit system. So the max address space it has is 2GB, which includes program space and heap space. Considering the fragmentation issue, the actual max memory (or heap size) for SL is no more than 1.6~1.7 GB. Among that, 768MB is a large enough portion to be reserved for textures only. 4, 512 MB cap is also sufficient for performance. Texture itself is hardly the reason causing FPS drop unless GPU is busy in doing a lot of texture swapping while rendering. This is not the case when we have 512MB texture memory. If you open the texture console by "ctrl+shift+3", and watch the total amount of textures to be bound at an instant, it is very rare that that number is more than 512MB. Instead of increasing the 512MB cap, we unfortunately might have to do the opposite changes: to shrink this cap, for certain cards. For instance, some ATI cards are not good at texture swapping. So textures eat up all VRAM quickly in some regions which causes FPS to crawl, and eventually crashes SL." https://jira.secondlife.com/browse/SH-2547? Link to comment Share on other sites More sharing options...
Waylon Blackthorne Posted October 31, 2013 Share Posted October 31, 2013 Okay it seems the extremely low frame rates and hangs were caused by an entirely different issue that I had overlooked. If I have the IM window open and have a few hours of (nearby chat) backlogged, my fps will plummet horrendously. So the more chat history the lower the frame rate, and you could image what that would be like in a busy club environment after a long night. Does anyone have any thoughts or similar experiences on this? Link to comment Share on other sites More sharing options...
Perrie Juran Posted October 31, 2013 Share Posted October 31, 2013 Waylon Blackthorne wrote: Okay it seems the extremely low frame rates and hangs were caused by an entirely different issue that I had overlooked. If I have the IM window open and have a few hours of (nearby chat) backlogged, my fps will plummet horrendously. So the more chat history the lower the frame rate, and you could image what that would be like in a busy club environment after a long night. Does anyone have any thoughts or similar experiences on this? Are you saving local chat also? I don't know the whyfores or wherefores but there is a warning in the viewer that saving local chat could impede performance. Link to comment Share on other sites More sharing options...
Waylon Blackthorne Posted October 31, 2013 Share Posted October 31, 2013 It was never a problem until the latest update but looks like a temporary fix is to delete transcripts. Still it's something which needs addressing as I've found out others are also experiencing this and quite often a relog is necessary to speed things up again. Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted November 1, 2013 Share Posted November 1, 2013 The poor performance issue when the conversation window is open on that viewer build is a known bug. It appears to happen when you have chat mode set to "Expanded view". If you change chat mode to "Compact view" you should find you no longer get the performance drop when focussed on a chat tab with many lines of chat history. Regarding your login memory useage of 1.1GB, this is quite high unless you have a large inventory. The larger your inventory, the higher your memory useage will be right from login (unless inventory cache is empty). For example, my alt has about 7k of inventory and the viewer will be using about 450Mb just after login. If I login my main, which has over 100k of inventory, the same viewer with same settings in same locatyion will be using around 1 gig at login Link to comment Share on other sites More sharing options...
HenryCrawford Posted November 11, 2013 Share Posted November 11, 2013 I have about 3.5 GB of usable RAM and I am not having as hard of a time as you are, OP. Are you by any chance in a heavily populated area or an area designated for active role play? Link to comment Share on other sites More sharing options...
Oisean Posted November 18, 2013 Share Posted November 18, 2013 I'm curious does this all apply to Firestorm too? And does Firestorm have the same 'expanded' chat view and how do you turn it off if so? As have been seeing the performance slow down over time lately as well. Win 7 64 I3 3.4ghz Radeon HD 5770 1g 4 G Ram hardwired network 1gps Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted November 18, 2013 Share Posted November 18, 2013 Firestorm 4.4.2 release and 4.5.1 beta are not affected by this bug no. The internal builds of Firestorm were affected by it but unless you are self compiling, you wont have seen it. It is now fixed internally. Firestorm does have the compact and expanded view options but they have different names. Preferences -> Chat -> General -> Use V1 style chat headers When this option is enabled, thats "compact view". When this option is disabled, thats "Expanded view". Link to comment Share on other sites More sharing options...
Oisean Posted November 19, 2013 Share Posted November 19, 2013 Thank you for the reply that helps. My GF and I both have been noticing the cumulative memory issues lately and have similar machines only thing that I can think of is tossing another 4G ram in it and see if that helps Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted November 19, 2013 Share Posted November 19, 2013 As far as the memory bloat is concerned, Firestorm does suffer just the same as Viewer 3. The performance issue is Viewer 3 when using expanded view for chat is unrelated to the memory problem. Seeing as you have a 64bit Windows system, give the 64bit alpha build of Firestorm a try. For details see http://wiki.phoenixviewer.com/fs_firestorm-64-bit Link to comment Share on other sites More sharing options...
orauswalker Posted May 24, 2014 Share Posted May 24, 2014 (sorry in advance for my English , I'm from Russia ) I have this problem and I found a partial solution installing the application Minimem "(following the advice from the forum CL)when my memory is greater than 1.4 GB of RAM involved in SL ( on any viewer I get a crash when turning the camera memory dump shoot up from 500 MB to 1.0 GB + , and I failed . This program has helped to reduce my crash by 80%, reaching about 800 MB of memory used Minimem frees memory up to 300 MB , and has a stable client work . But sometimes it still fails .....probably due to open other application. Not sure how this will help you ...but I tried., tnks Link to comment Share on other sites More sharing options...
Facebook
Instagram
Twitter
YouTube
Flickr
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now