On Sun, 24 Oct 2010 05:54:56 +0100 Marko Vojinovic <vvmarko@xxxxxxxxx> wrote: > Just tried it, logged out and logged back in. Didn't go to runlevel > 3, X gets restarted with only logging out and in, AFAIK. You're probably right. I think of X as this huge complex beast that sits between the OS and me, and think of it as a black box. :-) > > Anyway, you seem to be right! Restarting X purged most of the swap, > from 1.3 GB it went down to 31.4 MB. And the system regained > responsiveness. Excellent, easier than rebooting, and eliminates the underlying OS as a problem. > > So apparently something inside X is leaking memory. But X has many > components --- compiz, emerald, KDE, Xorg, intel driver, etc., so any > idea how do I diagnose this further? I think this is the more likely place too, but as Roberto said, it could be an application within X leaking memory also. > > I mean, I can restore the system either by reboot or logging out/in, > but I'd like to know what is the actual cause of this end eliminate > *that*. Hopefully I would like to correct whatever is wrong so that I > don't need to get into the situation of having to reboot or relogin > myself again. > > I am open to suggestions on how to proceed in troubleshooting this > further. If anything, my system will become slow again in a week or > two... ;-) I haven't chased anything like this because I usually shut down overnight. I used to leave my systems up for months (I never noticed any slowing so my use case must be different), but I read an article that about 10% of the power used in the US is for electronics just idling so they are instantly available, and decided to do my part by going down when not using for any length of time. Not advocating, just explaining. Because it takes so long to manifest, it is probably something running constantly, but with a very small leak. I think there are tools that allow snapshots of jobs on the system and their memory footprint. Make a script and schedule that job to run every 12 hours or so, taking a snapshot of every active job on the system. The key thing here is that the system thinks that memory is being used, even though the job that is using it won't be aware it is using it because it is leaking. So you can track it through the view of the memory on the system. You can run the command Roberto suggested in the shell script, appending it to a file, and run a parse script on that file, having it flag any growing jobs. Should be easy to write in one of the scripting languages. Or schedule the parse program as part of the shell script and have *it* write a file that contains a meaningful summary of the output. There is probably a tool designed for this specific purpose, though I'm not aware of it. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
