From cb1c8ddc70789967e8f92684e42a98fca3b8d889 Mon Sep 17 00:00:00 2001 From: Chris Lu Date: Thu, 5 Nov 2026 04:35:49 -0800 Subject: [PATCH] Document weed admin -adminLock.fairnessWindow --- Admin-UI.md | 1 + Plugin-Worker-Scheduling.md | 9 +++++++++ 2 files changed, 10 insertions(+) diff --git a/Admin-UI.md b/Admin-UI.md index 97f6e69..aed1416 100644 --- a/Admin-UI.md +++ b/Admin-UI.md @@ -46,6 +46,7 @@ weed admin [options] | `-debug.port` | 6060 | HTTP port for the pprof debug server | | `-cpuprofile` | "" | CPU profile output file, written on shutdown | | `-memprofile` | "" | Memory profile output file, written on shutdown | +| `-adminLock.fairnessWindow` | 1m | Once scheduled jobs have held the cluster admin lock this long, new jobs wait until every holder releases it, so `weed shell` clients get a turn. `0` lets jobs keep joining the hold; shell clients then get the lock when the scheduler next drains (see [[Plugin Worker Scheduling]]) | ## Network Binding diff --git a/Plugin-Worker-Scheduling.md b/Plugin-Worker-Scheduling.md index 9c58968..a30399c 100644 --- a/Plugin-Worker-Scheduling.md +++ b/Plugin-Worker-Scheduling.md @@ -125,6 +125,15 @@ takes the cluster admin lock, so anything in it is serialised behind vacuum and balancing; `iceberg`, `lifecycle` and `lance` do not, because they act on table data rather than on volumes. +The `default` lane takes the lock around each detection and each job, and +overlapping holds share one lease. Once that lease is older than +`weed admin -adminLock.fairnessWindow` (one minute by default), new jobs wait +until every running job releases it, so a waiting `weed shell` gets a turn. With +long jobs (EC vacuum or repair running for an hour) this dispatches in waves: a +freed worker slot stays idle until the slowest job of the wave ends. Setting the +window to `0` lets new jobs keep joining the hold; shell clients then get the +lock when the lane drains, at the latest between job types. + Lane assignment lives in the admin server, not in the worker: a new job type from an external worker lands in `default` until it is mapped, which silently serialises it behind cluster maintenance.