1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-10 00:42:41 +01:00
No description
Find a file
epriestley 22c64c67ff Fix performance problem for large task queues
Summary:
Some time ago, we added `ORDER BY id ASC` to the worker `UPDATE ...` query, because someone reported that their MySQL read slaves were complaining about the query (I can't find the exact error message, but something to the effect of the rows the query affected not being deterministic). This seemed harmless since it should be the same as the query's implicit order (I guess?), but actually made the query dramatically slower for large numbers of rows.

On my local machine, this query takes about 2 seconds with ~1M rows. If I run `SELECT`, or run `UPDATE` without ORDER BY, the query takes < 0.01s. I don't understand exactly what's happening -- my guess is something to do with the ORDER BY implying that a lot of rows need to be locked?

In T2372, a user is seeing 20-60s rumtimes on this query.

I solved this by doing a SELECT, followed by an UPDATE. Each query runs quickly. This introduces the possibility of a race (two processes SELECT the same rows, then try to UPDATE), which we currently recover from by having the second UPDATE fail and then having that daemon try again 1 second later. This seems generally reasonable. Some alternatives I considered:

  - We could SELECT ... LOCK FOR UPDATE, but failing and retrying a little later seems at least as good as blocking.
  - We could select more rows than we need, and then try to lock some of them randomly. I think this would work well, but it's a bit more complex than what we're doing now so I left it until we have a clearer need.

Test Plan:
Inserted ~1M tasks into the queue. Ran `phd debug taskmaster`, saw ~2s task updates. Applied patch. Ran `phd debug taskmaster`, saw <1ms updates. Ran `phd launch 8 taskmaster`, saw rapid completion of tasks.

This stuff also has fairly thorough unit test coverage.

Reviewers: vrana, btrahan

Reviewed By: vrana

CC: aran

Maniphest Tasks: T2372

Differential Revision: https://secure.phabricator.com/D4576
2013-01-22 12:27:18 -08:00
bin Port Diviner Core to Phabricator 2013-01-07 14:04:23 -08:00
conf Added beta status for applications 2013-01-19 10:31:28 -08:00
externals one more phame tweak for better social sharing -- make sure $uri is the full uri 2012-12-21 13:46:23 -08:00
resources Use white "+" icon for homepage tile hoverstate 2013-01-22 09:56:18 -08:00
scripts Remove legacy support for 'phd repository-launch' and 'phd repository-launch-readonly' 2013-01-22 12:26:08 -08:00
src Fix performance problem for large task queues 2013-01-22 12:27:18 -08:00
support Consolidate environmental initialization 2012-12-25 06:15:28 -08:00
webroot Use white "+" icon for homepage tile hoverstate 2013-01-22 09:56:18 -08:00
.arcconfig Delete license headers from files 2012-11-05 11:16:51 -08:00
.divinerconfig Centralize rendering of application mail bodies 2012-07-16 19:01:43 -07:00
.editorconfig Specify config for text editors 2012-11-03 22:34:44 -07:00
.gitignore Add a local configuration source and a non-environmental ENV config source 2012-12-30 06:16:15 -08:00
.gitmodules Just change the location. 2011-05-28 15:14:54 -07:00
LICENSE Delete license headers from files 2012-11-05 11:16:51 -08:00
NOTICE Increment year. 2013-01-03 05:45:08 -08:00
README Delete license headers from files 2012-11-05 11:16:51 -08:00

Phabricator is a open source collection of web applications which make it easier
to write, review, and share source code. Phabricator was developed at Facebook.

This is an early release. It's pretty high-quality and usable, but under
active development so things may change quickly.

You can learn more about the project and find links to documentation and
resources at: http://phabricator.org/

LICENSE

Phabricator is released under the Apache 2.0 license except as otherwise noted.