@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
Undocument running multiple/dedicated pull daemons
Summary: In modern Phabricator, we should pretty much handle this automatically, and this advice is no longer very reasonable. See <https://github.com/phacility/phabricator/issues/660>
Test Plan: Read documentation.
Reviewers: chad, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D9738
+2
-44
+2
-44
src/docs/user/userguide/diffusion.diviner
+2
-44
src/docs/user/userguide/diffusion.diviner
···
88
88
89
89
You can use the repository detail screen and the Daemon Console to monitor the
90
90
daemons and their progress importing the repository. Small repositories should
91
-
import quickly, while larger repositories may take some time (it takes about 10
92
-
minutes to begin discovering commits in Facebook's 350,000-commit primary
93
-
repository, and about 18 hours to import it all with 64 taskmasters on modern
94
-
hardware). Commits should begin appearing in Diffusion within a few minutes for
95
-
all but the largest repositories.
96
-
97
-
== Tuning Daemons ==
98
-
99
-
By default, Phabricator launches one daemon to pull and discover all of the
100
-
tracked repositories. This works well for a small number of repositories or
101
-
a large number of relatively inactive repositories, but might benefit from
102
-
tuning in some cases. The daemon makes a rough effort to respect pull
103
-
frequencies defined in repository configuration, but may not be able to import
104
-
new commits very quickly if you have a large number of repositories (as it is
105
-
blocked waiting on I/O from other repositories).
106
-
107
-
If you want to provide lower commit import latency for some repositories, you
108
-
can either launch **more daemons** (which will generally lower latency for all
109
-
repositories) or launch additional **dedicated daemons** (which will give you
110
-
very fine-grained control over import latency).
111
-
112
-
=== More Daemons ===
113
-
114
-
The coarse approach to reducing import latency is to simply launch more daemons,
115
-
using `phd`:
116
-
117
-
phabricator/bin $ ./phd launch RepositoryPullLocal
118
-
119
-
This will launch another copy of the daemon. The daemons acquire a global lock
120
-
before pulling a repository, so you can launch additional daemons without
121
-
causing contention or race conditions.
122
-
123
-
=== Dedicated Daemons ===
124
-
125
-
You can take a more fine-grained approach and launch dedicated daemons for
126
-
specific repositories or groups of repositories. For example, if you want low
127
-
latency on the repositories with callsigns `A` and `B`, but don't care about
128
-
latency for the other repositories, you could launch two daemons like this:
129
-
130
-
phabricator/bin $ ./phd launch RepositoryPullLocal -- A B
131
-
phabricator/bin $ ./phd launch RepositoryPullLocal -- --not A --not B
132
-
133
-
The first one will work only on `A` and `B`, and should be able to import
134
-
commits with low latency more reliably. The second one will work on all other
91
+
import quickly, while larger repositories may take some time. Commits should
92
+
begin appearing in Diffusion within a few minutes for all but the largest
135
93
repositories.
136
94
137
95
= Next Steps =