Utiliser sysbench : benchmarks CPU, disque et MySQL

31 octobre 2026 7 min de lecture

sysbench est un outil de benchmark open source et multithread, bâti sur LuaJIT, qui fournit des tests CPU, mémoire, E/S fichiers, threads et mutex, ainsi que des scripts OLTP pour MySQL et PostgreSQL. Les tests qui ont besoin de données suivent le même cycle : prepare crée les fichiers ou les tables de test, run lance le benchmark pendant une durée ou un nombre d’événements donné, et cleanup supprime les données ; les tests CPU et mémoire n’ont besoin que de run. Il mesure une machine ou un serveur de base de données, et ne peut donc pas vous dire comment votre application se comporte face à un vrai trafic d’utilisateurs.

Nous n’avons pas exécuté sysbench pour ce guide. Les faits proviennent de son README et de son code source sur la branche master de GitHub, vérifiés le 31 octobre 2026, et les conseils sont les nôtres.

Sujet	sysbench
Licence	GPLv2
Écrit en	C, avec LuaJIT pour les scripts
Dernière version	1.0.20 (24 avril 2020)
Dernier commit	9 mars 2025
Tests intégrés	`cpu`, `memory`, `fileio`, `threads`, `mutex`
Scripts de base de données	Huit scripts `oltp_`, `bulk_insert`, deux `select_random_`
Pilotes de base de données	MySQL (par défaut), PostgreSQL
Plateformes	Linux, macOS ; Windows via WSL

sysbench est-il encore maintenu ?

Peu. La dernière version, la 1.0.20, date d’avril 2020 ; la branche master a reçu depuis des commits occasionnels, dont aucun n’est sorti dans une version, le dernier en mars 2025.

La version 1.0.20 est datée du 24 avril 2020. L’historique des commits montre des changements comme une distribution uniforme par défaut pour --rand-type (2020), un LuaJIT upstream (2023) et la prise en charge des bibliothèques client MariaDB (2023), puis quatre commits de build le 9 mars 2025 (vérifié le 31 octobre 2026). Les dépôts de paquets cités dans le README sont mis à jour à chaque version : ces changements demandent donc une compilation depuis les sources.

Comment se déroule une exécution de sysbench ?

Vous indiquez un test et une commande : sysbench [options] [testname] [command]. Le test est un test intégré, un script Lua fourni ou votre propre script, et la commande est en général prepare, run, cleanup ou help.

Selon le README, prepare crée les fichiers pour fileio ou remplit la base pour les scripts OLTP, cleanup supprime ces données, et sysbench <testname> help liste les options d’un test. Un test de disque :

sysbench fileio --file-total-size=8G prepare
sysbench fileio --file-total-size=8G \
  --file-test-mode=rndrw --time=300 run
sysbench fileio --file-total-size=8G cleanup

Le code source de fileio liste les modes seqwr, seqrewr, seqrd, rndrd, rndwr et rndrw, avec 2 Go de fichiers par défaut. Des fichiers qui tiennent en mémoire peuvent être servis par le cache de pages : prévoyez un volume supérieur à la RAM si c’est le disque que vous voulez mesurer.

Comment mesurer le CPU et la mémoire avec sysbench ?

Avec sysbench cpu run et sysbench memory run. Le test CPU indique des événements par seconde, un événement consistant à vérifier la primalité de chaque nombre jusqu’à une limite, et le test mémoire indique des opérations et des Mio transférés par seconde.

sysbench cpu --cpu-max-prime=20000 \
  --threads=4 --time=60 run

Le test CPU fixe --cpu-max-prime à 10000 par défaut, et le test mémoire accepte une taille de bloc, une taille totale, des opérations de lecture ou d’écriture et un accès séquentiel ou aléatoire (vérifié le 31 octobre 2026). Ne comparez que des exécutions aux réglages identiques.

Comment tester MySQL ou PostgreSQL avec sysbench ?

Choisissez un des scripts OLTP fournis, remplissez les tables avec prepare, lancez des transactions depuis plusieurs threads avec run, puis supprimez les tables avec cleanup. MySQL est le pilote par défaut ; PostgreSQL demande --db-driver=pgsql et un build compilé avec le support de PostgreSQL.

sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 \
  --threads=16 --time=300 --report-interval=10 run

Le script OLTP commun crée une table de 10 000 lignes si vous ne passez pas --tables et --table-size. Dans oltp_read_write, chaque transaction exécute 10 lectures par clé, quatre requêtes sur des plages, deux mises à jour et une suppression suivie d’une insertion, entre BEGIN et COMMIT (vérifié le 31 octobre 2026). Prévoyez des données plus grandes que le buffer pool du serveur si vous voulez des lectures disque dans le résultat.

Quelles options de sysbench comptent le plus ?

--threads et --time fixent la taille et la durée d’une exécution, --rate fixe un taux cible d’événements, et --report-interval, --percentile et --histogram déterminent ce que vous voyez.

