graysky2 / profile-sync-daemon

Symlinks and syncs browser profile dirs to RAM thus reducing HDD/SDD calls and speeding-up browsers.
https://wiki.archlinux.org/index.php/Profile-sync-daemon
Other
910 stars 88 forks source link

psd possibly looking up the system #52

Closed dvzrv closed 11 years ago

dvzrv commented 11 years ago

Hey there!

I'm experiencing lookups lately (since I'm using psd) on my Archlinux system (laptop) with Gnome as DE. I'm not very sure if it is related to psd, or not, but I'll not use it the coming weeks and see if it shows the same results again.

There's no good way of actually knowing why the system locks up, but it only happened (so far) with firefox opened (synced with psd). Sometimes audio was running meanwhile, sometimes not. The system freezes/locks up (mouse freezes, everything else as well, no way of switching to another TTY or anything). Beforehand there are no signs of heavy resource usage (RAM and CPU are being used smoothly). After that I have to hard reset the computer (not so nice ;) ).

Was wondering if anyone else is experiencing similiar issues while using psd...

graysky2 commented 11 years ago

Tough to believe psd is to blame based on the info provided. How large is the profile (post the output of psd p and how much RAM is on the machine? How much is typically in use when you are browsing/using it normally? Is your Arch up-to-date?

dvzrv commented 11 years ago

I know, but since I disabled the service I haven't had that issue again (knocking on wood here). psd p: Profile-sync-daemon v5.40.1 on Arch Linux.

Systemd service is currently active. Systemd resync service is currently active.

Psd will manage the following per /etc/psd.conf settings:

browser/psname: firefox/firefox owner/group id: dave/100 sync target: /home/dave/.mozilla/firefox/david.runge tmpfs dir: /tmp/dave-firefox-david.runge profile size: 564M

browser/psname: chromium/chromium owner/group id: dave/100 sync target: /home/dave/.config/chromium tmpfs dir: /tmp/dave-chromium profile size: 31M

My Arch is up-to-date and there's 8GB of RAM available (so that should be more than enough). The issue usually took place after half a day of the system being powered on. Once, by coincidence I saw something in the journalctl that suggested gnome trying to index or maybe even clean up /tmp (something like "too many files to enumerate" by gnome-session or a similar process). I couldn't investigate that yet, as my journal is not set to be persistent.

graysky2 commented 11 years ago

Might want to switch your journal to write to troubleshoot. As an aside, your firefox profile is kinda large... have you tried profile-cleaner or manually cleaning it?

dvzrv commented 11 years ago

Yeah, I did (and just now again, -8MB). Most of the size was because of Cache growing. I limited that now... hope it'll help.

graysky2 commented 11 years ago

You might wanna totally move your cache out of your profile. See the psd man page for suggestions.

dvzrv commented 11 years ago

Hm, the man page doesn't suggest anything like that (actually quite the opposite?). But it seems to be a good idea to move it out of the profile and into plain tmpfs.

Anyhow... it seems that the issue is related to gnome{-shell,whatever} > 3.8 in conjunction with Firefox + psd (that'll be really really hard to debug though, as the journal doesn't provide any helpful data when this happens :/ ).

I've switched to awesome and I haven't experienced any lockup so far!

graysky2 commented 11 years ago

Glad to hear that. Love the avatar. Shall we close this issue then?