- User Since
- Jun 22 2011, 10:09 PM (539 w, 1 d)
May 9 2017
Staring a bit more at the data I just posted, it occurs to me that it seems kind of sluggish for an UPDATE like those -- one row, indexed by what I assume is the PRIMARY KEY -- to take 1-4ms or so, as these are. There's probably a DB (or network-to-DB?) performance issue there that we'd benefit broadly from addressing.
We're still seeing this issue pretty severely, on our shiny upgraded 2017 Week 17 version on our shiny new Phabricator host. So I took a look just now with DarkConsole.
This issue is in fact actually fixed 🎊 ! Most recently, moving to a new host with a newer PHP (and everything else, running Ubuntu 16.04 rather than 12.04) made a big difference; we've also made a lot of improvements to our Phabricator setup over the past year or so, some of which likely helped too.
Apr 18 2017
Just in my personal experience, I think it was sometime in the last 6 months that I realized Phabricator has a concept of "application search" and "global search", and that a lot of the searches I'd been doing were the latter and that's why they were so limited in functionality. I'd been using Phabricator for years and always had the sense that search didn't work very well, and that there were different forms I might get for it with different sets of fields, and it was unpredictable which one I'd get; but it wasn't until I became responsible for actually running Phabricator and started paying much closer attention to its concepts that I twigged to that pattern as the explanation for which searches got which form.
Apr 4 2017
I'm also slightly confused because, as someone just reminded me, the usual behavior of arc patch is to apply the patch to the appropriate base commit for the revision, not to try to do it on the current HEAD. In this context, that seems like it'd mean applying it directly to the arcpatch-A branch, rather than try to cherry-pick that commit up on top of where the user ran arc patch from.
Also T6482 seems like it's fixed. I've been quite appreciating how Arcanist is increasingly aware of dependencies between revisions.
Feb 28 2017
Jan 23 2017
Having a generated-paths variable in .arcconfig with a similar semantics to the differential.generated-paths server configuration -- something like D11537 a couple of years ago was intended to do -- would be really useful!
Jan 9 2017
Jan 4 2017
Dec 19 2016
We weren't running quite HEAD then, but we were running a version that was our patches on top of something about a week old -- see the end of the description of T11743, which was the first report in that chain. Our version today is a couple of months old, so I see why that'd feel different.
Oct 8 2016
This helped! Thanks for another fast fix.
Oct 7 2016
Thanks also for the tip about SIGHUP to get a backtrace! Had not known that, and it looks extremely useful.
Deployed this on our install, and it worked -- resolved all symptoms of T11743. Thanks again for the swift fix!
Oct 6 2016
Sweet -- thanks for the fast fix! I'll try applying it locally to clear out the affected tasks we have, and to make sure any new ones don't get me paged tonight. :-)
Thank you! Not every day someone invites me to cause a crash on their production server. :-D
Just made P2011, and I think that's a repro -- the "Show Details" link hangs.
Nope -- pstree shows no subprocesses when the worker is stuck.
Meaning here on secure.phabricator.com? Sure -- no guarantee it'll work, but I have some guesses I can throw at it.