User Details
- User Since
- May 31 2013, 9:50 AM (605 w, 1 d)
- Availability
- Available
May 28 2017
I can confirm T12129 is indeed related, and the suggested workaround is very effective. Thanks for this!
For the record, our repo has about 60 branches total (about a dozen active only).
Jan 22 2017
Erm… I was just asking for time repository update on the repository you have already cloned, hence the 15 seconds. If I understand this correctly, you seem to indicate that it would still be too much. I'm having a hard time understanding, but if you're adamant about this, then there is nothing left to say :)
Jan 21 2017
What'd be the fee for that 1 second command and a 5 second copy/paste?
Jan 20 2017
Could you at least give me the time output for the broken/test repository update on your test system, so that I have a baseline for comparison later? Thanks!
We are certainly not going to engage into paid consulting without knowing how long it might take to solve the problem, given your hourly rate :)
I would have appreciated at least a tiny hint on how to solve this ourselves instead, so I guess I'm going to dive into the code and implement a workaround somewhere. For example, tinkering with the $smart_wait calculation might be a start.
I was afraid this would happen. However, short of giving you access to our server, there is no way I can exactly describe our setup: there are fare too many variables. Perhaps we could narrow it down a bit? What could be a factor here? The obvious non-standard features of our setup are :
- linux-vserver
- 32bit userland
- LVM on soft raid
- daemon user = web user
That said, I can't understand why the same user can run hg log with negligible CPU impact, and run the same hg log through phabricator with significant performance impact. Clearly phabricator does something in addition to calling mercurial that is causing the problem, and I don't know what it could be. That's where your input would help :-)
Jan 19 2017
The repository at https://bitbucket.org/LeCoyote/brokentest is enough to see unusual CPU usage. Of course, it is nowhere near as bad as the other one, but the CPU is still coasting a noticeable 2 or 3% above average, which seems disproportionate for such a small repo. Also, when calling the update manually:
$ time ./bin/repository update 3 Updated repository "cieltest".
Noted. I'll try and reproduce the problem with a different repository.
Unless you can make this task private to a group of people who would be prepared to sign a NDA in French, that's not going to happen.