Bencher CLI runner


Le binaire runner est l’agent qui exécute les Jobs de benchmark Bare Metal. Il constitue la référence détaillée pour la mise en place d’un Runner auto-hébergé. Le binaire fournit deux sous-commandes :

  • runner up : Démarre le runner, en interrogeant et en exécutant les Jobs de benchmark.
  • runner run : Récupère une Image et l’exécute une seule fois sur l’hôte local, à des fins de test.

🐰 Le binaire runner est distinct des sous-commandes bencher runner. Le binaire runner exploite un hôte Runner, tandis que bencher runner gère les ressources Runner via l’API REST.


runner up

Démarre le runner, en interrogeant et en exécutant les Jobs de benchmark. C’est la commande de longue durée utilisée pour exploiter un Runner auto-hébergé. Le runner ouvre une unique connexion WebSocket vers le serveur API, réclame les Jobs correspondant à ses Specs, les exécute, et renvoie les résultats. Le runner écrit son journal sur stderr en JSON, un objet par ligne, et ne journalise la sortie d’un Job que sous forme de nombres d’octets.

runner up [OPTIONS]

Options

--host <HOST>

Le serveur API Bencher auquel se connecter. Par défaut, https://api.bencher.dev est utilisé. Peut aussi être défini avec la variable d’environnement BENCHER_HOST.

--runner <RUNNER>

L’UUID ou le slug du Runner sous lequel opérer. Peut aussi être défini avec la variable d’environnement BENCHER_RUNNER.

--key <KEY>

La clé d’authentification du Runner (bencher_runner_...) renvoyée lors de la création du Runner. Peut aussi être défini avec la variable d’environnement BENCHER_RUNNER_KEY.

--poll-timeout <POLL_TIMEOUT>

Le délai d’attente du long-poll en secondes pendant l’attente d’un Job, entre 1 et 900. Par défaut, 55 est utilisé.

--state-dir <STATE_DIR>

Le répertoire d’état persistant du Runner. Il doit s’agir d’un chemin absolu. La prison qui confine le bac à sable est créée dans ce répertoire, et les prisons laissées par un arrêt brutal en sont supprimées avant chaque Job avec bac à sable. Chaque prison contient un système de fichiers racine invité complet et une copie du binaire de la microVM, et un Runner exécute ses Jobs un par un, ce répertoire a donc besoin d’une capacité réelle pour une prison. Avec --image-cache-size, il contient aussi le cache d’Image, jusqu’à cette taille. Un hôte n’exécute qu’un Runner à la fois, quel que soit son répertoire d’état : un Runner démarré en tant que root détient le verrou /run/bencher/runner.lock tant qu’il s’exécute, et un second démarré en tant que root se termine immédiatement avec une erreur qui nomme ce verrou ; un Runner qui n’est pas root ne peut pas ouvrir le verrou et s’exécute sans lui. Au démarrage, puis avant chaque Job avec bac à sable, un Runner démarré en tant que root tue tout processus encore en cours d’exécution dans un cgroup sous /sys/fs/cgroup/bencher, comme le bac à sable d’un Runner tué en plein Job, quel que soit le répertoire d’état de ce Runner. Un système de fichiers dédié ou un montage tmpfs est pris en charge et recommandé : il maintient cette charge d’écriture hors du disque système, et un système de fichiers fraîchement créé est accepté même s’il arrive avec un répertoire lost+found. Le système de fichiers ne doit pas être monté avec nodev ou noexec, comme le sont souvent /tmp, /dev/shm et /run ; montez donc pour lui un tmpfs sans ces options. Le répertoire d’état lui-même peut être un lien symbolique créé par root vers un tel système de fichiers, comme /var/lib/bencher-runner pointant vers un disque dédié. Le lien n’est suivi que lorsque le répertoire qui le contient n’est inscriptible que par root, qu’il pointe directement vers sa cible finale, et que cette cible existe déjà sur un chemin inscriptible uniquement par root ; un lien dont la cible n’existe pas encore est refusé, créez donc d’abord la cible. Par défaut, /var/lib/bencher-runner est utilisé. Peut également être défini avec la variable d’environnement BENCHER_STATE_DIR.

