Brian, I agree that this is a good place to start. The problem with this approach is that these kinds of bugs are typically filed upstream and so are scattered in a number of different bug databases. Until we have a meta bug tracker and a good process for linking bugs in our distribution directly to the component bug databases, we're stuck with trolling bugster and individual databases. Anyway, here are some of the bugs I'm aware of:
https://bugzilla.mozilla.org/show_bug.cgi?id=296818 Too much memory is used due to holding on to decoded image data Marked as fixed by Federico Mena Quintero. I don't know if the fix is in the latest vermillion codebase. https://bugzilla.mozilla.org/show_bug.cgi?id=296538 limit the memory cache to a reasonable value Also fixed. This page describes how to limit it: http://kb.mozillazine.org/Browser.cache.memory.capacity I need to try this since I've seen some firefox process heaps grow to over 2G! Bugster 6641518 Firefox leaks memory to Xserver Closed as not a bug, but maybe we should reopen as an RFE. The fact that firefox can grow to over 1G is bad enough, but when it causes the XSun process to also grow over 1G, the only way to fix it is for the user(s) to log out and restart the bloated X server. The only way the user knows this happens is that the Sun Ray server becomes memory starved. This memory fragmentation bug doesn't appear to be in bugster yet, but we should keep an eye on this: http://blog.pavlov.net/2007/11/10/memory-fragmentation/ I'll add more as I find them. Should I start a twiki on genuineunix.org or the sunray twiki? Brian Cameron wrote: > > Brian/Bob: > > I would think the first step would be to file bugs or enhancement > requests with the firefox, openoffice, etc. projects explaining > our needs. We might find, in response, that there are already > some configuration options that we could/should be tweaking to > improve thin-client performance. If not, filing these bugs/ > enhancement requests is the right first step to get such configuration > options added. > > Brian, are you aware if such bugs/enhancement requests exist? Could > you provide pointers to them? I suspect several people in this thread > would like to cc: themselves to any known reports. > > Brian > > >>> The intended scope is "JDS" which does include firefox and >>> staroffice. But the original optimization f27ch9hhconfiguation >>> settings for JDS2 were focused on components of the base GNOME >>> desktop. So more work will need to be done. Do you have any >>> suggestions for firefox? Turn off flash animations? reduce the >>> default cache size? Configuration settings don't exist for all of >>> these and some that do exist aren't yet available to the Java >>> Desktop Configuration Manager. >> >> I don't think config settings exist yet which would be interesting >> here - the work has to happen in the firefox community first. My >> first vote would be for firefox to do less aggressive retention of >> pixmaps for non-visible pages (e.g. pages "Back" in the URL history >> several steps, and possibly hidden tabs). This could have a profound >> effect on the memory footprint of the X server, which is one of the >> biggest culprits in desktop resource consumption. Perhaps we could >> have a multi-level setting (e.g. 1-5) where one extreme is what we >> have today, maybe the next level is to free up pixmaps which are at >> least 5 steps back in history (I don't know where the limit is today, >> and am guessing its higher than this), and finally maybe the other >> extreme might be non-visible tabs and any history. Or maybe an idle >> timeout could be applied (but beware of chewing up CPU in order to >> save resources ;-). >> >> I wouldn't recommend anything heavy-handed like disabling flash >> animations unless it was simply influencing a default that the user >> could override if they chose to do so (in a fairly obvious way). We >> don't want to limit function (unless we have a very extreme >> circumstance, and I'm not convinced flash is so bad that one or two >> people can't use it now and then), we only want to reduce impact. >> >> Simple stuff could be done right off the bat. I think I still see >> staroffice doing spin loops. That's bad citizenship. Everything >> should be done off of timers or events of some sort so that the CPU >> can be shared. >> >> A bit OT: I'd love to see JDS pick up and refine xautolock >> http://freshmeat.net/projects/xautolock/ so that it's a good >> multi-user citizen (i.e. remove spin loops). We have many customers >> who would like to have a desktop session terminate if it's been idle >> for a certain period of time. That's about maximizing desktop >> resource utilization also, but on an aggregate server basis vs an >> individual desktop basis. >> >> -Bob >> >> Disclaimer: Opinions expressed in this mail are my own, >> and are not necessarily shared by my employer >> >>> I intend to gather Sun Ray performance enhancement requests which >>> are not yet configurable into a proposal for the "Gnome lite" project. >>> >>> Bob Doolittle wrote: >>>> Hi Brian, >>>> >>>> First off - kudos for dusting off the perf doc and making it current. >>>> That'll be a big help to folks. >>>> >>>> Comment inline: >>>> >>>> Brian Nitz wrote: >>>>>>> And even better if that configuration were visible and could be >>>>>>> leveraged >>>>>>> by higher-level apps :-) >>>>>> I agree. It might be helpful if we talked through how we think this >>>>>> should work. >>>>> Most if not all of the performance related gconf keys are now >>>>> exposed via Sun Java Desktop System Configuration manager (was >>>>> APOC). This document >>>>> (http://www.sun.com/bigadmin/content/submitted/jds_optimize.html) >>>>> was written for JDS2 linux, but the changes necessary to make >>>>> these policies work went into the codebase for JDS3 on Solaris 10. >>>> >>>> Since "JDS" encompasses some pretty pertinent higher-level apps, >>>> as well as the desktop, I wonder what scope you're describing here? >>>> When you say "changes necessary to make these policies work" >>>> are you suggesting that firefox (for example) is now looking at >>>> these keys and changing its behavior? >>>> >>>> That's the sort of thing I was imagining with my comment, but >>>> I'd be (very pleasantly! :-) ) surprised to hear that such work has >>>> already been done. >>>> >>>> -Bob >>>> >>> >> >
