Kommen mehr Anfragen, als der Datenträger pro Sekunde bewältigt, wird die Warteschlange lang und die Latenz explodiert.
Warum Lese- und Schreibanfragen nähern sich der Kapazität des Datenträgers → Folge Warteschlange wird länger (explodiert meist ab 90 % Auslastung) → Auf dem Bildschirm Verzögertes Speichern und Laden, bei synchronen Aufrufen Freeze
Anfragen zusammenfassen, häufig gelesene Daten cachen, Zugriffe asynchron gestalten, damit der Game-Thread nicht auf den Datenträger wartet.
Aufgaben Infrastrukturteam
Server/OS: schnellere Datenträger einsetzen, Limits für Disk-Bandbreite und IOPS je Instanztyp prüfen, Alarme auf Disk-Auslastung und Warteschlange einrichten, große Dateikopien in ruhige Zeiten legen. DB-Systeme: auch für DB-Datenträger Alarme auf IOPS- und Durchsatzauslastung einrichten, Disk-Limits der DB-Instanzgröße prüfen.
Größenordnungen
HDD etwa 150 IOPS, SATA-SSD Zehntausende, NVMe Hunderttausende. Der Standard-Cloud-Datenträger (AWS gp3) liefert 3.000 IOPS und 125 MiB pro Sekunde. Daneben gibt es ein eigenes Durchsatzlimit pro Sekunde. Schöpft eine große Dateikopie es aus, stauen sich selbst kleine Schreibvorgänge.
Im Graphen
Plateau am Limit · IOPS, Länge der Disk-Warteschlange
Wo nachsehen
r/s und w/s, rkB/s und wkB/s, aqu-sz sowie r_await und w_await aus iostat -x 1 prüfen. In der Cloud VolumeReadOps, VolumeWriteOps und VolumeQueueLength von EBS sowie die Limit-Prüfungen VolumeIOPSExceededCheck und VolumeThroughputExceededCheck, auf Instanzseite InstanceEBSIOPSExceededCheck und InstanceEBSThroughputExceededCheck prüfen
Spricht dafür
Anfragen pro Sekunde oder Durchsatz verlaufen flach auf dem Limitwert, aqu-sz und await schießen gemeinsam hoch. In der Cloud steht die Exceeded-Metrik auf 1
Spricht dagegen
%util bei 100 %, await aber niedrig: möglicherweise noch Reserven. Bei SSDs und RAID mit paralleler Verarbeitung zeigt %util nicht das Limit an. Limit nicht erreicht, nur await hoch: Latenz des Datenträgers selbst (dk-hdd) oder fsync (dk-fsync)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
In der Cloud hat zusätzlich zum Limit des Datenträgers jede Servergröße (Instanztyp) eigene Limits für Disk-Bandbreite und IOPS. Selbst mit einem teuren Datenträger stößt ein kleiner Server an das Limit der Instanz.
Quellen
Exos X18 Data SheetSeagate 4K-Random-Reads auf einer Server-HDD mit 7.200 U/min: 170 IOPS (QD16)
D3-S4520 SSDSolidigm Server-SATA-SSD, 4-KB-Random-Read/-Write bis 92K/48K IOPS
Amazon EBS General Purpose SSD volumesAWS Basisleistung von gp3: 3.000 IOPS und 125 MiB/s, zwei getrennte Limits, die sich unabhängig voneinander erhöhen lassen
iostat(1) — Linux manual pagesysstat -x: r/s und w/s, rkB/s und wkB/s, aqu-sz (früher avgqu-sz), r_await und w_await, %util. Bei RAID und modernen SSDs mit paralleler Verarbeitung zeigt %util nicht das Leistungslimit an
Amazon CloudWatch metrics for Amazon EBSAWS VolumeIOPSExceededCheck und VolumeThroughputExceededCheck: 1, wenn das Volume versucht hat, sein IOPS- oder Durchsatzlimit zu überschreiten (Nitro-Instanzen), VolumeQueueLength