--jail-uid <JAIL_UID>

L’identifiant d’utilisateur non privilégié que le processus du bac à sable adopte. Par défaut, 61016 est utilisé. Il ne peut pas valoir 0. Un processus de l’hôte possédant cet identifiant peut envoyer des signaux au bac à sable, choisissez donc un identifiant que l’hôte n’attribue à rien d’autre. Peut également être défini avec la variable d’environnement BENCHER_JAIL_UID.

--jail-gid <JAIL_GID>

L’identifiant de groupe non privilégié que le processus du bac à sable adopte. Par défaut, 61016 est utilisé. Il ne peut pas valoir 0. Peut également être défini avec la variable d’environnement BENCHER_JAIL_GID.

--danger-allow-no-sandbox

Autorise l’exécution de Jobs sans Sandbox. Sans ce drapeau, un Job dont le Spec n’a pas de Sandbox est rejeté à l’exécution. Les Jobs sans sandbox s’exécutent directement sur l’hôte, n’activez donc ceci que pour des charges de travail de confiance. Peut aussi être défini avec la variable d’environnement BENCHER_DANGER_ALLOW_NO_SANDBOX.

--sandbox-log-level <SANDBOX_LOG_LEVEL>

Le niveau de journalisation du processus de sandbox. Par défaut, warning est utilisé.

--no-raid-pause

Continuer à accepter des Jobs pendant qu’une grappe RAID md de l’hôte se resynchronise, se reconstruit, se vérifie, se répare ou se remodèle. Par défaut, le Runner vérifie ses grappes md avant de demander chaque Job, et tant que l’une d’elles effectue l’une de ces opérations, il se met en pause : il n’accepte aucun nouveau Job avant la fin de la synchronisation, et il n’arrête jamais un Job déjà en cours. Un Runner en pause reste connecté et continue de se mettre à jour.

--no-auto-update

Désactive les mises à jour automatiques depuis le serveur. Par défaut, le runner se met à jour lui-même entre les Jobs lorsque le serveur propose une nouvelle version. Peut aussi être défini avec la variable d’environnement BENCHER_NO_AUTO_UPDATE.

--update-channel <UPDATE_CHANNEL>

Le canal de mise à jour pour les mises à jour automatiques, soit stable, soit canary. Par défaut, stable est utilisé. Le canal stable met à jour vers les versions publiées. Le canal canary suit le build canary continu, qui est reconstruit chaque fois que le runner change lors d’un déploiement Bencher Cloud. Peut aussi être défini avec la variable d’environnement BENCHER_UPDATE_CHANNEL. En conflit avec --no-auto-update.

--max-download-size <MAX_DOWNLOAD_SIZE>

La taille de téléchargement maximale en octets pour les binaires de mise à jour automatique. Par défaut, 500 Mio est utilisé. En conflit avec --no-auto-update.

--image-cache-size <IMAGE_CACHE_SIZE>

La taille maximale en octets des blobs d’Image que le Runner conserve d’un Job à l’autre. Le Runner conserve les blobs de configuration et de couches de chaque Image qu’il récupère dans blobs, sous son --state-dir, de sorte qu’un Job ne télécharge que les blobs que le Runner ne détient pas déjà, mais récupère toujours le manifeste de son Image depuis le registre. Entre les Jobs, le Runner supprime les blobs les moins récemment utilisés jusqu’à ce que le reste tienne dans cette taille. Au démarrage, le Runner crée le stockage et le fait sien, et s’il n’y parvient pas, il s’arrête aussitôt avec une erreur qui nomme le répertoire. Par défaut, ou avec 0, le Runner ne conserve aucun blob d’un Job à l’autre et supprime ceux qu’il conservait auparavant. Peut également être défini avec la variable d’environnement BENCHER_IMAGE_CACHE_SIZE.

--max-output-size <MAX_OUTPUT_SIZE>

La taille maximale en octets pour les sorties stdout et stderr collectées. Par défaut, 25 Mio est utilisé.

--max-file-count <MAX_FILE_COUNT>

Le nombre maximal de fichiers de sortie à décoder. Par défaut, 255 est utilisé.

