Performances et lagChaque bloc posé, chaque chunk généré et chaque sauvegarde prise est une écriture sur le même disque NVMe. Ce disque est partagé, rapide et fini — et ce qui ressemble à de l'entretien de stockage inoffensif peut discrètement entrer en concurrence avec le monde lui-même pour la même bande passante d'E/S.
Pourquoi une sauvegarde inactive a quand même un coût
Une sauvegarde compressée posée sur disque ne coûte rien tant que rien n'y touche — mais elle est rarement vraiment inactive. Les analyses type antivirus, les propres calculs de taille du panel, et tout processus qui parcourt l'arborescence doivent la traverser, et un grand nombre de gros fichiers ralentit chacune de ces opérations routinières plus que nécessaire.
Le coût le plus direct apparaît pendant la création même de la sauvegarde : compresser des gigaoctets de données du monde est une opération soutenue de lecture-écriture en concurrence avec les propres sauvegardes de chunks et écritures de journal du serveur en direct, pour la même file d'attente du disque. Sur un serveur déjà limité par l'E/S, une tâche de sauvegarde tournant en même temps qu'une forte activité du monde, ce sont deux tâches exigeantes se partageant une ressource qu'aucune n'est dimensionnée à partager seule.
Ce qui utilise vraiment l'E/S sur un serveur de jeu
| Activité | Motif |
|---|---|
| Sauvegarde automatique des chunks | Écritures fréquentes, petites et dispersées — c'est le coût de base toujours en cours |
| Génération du monde | Écritures par rafales à mesure que du nouveau terrain est créé, plus lourdes quand les joueurs explorent |
| Création de sauvegarde | Lecture soutenue de tout le monde, plus écriture de l'archive compressée |
| Fichiers de journal | Petites écritures continues — normalement négligeables, importantes si quelque chose inonde le journal |
| Archives non compressées laissées sur disque | Pas de coût d'écriture continu, mais s'ajoutent à ce que doit parcourir chaque analyse de répertoire |
Le travail d'une sauvegarde est fait dès qu'elle existe quelque part en sécurité — la garder sur le même disque où le monde en direct continue d'écrire n'apporte aucune protection supplémentaire et n'ajoute qu'un coût continu. La télécharger et retirer la copie locale ne concerne pas seulement le quota de stockage : cela évite que le serveur en direct entre en concurrence avec sa propre copie de sécurité pour le même disque.
Le stockage flash a un nombre fini de cycles d'écriture par cellule, et des données inutiles subissant des analyses et passages de sauvegarde répétés ajoutent des écritures sans aucun bénéfice. C'est un coût lent, de fond, plutôt que quelque chose qui se voit dans la performance d'une seule journée — ce qui explique justement pourquoi c'est facile à ignorer jusqu'à ce que le disque soit vieux.
L'usage disque ne reflète que les fichiers de jeu actifs et les sauvegardes téléchargées puis supprimées ne laissent pas de trace durable, et une tâche de sauvegarde en cours n'affecte pas visiblement le TPS sur un serveur qui était stable auparavant.