Bencher runner CLI

runner up

Startet den Runner und fragt Benchmark-Jobs ab und führt sie aus. Dies ist der langlaufende Befehl zum Betrieb eines Self-Hosted Runner. Der Runner öffnet eine einzige WebSocket-Verbindung zum API-Server, beansprucht Jobs, die zu seinen Specs passen, führt sie aus und meldet die Ergebnisse zurück. Der Runner schreibt sein Log als JSON nach stderr, ein Objekt pro Zeile, und protokolliert die Ausgabe eines Jobs nur als Byte-Anzahl.

runner up [OPTIONS]

Optionen

--host <HOST>

Der Bencher API-Server, zu dem eine Verbindung hergestellt werden soll. Standardmäßig wird https://api.bencher.dev verwendet. Kann auch mit der Umgebungsvariable BENCHER_HOST gesetzt werden.

--runner <RUNNER>

Die UUID oder der Slug des Runner, als der agiert werden soll. Kann auch mit der Umgebungsvariable BENCHER_RUNNER gesetzt werden.

--key <KEY>

Der Runner-Authentifizierungsschlüssel (bencher_runner_...), der zurückgegeben wurde, als der Runner erstellt wurde. Kann auch mit der Umgebungsvariable BENCHER_RUNNER_KEY gesetzt werden.

--poll-timeout <POLL_TIMEOUT>

Das Long-Poll-Timeout in Sekunden beim Warten auf einen Job, zwischen 1 und 900. Standardmäßig wird 55 verwendet.

--state-dir <STATE_DIR>

Das persistente Zustandsverzeichnis für den Runner. Es muss ein absoluter Pfad sein. Das Jail, das die Sandbox einschließt, wird unter diesem Verzeichnis erstellt, und Jails, die durch eine unsaubere Beendigung zurückgeblieben sind, werden vor jedem Sandbox-Job daraus entfernt. Jedes Jail enthält ein vollständiges Gast-Root-Dateisystem und eine Kopie der microVM-Binärdatei, und ein Runner führt seine Jobs nacheinander aus, daher braucht dieses Verzeichnis echte Kapazität für ein Jail. Mit --image-cache-size enthält es zusätzlich den Image-Cache, bis zu dieser Größe. Auf einem Host läuft immer nur ein Runner, unabhängig von seinem Zustandsverzeichnis: Ein als root gestarteter Runner hält die Sperre /run/bencher/runner.lock, solange er läuft, und ein zweiter, als root gestarteter beendet sich sofort mit einem Fehler, der diese Sperre nennt; ein Runner, der nicht als root läuft, kann die Sperre nicht öffnen und läuft ohne sie. Beim Start und erneut vor jedem Sandbox-Job beendet ein als root gestarteter Runner jeden Prozess, der noch in einer Cgroup unter /sys/fs/cgroup/bencher läuft, etwa die Sandbox eines Runners, der mitten in einem Job beendet wurde, unabhängig vom Zustandsverzeichnis dieses Runners. Ein eigenes Dateisystem oder ein tmpfs-Mount wird unterstützt und empfohlen: es hält diese Schreiblast von der Systemplatte fern, und ein neu erstelltes Dateisystem wird akzeptiert, auch wenn es ein lost+found-Verzeichnis mitbringt. Das Dateisystem darf nicht mit nodev oder noexec eingehängt sein, wie es /tmp, /dev/shm und /run oft sind; hängen Sie dafür also ein tmpfs ohne diese Optionen ein. Das Zustandsverzeichnis selbst darf ein von root angelegter symbolischer Link auf ein solches Dateisystem sein, etwa /var/lib/bencher-runner auf eine eigene Platte. Dem Link wird nur gefolgt, wenn das Verzeichnis, das ihn enthält, nur von root beschreibbar ist, er direkt auf sein endgültiges Ziel zeigt und dieses Ziel bereits auf einem nur von root beschreibbaren Pfad existiert; ein Link, dessen Ziel noch nicht existiert, wird abgelehnt, also zuerst das Ziel anlegen. Standardmäßig wird /var/lib/bencher-runner verwendet. Kann auch mit der Umgebungsvariable BENCHER_STATE_DIR gesetzt werden.

--jail-uid <JAIL_UID>

Die unprivilegierte Benutzer-ID, auf die der Sandbox-Prozess wechselt. Standardmäßig wird 61016 verwendet. Sie darf nicht 0 sein. Ein Prozess auf dem Host, dem diese Benutzer-ID gehört, kann Signale an die Sandbox senden, setzen Sie sie also auf eine ID, die der Host nichts anderem zuweist. Kann auch mit der Umgebungsvariable BENCHER_JAIL_UID gesetzt werden.