Le nombre maximal de liens symboliques à suivre lors de la résolution des chemins, correspondant à la limite MAXSYMLINKS du noyau Linux. Par défaut, 40 est utilisé. Utilisé uniquement en mode sans sandbox.

Réglage de l’hôte

Avant chaque benchmark, le runner applique un réglage de l’hôte pour réduire le bruit de mesure. Par défaut, il désactive l’ASLR, le NMI watchdog, le SMT / hyper-threading et le turbo boost ; règle le gouverneur de mise à l’échelle du CPU sur performance, la swappiness sur 10, et perf_event_paranoid sur -1. Sur un hôte que le runner n’a pas réglé depuis son dernier redémarrage, les drapeaux ci-dessous conservent au contraire les optimisations individuelles à leurs valeurs par défaut de l’hôte.

Le réglage de l’hôte persiste jusqu’au redémarrage de l’hôte : chaque paramètre est une écriture valable uniquement à l’exécution, que le runner n’annule pas lorsqu’il se termine, sauf le maintien des C-states, qui prend fin lorsque le runner se termine. Après une exécution avec réglage, un drapeau qui ignore tout autre paramètre prend effet à partir du prochain redémarrage : jusque-là, le paramètre conserve sa valeur réglée, et le runner journalise cette valeur au démarrage. Redémarrez un hôte partagé après avoir retiré le runner.

--no-tuning

Désactive toutes les optimisations de réglage de l’hôte.

--aslr

Ne désactive pas l’ASLR (par défaut : désactivé pour les benchmarks).

--nmi-watchdog

Ne désactive pas le NMI watchdog (par défaut : désactivé pour les benchmarks).

--smt

Ne désactive pas le SMT / hyper-threading (par défaut : désactivé pour les benchmarks).

--turbo

Ne désactive pas le turbo boost (par défaut : désactivé pour les benchmarks).

--numa-balancing

Ne désactive pas l’équilibrage NUMA automatique (par défaut : désactivé pour les benchmarks).

--timer-migration

Ne désactive pas la migration des timers (par défaut : désactivée pour les benchmarks).

--soft-watchdog

Ne désactive pas le soft lockup watchdog (par défaut : désactivé pour les benchmarks).

--ksm

Ne désactive pas le KSM, kernel samepage merging (par défaut : désactivé pour les benchmarks).

--cstates

Ne désactive pas les C-states profonds (par défaut : désactivés pour les benchmarks).

--no-irq-steering

Ne dirige pas les IRQ des périphériques ni les workqueues du noyau vers les cœurs de housekeeping.

--no-cpuset-partition

Ne détache pas les cœurs de benchmark de l’ordonnanceur via une partition cpuset isolée.

--swappiness <SWAPPINESS>

Définit la valeur de swappiness. Par défaut, 10 est utilisé.

--governor <GOVERNOR>

Définit le gouverneur de mise à l’échelle du CPU. Par défaut, performance est utilisé.

--perf-event-paranoid <PERF_EVENT_PARANOID>

Définit la valeur de perf_event_paranoid. Par défaut, -1 est utilisé.

--thp <THP>

Définit le mode transparent hugepage de l’hôte : never, madvise, always ou leave. Utilisez leave pour conserver le mode actuel de l’hôte. Par défaut, never est utilisé.

--help

Affiche l’aide.


runner run

Récupère une Image, crée un rootfs, et l’exécute une seule fois sur l’hôte local. Contrairement à runner up, cette commande ne se connecte pas à un serveur API et ne réclame pas de Job. Elle exécute une seule Image directement, ce qui est utile pour tester et déboguer un hôte Runner ou une Image avant de soumettre de vrais Jobs. La sortie de l’Image va telle quelle sur stdout et stderr, et le journal propre du runner va sur stderr en JSON, un objet par ligne.

runner run --image <IMAGE> [OPTIONS]

Options

--image <IMAGE>

L’Image OCI à exécuter, sous forme de chemin local ou de référence de registre.

--token <TOKEN>

Un jeton JWT pour l’authentification au registre lors de la récupération de l’Image.

--sandbox <SANDBOX>

Le mode de sandbox pour l’exécution du benchmark. Utilisez firecracker pour une microVM Firecracker (Linux uniquement). Omettez pour une exécution sur l’hôte sans sandbox.

