Skip to content

v0.15.0

Choose a tag to compare

@github-actions github-actions released this 16 Oct 14:02
· 32 commits to main since this release

A task that sizes itself by LOADMASTER_WEIGHT can now start with the cores that are left instead of waiting for its whole weight: set min_weight. Every job that may start now starts at once, in line order. The queue moves to a new admission protocol for this, once the jobs of 0.12 to 0.14 in it are done: upgrade every agent on a machine at once.

Added

  • min_weight, per task: the fewest cores it may start with, from 1 to its weight. The job then starts with the most cores between that and its weight that fit beside what runs and waits ahead of it, and LOADMASTER_WEIGHT says how many. Set it only for a task that sizes its workers by LOADMASTER_WEIGHT (vitest --maxWorkers=$LOADMASTER_WEIGHT), which runs longer with fewer: in a simulation of a day of agents' checks on 8 cores, it cut the mean time from getting in line to the end by 30 to 45%. A task without it always starts with its weight. A task that holds a scarce resource (a browser, a database) holds it longer with fewer cores, which may keep others waiting longer than it gains. Like a weight, a min_weight above the machine's capacity counts as all of it, so a repository's settings work on a small CI runner too.
  • Jobs behind one that may start with fewer cores leave room for it to start with its min_weight, and still count it at its weight. No job is delayed, or started with fewer cores, by the jobs that got in line after it, and the jobs that start never take the machine past a limit.
  • status, status --json (protocol, moving, each job's min_weight, wait.cores), check, check --scenario, the history and report (a row of its own for each min_weight, shown as 4 (from 1)) show the least each task may start with.

Changed

  • Every job that may start now starts at once. The first waiting loadmaster that finds jobs that may start starts all of them, in line order, in one transaction; each one's loadmaster finds its job started on its next poll. Before, each job started on its own poll.
  • A run that gives up and is started meanwhile by another waiting loadmaster runs instead of parking.
  • A job's time in line (the history's queued_at, enqueued_at_ms in status --json) counts from when its run asked for a place, so a wait while the queue moves counts as waiting.

Breaking changes

  • The queue moves to protocol 2. The first 0.15 to open a queue of 0.12 to 0.14 closes it to new jobs: runs of 0.12 to 0.14 then fail and say to upgrade, and runs of 0.15 wait without a place in line, as long as --max-wait allows (exit code 75, no place kept). The jobs already in it finish by their own loadmaster's rule; running jobs are never stopped. Once it is empty, the first 0.15 moves it, and 0.12 to 0.14 cannot use it any more. The queue file stays queue-v4.db.
  • CPU busy outside the queue lowers what a job with min_weight starts with, never below its min_weight. A task without min_weight now always starts with its weight, never with fewer: give it a min_weight to have it start with fewer while the CPU is busy.
  • A nested loadmaster run must fit in the cores its holder got, not the holder's weight: a holder that started with 2 of 8 no longer runs an inner task of weight 4. An inner task with min_weight runs if that fits, with the holder's LOADMASTER_WEIGHT.

Install

mise use -g github:ktanaka101/loadmaster@0.15.0

Or download the archive for your platform below: macOS (Apple Silicon and Intel) and Linux (x86_64 and arm64, statically linked).