Buku Putih Lag Game › L10 Memori

GC thrashing (heap hampir penuh) GC thrashing (heap nearly full)

ID penyebab mem-gc-thrash · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Buka kartu interaktif dengan gambar dan simulasi →

Jika data hidup mendekati batas heap, GC hampir tidak bisa membebaskan memori setiap kali berjalan, sehingga GC berulang tanpa henti.

Mengapa Data hidup memenuhi heap hingga mendekati batasnya karena jumlah pemain bertambah saat event atau karena kebocoran → Akibatnya GC hanya membebaskan sedikit memori sehingga Full GC langsung berjalan lagi, dan sebagian besar CPU terpakai untuk GC → Di layar Seluruh server berulang kali slow motion dan freeze selama beberapa menit, lalu mati karena kehabisan memori

Gejala

Slow motion, Freeze, Disconnect

Faktor

Stall

Siapa yang mengalami

Seluruh server

Kapan

Jam sibuk malam hari, Saat banyak pemain berkumpul, Makin lama menyala

Penanggung jawab

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

Tugas Tim Pengembang Game

Atur heap jauh lebih besar daripada data hidup saat puncak (biasanya minimal 2 kali lipat), kurangi kebocoran dan data yang direferensikan dalam waktu lama.

Tugas Tim Infrastruktur

Pasang alert rasio waktu GC, jangan menunda dan segera lakukan restart, pilih instance dengan memori cukup agar heap bisa diperbesar.

Kisaran angka

Jika GC memakai lebih dari 10% waktu eksekusi, biasanya itu dianggap tanda bahaya. Sebagian GC di Java memunculkan error kehabisan memori jika 98% waktu sudah dipakai untuk GC tetapi hampir tidak ada memori yang berhasil dibebaskan.

Di grafik

Mendatar di batas · Heap tepat setelah GC, rasio waktu GC

Yang diperiksa

Periksa seberapa dekat heap yang tersisa tepat setelah GC dengan heap maksimum, dan rasio waktu yang dipakai untuk GC. Java: bagian “setelah GC (ukuran heap)” di baris -Xlog:gc dan frekuensi baris Pause Full; .NET: dotnet-counters (.NET 8 ke bawah: % Time in GC since last GC, .NET 9 ke atas: kenaikan dotnet.gc.pause.time); Go: jarak antarbaris GODEBUG=gctrace=1

Cocok jika

Heap tetap mendekati maksimum bahkan tepat setelah GC, Full GC berjalan beruntun, dan rasio waktu GC naik jauh di atas biasanya (umumnya lebih dari 10%). Selama itu tick seluruh server ikut melambat

Tidak cocok jika

Heap masih longgar tepat setelah GC, hanya jedanya yang panjang: lebih mungkin jenis atau pengaturan GC (mem-gc)

Sarana pemeriksaan

Tools infrastruktur (tanpa perlu kode game)

Sumber

1. The Parallel Collector Oracle
   Parallel GC memunculkan OutOfMemoryError jika lebih dari 98% total waktu dipakai untuk GC tetapi heap yang dibebaskan kurang dari 2%
2. Garbage-First Garbage Collector Tuning Oracle
   Secara default (GCTimeRatio=12), G1 menentukan ukuran heap agar waktu GC sekitar 8% dari total waktu atau kurang; Full GC akibat okupansi heap yang terlalu tinggi ditemukan lewat Pause Full (G1 Compaction Pause) di log
3. A Guide to the Go Garbage Collector Go
   Dengan default GOGC=100, target heap sekitar 2 kali heap hidup; jika menempel di batas memori, terjadi thrashing, yaitu GC berjalan tanpa henti; output trace GC dengan GODEBUG=gctrace=1
4. Garbage Collector Implementation Oracle
   Baris -Xlog:gc berisi jenis GC (Pause Young, Pause Full), “penggunaan sebelum GC->penggunaan setelah GC (ukuran heap)”, dan lama jeda
5. dotnet-counters diagnostic tool .NET
   .NET 9 ke atas menampilkan dotnet.gc.pause.time, .NET 8 ke bawah menampilkan % Time in GC since last GC

Lihat juga

Lapisan yang sama: L10 Memori

• Jeda GC stop-the-world di server
• Jeda GC di engine skrip
• Lonjakan alokasi
• Kebocoran memori
• Swap
• Cache miss
• Fragmentasi memori
• Akses memori NUMA remote

Penyebab di lapisan lain dengan gejala yang sama (Slow motion)

• Catch-up fixed timestep yang lepas kendali L1 Proses game di klien
• Distribusi load balancer timpang dan health check keliru L5 Perangkat jaringan data center
• Thread berlebihan dan context switching L7 OS server (kernel)
• CPU throttling di container (kuota CFS) L7 OS server (kernel)
• Lonjakan latensi akibat manajemen daya server (C-state, pengaturan frekuensi) L7 OS server (kernel)
• Tugas terjadwal L7 OS server (kernel)
• Perubahan performa setelah update OS, kernel, driver, atau firmware L7 OS server (kernel)
• Pengiriman blocking akibat klien lambat L8 Socket dan protokol

Lihat kartu interaktif dengan gambar dan simulasi