On Sun, May 31, 2009 at 11:23:08PM -0400, Laura Conrad wrote: > >>>>> "Derek" == Derek Martin writes: > > Derek> That seems unlikely to be the case here though. The most > Derek> likely cause is memory leaks in Firefox or one of its > Derek> plugins... restarting firefox may very well solve the problem > Derek> without the need for more/new hardware. > > There was never any question that firefox was the problem. It did go > away when I restarted firefox; I just tended to put off doing that until > it was so slow to redraw the screen that I'd have to go for a cup of > coffee before I could restart it. This was irritating. There is, sadly, no way around that, other than to restart the offending process before it happens. Once your system starts swapping, EVERYTHING is competing for scarce computing resources, including the X server (which controls the redraw of the screen). Changing the driver is unlikely to have any noticable effect. The problem is that while the system is thrashing, the X server's memory pages get swapped out, and they need to be swapped back in for the screen to redraw. You're waiting on disk, not the video driver. Meanwhile Firefox is still running, competing for those very same resources... Thrashing is bad. :) You just need to get in the habit of restarting firefox more often... [...] > and using chromium-browser for everything it works for. With > firefox running only a couple of tabs for the things chromium > doesn't work on, it takes a lot longer for firefox to leak all the > memory out of the machine. Or that. But you haven't really solved the problem, just delayed it (though that might be satisfactory). You may still find that at rather inopportune times, your system starts thrashing, albeit less often than before. It might be worthwhile to keep a system monitoring application (there are dozens of them) on your desktop, and take note of what the memory and swap utilization looks like when the machine starts swapping... Hopefully that will give you an indication of what to look for so that you can restart firefox *before* you get there... You might also use the VSZ column in the output of ps aux to determine what a safe virtual memory size for firefox is -- it's probably using more memory than anything else you're running -- then use ulimit -v to set the maximum per-process VSIZE to that. Firefox (and any other process) should basically break at that point, causing it to either crash or exit, but saving the rest of your system from meltdown. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.