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.
If we are keeping a Wiki to keep track of the latest recommended performance tunings, I'd say the Wiki would be a good place to highlight & keep track of known related bugs. > 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! It doesn't sound like there is a Firefox bug for the #1 issue that Bob raised: >>> 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). I think we should file a bug with them about this. It would be nice if there were some firefox configuration options that allowed you to control this. > 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. Yes, re-opening as an RFE would be good. Perhaps we could suggest adding new configuration option(s) that would control the behavior. This might be good if they don't want to change the default behavior for the normal-desktop user case. > 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? I'd put this information on our Sun Ray Twiki so people can keep track of current issues, what work we are doing to resolve them, and how to get involved. Also, I'd think there would be some opportunities with OpenOffice as well to make it more configurable to support thin clients. What are the issues with OpenOffice that make its performance so bad on thin clients? Brian
