Belegen nächtliche Backups, Log-Komprimierung oder Sicherheitsscans den Datenträger, stauen sich die Lese- und Schreibzugriffe des Spielservers.
Warum Geplanter Backup- oder Komprimierungsjob startet → Folge Belegt den Großteil von Disk-Bandbreite und IOPS → Auf dem Bildschirm Lag jeden Tag zur selben Uhrzeit
Server/OS: Backup-, Komprimierungs- und Scan-Jobs mit niedrigerer I/O-Priorität ausführen, Startzeiten verteilen. DB-Systeme: Backups auf einem Replikat erstellen.
Im Graphen
Spitzen in festen Abständen · Disk-Auslastung, Disk-Wartezeit
Wo nachsehen
Mit sar -d %util, await und aqu-sz der letzten Tage (Tagesdateien unter /var/log/sa; sadc muss mit -S DISK auch die Disk-Daten sammeln) tageweise übereinanderlegen, zu diesen Uhrzeiten mit pidstat -d 1 die Prozesse mit den höchsten kB_rd/s und kB_wr/s suchen und mit den Zeitplänen von Cron und systemd-Timern abgleichen
Spricht dafür
Jeden Tag zur selben Uhrzeit schießen await und %util hoch, und Backup-, Komprimierungs- oder Scan-Prozesse verursachen dann den Großteil der Lese- und Schreibzugriffe
Spricht dagegen
Spitzen jeden Tag zu anderen Uhrzeiten: geplanter Job unwahrscheinlich. I/O zu diesem Zeitpunkt größtenteils vom Spielserver selbst: eher Speichern oder Logging (dk-fsync, dk-sync-log)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
ionice(1) — Linux manual pageutil-linux Ein Job in der Klasse idle bekommt nur dann Zeit auf dem Datenträger, wenn kein anderes Programm ihn nutzt
Using Replication for BackupsMySQL Ein Backup von einem angehaltenen Replikat beeinträchtigt den Betrieb der Primär-DB nicht
sar(1) — Linux manual pagesysstat -d: await, aqu-sz und %util je Gerät aus den Tagesdateien (Standard /var/log/sa), die Disk-Daten müssen mit der sadc-Option -S DISK gesammelt werden
pidstat(1) — Linux manual pagesysstat -d: kB_rd/s und kB_wr/s je Prozess (pro Sekunde vom Datenträger gelesene bzw. auf ihn geschriebene Datenmenge)