--jail-gid <JAIL_GID>

Die unprivilegierte Gruppen-ID, auf die der Sandbox-Prozess wechselt. Standardmäßig wird 61016 verwendet. Sie darf nicht 0 sein. Kann auch mit der Umgebungsvariable BENCHER_JAIL_GID gesetzt werden.

--danger-allow-no-sandbox

Erlaubt das Ausführen von Jobs ohne Sandbox. Ohne dieses Flag wird ein Job, dessen Spec keine Sandbox hat, zur Laufzeit abgelehnt. Jobs ohne Sandbox laufen direkt auf dem Host, aktivieren Sie dies also nur für vertrauenswürdige Workloads. Kann auch mit der Umgebungsvariable BENCHER_DANGER_ALLOW_NO_SANDBOX gesetzt werden.

--sandbox-log-level <SANDBOX_LOG_LEVEL>

Das Log-Level für den Sandbox-Prozess. Standardmäßig wird warning verwendet.

--no-raid-pause

Weiterhin Jobs annehmen, während ein md-RAID-Array auf dem Host resynchronisiert, wiederherstellt, prüft, repariert oder umformt. Standardmäßig prüft der Runner seine md-Arrays, bevor er nach jedem Job fragt, und solange eines davon einen dieser Vorgänge ausführt, pausiert er: Er nimmt keinen neuen Job an, bis die Synchronisierung abgeschlossen ist, und er stoppt nie einen Job, der bereits läuft. Ein pausierter Runner bleibt verbunden und aktualisiert sich weiterhin selbst.

--no-auto-update

Deaktiviert automatische Updates vom Server. Standardmäßig aktualisiert sich der Runner zwischen Jobs selbst, wenn der Server eine neue Version anbietet. Kann auch mit der Umgebungsvariable BENCHER_NO_AUTO_UPDATE gesetzt werden.

--update-channel <UPDATE_CHANNEL>

Der Update-Kanal für automatische Updates, entweder stable oder canary. Standardmäßig wird stable verwendet. Der stable-Kanal aktualisiert auf versionierte Releases. Der canary-Kanal folgt dem rollierenden Canary-Build, der neu gebaut wird, wann immer sich der Runner bei einem Bencher Cloud-Deployment ändert. Kann auch mit der Umgebungsvariable BENCHER_UPDATE_CHANNEL gesetzt werden. Steht im Konflikt mit --no-auto-update.

--max-download-size <MAX_DOWNLOAD_SIZE>

Die maximale Download-Größe in Bytes für Self-Update-Binaries. Standardmäßig werden 500 MiB verwendet. Steht im Konflikt mit --no-auto-update.

--image-cache-size <IMAGE_CACHE_SIZE>

Die maximale Größe in Bytes der Image-Blobs, die der Runner über Jobs hinweg behält. Der Runner behält die Config- und Layer-Blobs jedes Image, das er herunterlädt, in blobs unter seinem --state-dir, sodass ein Job nur die Blobs herunterlädt, die der Runner noch nicht hat, das Manifest seines Image aber trotzdem jedes Mal aus der Registry abruft. Zwischen Jobs entfernt der Runner die am längsten nicht verwendeten Blobs, bis der Rest in diese Größe passt. Beim Start legt der Runner den Speicher an und macht ihn zu seinem eigenen; kann er das nicht, beendet er sich sofort mit einem Fehler, der das Verzeichnis nennt. Standardmäßig, oder mit 0, behält der Runner keine Blobs über Jobs hinweg und entfernt alle, die er zuvor behalten hat. Kann auch mit der Umgebungsvariable BENCHER_IMAGE_CACHE_SIZE gesetzt werden.

--max-output-size <MAX_OUTPUT_SIZE>

Die maximale Größe in Bytes für erfasstes stdout und stderr. Standardmäßig werden 25 MiB verwendet.

--max-file-count <MAX_FILE_COUNT>

Die maximale Anzahl an Ausgabedateien, die dekodiert werden. Standardmäßig wird 255 verwendet.

--max-symlinks <MAX_SYMLINKS>

Die maximale Anzahl an Symlinks, denen bei der Pfadauflösung gefolgt wird, entsprechend dem MAXSYMLINKS-Limit des Linux-Kernels. Standardmäßig wird 40 verwendet. Wird nur im Modus ohne Sandbox verwendet.

