queue-runner: switch to pseudorandom ordering of builds processing

We don't rely on sequential / monotonic build IDs processing anymore, so
randomizing actually has the advantage of mixing builds for different
systems together, to avoid only one chunk of builds for a single system
getting processed while builders for other systems are starved.
This commit is contained in:
Pierre Bourdon 2024-04-20 22:49:24 +02:00
parent 6606a7f86e
commit 026e3a3103
Signed by untrusted user: delroth
GPG key ID: 6FB80DCD84DA0F1C

View file

@ -101,7 +101,7 @@ bool State::getQueuedBuilds(Connection & conn,
/* Grab the queued builds from the database, but don't process
them yet (since we don't want a long-running transaction). */
std::vector<BuildID> newIDs;
std::map<BuildID, Build::ptr> newBuildsByID;
std::unordered_map<BuildID, Build::ptr> newBuildsByID;
std::multimap<StorePath, BuildID> newBuildsByPath;
{
@ -112,7 +112,7 @@ bool State::getQueuedBuilds(Connection & conn,
"jobsets.name as jobset, job, drvPath, maxsilent, timeout, timestamp, "
"globalPriority, priority from Builds "
"inner join jobsets on builds.jobset_id = jobsets.id "
"where finished = 0 order by globalPriority desc, builds.id");
"where finished = 0 order by globalPriority desc, random()");
for (auto const & row : res) {
auto builds_(builds.lock());