Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
I'm @ethomson, a member of GitHub's Git Infrastructure team, which is responsible for ensuring that GitHub's file servers are nice and healthy and serving
I'm opening this issue because we have been periodically detecting very high load on the syl20bnr/spacemacs repository. When this occurs, we will begin applying quotas to actions on this repository, and automatically delaying
After some brief investigation, I suspect that much of this load is coming from the automatic update mechanism. (I regret that I am not an emacs user, and not super familiar with Emacs Lisp, so I apologize in advance if I'm misinterpreting the update mechanism.)
It looks like spacemacs is doing a
Reducing this from 3 operations to 1 when checking for updates would reduce the number of concurrent git operations significantly. This would speed up the new version check in all cases, but this would be an especially helpful change when the fetches are slow (for example, when we're intentionally slowing them down
I think that this change alone would be enough to bring the syl20bnr/spacemacs repository back into a place where it's healthy and we are not applying quotas to it. But I would also encourage you to limit the frequency with which you poll -- at present, it looks like you're checking for updates at startup. This seems reasonable for people who keep their emacs running and use a mechanism like
Finally, using a cheaper
Apologies for the wall of text, and thanks for reading.
@ethomson I pushed the fixes to the develop branch. They will be merged to master this month when the new release is ready, you may not see any improvement until the fixes are merged. I can check to backport them sooner if you really want me to do it.
The fixes consist of the following changes:
If we still popup in your monitoring with these changes then it would mean that Spacemacs is more popular than Atom
(or we have a bug....
No, there's definitely no need for that. :) If we detect very high load again, we'll rate limit and slow down concurrent
If you're happy, we're happy.
@gerrywastaken Indeed you are right I made an opt-in for a different reason.
We could makes this more explicit and add a question to the wizard though.