summaryrefslogtreecommitdiff
path: root/doc/bugs/Too_much_system_load_on_startup.mdwn
diff options
context:
space:
mode:
authorGravatar https://www.google.com/accounts/o8/id?id=AItOawmuDUw7m3DQDBZZQuVoTKAZVR2Dl5-OXHs <Jason@web>2013-10-25 15:14:02 +0000
committerGravatar admin <admin@branchable.com>2013-10-25 15:14:02 +0000
commit21fe2ef3ee9b351697ce3d81a8422f4b60d682e0 (patch)
tree4c8310cf2a918625dbbe563665e33a957f7e57d5 /doc/bugs/Too_much_system_load_on_startup.mdwn
parentbffa931e31a53add4c15a51a3ade4f5300fdf1fc (diff)
Diffstat (limited to 'doc/bugs/Too_much_system_load_on_startup.mdwn')
-rw-r--r--doc/bugs/Too_much_system_load_on_startup.mdwn20
1 files changed, 20 insertions, 0 deletions
diff --git a/doc/bugs/Too_much_system_load_on_startup.mdwn b/doc/bugs/Too_much_system_load_on_startup.mdwn
new file mode 100644
index 000000000..9ee63f6d7
--- /dev/null
+++ b/doc/bugs/Too_much_system_load_on_startup.mdwn
@@ -0,0 +1,20 @@
+### Please describe the problem.
+When I log in, if git annex is monitoring a large repo, my desktop is very sluggish getting started. Git-annex causes moderate CPU load, but keeps the disk IO very busy -delaying the opening of desktop applications.
+
+### What steps will reproduce the problem?
+On Linux, with git-annex set to autostart and monitoring a folder with more than a few hundred files (I have a pdf library of a few thousand journal articles).
+
+### What version of git-annex are you using? On what operating system?
+4.20131002 Ubuntu, from Hess's PPA.
+
+### Please provide any additional information below.
+
+I solved this problem by changing the call to git-annex in /etc/xdg/autostart/git-annex.desktop from:
+
+Exec=/usr/bin/git-annex assistant --autostart
+
+to
+
+Exec=sleep 5 ionice -c 3 /usr/bin/git-annex assistant --autostart
+
+This delays the start of git-annex for 5 seconds, letting the desktop get started, and forces git-annex to yield IO to other programs -preventing it from slowing them down by forcing them to wait for disk access. Since this is a background daemon with potentially high IO usage, but no need for quick responsiveness, perhaps that would make a decent default?