Buku Putih Lag Game › L11 Disk

Lazy loading di server Lazy loading on the server

ID penyebab dk-lazy-load · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Buka kartu interaktif dengan gambar dan simulasi →

Jika server membaca data dungeon atau map dari disk saat pertama kali diminta, semua pemain berhenti selama tick itu.

Mengapa Seseorang masuk ke dungeon atau area untuk pertama kali → Akibatnya Server membaca data dari disk di thread game → Di layar Semua pemain di server itu mengalami freeze sesaat

Gejala

Freeze

Faktor

Stall

Siapa yang mengalami

Lokasi/channel tertentu, Seluruh server

Kapan

Saat bergerak atau pindah area

Penanggung jawab

Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Tugas Tim Pengembang Game

Muat data lebih dulu saat server dinyalakan, gunakan pemuatan asinkron.

Tugas Tim Infrastruktur

Untuk server yang baru dibuat dari snapshot, lakukan pemanasan disk sebelum melayani pemain (baca semua blok sekali) atau gunakan fitur fast snapshot restore.

Di grafik

Melonjak acak sesekali · Waktu tick server, pembacaan disk

Yang diperiksa

Cocokkan waktu berhenti dengan catatan masuk pertama ke dungeon atau area di log server game, lalu periksa pembacaan disk server game saat itu (kB_rd/s di pidstat -d) dan pemanggilan read serta open yang lama dengan perf trace --duration. Untuk server cloud yang baru dinyalakan, bandingkan VolumeAvgReadLatency di EBS dengan server lama

Cocok jika

Berhenti hanya saat masuk pertama kali, dan tidak berhenti saat masuk ke tempat yang sama untuk kedua kalinya. Selama berhenti, thread game menunggu pembacaan file

Tidak cocok jika

Berhenti dengan cara yang sama juga di area yang sudah dimuat: lebih mungkin penyebab lain seperti tick yang melewati budget atau GC

Sarana pemeriksaan

Log dan metrik server atau klien game

Pelajari lebih lanjut

Di cloud, server yang baru dibuat dari snapshot (salinan disk) mengambil setiap blok yang pertama kali dibaca dari storage jarak jauh, sehingga jauh lebih lambat daripada biasanya. Jika masuk pertama kali terasa sangat lama hanya di server yang baru dinyalakan oleh autoscaling, curigai penyebab ini.

Sumber

1. Initialize Amazon EBS volumes AWS
   Volume yang dibuat dari snapshot mengalami latensi lebih tinggi dan performa lebih rendah selama bloknya diambil dari S3; inisialisasi lebih dulu dengan membaca semua blok menggunakan dd atau fio
2. Amazon EBS fast snapshot restore AWS
   Fast snapshot restore memberikan volume yang sudah terinisialisasi sejak dibuat, sehingga latensi akses pertama hilang
3. pidstat(1) — Linux manual page sysstat
   -d: kB_rd/s per proses (volume baca disk per detik)
4. perf-trace(1) — Linux manual page perf
   Hanya menampilkan system call yang lebih lama dari jumlah ms yang ditentukan dengan --duration
5. Amazon CloudWatch metrics for Amazon EBS AWS
   VolumeAvgReadLatency: rata-rata latensi baca per 1 menit (instance Nitro)

Lihat juga

Lapisan yang sama: L11 Disk

• Penulisan log sinkron
• Lonjakan fsync
• Burst credit disk cloud habis
• Batas IOPS dan antrean jenuh
• Disk penuh
• Tugas backup, kompresi, dan pemindaian
• Penulisan core dump
• Latensi seek HDD

Penyebab di lapisan lain dengan gejala yang sama (Freeze)

• Lonjakan frame time L1 Proses game di klien
• Garbage collection di klien L1 Proses game di klien
• Pemuatan sinkron dan kompilasi shader di main thread L1 Proses game di klien
• Streaming aset tertinggal akibat storage lambat L1 Proses game di klien
• Pemindaian oleh modul keamanan game (anti-cheat) L1 Proses game di klien
• Perpindahan Wi-Fi ↔ LTE/5G L2 OS dan perangkat klien
• Kekurangan memori dan swap di klien L2 OS dan perangkat klien
• Kekurangan memori grafis (VRAM) L2 OS dan perangkat klien

Lihat kartu interaktif dengan gambar dan simulasi