Hello This is a problem I see on a lot of apps relying on sqlite (like firefox, evolution...). When I am using them for some months, they start to take more and more time to startup because their databases looks to not auto-vacuum (not sure if this is a bug or desired effect). Now, I have run the following: cd ~/.config/chromium/Default find -type f -exec file '{}' \; | perl -ne 'print "$1\n" if /(.*?): SQLite/' | while read fname; do sqlite3 "${fname}" VACUUM; sqlite3 "${fname}" REINDEX; done And it starts again much faster :) The problem is that I am sure I will need to manually rerun this in some weeks. I thought that maybe a more general script could be placed in cron.monthly to run vacuum on all user accounts if chromium process is not running. What do you think? Reproducible: Always
There are a couple of open bug reports upstream that mention vacuuming. These have been largely ignored by the chromium developers. http://code.google.com/p/chromium/issues/list?q=sqlite+vacuum My 2 cents: I don't really think a cron job is a good idea, but maybe we could document your workaround somewhere.
The problem is that that workarounds are around the web for firefox, evolution, chromium... and then, it makes this a bit annoying as I need to manually run them for all machines I maintain :(
(In reply to comment #0) > cd ~/.config/chromium/Default > find -type f -exec file '{}' \; | perl -ne 'print "$1\n" if /(.*?): SQLite/' > | while read fname; do > sqlite3 "${fname}" VACUUM; > sqlite3 "${fname}" REINDEX; > done The discussion on chromium-dev indicates it's unsafe to run this automatically. However, I'd be fine with including such a script in the www-client/chromium package (so it could be run manually). Does that sound good to you?
I am fine with it, but please wait a bit more as maybe we would be able to make a more complex script allowing it to detect if chromium is running and so. I am still around in upstream mailing list but won't probably be able to reply today as I don't have much time now :( Thanks a lot for your help on this :)
(In reply to comment #4) > I am fine with it, but please wait a bit more as maybe we would be able to > make a more complex script allowing it to detect if chromium is running and > so. I'm skeptical about that, and the most serious problem are race conditions. For manually running the script, such detection is not very helpful or needed anyway. The user knows whether chromium is running or not, and knows when the script finishes running.
OK, thanks for adding the script then :) (it should probably be enhanced a bit to show a warning to the users asking them to kill chromium before running)
Pushed to http://git.overlays.gentoo.org/gitweb/?p=proj/chromium-tools.git;a=summary
Nice, thanks :) I see it was moved to a "python version" ;)
(In reply to comment #7) > Pushed to > http://git.overlays.gentoo.org/gitweb/?p=proj/chromium-tools.git;a=summary How should people install that chromium-tools? Looks like they are not supplied in main tree, or I am looking in wrong place? Thanks for the info
(In reply to comment #9) > (In reply to comment #7) > > Pushed to > > http://git.overlays.gentoo.org/gitweb/?p=proj/chromium-tools.git;a=summary > > How should people install that chromium-tools? Looks like they are not > supplied in main tree, or I am looking in wrong place? Just clone the git repo. Suggestions how to handle this better are welcome (off-bugzilla if possible), but I'm not enthusiastic about creating a package just to install one script.
I gave up on using the script in the overlay - I think it was missing some python dependencies/etc and seemed like overkill. I just stuck the following in a script: cd ~/.config/chromium/Default find -type f -exec file '{}' \; | perl -ne 'print "$1\n" if /(.*?): SQLite/' | while read fname; do echo "sqlite3 \"${fname}\" VACUUM ; sqlite3 \"${fname}\" REINDEX" ; done | parallel (obviously based on previous contributions in this bug, and it does require gnu parallel) Probably wouldn't hurt to place suggestions on the wiki or a blog/etc. While a script in the tree would be ideal, all of this is a bit of a nice-to-have, and it is dangerous to run without care.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #7) > > > Pushed to > > > http://git.overlays.gentoo.org/gitweb/?p=proj/chromium-tools.git;a=summary > > > > How should people install that chromium-tools? Looks like they are not > > supplied in main tree, or I am looking in wrong place? > > Just clone the git repo. Suggestions how to handle this better are welcome > (off-bugzilla if possible), but I'm not enthusiastic about creating a > package just to install one script. Why not install it under /usr/share/doc? (we do a similar thing to install script for converting xscreensaver screensavers to gnome-screensaver files)
(In reply to comment #12) > (In reply to comment #10) > > (In reply to comment #9) > > > (In reply to comment #7) > > > > Pushed to > > > > http://git.overlays.gentoo.org/gitweb/?p=proj/chromium-tools.git;a=summary > > > > > > How should people install that chromium-tools? Looks like they are not > > > supplied in main tree, or I am looking in wrong place? > > > > Just clone the git repo. Suggestions how to handle this better are welcome > > (off-bugzilla if possible), but I'm not enthusiastic about creating a > > package just to install one script. > > Why not install it under /usr/share/doc? (we do a similar thing to install > script for converting xscreensaver screensavers to gnome-screensaver files) The script applies to both chromium and google-chrome. /usr/share/doc location itself is fine, the issue is more about how to handle dependencies and sharing between chromium and google-chrome (and also versioning of the script) while avoiding unnecessary duplication.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > > (In reply to comment #9) > > > > (In reply to comment #7) > > > > > Pushed to > > > > > http://git.overlays.gentoo.org/gitweb/?p=proj/chromium-tools.git;a=summary > > > > > > > > How should people install that chromium-tools? Looks like they are not > > > > supplied in main tree, or I am looking in wrong place? > > > > > > Just clone the git repo. Suggestions how to handle this better are welcome > > > (off-bugzilla if possible), but I'm not enthusiastic about creating a > > > package just to install one script. > > > > Why not install it under /usr/share/doc? (we do a similar thing to install > > script for converting xscreensaver screensavers to gnome-screensaver files) > > The script applies to both chromium and google-chrome. /usr/share/doc > location itself is fine, the issue is more about how to handle dependencies > and sharing between chromium and google-chrome (and also versioning of the > script) while avoiding unnecessary duplication. It is still a big improvement in "accessibility" to install it in /usr/share/doc over needing to figure out that I need to clone that git repo that is mostly unknown for userbase. Also, current script looks to work over .chromium, if I don't misremember google-chrome used a different config dir under /home :/
Other option would be to add an ebuild for installing that chromium-tools package... because currently this script is completely hidden to administrators
I think this whole idea is hacky and should not be in the tree at all.