--threads : threads de travail, 1 par défaut.
--time : durée en secondes, 10 par défaut, 0 pour aucune limite. --events plafonne le nombre d’événements, et les deux limites s’appliquent : associez-le à --time=0.
--warmup-time : tourne d’abord sans statistiques, pour que des caches froids ne faussent pas le résultat. Branche master uniquement : la version 1.0.20 ne l’a pas.
--rate : nombre moyen d’événements par seconde pour l’ensemble des threads ; 0, la valeur par défaut, signifie le plus vite possible.
--report-interval : des chiffres par intervalle toutes les N secondes, pour révéler les blocages.
--percentile : le percentile de latence affiché, 95 par défaut.
--histogram : un histogramme des latences en fin d’exécution, défini dans sb_logger.c.

sysbench suit-il un modèle de charge fermé ou ouvert ?

Fermé par défaut : un nombre fixe de threads lancent chacun l’événement suivant dès que le précédent se termine, si bien qu’un serveur lent reçoit moins d’événements. Avec --rate, les événements arrivent selon leur propre calendrier, ce qui se rapproche d’un modèle de charge ouvert.

Notre article sur le modèle de charge ouvert ou fermé explique pourquoi cela change ce que mesure un benchmark. En mode par défaut, un blocage retarde aussi les événements qui auraient démarré pendant ce temps, et ces retards n’apparaissent jamais dans les latences : c’est la coordinated omission. Le fichier source principal montre que --rate place les événements dans une file à des intervalles suivant une loi exponentielle, ajoute à la latence de chaque événement son temps d’attente dans la file, et s’arrête avec l’erreur “event queue is full” quand les threads ne suivent plus (vérifié le 31 octobre 2026).

Comment lire les résultats de sysbench ?

Commencez par le débit : événements par seconde, ou transactions et requêtes par seconde pour les scripts OLTP. Lisez ensuite le bloc de latence en millisecondes : minimum, moyenne, maximum, le percentile choisi (p95 par défaut) et la somme.

La version 1.0.20 affiche à la place de « Throughput » un bloc « General statistics » avec la durée totale et le nombre total d’événements. Les noms de champs viennent du code du rapport base de données et du fichier source principal sur master, ici sans valeurs :

SQL statistics:
    queries performed: read, write, other, total
    transactions, queries (N per sec.)
    ignored errors, reconnects (N per sec.)
Throughput:
    events/s (eps), time elapsed, total number of events
Latency (ms):
    min, avg, max, 95th percentile, sum
Threads fairness:
    events, execution time (avg/stddev)

Un 95e percentile laisse de côté l’événement le plus lent sur vingt. Passez --percentile=99 ou ajoutez --histogram quand la queue de distribution compte ; notre guide sur la latence de queue explique pourquoi.

Quand sysbench n’est-il pas le bon outil ?

Quand votre question porte sur votre application. Un score CPU montre à quelle vitesse une machine vérifie des nombres premiers, et une exécution OLTP mesure le serveur de base de données avec les tables et requêtes de sysbench, sans votre schéma, votre pool de connexions ni le chemin réseau.

Choisissez pgbench pour des tests propres à PostgreSQL : la documentation de PostgreSQL décrit un scénario par défaut vaguement inspiré de TPC-B, ainsi que des fichiers de script personnalisés (vérifié le 31 octobre 2026).
Choisissez HammerDB pour des tests de type TPC-C : sa documentation couvre la charge TPROC-C, dérivée de TPC-C, pour SQL Server, Db2, Oracle, PostgreSQL, MariaDB et MySQL (vérifié le 31 octobre 2026).
Choisissez JMeter avec son sampler JDBC Request pour mêler SQL et HTTP dans un même plan de test ; le guide des plans de test de base de données indique que le .jar du pilote va dans le dossier lib de JMeter.

LoadFocus, qui publie ce site, n’exécute pas sysbench et ne peut pas se connecter lui-même à MySQL ou PostgreSQL. LoadFocus exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud contre la couche web ou API placée devant la base. Une combinaison utile : une exécution de sysbench pour dimensionner le serveur de base de données, puis un test de charge de l’application pour voir si de vraies requêtes atteignent cette limite.

FAQ

sysbench est-il encore maintenu ? Peu. La dernière version est la 1.0.20 du 24 avril 2020. La branche master a reçu depuis des commits occasionnels, aucun dans une version, le plus récent le 9 mars 2025.

Que signifie le 95e percentile dans les résultats de sysbench ? C’est la latence, en millisecondes, en dessous de laquelle 95 % des événements se sont terminés. 95 est la valeur par défaut de l’option --percentile, et vous pouvez en choisir une autre, comme 99.

sysbench peut-il tester PostgreSQL ? Oui. Les scripts OLTP fournis tournent contre PostgreSQL avec --db-driver=pgsql quand sysbench a été compilé avec le support de PostgreSQL.

LoadFocus peut-il exécuter sysbench ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6 contre des sites web et des API depuis 25 régions cloud, et ne se connecte pas directement à MySQL ou PostgreSQL.