Host-Tuning

Vor jedem Benchmark wendet der runner Host-Tuning an, um Messrauschen zu reduzieren. Standardmäßig deaktiviert er ASLR, den NMI-Watchdog, SMT / Hyper-Threading und Turbo Boost; setzt den CPU-Scaling-Governor auf performance, Swappiness auf 10 und perf_event_paranoid auf -1. Auf einem Host, auf den der runner seit dem letzten Neustart kein Host-Tuning angewendet hat, belassen die folgenden Flags einzelne Optimierungen stattdessen bei ihren Host-Standardwerten.

Das Host-Tuning bleibt bis zum Neustart des Hosts bestehen: Jede Einstellung ist ein reiner Laufzeit-Schreibvorgang, den der runner beim Beenden nicht zurücksetzt, mit Ausnahme der C-State-Sperre, die endet, wenn sich der runner beendet. Nach einem Lauf mit Host-Tuning wirkt ein Flag, das eine andere Einstellung überspringt, erst ab dem nächsten Neustart: Bis dahin behält die Einstellung ihren getunten Wert, und der runner protokolliert diesen Wert beim Start. Starten Sie einen gemeinsam genutzten Host neu, nachdem Sie den runner entfernt haben.

--no-tuning

Deaktiviert alle Host-Tuning-Optimierungen.

--aslr

Deaktiviert ASLR nicht (Standard: für Benchmarks deaktiviert).

--nmi-watchdog

Deaktiviert den NMI-Watchdog nicht (Standard: für Benchmarks deaktiviert).

--smt

Deaktiviert SMT / Hyper-Threading nicht (Standard: für Benchmarks deaktiviert).

--turbo

Deaktiviert Turbo Boost nicht (Standard: für Benchmarks deaktiviert).

--numa-balancing

Deaktiviert das automatische NUMA-Balancing nicht (Standard: für Benchmarks deaktiviert).

--timer-migration

Deaktiviert die Timer-Migration nicht (Standard: für Benchmarks deaktiviert).

--soft-watchdog

Deaktiviert den Soft-Lockup-Watchdog nicht (Standard: für Benchmarks deaktiviert).

--ksm

Deaktiviert KSM, das Kernel Samepage Merging, nicht (Standard: für Benchmarks deaktiviert).

--cstates

Deaktiviert tiefe C-States nicht (Standard: für Benchmarks deaktiviert).

--no-irq-steering

Lenkt Geräte-IRQs und Kernel-Workqueues nicht auf Housekeeping-Kerne.

--no-cpuset-partition

Löst Benchmark-Kerne nicht über eine isolierte cpuset-Partition vom Scheduler.

--swappiness <SWAPPINESS>

Setzt den Swappiness-Wert. Standardmäßig wird 10 verwendet.

--governor <GOVERNOR>

Setzt den CPU-Scaling-Governor. Standardmäßig wird performance verwendet.

--perf-event-paranoid <PERF_EVENT_PARANOID>

Setzt den perf_event_paranoid-Wert. Standardmäßig wird -1 verwendet.

--thp <THP>

Setzt den Transparent-Hugepage-Modus des Hosts: never, madvise, always oder leave. Mit leave bleibt der aktuelle Modus des Hosts erhalten. Standardmäßig wird never verwendet.

--help

Hilfe ausgeben.

runner run

Lädt ein Image herunter, erstellt ein rootfs und führt es einmal auf dem lokalen Host aus. Anders als runner up stellt dies keine Verbindung zu einem API-Server her und beansprucht keinen Job. Es führt ein einzelnes Image direkt aus, was zum Testen und Debuggen eines Runner-Hosts oder eines Image nützlich ist, bevor echte Jobs eingereicht werden. Die Ausgabe des Image geht unverändert nach stdout und stderr, und das eigene Log des Runners geht als JSON nach stderr, ein Objekt pro Zeile.

runner run --image <IMAGE> [OPTIONS]

Optionen

--image <IMAGE>

Das auszuführende OCI Image, als lokaler Pfad oder als Registry-Referenz.

--token <TOKEN>

Ein JWT-Token für die Registry-Authentifizierung beim Herunterladen des Image.

--sandbox <SANDBOX>

Der Sandbox-Modus für die Benchmark-Ausführung. Verwenden Sie firecracker für eine Firecracker-microVM (nur Linux). Lassen Sie es für die Ausführung auf dem Host ohne Sandbox weg.

--timeout <TIMEOUT>

Das Ausführungs-Timeout in Sekunden, das sich alle Iterationen ab dem Start des Laufs teilen. Standardmäßig wird 300 verwendet.