--timeout <TIMEOUT>

Le délai d’attente d’exécution en secondes, partagé par toutes les itérations depuis le début de l’exécution. Par défaut, 300 est utilisé.

--state-dir <STATE_DIR>

Le répertoire d’état persistant du Runner. Il doit s’agir d’un chemin absolu. La prison qui confine le bac à sable est créée dans ce répertoire, et les prisons laissées par un arrêt brutal en sont supprimées avant chaque Job avec bac à sable. Chaque prison contient un système de fichiers racine invité complet et une copie du binaire de la microVM, et un Runner exécute ses Jobs un par un, ce répertoire a donc besoin d’une capacité réelle pour une prison. Un hôte n’exécute qu’un Runner à la fois, quel que soit son répertoire d’état : un Runner démarré en tant que root détient le verrou /run/bencher/runner.lock tant qu’il s’exécute, et un second démarré en tant que root se termine immédiatement avec une erreur qui nomme ce verrou ; un Runner qui n’est pas root ne peut pas ouvrir le verrou et s’exécute sans lui. Au démarrage, puis avant chaque Job avec bac à sable, un Runner démarré en tant que root tue tout processus encore en cours d’exécution dans un cgroup sous /sys/fs/cgroup/bencher, comme le bac à sable d’un Runner tué en plein Job, quel que soit le répertoire d’état de ce Runner. Un système de fichiers dédié ou un montage tmpfs est pris en charge et recommandé : il maintient cette charge d’écriture hors du disque système, et un système de fichiers fraîchement créé est accepté même s’il arrive avec un répertoire lost+found. Le système de fichiers ne doit pas être monté avec nodev ou noexec, comme le sont souvent /tmp, /dev/shm et /run ; montez donc pour lui un tmpfs sans ces options. Le répertoire d’état lui-même peut être un lien symbolique créé par root vers un tel système de fichiers, comme /var/lib/bencher-runner pointant vers un disque dédié. Le lien n’est suivi que lorsque le répertoire qui le contient n’est inscriptible que par root, qu’il pointe directement vers sa cible finale, et que cette cible existe déjà sur un chemin inscriptible uniquement par root ; un lien dont la cible n’existe pas encore est refusé, créez donc d’abord la cible. Par défaut, /var/lib/bencher-runner est utilisé. Peut également être défini avec la variable d’environnement BENCHER_STATE_DIR.

--jail-uid <JAIL_UID>

L’identifiant d’utilisateur non privilégié que le processus du bac à sable adopte. Par défaut, 61016 est utilisé. Il ne peut pas valoir 0. Un processus de l’hôte possédant cet identifiant peut envoyer des signaux au bac à sable, choisissez donc un identifiant que l’hôte n’attribue à rien d’autre. Peut également être défini avec la variable d’environnement BENCHER_JAIL_UID.

--jail-gid <JAIL_GID>

L’identifiant de groupe non privilégié que le processus du bac à sable adopte. Par défaut, 61016 est utilisé. Il ne peut pas valoir 0. Peut également être défini avec la variable d’environnement BENCHER_JAIL_GID.

--iter <ITER>

Le nombre d’itérations de benchmark à exécuter. Par défaut, 1 est utilisé.

--allow-failure

Autorise un échec de benchmark sans court-circuiter les itérations restantes. Si le délai est épuisé, l’exécution se termine tout de même par un dépassement de délai. Une Image qui ne peut être ni récupérée ni préparée termine aussi l’exécution.

--entrypoint <ENTRYPOINT>

Remplace l’entrypoint du conteneur. Peut être spécifié plusieurs fois.

--cmd <CMD>

Remplace la commande du conteneur. Peut être spécifié plusieurs fois.

--env <ENV>

Définit une variable d’environnement au format KEY=VALUE. Peut être spécifié plusieurs fois.

--network

Active l’accès réseau à l’intérieur de la VM.

--output <OUTPUT>

Un chemin de fichier de sortie à l’intérieur de l’invité à collecter. Peut être spécifié plusieurs fois.

--vcpus <VCPUS>

Remplace le nombre de vCPU (à des fins de test).