--state-dir <STATE_DIR>

Das persistente Zustandsverzeichnis für den Runner. Es muss ein absoluter Pfad sein. Das Jail, das die Sandbox einschließt, wird unter diesem Verzeichnis erstellt, und Jails, die durch eine unsaubere Beendigung zurückgeblieben sind, werden vor jedem Sandbox-Job daraus entfernt. Jedes Jail enthält ein vollständiges Gast-Root-Dateisystem und eine Kopie der microVM-Binärdatei, und ein Runner führt seine Jobs nacheinander aus, daher braucht dieses Verzeichnis echte Kapazität für ein Jail. Auf einem Host läuft immer nur ein Runner, unabhängig von seinem Zustandsverzeichnis: Ein als root gestarteter Runner hält die Sperre /run/bencher/runner.lock, solange er läuft, und ein zweiter, als root gestarteter beendet sich sofort mit einem Fehler, der diese Sperre nennt; ein Runner, der nicht als root läuft, kann die Sperre nicht öffnen und läuft ohne sie. Beim Start und erneut vor jedem Sandbox-Job beendet ein als root gestarteter Runner jeden Prozess, der noch in einer Cgroup unter /sys/fs/cgroup/bencher läuft, etwa die Sandbox eines Runners, der mitten in einem Job beendet wurde, unabhängig vom Zustandsverzeichnis dieses Runners. Ein eigenes Dateisystem oder ein tmpfs-Mount wird unterstützt und empfohlen: es hält diese Schreiblast von der Systemplatte fern, und ein neu erstelltes Dateisystem wird akzeptiert, auch wenn es ein lost+found-Verzeichnis mitbringt. Das Dateisystem darf nicht mit nodev oder noexec eingehängt sein, wie es /tmp, /dev/shm und /run oft sind; hängen Sie dafür also ein tmpfs ohne diese Optionen ein. Das Zustandsverzeichnis selbst darf ein von root angelegter symbolischer Link auf ein solches Dateisystem sein, etwa /var/lib/bencher-runner auf eine eigene Platte. Dem Link wird nur gefolgt, wenn das Verzeichnis, das ihn enthält, nur von root beschreibbar ist, er direkt auf sein endgültiges Ziel zeigt und dieses Ziel bereits auf einem nur von root beschreibbaren Pfad existiert; ein Link, dessen Ziel noch nicht existiert, wird abgelehnt, also zuerst das Ziel anlegen. Standardmäßig wird /var/lib/bencher-runner verwendet. Kann auch mit der Umgebungsvariable BENCHER_STATE_DIR gesetzt werden.

--jail-uid <JAIL_UID>

Die unprivilegierte Benutzer-ID, auf die der Sandbox-Prozess wechselt. Standardmäßig wird 61016 verwendet. Sie darf nicht 0 sein. Ein Prozess auf dem Host, dem diese Benutzer-ID gehört, kann Signale an die Sandbox senden, setzen Sie sie also auf eine ID, die der Host nichts anderem zuweist. Kann auch mit der Umgebungsvariable BENCHER_JAIL_UID gesetzt werden.

--jail-gid <JAIL_GID>

Die unprivilegierte Gruppen-ID, auf die der Sandbox-Prozess wechselt. Standardmäßig wird 61016 verwendet. Sie darf nicht 0 sein. Kann auch mit der Umgebungsvariable BENCHER_JAIL_GID gesetzt werden.

--iter <ITER>

Die Anzahl der auszuführenden Benchmark-Iterationen. Standardmäßig wird 1 verwendet.

--allow-failure

Erlaubt einen Benchmark-Fehlschlag, ohne die verbleibenden Iterationen kurzzuschließen. Läuft die Zeit ab, endet der Lauf trotzdem mit einem Timeout. Ein Image, das nicht heruntergeladen oder vorbereitet werden kann, beendet den Lauf ebenfalls.

--entrypoint <ENTRYPOINT>

Überschreibt den Container-Entrypoint. Kann mehrfach angegeben werden.

--cmd <CMD>

Überschreibt den Container-Befehl. Kann mehrfach angegeben werden.

--env <ENV>

Setzt eine Umgebungsvariable im Format KEY=VALUE. Kann mehrfach angegeben werden.

--network

Aktiviert Netzwerkzugriff innerhalb der VM.

--output <OUTPUT>

Ein Ausgabedateipfad innerhalb des Gasts, der erfasst werden soll. Kann mehrfach angegeben werden.

--vcpus <VCPUS>

Überschreibt die Anzahl der vCPUs (zum Testen).

--memory <MEMORY>

Überschreibt den Arbeitsspeicher in MiB (zum Testen).

--disk <DISK>

Überschreibt die Festplattengröße in MiB (zum Testen).

--max-output-size <MAX_OUTPUT_SIZE>

Die maximale Größe in Bytes für erfasstes stdout und stderr. Standardmäßig werden 25 MiB verwendet.

--max-file-count <MAX_FILE_COUNT>

Die maximale Anzahl an Ausgabedateien, die dekodiert werden. Standardmäßig wird 255 verwendet.

--max-symlinks <MAX_SYMLINKS>

Die maximale Anzahl an Symlinks, denen bei der Pfadauflösung gefolgt wird, entsprechend dem MAXSYMLINKS-Limit des Linux-Kernels. Standardmäßig wird 40 verwendet. Wird nur im Modus ohne Sandbox verwendet und steht daher im Konflikt mit --sandbox.

--sandbox-log-level <SANDBOX_LOG_LEVEL>

Das Log-Level für den Sandbox-Prozess. Erfordert --sandbox. Standardmäßig wird warning verwendet.

Host-Tuning

Vor jedem Benchmark wendet der runner Host-Tuning an, um Messrauschen zu reduzieren. Standardmäßig deaktiviert er ASLR, den NMI-Watchdog, SMT / Hyper-Threading und Turbo Boost; setzt den CPU-Scaling-Governor auf performance, Swappiness auf 10 und perf_event_paranoid auf -1. Auf einem Host, auf den der runner seit dem letzten Neustart kein Host-Tuning angewendet hat, belassen die folgenden Flags einzelne Optimierungen stattdessen bei ihren Host-Standardwerten.

Das Host-Tuning bleibt bis zum Neustart des Hosts bestehen: Jede Einstellung ist ein reiner Laufzeit-Schreibvorgang, den der runner beim Beenden nicht zurücksetzt, mit Ausnahme der C-State-Sperre, die endet, wenn sich der runner beendet. Nach einem Lauf mit Host-Tuning wirkt ein Flag, das eine andere Einstellung überspringt, erst ab dem nächsten Neustart: Bis dahin behält die Einstellung ihren getunten Wert, und der runner protokolliert diesen Wert beim Start. Starten Sie einen gemeinsam genutzten Host neu, nachdem Sie den runner entfernt haben.

--no-tuning

Deaktiviert alle Host-Tuning-Optimierungen.

--aslr

Deaktiviert ASLR nicht (Standard: für Benchmarks deaktiviert).

--nmi-watchdog

Deaktiviert den NMI-Watchdog nicht (Standard: für Benchmarks deaktiviert).

--smt

Deaktiviert SMT / Hyper-Threading nicht (Standard: für Benchmarks deaktiviert).

--turbo

Deaktiviert Turbo Boost nicht (Standard: für Benchmarks deaktiviert).

--numa-balancing

Deaktiviert das automatische NUMA-Balancing nicht (Standard: für Benchmarks deaktiviert).

--timer-migration

Deaktiviert die Timer-Migration nicht (Standard: für Benchmarks deaktiviert).

--soft-watchdog

Deaktiviert den Soft-Lockup-Watchdog nicht (Standard: für Benchmarks deaktiviert).

--ksm

Deaktiviert KSM, das Kernel Samepage Merging, nicht (Standard: für Benchmarks deaktiviert).

--cstates

Deaktiviert tiefe C-States nicht (Standard: für Benchmarks deaktiviert).

--no-irq-steering

Lenkt Geräte-IRQs und Kernel-Workqueues nicht auf Housekeeping-Kerne.

--no-cpuset-partition

Löst Benchmark-Kerne nicht über eine isolierte cpuset-Partition vom Scheduler.

--swappiness <SWAPPINESS>

Setzt den Swappiness-Wert. Standardmäßig wird 10 verwendet.

--governor <GOVERNOR>

Setzt den CPU-Scaling-Governor. Standardmäßig wird performance verwendet.

--perf-event-paranoid <PERF_EVENT_PARANOID>

Setzt den perf_event_paranoid-Wert. Standardmäßig wird -1 verwendet.

--thp <THP>

Setzt den Transparent-Hugepage-Modus des Hosts: never, madvise, always oder leave. Mit leave bleibt der aktuelle Modus des Hosts erhalten. Standardmäßig wird never verwendet.

--help

Hilfe ausgeben.