--memory <MEMORY>

Remplace la mémoire en Mio (à des fins de test).

--disk <DISK>

Remplace la taille du disque en Mio (à des fins de test).

--max-output-size <MAX_OUTPUT_SIZE>

La taille maximale en octets pour les sorties stdout et stderr collectées. Par défaut, 25 Mio est utilisé.

--max-file-count <MAX_FILE_COUNT>

Le nombre maximal de fichiers de sortie à décoder. Par défaut, 255 est utilisé.

Le nombre maximal de liens symboliques à suivre lors de la résolution des chemins, correspondant à la limite MAXSYMLINKS du noyau Linux. Par défaut, 40 est utilisé. Utilisé uniquement en mode sans sandbox, il est donc en conflit avec --sandbox.

--sandbox-log-level <SANDBOX_LOG_LEVEL>

Le niveau de journalisation du processus de sandbox. Nécessite --sandbox. Par défaut, warning est utilisé.

Réglage de l’hôte

Avant chaque benchmark, le runner applique un réglage de l’hôte pour réduire le bruit de mesure. Par défaut, il désactive l’ASLR, le NMI watchdog, le SMT / hyper-threading et le turbo boost ; règle le gouverneur de mise à l’échelle du CPU sur performance, la swappiness sur 10, et perf_event_paranoid sur -1. Sur un hôte que le runner n’a pas réglé depuis son dernier redémarrage, les drapeaux ci-dessous conservent au contraire les optimisations individuelles à leurs valeurs par défaut de l’hôte.

Le réglage de l’hôte persiste jusqu’au redémarrage de l’hôte : chaque paramètre est une écriture valable uniquement à l’exécution, que le runner n’annule pas lorsqu’il se termine, sauf le maintien des C-states, qui prend fin lorsque le runner se termine. Après une exécution avec réglage, un drapeau qui ignore tout autre paramètre prend effet à partir du prochain redémarrage : jusque-là, le paramètre conserve sa valeur réglée, et le runner journalise cette valeur au démarrage. Redémarrez un hôte partagé après avoir retiré le runner.

--no-tuning

Désactive toutes les optimisations de réglage de l’hôte.

--aslr

Ne désactive pas l’ASLR (par défaut : désactivé pour les benchmarks).

--nmi-watchdog

Ne désactive pas le NMI watchdog (par défaut : désactivé pour les benchmarks).

--smt

Ne désactive pas le SMT / hyper-threading (par défaut : désactivé pour les benchmarks).

--turbo

Ne désactive pas le turbo boost (par défaut : désactivé pour les benchmarks).

--numa-balancing

Ne désactive pas l’équilibrage NUMA automatique (par défaut : désactivé pour les benchmarks).

--timer-migration

Ne désactive pas la migration des timers (par défaut : désactivée pour les benchmarks).

--soft-watchdog

Ne désactive pas le soft lockup watchdog (par défaut : désactivé pour les benchmarks).

--ksm

Ne désactive pas le KSM, kernel samepage merging (par défaut : désactivé pour les benchmarks).

--cstates

Ne désactive pas les C-states profonds (par défaut : désactivés pour les benchmarks).

--no-irq-steering

Ne dirige pas les IRQ des périphériques ni les workqueues du noyau vers les cœurs de housekeeping.

--no-cpuset-partition

Ne détache pas les cœurs de benchmark de l’ordonnanceur via une partition cpuset isolée.

--swappiness <SWAPPINESS>

Définit la valeur de swappiness. Par défaut, 10 est utilisé.

--governor <GOVERNOR>

Définit le gouverneur de mise à l’échelle du CPU. Par défaut, performance est utilisé.

--perf-event-paranoid <PERF_EVENT_PARANOID>

Définit la valeur de perf_event_paranoid. Par défaut, -1 est utilisé.

--thp <THP>

Définit le mode transparent hugepage de l’hôte : never, madvise, always ou leave. Utilisez leave pour conserver le mode actuel de l’hôte. Par défaut, never est utilisé.

--help

Affiche l’aide.



Published: Fri, June 19, 2026 at 8:00:00 AM UTC | Last Updated: Fri, October 9, 2026 at 3:22:48 PM UTC