Buku Putih Lag Game versi teks: 228 penyebab lag game online

Versi teks yang merangkum 228 penyebab game online patah-patah, karakter teleport, dan disconnect, lapis demi lapis dari layar Anda sampai database server. Setiap penyebab dilengkapi gejala, tim penanggung jawab (Tim Pengembang Game, Tim Infrastruktur), angka, dan sumber tepercaya.

Versi interaktif dengan gambar dan simulasi yang bisa Anda coba sendiri ada di Buku Putih Lag Game. Versi ini mengumpulkan penyebab, istilah, dan sumber yang sama dalam satu halaman yang bisa dibaca tanpa JavaScript. Setiap penyebab juga punya halaman tersendiri (c/ID.html). Versi Markdown dalam satu file tersedia di llms-full.txt.

Cari berdasarkan gejala

Lag berasal dari empat faktor: Latensi (Jarak, antrean, dan waktu pemrosesan membuat semua paket tiba terlambat secara konsisten.) Jitter (Rata-ratanya normal, tetapi sebagian paket datang cepat dan sebagian lagi terlambat. Penyebabnya antara lain Wi-Fi, jalur yang padat, dan CPU yang sibuk.) Packet loss (Antrean yang meluap, interferensi sinyal, dan perangkat yang rusak membuang paket. Koneksi yang putus sesaat juga terhitung packet loss beruntun.) Stall (Tick server terlambat atau terhenti (GC, lock, pemanggilan sinkron, beban berlebih), atau frame di PC Anda terhenti. Ini bisa terjadi meskipun koneksinya baik-baik saja.)

Tim penanggung jawab dan kode penanggung jawab

L1 Proses game di klien

Kode	Tim	Penanggung jawab	Cakupan
`cli`	Tim Pengembang Game	Pengembangan klien	Kode klien game: frame, GC, dan loading; interpolasi, ekstrapolasi, dan prediksi; pemrosesan jaringan di klien (termasuk pengiriman heartbeat dan reconnect otomatis)
`srv`	Tim Pengembang Game	Pengembangan server	Kode server game: tick, thread, dan lock; desain sinkronisasi; penanganan koneksi (loop accept, argumen listen); respons heartbeat dan pembersihan koneksi yang terputus; opsi socket; desain query dan transaksi
`net`	Tim Infrastruktur	Infrastruktur jaringan	Jalur dan perangkat jaringan data center (switch, router, firewall, load balancer, proteksi DDoS); network ACL, routing VPC, dan load balancer di cloud; ISP dan peering
`sys`	Tim Infrastruktur	Infrastruktur server	Server fisik dan instance cloud (termasuk security group dan connection tracking), konfigurasi OS dan kernel, NIC, lingkungan deploy dan monitoring
`dba`	Tim Infrastruktur	Infrastruktur DB	Server DB dan storage; konfigurasi, replikasi, dan backup DB; server cache
`ext`	Pihak Eksternal	Pihak Eksternal	PC dan jaringan rumah pemain, jalur ISP (di luar kontrak kami), penyedia cloud. Tidak bisa diperbaiki langsung, jadi ditangani lewat panduan untuk pemain, permintaan ke penyedia, dan solusi sementara (workaround)

Lonjakan frame time Frame hitch

ID cg-hitch · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Perhitungan satu frame memakan waktu beberapa kali lebih lama dari biasanya sehingga layar berhenti sejenak.

Mengapa Jumlah efek skill melonjak, spawn massal, dan pembaruan seluruh UI menumpuk dalam satu frame → Akibatnya Tidak selesai dalam 16,7 ms dan memakan 50–300 ms → Di layar Layar tersendat sesaat, lalu di frame berikutnya semua karakter berpindah sekaligus

Gejala: Patah-patah, Freeze
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Saat banyak pemain berkumpul, Saat melakukan aksi tertentu, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pecah pekerjaan berat ke beberapa frame, cari frame yang melonjak dengan profiler, batasi jumlah efek.
Kisaran angka: Satu frame pada 60 FPS adalah 16,7 ms. Satu frame saja yang melewati 50 ms sudah mudah dirasakan sebagai “tersendat”.
Di grafik: Melonjak acak sesekali · Frame time
Yang diperiksa: Rekam frame time (FrameTime) dan waktu yang dipakai CPU dan GPU untuk frame tersebut (CPUBusy dan GPUBusy) selama bermain dengan PresentMon. Untuk mobile, periksa metrik sesi lambat dan rendering lambat di Android vitals
Cocok jika: Frame time yang biasanya sekitar 16,7 ms melonjak melewati 50 ms tepat saat efek skill, spawn massal, atau pembaruan seluruh UI terjadi, dan pada saat itu ping tidak berubah
Tidak cocok jika: Frame time stabil, tetapi hanya karakter lain yang tersendat: mengarah ke sisi jaringan seperti “Buffer interpolasi tidak ada atau terlalu pendek”. Interval lonjakan teratur: periksa dulu “Garbage collection di klien”
Sarana pemeriksaan: Lingkungan pemain sendiri

3 sumber

Slow rendering Android (Google)
Untuk mencapai 60 FPS, satu frame harus digambar dalam 16 ms; jika terlambat, frame dilewati dan terlihat tersendat (jank)
Slow Sessions (games only) Android (Google)
Android vitals menganggap frame game lambat jika melewati 50 ms (20 FPS) atau 34 ms (30 FPS)
PresentMon Capture Application (README-CaptureApplication.md) Intel
FrameTime (waktu CPU di antara frame), CPUBusy dan GPUBusy (waktu yang dipakai CPU dan GPU untuk membuat frame itu)

Garbage collection di klien Client GC (Unity C#, Unreal, Lua)

ID cg-gc · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Selama memori bekas pakai (garbage) dikumpulkan kembali, seluruh game berhenti. Cirinya adalah patah-patah dengan interval yang teratur.

Mengapa Setiap frame membuat lalu membuang string, array, dan list sementara → Akibatnya Saat garbage menumpuk, GC menghentikan main thread untuk mengumpulkannya → Di layar Patah-patah secara teratur setiap beberapa detik hingga puluhan detik

Gejala: Patah-patah, Freeze
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Secara berkala, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Kurangi alokasi (hindari penggabungan string, LINQ, dan capture lambda), gunakan object pool, biarkan incremental GC aktif (default sejak Unity 2020), jalankan GC lebih awal saat jeda tidak mengganggu, misalnya di layar loading.
Kisaran angka: Biasanya beberapa ms hingga 100 ms sekali jalan; di ponsel spesifikasi rendah atau game yang memakai banyak memori bisa lebih lama (di simulasi sekitar 150–170 ms). GC Unity memeriksa seluruh heap setiap kali berjalan, jadi makin banyak memori yang dipakai game, makin lama jedanya.
Di grafik: Melonjak secara berkala · Frame time, waktu GC berjalan
Yang diperiksa: Di development build, periksa marker GC.Collect dan GC.Alloc di Unity Profiler. Di Unreal, gunakan stat GC dan stat Hitches (mencatat ke log setiap frame yang melewati waktu yang ditetapkan t.HitchFrameTimeThreshold)
Cocok jika: Setiap frame yang melonjak memiliki bagian GC.Collect yang lamanya mirip dengan lama lonjakan, dan intervalnya teratur setiap beberapa detik hingga puluhan detik. GC.Alloc per frame meningkat di tempat ramai
Tidak cocok jika: Tidak ada bagian GC di frame yang melonjak: lebih mungkin “Pemuatan sinkron dan kompilasi shader di main thread” atau “Beban rendering kerumunan besar”
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Umum di klien yang memakai C# seperti Unity. Penyebab utamanya adalah kode yang membuat ulang string log pertempuran, angka damage, dan teks UI di setiap frame. Jika patah-patah hanya terjadi di tempat ramai, berarti ada kode yang menghasilkan garbage sebanding dengan jumlah pemain. Incremental GC membagi pengumpulan sedikit demi sedikit per frame (default Unity 3 ms), tetapi jika garbage dibuat lebih cepat daripada kecepatan pengumpulannya, akhirnya game tetap berhenti sekaligus. Unreal Engine juga punya GC sendiri yang membersihkan game object yang tidak dipakai. Perilakunya berbeda menurut versi engine dan pengaturannya, tetapi dengan pengaturan default GC ini berjalan kira-kira setiap 1 menit dan bisa membuat game tersendat sesaat dengan interval 1 menit. Klien yang menulis aturan game dalam skrip seperti Lua juga menjalankan GC skrip itu secara terpisah.

5 sumber

Garbage collection modes Unity
Incremental GC adalah default dan mengumpulkan garbage secara terbagi di beberapa frame; jika dimatikan, main thread berhenti selama seluruh heap diperiksa dan jedanya bisa mencapai ratusan ms
Scripting.GarbageCollector.CollectIncremental Unity
Target default waktu yang dipakai incremental GC sekali jalan (time slice) adalah 3 ms (incrementalTimeSliceNanoseconds)
Garbage Collection Settings in the Unreal Engine Project Settings Epic Games
Pengaturan bahwa GC Unreal berjalan pada interval tertentu (Time Between Purging Pending Kill Objects, dalam detik). Nilai default tidak disebutkan di dokumen ini
Profiler markers reference Unity
GC.Collect: bagian saat kode program berhenti selama garbage collection (kurang dari 1 ms hingga ratusan ms), GC.Alloc: alokasi managed heap
Stat Commands in Unreal Engine Epic Games
stat GC (statistik garbage collection), stat Hitches (mencatat ke log frame yang melewati t.HitchFrameTimeThreshold)

Pemuatan sinkron dan kompilasi shader di main thread Synchronous asset load, shader compile

ID cg-sync-load · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Game berhenti karena harus membaca file dan membuat shader tepat sebelum menggambar area, monster, atau efek yang baru pertama kali muncul.

Mengapa Masuk area baru, skill, equipment, atau monster yang baru pertama kali muncul → Akibatnya Main thread menunggu pembacaan file dan kompilasi shader → Di layar Berhenti 0,1–1 detik hanya pada kali pertama, setelah itu normal

Gejala: Freeze, Patah-patah
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Saat bergerak atau pindah area, Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Gunakan loading asinkron, muat lebih awal (prewarming), kompilasi shader lebih awal di layar loading atau saat game pertama kali dijalankan, manfaatkan layar loading.
Kisaran angka: Kompilasi satu shader memakan puluhan ms, kalau lama bisa 100 ms atau lebih. Loading tekstur memakan puluhan hingga ratusan ms, tergantung kecepatan storage.
Di grafik: Melonjak tepat setelah server dibuka · Jumlah lonjakan frame (tepat setelah patch atau update driver)
Yang diperiksa: Rekam rute yang sama dua kali dengan PresentMon, lalu bandingkan kunjungan pertama dan kedua. Di development build Unreal, aktifkan r.PSOPrecache.Validation lalu periksa stat PSOPrecache dan “PSO PRECACHING MISS” di log; di Unity, periksa bagian loading dan shader pada frame yang melonjak di Timeline profiler
Cocok jika: Lonjakan 0,1–1 detik hanya terjadi di tempat yang pertama didatangi atau skill yang pertama dipakai, lalu hilang pada kali kedua. Laporan menumpuk tepat setelah patch atau update driver grafis, lalu berkurang
Tidak cocok jika: Selalu melonjak di tempat yang sama: masalahnya ada di luar cache shader. Berulang setiap kali bergerak, hanya di PC dengan storage lambat: lebih mungkin “Streaming aset tertinggal akibat storage lambat”. Memori GPU khusus penuh: lebih mungkin “Kekurangan memori grafis (VRAM)”
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Di PC, shader yang sudah dibuat sekali disimpan oleh driver grafis di cache shader lalu dipakai ulang. Karena itu, tepat setelah driver grafis diperbarui atau patch game dirilis, cache ini menjadi tidak berlaku, sehingga pemain yang tadinya lancar pun kembali mengalami patah-patah untuk sementara. Laporan yang khas berbunyi “setelah patch, tersendat setiap kali masuk tempat yang baru pertama didatangi”.

5 sumber

Shader loading Unity
Saat varian shader dipakai pertama kali, driver grafis harus membuatnya untuk GPU sehingga bisa terjadi jeda yang terasa; yang sudah dibuat disimpan di cache sehingga tidak berhenti lagi
Optimizing Rendering With PSO Caches in Unreal Engine Epic Games
Membuat pipeline state (PSO) tepat saat dibutuhkan bisa memakan 100 ms atau lebih, jadi PSO harus dibuat lebih awal
Direct3D 12 Return Codes Microsoft
D3D12_ERROR_DRIVER_VERSION_MISMATCH: cache PSO yang dibuat dengan versi driver lain tidak bisa dipakai ulang (dikompilasi ulang setelah update driver)
PresentMon Capture Application (README-CaptureApplication.md) Intel
Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame)
PSO Precaching for Unreal Engine Epic Games
Jika r.PSOPrecache.Validation diaktifkan, statistik PSO yang terlewat terlihat di stat PSOPrecache dan “PSO PRECACHING MISS” dicatat di log; pembuatan PSO saat runtime yang melewati 20 ms (default) dihitung sebagai hitch

Streaming aset tertinggal akibat storage lambat Slow storage stalls asset streaming

ID cg-asset-stream · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Pada storage lambat seperti HDD, kecepatan membaca tekstur dan model di open world tidak bisa mengimbangi gerakan pemain, sehingga objek terlambat muncul atau game patah-patah karena menunggu pembacaan selesai.

Mengapa Bergerak cepat dengan tunggangan atau teleportasi, atau masuk ke tempat ramai, sehingga banyak tekstur dan model baru dibutuhkan sekaligus → Akibatnya Storage lambat seperti HDD tidak bisa membaca secepat yang dibutuhkan sehingga permintaan baca menumpuk, dan sebagian loading membuat main thread menunggu sampai selesai → Di layar Tekstur buram untuk sementara, bangunan dan karakter terlambat muncul, dan saat menunggu pembacaan terjadi patah-patah atau freeze

Gejala: Tidak terlihat / objek hantu, Patah-patah, Freeze
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Saat bergerak atau pindah area, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Gunakan streaming asinkron agar main thread tidak menunggu pembacaan, baca lebih awal berdasarkan arah dan kecepatan gerak, tampilkan resolusi rendah (mipmap) dan model sederhana lebih dulu lalu ganti kemudian, batasi kecepatan gerak sebentar atau pakai layar loading jika streaming tertinggal saat bergerak cepat, cantumkan apakah SSD diperlukan di spesifikasi minimum dan yang direkomendasikan.
Tugas Pihak Eksternal: Imbau pemain untuk memasang game di SSD, minta pemain memeriksa apakah ada unduhan atau pemindaian antivirus yang berjalan di disk yang sama.
Kisaran angka: Menurut penjelasan Microsoft, hard disk lama membaca puluhan MB per detik, NVMe SSD membaca beberapa GB per detik, dan game generasi sebelumnya memakai sekitar 50 MB per detik untuk streaming. Jika game yang dirancang dengan asumsi kecepatan SSD dan membaca jauh lebih banyak dari itu dijalankan di HDD, pembacaan mudah tertinggal dari gerakan pemain.
Di grafik: Hanya sebagian yang tinggi · Jumlah lonjakan frame (per jenis storage), latensi baca disk
Yang diperiksa: Rekam PhysicalDisk\Avg. Disk sec/Read (rata-rata waktu satu kali baca) dan Current Disk Queue Length di Performance Monitor Windows bersama frame time PresentMon sambil bergerak cepat. Di development build, periksa stat Streaming dan stat AsyncLoad di Unreal, serta peringatan AssetBundle.asset/allAssets di Unity Profiler (hasil diminta sebelum loading selesai sehingga main thread menunggu)
Cocok jika: Saat bergerak cepat, latensi baca disk dan antrean melonjak, dan pada saat yang sama frame melonjak atau tekstur dan objek terlambat muncul. Hilang jika adegan yang sama dijalankan di SSD
Tidak cocok jika: Disk tidak sibuk, tetapi tekstur buram: lebih mungkin “Kekurangan memori grafis (VRAM)”. Normal sejak kunjungan kedua ke tempat yang sama: lebih mungkin “Pemuatan sinkron dan kompilasi shader di main thread”
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Jika game hanya berhenti pada kali pertama lalu normal, penyebabnya lebih dekat ke “Pemuatan sinkron dan kompilasi shader di main thread”. Jika berulang setiap kali bergerak dan hanya di PC dengan storage lambat, penyebabnya adalah yang ini. “Kekurangan memori grafis (VRAM)”, yaitu tekstur diturunkan lalu dinaikkan lagi karena memori grafis kurang, juga membuat tekstur buram, jadi periksa waktu tunggu baca disk dan pemakaian memori grafis bersama-sama. Pemindaian real-time antivirus juga bisa menyela setiap kali game membuka file sehingga pembacaan makin lambat.

8 sumber

DirectStorage is coming to PC Microsoft
Hard disk lama membaca puluhan MB per detik, NVMe SSD beberapa GB per detik, budget streaming aset game generasi sebelumnya sekitar 50 MB per detik, dan game open world membaca serta membuang pemandangan jauh secara real-time sambil pemain bergerak
Texture and mesh loading Unity
Upload sinkron membaca dan mengunggah data di main thread dalam satu frame sehingga terjadi jeda yang terlihat; upload asinkron melakukan streaming di beberapa frame
Texture Streaming Overview for Unreal Engine Epic Games
Streamer menaikkan dan menurunkan resolusi tekstur (mip) sesuai sudut pandang; sebagian besar perhitungan dilakukan di worker thread asinkron, dan mip yang terlihat di layar dimuat lebih dulu
Profiler markers reference Unity
Peringatan AssetBundle.asset/allAssets: hasil diminta sebelum loading selesai sehingga main thread berhenti untuk menunggu
Stat Commands in Unreal Engine Epic Games
stat Streaming (memori dan jumlah tekstur streaming), stat AsyncLoad (statistik loading asinkron)
Windows Performance Monitor Disk Counters Explained Microsoft
Avg. Disk sec/Read adalah rata-rata waktu untuk menyelesaikan satu kali baca (latensi I/O), Current Disk Queue Length adalah panjang antrean disk pada saat pengukuran
PresentMon Capture Application (README-CaptureApplication.md) Intel
Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame)
About regular quick and full scans with Microsoft Defender Antivirus Microsoft
Perlindungan real-time memeriksa file setiap kali file dibuka dan ditutup

Beban rendering kerumunan besar Render/animation cost of crowds

ID cg-crowd · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Saat ratusan karakter masuk ke satu layar seperti di siege atau world boss, biaya menggambarnya saja sudah tidak sanggup ditangani.

Mengapa Ratusan karakter dan efek bertumpuk di satu layar → Akibatnya Biaya animasi, bayangan, name tag, dan efek naik sebanding dengan jumlah karakter → Di layar FPS turun 60 → 15 sehingga semua gerakan patah-patah dan input juga terlambat

Gejala: Patah-patah, Input lag
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu, Hanya saya
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Sederhanakan model berdasarkan jarak (LOD), batasi jumlah karakter yang ditampilkan, sediakan opsi penyederhanaan efek, turunkan frekuensi update animasi.
Kisaran angka: Meskipun hanya 0,02–0,1 ms per karakter, 300 karakter berarti 6–30 ms. Frame budget pada 60 FPS adalah 16,7 ms, jadi itu saja sudah memakai lebih dari 1/3-nya, dan kalau banyak bisa melewatinya.
Di grafik: Naik mengikuti beban · Frame time, jumlah karakter di layar
Yang diperiksa: Bandingkan frame time serta CPUBusy dan GPUBusy di PresentMon sebelum dan sesudah siege atau world boss. Di development build, gunakan stat Unit di Unreal (waktu game thread, rendering thread, dan GPU)
Cocok jika: Frame time ikut naik seiring bertambahnya karakter di layar, dan langsung membaik jika batas jumlah karakter yang ditampilkan atau opsi penyederhanaan efek diaktifkan
Tidak cocok jika: Melonjak tanpa kaitan dengan jumlah karakter: lebih mungkin “Lonjakan frame time” atau “Garbage collection di klien”. FPS normal, tetapi hanya gerakan pemain lain yang tertinggal: lebih mungkin “Bottleneck pemrosesan paket di main thread”
Sarana pemeriksaan: Lingkungan pemain sendiri

4 sumber

Introduction to level of detail Unity
Tanpa LOD, objek yang terlihat kecil di layar pun digambar dengan kompleksitas yang sama; LOD mengurangi beban menggambar
Animation Budget Allocator in Unreal Engine Epic Games
Mengurangi update (tick) animasi skeletal mesh secara dinamis untuk menjaga waktu animasi tetap dalam budget
PresentMon Capture Application (README-CaptureApplication.md) Intel
Membedakan apakah CPU atau GPU yang memperlambat frame dengan FrameTime, CPUBusy, dan GPUBusy
Stat Commands in Unreal Engine Epic Games
stat Unit: frame time total serta waktu game thread, rendering thread, dan GPU

Bottleneck pemrosesan paket di main thread Network processing on the main thread

ID cg-net-mainthread · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika paket yang diterima hanya diproses dalam jumlah tertentu per frame, paket yang datang bertumpuk terus terdorong ke frame berikutnya.

Mengapa Di tempat ramai, ribuan update tiba setiap detik → Akibatnya Main thread terbentur batas jumlah pemrosesan per frame dan tidak sempat membaca semuanya → Di layar Gerakan pemain lain makin lama makin terlambat, lalu diterapkan sekaligus

Gejala: Fast forward, Input lag
Faktor: Stall, Latensi
Siapa yang mengalami: Lokasi/channel tertentu, Hanya saya
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: terima dan parse paket di thread terpisah, gabungkan update posisi lama untuk objek yang sama dan terapkan yang terbaru saja. Server: di tempat ramai, kirim update karakter yang jauh dengan frekuensi lebih rendah untuk mengurangi volume kirim.
Kisaran angka: Begitu paket yang belum diproses menumpuk, hanya butuh beberapa detik sampai tertinggal sebanyak 1 detik.
Di grafik: Naik mengikuti beban · Jumlah paket terima yang belum diproses, latensi dari diterima hingga diterapkan
Yang diperiksa: Catat di log jumlah paket yang tersisa karena tidak sempat diproses klien di setiap frame, serta latensi dari waktu paket tiba hingga diterapkan ke game, lalu periksa bersama jumlah pemain di sekitar
Cocok jika: Di tempat ramai, jumlah paket yang tersisa dan latensi penerapan terus bertambah, sedangkan pada saat yang sama ping dan interval kirim server normal
Tidak cocok jika: Tidak ada latensi penerapan, tetapi paketnya sendiri tiba terlambat: mengarah ke jalur jaringan. Frame time naik tajam: lebih mungkin “Beban rendering kerumunan besar”
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

Actor Priority in Unreal Engine Epic Games
Jika bandwidth kurang, tidak semua actor direplikasi setiap kali; prioritas ditentukan dari jarak ke pengamat dan waktu sejak replikasi terakhir
Replication Graph in Unreal Engine Epic Games
Game dengan banyak pemain dan objek replikasi (MMORPG dan sebagainya) harus mengelompokkannya per lokasi dan hanya mengirim objek yang diperlukan agar terhindar dari bottleneck CPU server

Buffer interpolasi tidak ada atau terlalu pendek Missing/short interpolation buffer

ID cg-no-buffer · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika paket server langsung digambar begitu diterima, jitter (variasi selang waktu kedatangan paket) langsung terlihat di layar.

Mengapa Posisi yang diterima langsung digambar, atau buffer lebih pendek dari jitter → Akibatnya Berhenti selama paket terlambat, lalu melompat saat paket datang bertumpuk → Di layar Karakter lain bergerak tersendat-sendat

Gejala: Patah-patah
Faktor: Jitter
Siapa yang mengalami: Hanya saya
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: siapkan buffer interpolasi, sesuaikan panjang buffer secara otomatis menurut kondisi koneksi. Server: terapkan lag compensation (hit registration dengan memutar mundur waktu) agar tembakan ke posisi lawan di masa lalu (sepanjang buffer) tetap dinilai tepat.
Kisaran angka: Biasanya buffer diatur sekitar 2 kali interval pengiriman paket dari server (100 ms jika menerima 20 kali per detik).
Di grafik: Selalu tinggi sejak awal · Interval kedatangan paket, berapa kali buffer interpolasi kosong
Yang diperiksa: Di klien, catat distribusi interval kedatangan paket server dan jumlah frame yang berhenti atau beralih ke ekstrapolasi karena tidak ada snapshot berikutnya untuk diinterpolasi
Cocok jika: Variasi interval kedatangan sering melebihi panjang buffer interpolasi, dan setiap kali itu buffer kosong sehingga karakter lain tersendat. Berkurang jika buffer diperpanjang
Tidak cocok jika: Buffer sudah cukup, tetapi tetap tersendat: periksa apakah interval kirim server sendiri tidak teratur (tick terlambat)
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Buffer yang lebih panjang membuat gerakan lebih mulus, tetapi lawan juga terlihat dalam posisi masa lalu sepanjang itu. Karena itu, hit registration dibarengi lag compensation: server memutar mundur waktu ke “masa lalu yang dilihat pemain itu” untuk memeriksanya.

3 sumber

Interpolation and extrapolation (Netcode for Entities 6.5) Unity
Interpolasi dengan buffer, yaitu sengaja menggambar lebih lambat untuk menunggu paket yang terlambat; makin besar buffer, makin akurat, tetapi latensinya juga makin besar
Struct ClientTickRate (Netcode for Entities 6.5) Unity
Nilai default buffer interpolasi InterpolationTimeNetTicks = 2 (setara 2 kali pengiriman server)
Physics (Netcode for Entities 6.5) Unity
Lag compensation: server mencari state collision yang dilihat klien pada tick itu untuk menentukan apakah serangan kena

Ekstrapolasi berlebihan (dead reckoning) Over-extrapolation / dead reckoning

ID cg-extrap · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Selama paket tidak datang, objek terus ditampilkan bergerak dengan kecepatan terakhir, lalu dikembalikan begitu ketahuan salah.

Mengapa Paket berhenti diterima, objek terus digerakkan dengan arah dan kecepatan terakhir → Akibatnya Sebenarnya lawan sudah berhenti atau berbelok → Di layar Karakter lawan berjalan cukup jauh lalu tiba-tiba pindah ke posisi sebenarnya atau menembus dinding. Jika interval kedatangan paket tidak beraturan, karakter berulang kali melaju ke depan lalu tertarik kembali sehingga bergerak seperti bergetar

Gejala: Teleport, Patah-patah
Faktor: Packet loss, Jitter
Siapa yang mengalami: Hanya saya
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Batasi waktu ekstrapolasi (misalnya 200–250 ms), geser perlahan ke posisi yang benar saat ternyata salah.
Kisaran angka: Pada kecepatan 6 m/s, selisih 300 ms saja sudah membuat posisi meleset 1,8 m.
Di grafik: Melonjak acak sesekali · Waktu ekstrapolasi, jarak koreksi posisi
Yang diperiksa: Catat berapa lama karakter lain digambar dengan ekstrapolasi dan seberapa jauh posisinya dikoreksi setelah paket baru datang
Cocok jika: Setiap kali paket terputus, waktu ekstrapolasi memanjang tanpa batas, lalu jarak koreksinya membesar hingga beberapa m
Tidak cocok jika: Ekstrapolasi sudah berhenti cepat, tetapi karakter tetap teleport: packet loss atau latensinya sendiri besar, periksa sisi koneksi dan rute
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

Interpolation and extrapolation (Netcode for Entities 6.5) Unity
Ekstrapolasi yang terus bergerak dengan arah dan kecepatan yang sama saat snapshot berikutnya tidak datang tepat waktu sering salah, jadi diberi batas (default Unity 20 tick, sekitar 1/3 detik pada 60 Hz)
Peeking into VALORANT's Netcode Riot Games
Jika tebakan untuk mengisi data yang terlambat atau hilang ternyata salah, posisi tidak cocok dengan server sehingga karakter melompat atau dikoreksi seperti meluncur

Prediksi sisi klien meleset Prediction mismatch / reconciliation

ID cg-predict · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Klien Anda menampilkan gerakan lebih dulu, tetapi jika server menghitungnya berbeda, karakter Anda tertarik kembali.

Mengapa Klien bergerak lebih dulu sebelum konfirmasi server (prediksi) → Akibatnya Server menghitung collision, kecepatan gerak, atau buff secara berbeda, atau tidak menerima perintahnya → Di layar Saat konfirmasi datang, karakter Anda tertarik ke belakang

Gejala: Rubber banding
Faktor: Packet loss, Latensi
Siapa yang mengalami: Hanya saya
Kapan: Saat bergerak atau pindah area, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: pakai kode gerakan yang sama dengan server, kirim input secara duplikat, haluskan koreksi. Server: pakai kode gerakan yang sama dengan klien, saring input duplikat berdasarkan nomor input agar hanya diproses sekali.
Kisaran angka: Jarak karakter tertarik adalah “lama ketidakcocokan × kecepatan gerak”. Hilangnya beberapa perintah saja sudah membuat karakter tertarik 1–3 m.
Di grafik: Melonjak acak sesekali · Jumlah rekonsiliasi server (prediksi gagal)
Yang diperiksa: Catat jumlah dan jarak koreksi posisi yang dikirim server. Di Unreal, hitung koreksi ClientAdjustPosition dari server; di Unity Netcode for Entities, hitung berapa kali simulasi diputar mundur dan dihitung ulang karena prediksi gagal
Cocok jika: Koreksi menumpuk pada waktu laporan rubber banding, dan jarak koreksi berulang kali besar pada buff, medan, atau skill gerak tertentu
Tidak cocok jika: Koreksi hanya menumpuk saat packet loss tinggi: mengarah ke paket input yang hilang (koneksi). Tidak ada koreksi, tetapi hanya karakter lain yang terlihat tertarik: lebih mungkin “Ekstrapolasi berlebihan (dead reckoning)”
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Introduction to prediction (Netcode for Entities 6.5) Unity
Klien dan server memprediksi dengan kode simulasi yang sama; jika berbeda dari state server (prediksi gagal), simulasi diputar mundur dan dihitung ulang, dan koreksinya terlihat
Use the command stream to handle user inputs (Netcode for Entities 6.5) Unity
Untuk mengantisipasi packet loss, input beberapa tick sebelumnya dikirim secara duplikat bersama input terbaru
Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
Klien bergerak lebih dulu dan server mereproduksi gerakan yang sama; jika posisinya berbeda, server mengoreksi dengan ClientAdjustPosition lalu gerakan yang tersimpan diterapkan ulang

Catch-up fixed timestep yang lepas kendali Fixed-timestep catch-up / spiral of death

ID cg-fixed-step · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Setelah sekali berhenti, game menghitung kerja yang tertunda sekaligus, dan perhitungan itu membuatnya tertinggal lagi.

Mengapa Simulasi game berjalan dengan interval tetap, lalu sekali berhenti → Akibatnya Step yang tertunda dihitung sekaligus dalam satu frame → Di layar Frame panjang terjadi beruntun dan melonjak, atau terbentur batas sehingga dunia game melambat

Gejala: Patah-patah, Fast forward, Slow motion
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Sesekali secara acak, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Batasi catch-up per frame, tangani sisa waktu dengan interpolasi.
Di grafik: Melonjak acak sesekali · Frame time, jumlah fixed step per frame
Yang diperiksa: Di profiler development build, periksa berapa kali fixed step berjalan dalam satu frame (di Unity, jumlah marker tahap FixedUpdate seperti FixedBehaviourUpdate) bersama frame time
Cocok jika: Setelah satu frame panjang, menyusul beruntun frame panjang yang menjalankan banyak step, dan saat menyentuh batas (Maximum Allowed Timestep di Unity) waktu game berjalan lebih lambat dari waktu nyata
Tidak cocok jika: Frame panjang hanya terjadi sekali: lebih mungkin “Lonjakan frame time” atau “Garbage collection di klien”
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Perhitungan fisika Unity (FixedUpdate) adalah contoh khas fixed step (default 0,02 detik, 50 kali per detik). Maximum Allowed Timestep di pengaturan Time (waktu maksimum yang dikejar dalam satu frame, default sekitar 0,33 detik) adalah batas catch-up. Jika satu frame lebih panjang dari itu, kelebihan waktunya dibuang, sehingga jam game tertinggal dari waktu nyata sebanyak itu.

3 sumber

Set fixed timestep to optimize physics simulation frequency Unity
Default Fixed Timestep 0,02 detik (50 kali per detik); jika frame panjang, step fisika dijalankan beberapa kali dalam satu frame sehingga beban bertambah
Handling variation in time Unity
Default Maximum Allowed Timestep 1/3 detik (0.3333333); walaupun game berhenti 1 detik, waktu game hanya maju 0,333 detik; batas ini mencegah lingkaran setan ketika step catch-up memperlambat game lagi
Profiler markers reference Unity
FixedBehaviourUpdate: bagian eksekusi MonoBehaviour.FixedUpdate; marker fisika dipanggil di tahap FixedUpdate

Kesalahan sinkronisasi jam Clock sync error

ID cg-clock · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Jika waktu server yang diperkirakan klien salah, titik waktu interpolasi dan pengecekan cooldown tidak cocok dengan server.

Mengapa Waktu server hanya disamakan sekali saat login, lalu dibiarkan meski ping berubah → Akibatnya Titik waktu interpolasi dan waktu berakhirnya cooldown tidak cocok dengan server → Di layar Lawan sesekali tersendat, skill ditolak padahal cooldown sudah selesai

Gejala: Patah-patah, Aksi hilang / rollback
Faktor: Latensi
Siapa yang mengalami: Hanya saya
Kapan: Makin lama menyala, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Sinkronkan waktu secara berkala (ukur waktu pulang-pergi lalu koreksi), sesuaikan perlahan tanpa perubahan mendadak, ukur waktu yang berlalu dengan monotonic clock, jangan dengan jam PC.
Di grafik: Naik perlahan · Selisih waktu server yang diperkirakan
Yang diperiksa: Catat secara berkala selisih antara waktu server yang diperkirakan klien dan waktu server (nomor tick) yang dikirim server di dalam paket
Cocok jika: Selisih makin besar seiring waktu sejak login, atau melonjak sekaligus saat jam PC disesuaikan, dan sekitar waktu itu laporan skill ditolak atau tersendat bertambah
Tidak cocok jika: Selisih tetap kecil, tetapi skill ditolak: mengarah ke keputusan server atau latensi
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Jika waktu yang berlalu diukur dengan tanggal dan jam PC (wall clock), waktu game melonjak begitu Windows menyesuaikan jam dengan waktu internet atau pengguna mengubah jam. Waktu yang berlalu harus diukur dengan monotonic clock yang tidak pernah mundur (Stopwatch dan sebagainya).

3 sumber

RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification IETF
Cara menghitung latensi pulang-pergi dan selisih jam dari empat stempel waktu request dan response
Acquiring high-resolution time stamps Microsoft
QueryPerformanceCounter (dipakai Stopwatch) adalah jam untuk mengukur waktu berlalu yang tidak disinkronkan dengan waktu eksternal; waktu sistem dipakai hanya jika butuh waktu UTC
Time synchronization (Netcode for Entities 6.5) Unity
Memperkirakan waktu server dari waktu pulang-pergi, lalu menyamakannya dengan menyesuaikan laju waktu sedikit demi sedikit tanpa mengubah jam secara drastis

Hilangnya presisi waktu bertipe float Float time precision loss on long sessions

ID cg-float-time · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Jika waktu game disimpan dalam format bilangan desimal berpresisi rendah (float), makin lama game menyala, makin turun resolusi waktunya (selisih waktu terkecil yang bisa dibedakan), sehingga gerakan dan efek bergetar.

Mengapa Waktu sejak game dinyalakan diakumulasi dalam float atau langsung diteruskan ke shader → Akibatnya Makin lama game menyala, makin besar selisih terkecil yang bisa dinyatakan float → Di layar Karakter, animasi, dan efek yang mengalir bergetar hanya di klien yang sudah menyala berhari-hari, lalu normal lagi setelah game dimulai ulang

Gejala: Patah-patah
Faktor: Jitter
Siapa yang mengalami: Hanya saya
Kapan: Makin lama menyala
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Simpan waktu yang berlalu dalam double (64-bit) atau integer, reset waktu yang diteruskan ke shader secara berkala, jalankan tes otomatis jangka panjang selama beberapa hari.
Kisaran angka: Float 32-bit hanya punya sedikit lebih dari 7 digit signifikan, sehingga setelah menyala sehari (sekitar 86.400 detik) resolusi waktunya sekitar 8 ms, kira-kira setengah dari satu frame 60 FPS (16,7 ms), dan setelah seminggu sekitar 60 ms, lebih besar dari satu frame.
Di grafik: Naik perlahan · Laporan getaran per lama klien menyala
Yang diperiksa: Minta laporan getaran disertai lama klien menyala, lalu bandingkan sebelum dan sesudah game dimulai ulang. Di sisi pengembangan, uji dengan mengatur nilai waktu mulai game seolah sudah lewat beberapa hari
Cocok jika: Bergetar hanya di klien yang menyala berhari-hari, hilang setelah dimulai ulang, dan makin parah makin lama klien menyala
Tidak cocok jika: Langsung bergetar begitu dinyalakan: lebih mungkin “Buffer interpolasi tidak ada atau terlalu pendek” atau “Resolusi timer”
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Terutama muncul di MMO mobile yang fitur auto hunt-nya dinyalakan dan tidak dimatikan selama berhari-hari. Time.time di Unity juga bertipe float, sehingga Unity menyediakan Time.timeAsDouble yang bertipe double secara terpisah dan menyarankan pemakaiannya.

2 sumber

Time.timeAsDouble Unity
Versi double dari Time.time; makin lama game menyala, makin presisi dibanding float, sehingga umumnya disarankan
Floating-point numeric types (C# reference) Microsoft
Presisi float sekitar 6–9 digit, double sekitar 15–17 digit

V-Sync dan antrean render V-Sync, render queue

ID cg-vsync · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Frame yang sudah digambar GPU ditumpuk beberapa buah di antrean, lalu dikirim ke layar mengikuti siklus refresh monitor; selama itu input terlambat.

Mengapa Driver grafis menumpuk 1–3 frame lebih dulu di antrean → Akibatnya Input butuh waktu lebih lama sebanyak itu sampai tampil di layar → Di layar Ping rendah, tetapi kontrol terasa berat dan lamban

Gejala: Input lag, Patah-patah
Faktor: Latensi
Siapa yang mengalami: Hanya saya
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Dukung mode latensi rendah, perkecil antrean frame, sediakan opsi batas FPS sedikit di bawah refresh rate, aktifkan fitur frame pacing di ponsel.
Tugas Pihak Eksternal: Imbau pemain untuk memasang batas FPS sedikit di bawah refresh rate saat memakai monitor variable refresh rate, dan untuk mengaktifkan mode latensi rendah di driver grafis.
Kisaran angka: Pada 60 Hz, satu frame 16,7 ms. Jika CPU lebih cepat dari GPU atau siklus layar sehingga antrean tiga frame (default DirectX 11) penuh, latensinya bertambah 50 ms. Pada V-Sync double buffer, frame yang butuh 17 ms harus menunggu sampai refresh layar berikutnya (33,3 ms), dan selama itu frame sebelumnya tampil sekali lagi.
Di grafik: Selalu tinggi sejak awal · Latensi dari input hingga layar
Yang diperiksa: Bandingkan MsClickToPhotonLatency dan MsAllInputToPhotonLatency (dari input mouse dan keyboard sampai dikirim ke layar) serta DisplayLatency di PresentMon sambil mengganti V-Sync, mode latensi rendah, dan batas FPS. MsPCLatency (sejak PC menerima input sampai dikirim ke layar) hanya tercatat jika game mengirim event PC Latency
Cocok jika: Saat V-Sync aktif atau tanpa batas FPS, latensi ini bertambah satu atau dua frame (puluhan ms), lalu berkurang dengan mode latensi rendah atau batas FPS sedikit di bawah refresh rate. Ping tidak berubah
Tidak cocok jika: Latensi di dalam PC rendah, tetapi kontrol tetap terlambat: lebih mungkin “Latensi layar, perangkat input, dan frame generation”. Ping tinggi: mengarah ke sisi jaringan
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: V-Sync (vertical sync) adalah pengaturan yang hanya mengirim frame baru tepat saat monitor mengganti gambar. Screen tearing hilang, tetapi input terlambat sebanyak waktu menunggu momen itu, dan jika FPS turun di bawah 60, FPS bolak-balik antara 60 dan 30 sehingga game patah-patah. Monitor variable refresh rate mengganti gambar mengikuti saat frame siap sehingga waktu tunggu ini berkurang. Hal yang sama terjadi di ponsel. Jika game 30 FPS tidak bisa mengirim frame secara merata ke layar 60 Hz, rata-ratanya memang 30 FPS, tetapi tiap frame tampil dengan lama yang tidak beraturan seperti 49, 16, dan 33 ms sehingga game patah-patah (contoh dari dokumentasi developer Android). Masalah ini dikurangi dengan library frame pacing Android (meratakan interval keluaran frame) atau opsi serupa di engine.

5 sumber

IDXGIDevice1::SetMaximumFrameLatency Microsoft
Default jumlah frame yang bisa ditumpuk driver di antrean adalah 3 (1–16)
Reduce latency with DXGI 1.3 swap chains Microsoft
Present terblokir sampai antrean kosong sehingga frame menunggu hampir satu frame lagi antara selesai digambar dan ditampilkan; dikurangi dengan waitable swap chain
Frame Pacing library Android (Google)
Di layar 60 Hz, jika tidak ada frame baru, frame sebelumnya ditampilkan lagi; contoh frame time game 30 FPS yang tidak beraturan seperti 49, 16, dan 33 ms
PresentMon Capture Application (README-CaptureApplication.md) Intel
MsPCLatency (sejak PC menerima input hingga dikirim ke layar), MsClickToPhotonLatency (klik mouse hingga layar), MsAllInputToPhotonLatency (input keyboard dan mouse hingga layar), DisplayLatency (frame diserahkan hingga dikirim ke monitor)
PresentMon Console Application (README-ConsoleApplication.md) Intel
MsPCLatency hanya tercatat jika aplikasi mengirim event PC Latency (--track_pc_latency), MsAllInputToPhotonLatency diukur dari input keyboard dan mouse

Kebocoran memori di klien Client memory leak

ID cg-leak · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Makin lama game menyala, makin besar memori yang dipakai sehingga game makin lambat dan akhirnya tertutup paksa.

Mengapa Tekstur, UI, dan efek tidak dilepas saat berpindah area bolak-balik → Akibatnya GC makin sering berjalan dan memori OS kurang sehingga terjadi swap → Di layar Setelah beberapa jam bermain, game makin patah-patah lalu tertutup paksa (bagi pemain terlihat seperti disconnect)

Gejala: Patah-patah, Disconnect
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Makin lama menyala
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Ukur pemakaian memori saat berpindah area, cari dan perbaiki tekstur, UI, dan efek yang tidak dilepas, jalankan tes otomatis jangka panjang (soak test).
Di grafik: Naik perlahan · Memori proses game
Yang diperiksa: Rekam Process(game)\Private Bytes selama beberapa jam dengan Performance Monitor. Untuk mobile, periksa alasan penutupan di ApplicationExitInfo Android (REASON_LOW_MEMORY) dan laporan jetsam iOS
Cocok jika: Memori naik setiap kali berpindah area dan tidak turun lagi, dan makin lama game menyala, makin sering patah-patah dan tertutup paksa
Tidak cocok jika: Memori stabil, tetapi makin lama game menyala hanya getarannya yang makin parah: lebih mungkin “Hilangnya presisi waktu bertipe float”
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Ponsel umumnya bertahan dengan mengompresi memori. Jika memori tetap kurang, OS langsung menutup game (terlempar keluar). Makin kecil RAM perangkat, makin cepat game ditutup.

4 sumber

Memory allocation among processes Android (Google)
Android bertahan dengan mengompresi memori ke zRAM, dan jika tetap kurang, low memory killer menutup proses; jika aplikasi yang sedang tampil di depan ditutup, terlihat seperti crash
Identifying high-memory use with jetsam event reports Apple
iOS menutup paksa aplikasi (jetsam) jika tekanan memori tidak mereda, dan aplikasi yang melewati batas memorinya menjadi sasaran penutupan
Find user-mode memory leaks with Performance Monitor (PerfMon) Microsoft
Rekam Process > Private Bytes (memori privat yang dialokasikan proses) dan Virtual Bytes dalam waktu lama; jika terus naik, berarti ada kebocoran
ApplicationExitInfo Android (Google)
REASON_LOW_MEMORY: low memory killer sistem menutup proses aplikasi (perangkat yang tidak mendukungnya melaporkannya sebagai REASON_SIGNALED dengan SIGKILL)

Crash di klien Client crash

ID cg-crash · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Game tertutup karena error yang tidak tertangani. Bagi pemain ini terlihat seperti disconnect, tetapi server normal.

Mengapa Null reference, memori kurang, error driver grafis → Akibatnya Proses game tertutup paksa → Di layar Laporan “terlempar keluar”. Pada saat yang sama pemain lain baik-baik saja

Gejala: Disconnect
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Saat melakukan aksi tertentu, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Kumpulkan laporan crash, buat statistik per perangkat dan driver, perbaiki lebih dulu error yang paling banyak terjadi.
Tugas Pihak Eksternal: Jika crash terkumpul pada versi driver grafis tertentu, imbau pemain untuk memperbarui driver.
Di grafik: Hanya sebagian yang tinggi · Jumlah crash (per perangkat, driver grafis, dan build)
Yang diperiksa: Periksa laporan crash dan crash rate di Android vitals per perangkat, driver, dan build. Di PC pemain, periksa event ID 1000 di log Application pada Event Viewer (nama modul yang error) dan catatan “Display driver stopped responding and has recovered”
Cocok jika: Ada catatan crash pada waktu laporan disconnect, dan pemain lain di server yang sama pada waktu itu normal. Terkumpul pada perangkat, versi driver, atau modul tertentu
Tidak cocok jika: Tidak ada catatan crash, hanya koneksinya yang putus: lebih mungkin “Mapping NAT kedaluwarsa” atau sisi koneksi
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Crashes Android (Google)
Crash adalah aplikasi yang tertutup tanpa terduga karena exception yang tidak ditangani atau sinyal (SIGSEGV dan sebagainya); dihitung di Android vitals pada Play Console
WDDM Support for Timeout Detection and Recovery (TDR) Microsoft
Jika GPU tidak menyelesaikan pekerjaan dalam 2 detik (default), Windows mengatur ulang driver grafis dan GPU
The application or service crashing behavior troubleshooting guidance Microsoft
Event ID 1000 di log Application adalah catatan crash yang sebenarnya, berisi nama aplikasi yang error dan nama modul yang error (Faulting module name)

Pemindaian oleh modul keamanan game (anti-cheat) Anti-cheat scan and heartbeat

ID cg-anticheat · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Modul keamanan yang berjalan bersama game untuk mencegah cheat melakukan pemeriksaan secara berkala. Jika pemeriksaannya berat atau heartbeat (sinyal berkala yang menandakan klien masih hidup) ke server keamanan terlambat, game menjadi patah-patah atau disconnect.

Mengapa Modul keamanan secara berkala memeriksa memori game, program yang sedang berjalan, dan driver → Akibatnya Selama pemeriksaan, thread game berhenti, atau heartbeat tidak terkirim tepat waktu → Di layar Tersendat sesaat dengan interval tetap; jika parah, disconnect disertai pesan error keamanan

Gejala: Patah-patah, Freeze, Disconnect
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Secara berkala, Tepat setelah login atau maintenance, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: jalankan pemeriksaan berat di luar thread game dan bagi sedikit demi sedikit, bandingkan statistik patah-patah dan terlempar keluar per versi modul keamanan (jika menumpuk tepat setelah update, teruskan ke vendor modul keamanan). Server: toleransi heartbeat yang terlambat satu atau dua kali.
Kisaran angka: Pemeriksaan ringan biasanya kurang dari 1 ms, tetapi pemeriksaan berat yang berjalan di thread game bisa memakan puluhan hingga ratusan ms sekali jalan, tergantung implementasinya.
Di grafik: Melonjak secara berkala · Frame time, jumlah kick oleh anti-cheat
Yang diperiksa: Ukur interval lonjakan di frame time PresentMon, lalu agregasikan alasan kick anti-cheat yang diterima server (di EOS, AuthenticationFailed / Authentication Timed Out di ClientActionReason, dan sebagainya) per versi modul keamanan dan spesifikasi
Cocok jika: Jeda singkat dengan interval tetap berulang tanpa kaitan dengan situasi game, dan tepat setelah update modul keamanan, patah-patah dan kick karena timeout autentikasi bertambah pada spesifikasi tertentu
Tidak cocok jika: Interval yang sama di semua spesifikasi tanpa kaitan dengan versi modul keamanan: lebih mungkin “Garbage collection di klien” atau “Pemakaian CPU oleh proses di latar belakang”
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Modul keamanan masuk jauh ke dalam OS sebagai driver, sehingga bisa bentrok dengan antivirus, overlay, atau modul keamanan game lain. Jika laporan patah-patah dan terlempar keluar menumpuk hanya pada spesifikasi tertentu tepat setelah update modul keamanan, curigai penyebab ini lebih dulu.

2 sumber

Using the Anti-Cheat Interfaces Epic Games
Jika server tidak menerima pesan anti-cheat dari klien dalam waktu yang ditentukan (RegisterTimeout), klien dikeluarkan karena timeout autentikasi (penyebab umumnya klien yang berhenti karena loading); jika masalahnya ada di update modul terbaru, kembalikan ke modul sebelumnya
PresentMon Capture Application (README-CaptureApplication.md) Intel
Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame)

L2 OS dan perangkat klien

Pemakaian CPU oleh proses di latar belakang Background CPU contention

ID co-background · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Saat pemindaian antivirus, Windows Update, program streaming, atau video di browser memakai core CPU, thread game tidak mendapat jatah CPU dan harus menunggu.

Mengapa Program lain memakai core CPU dalam waktu lama → Akibatnya Thread game menunggu jatah CPU → Di layar Frame terlambat dan pemrosesan paket yang diterima juga terlambat

Gejala: Patah-patah, Fast forward
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Sesekali secara acak, Secara berkala
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Sesuaikan prioritas thread game, sertakan pemakaian CPU seluruh PC di log saat terjadi patah-patah untuk membedakan apakah penyebabnya program lain.
Tugas Pihak Eksternal: Imbau pemain untuk mengaktifkan Mode Game di Windows dan menutup program yang tidak perlu selama bermain (pemindaian antivirus, Windows Update, program streaming, video di browser).
Kisaran angka: Windows biasanya memberikan core sekali jalan selama beberapa ms hingga puluhan ms. Tertunda sekali saja dalam penjadwalan sudah membuat satu frame hilang.
Di grafik: Melonjak acak sesekali · Pemakaian CPU seluruh PC, frame time
Yang diperiksa: Rekam kolom CPU di tab Processes pada Task Manager dan Processor Information(_Total)\% Processor Time di Performance Monitor bersama frame time PresentMon. Jika curiga antivirus, rekam dengan New-MpPerformanceRecording lalu cari file dan proses dengan waktu pemindaian terlama lewat Get-MpPerformanceReport
Cocok jika: Pada waktu tersendat, pemakaian CPU program lain (pemindaian antivirus, update, program streaming) melonjak, atau file di folder game masuk daftar teratas waktu pemindaian. Hilang jika program itu dimatikan atau dikecualikan
Tidak cocok jika: Pemakaian CPU rendah, tetapi seluruh layar tersendat dan suara berderak: lebih mungkin “Mode hemat daya NIC dan masalah driver” (latensi DPC)
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Windows memberi prioritas sedikit lebih tinggi pada program di jendela yang sedang aktif di depan (foreground), tetapi jika pekerjaan lebih banyak daripada core yang ada, game pun harus menunggu. Antivirus lebih sering mengganggu lewat “pemantauan real-time” daripada lewat pemakaian CPU. Setiap kali game membuka file, antivirus memeriksanya sehingga jeda saat membaca aset makin panjang.

6 sumber

Multitasking Microsoft
Windows memberi setiap thread time slice dan beralih ke thread berikutnya saat jatahnya habis; time slice sekitar 20 ms (berbeda menurut OS dan CPU)
Priority Boosts Microsoft
Proses di jendela depan (foreground) dinaikkan prioritasnya hingga minimal setara dengan proses di latar belakang
About regular quick and full scans with Microsoft Defender Antivirus Microsoft
Perlindungan real-time memeriksa setiap kali file dibuka dan ditutup, dan setiap kali folder dibuka
Network-Related Performance Counters Microsoft
Counter Processor Information: % Processor Time
Performance analyzer for Microsoft Defender Antivirus Microsoft
Rekam dengan New-MpPerformanceRecording lalu lihat file, path, dan proses teratas yang memengaruhi waktu pemindaian dengan Get-MpPerformanceReport
PresentMon Capture Application (README-CaptureApplication.md) Intel
Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame)

Mode hemat daya dan thermal throttling Power saving, thermal throttling

ID co-power · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Mode baterai laptop, mode hemat daya ponsel, dan panas perangkat menurunkan kecepatan CPU dan GPU. Ciri penurunan karena panas: awalnya normal, lalu baru melambat setelah cukup lama.

Mengapa Mode baterai atau hemat daya aktif, atau perangkat menjadi panas → Akibatnya Clock CPU dan GPU diturunkan 30–50%, tergantung perangkat → Di layar Dengan mode hemat daya, FPS turun dan game patah-patah sejak awal; karena panas, setelah bermain beberapa menit hingga sekitar 20 menit

Gejala: Patah-patah, Input lag
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Makin lama menyala, Selalu
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Atur opsi grafis secara otomatis, kelola panas dengan batas FPS, turunkan opsi lebih awal berdasarkan tingkat panas yang dilaporkan OS (thermalState di iOS, API status termal di Android), tandai file executable agar memakai GPU diskrit di laptop dengan dua chip grafis (ekspor NvOptimusEnablement dan AmdPowerXpressRequestHighPerformance).
Tugas Pihak Eksternal: Imbau pemain untuk mematikan mode hemat daya dan menyambungkan laptop ke listrik, untuk laporan “laptop bagus, tetapi FPS rendah” periksa chip grafis mana yang menjalankan game lalu minta pemain menetapkan game ke GPU berperforma tinggi di pengaturan grafis Windows.
Di grafik: Naik perlahan · FPS, clock CPU dan GPU
Yang diperiksa: Rekam CPUFrequency, GPUFrequency, CPUTemperature, dan GPUTemperature di PresentMon bersama frame time selama 20–30 menit, lalu periksa chip grafis yang menjalankan game lewat kolom GPU engine di tab Processes pada Task Manager. Untuk mobile, rekam API termal Android (getThermalHeadroom, status termal) dan thermalState iOS bersama FPS
Cocok jika: FPS turun sejak clock turun setelah suhu naik, atau clock rendah hanya dalam mode baterai atau hemat daya. Atau game berjalan di grafis terintegrasi
Tidak cocok jika: Clock dan suhu tetap, tetapi FPS turun: lebih mungkin “Pemakaian CPU oleh proses di latar belakang” atau “Kebocoran memori di klien”
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Laptop dengan dua chip grafis kadang menjalankan game di grafis terintegrasi yang lebih lambat untuk menghemat daya. Jika laporannya “laptop bagus, tetapi FPS rendah”, periksa dulu chip grafis mana yang menjalankan game.

5 sumber

Thermal API Android (Google)
Perangkat hanya mempertahankan performa tinggi dalam waktu terbatas, lalu mengalami thermal throttling karena panas; disarankan menurunkan beban lebih awal berdasarkan status termal
thermalState Apple
Tingkat termal saat ini yang dilaporkan iOS; jika tingkatnya naik, aplikasi harus mengurangi pemakaian sumber daya
Selecting the Best Graphics Device to Run a 3D Intensive Application AMD
Di laptop dengan dua chip grafis, game 60 FPS bisa menjadi 30 FPS jika berjalan di grafis terintegrasi; GPU diskrit dipilih dengan mengekspor AmdPowerXpressRequestHighPerformance
PresentMon Capture Application (README-CaptureApplication.md) Intel
Merekam CPUFrequency dan GPUFrequency (clock) serta CPUTemperature dan GPUTemperature (suhu) per frame
GPUs in the task manager Microsoft
Task Manager punya kolom yang menunjukkan pemakaian GPU per proses beserta GPU dan engine mana yang dipakai

Resolusi timer Timer resolution (Windows 15.6ms)

ID co-timer · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Timer default Windows bekerja dalam satuan 15,6 ms, sehingga “tidur 1 ms saja” sebenarnya memanjang sampai siklus timer berikutnya, paling lama 15,6 ms.

Mengapa Batas frame dan pengiriman paket diimplementasikan dengan Sleep (menunggu sebentar) → Akibatnya OS hanya membangunkan thread dalam satuan 15,6 ms → Di layar Interval frame dan interval pengiriman input tidak beraturan

Gejala: Patah-patah
Faktor: Jitter
Siapa yang mengalami: Hanya saya
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Gunakan timer resolusi tinggi, atur pacing berbasis event atau V-Sync tanpa menunggu dengan sleep.
Kisaran angka: Dengan satuan 15,6 ms, interval 16,7 ms tidak bisa dicapai, sehingga interval frame bolak-balik antara 15,6 ms dan 31,2 ms.
Di grafik: Selalu tinggi sejak awal · Distribusi interval frame
Yang diperiksa: Periksa distribusi MsBetweenPresents (interval frame) di PresentMon dan bagian “Platform Timer Resolution” di laporan powercfg /energy (proses yang mengubah resolusi timer)
Cocok jika: Interval frame terkumpul di kelipatan 15,6 ms seperti 15,6 ms dan 31,2 ms, dan game tidak meminta resolusi timer yang lebih tinggi
Tidak cocok jika: Interval tersebar merata: kecil kemungkinan karena timer, lebih mungkin “Pemakaian CPU oleh proses di latar belakang” atau beban frame
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Di Windows versi lama, jika satu program mengubah timer menjadi 1 ms, perubahan itu berlaku untuk semua program. Karena itu sempat ada anggapan “game jadi lebih mulus kalau browser dibiarkan terbuka”. Sejak Windows 10 versi 2004, perubahan hanya berlaku untuk program yang memintanya, dan Windows 11 bisa mengabaikan permintaan dari jendela yang diminimalkan atau tertutup sepenuhnya dan tidak mengeluarkan suara.

6 sumber

_WDF_TIMER_CONFIG (wdftimer.h) Microsoft
Akurasi timer biasa adalah interval tick clock sistem, default 15,6 ms; timer resolusi tinggi 1 ms
timeBeginPeriod function (timeapi.h) Microsoft
Sebelum Windows 10 2004 berupa pengaturan global, sesudahnya hanya berlaku untuk proses yang meminta; Windows 11 tidak menjamin resolusi tinggi untuk proses dengan jendela yang tertutup atau diminimalkan
CreateWaitableTimerExW function (synchapi.h) Microsoft
Flag waitable timer resolusi tinggi CREATE_WAITABLE_TIMER_HIGH_RESOLUTION
PresentMon Capture Application (README-CaptureApplication.md) Intel
MsBetweenPresents: waktu (ms) antara pemanggilan Present() saat ini dan pemanggilan sebelumnya
Results for the Idle Energy Efficiency Assessment Microsoft
Resolusi timer sistem default 15,6 ms; proses yang mengubah resolusi timer bisa ditemukan di bagian “Platform Timer Resolution” laporan energi
Powercfg command-line options Microsoft
powercfg /energy: menganalisis sistem dan membuat laporan energi (HTML)

Aplikasi mobile masuk ke latar belakang App suspended in background

ID co-mobile-bg · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika Anda keluar sebentar dari game untuk melihat notifikasi, OS menangguhkan aplikasi (suspend) beberapa detik kemudian, dan selama itu server memutus koneksi Anda.

Mengapa Keluar sebentar dari game untuk membaca pesan atau menerima telepon → Akibatnya Engine game menghentikan jalannya game, dan OS pun segera menghentikan aplikasi dan jaringannya → Di layar Saat kembali, sudah disconnect dan harus reconnect

Gejala: Disconnect
Faktor: Stall, Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Setelah lama diam, Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: saat kembali, jangan menunggu koneksi yang sudah putus, langsung reconnect otomatis dengan token sesi (melanjutkan sesi tanpa login ulang), terima state terbaru sekaligus untuk menyamakan. Server: jika heartbeat terputus, bersihkan koneksinya tetapi pertahankan sesi karakter selama masa tenggang singkat (jangan langsung dikeluarkan), lanjutkan sesi dengan token sesi jika pemain reconnect dalam waktu itu.
Kisaran angka: Engine game biasanya berhenti begitu aplikasi keluar dari layar. iOS menangguhkan aplikasi dalam beberapa detik, atau umumnya dalam puluhan detik jika mendapat waktu tambahan; Android 14 ke atas membekukan (freeze) aplikasi yang keluar dari layar sekitar 10 detik kemudian.
Di grafik: Koneksi putus serentak · Jumlah disconnect (timeout heartbeat), catatan aplikasi ditangguhkan
Yang diperiksa: Cocokkan waktu aplikasi ditangguhkan dan kembali di log klien (OnApplicationPause di Unity) dengan alasan dan waktu disconnect di server lewat ID sesi. Di Android, periksa juga alasan penutupan proses yang tercatat di ApplicationExitInfo (REASON_LOW_MEMORY dan sebagainya)
Cocok jika: Klien masuk ke status ditangguhkan tepat sebelum server mencatat disconnect karena timeout heartbeat, lalu reconnect tepat setelah kembali
Tidak cocok jika: Terputus saat aplikasi tetap tampil di depan: lebih mungkin “Mapping NAT kedaluwarsa”, “IP bersama dari ISP (CGNAT)”, atau “Perpindahan Wi-Fi ↔ LTE/5G”
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Jika memori kurang, ponsel kadang menutup sepenuhnya game yang sedang di latar belakang. Inilah alasan game mulai lagi dari awal setelah Anda membuka kamera atau aplikasi pembayaran dan autentikasi. Makin rendah spesifikasi perangkat, makin sering terjadi.

5 sumber

Extending your app’s background execution time Apple
Saat masuk ke latar belakang, applicationDidEnterBackground diberi waktu 5 detik lalu aplikasi segera ditangguhkan; jika butuh lebih, minta waktu dengan beginBackgroundTask (sisa waktunya di backgroundTimeRemaining)
Cached apps freezer Android (Google)
Android 14 ke atas membekukan proses aplikasi yang sudah berstatus cached setelah 10 detik; saat dibekukan, semua thread berhenti
Application.runInBackground Unity
Default false sehingga game berhenti di latar belakang; Android selalu berhenti di latar belakang apa pun pengaturannya, dan iOS mengabaikan pengaturan ini
MonoBehaviour.OnApplicationPause(bool) Unity
Saat aplikasi ditangguhkan atau berjalan lagi, OnApplicationPause(true/false) dikirim ke semua MonoBehaviour
ApplicationExitInfo Android (Google)
REASON_LOW_MEMORY: low memory killer sistem menutup proses aplikasi (perangkat yang tidak mendukungnya melaporkannya sebagai REASON_SIGNALED dengan SIGKILL)

Perpindahan Wi-Fi ↔ LTE/5G Network switch changes IP

ID co-netswitch · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)

Saat Anda keluar rumah, Wi-Fi terputus dan beralih ke LTE/5G sehingga alamat IP Anda berubah dan koneksi yang ada menjadi tidak berlaku.

Mengapa Sinyal Wi-Fi melemah sehingga beralih ke jaringan seluler → Akibatnya Alamat IP Anda berubah sehingga koneksi yang dibuat dengan alamat lama tidak bisa dipakai lagi → Di layar Berhenti sejenak, lalu disconnect atau reconnect

Gejala: Freeze, Disconnect
Faktor: Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Pengembang Game: Server: sambungkan kembali sebagai pemain yang sama dengan token sesi walaupun alamatnya berubah dan langsung bersihkan koneksi di alamat lama, pertimbangkan protokol yang tetap tersambung walau alamat berubah (connection migration pada QUIC dan sebagainya). Klien: begitu mendeteksi perpindahan jaringan, langsung reconnect dengan token sesi tanpa menunggu timeout heartbeat.
Tugas Tim Infrastruktur: Jika memakai connection migration QUIC, atur load balancer agar memilih server berdasarkan connection ID (jika memilih berdasarkan alamat dan port, paket yang alamatnya berubah dikirim ke server lain).
Di grafik: Koneksi putus serentak · Jumlah disconnect dan reconnect, IP yang berubah saat reconnect
Yang diperiksa: Cari catatan di log koneksi server saat token sesi yang sama reconnect dari IP lain, lalu cocokkan dengan waktu callback perubahan jaringan default di klien (registerDefaultNetworkCallback)
Cocok jika: IP yang dipakai untuk reconnect tepat setelah terputus berpindah dari rentang Wi-Fi (koneksi rumah) ke rentang operator seluler, atau sebaliknya, dan tepat sebelumnya ada callback perpindahan jaringan
Tidak cocok jika: IP tetap sama, tetapi koneksi terputus: lebih mungkin “Handover antar-BTS (saat bergerak)” atau “Sinyal seluler lemah dan area blank spot”
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Read network state Android (Google)
Saat jaringan default berubah, koneksi baru lewat jaringan baru dan koneksi di jaringan lama akhirnya diputus paksa; perpindahan dideteksi dengan registerDefaultNetworkCallback
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport IETF
Dengan connection ID, koneksi tetap bertahan walau alamat IP dan port berubah (bab 9); load balancer yang membagi beban hanya berdasarkan alamat dan port bisa mengirim paket yang alamatnya berubah ke server lain (subbab 5.2.3)
RFC 9293: Transmission Control Protocol (TCP) IETF
Koneksi TCP diidentifikasi oleh pasangan socket (alamat dan port) di kedua ujung

Pemeriksaan paket oleh program keamanan Antivirus / firewall inspection

ID co-security · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika antivirus atau firewall memeriksa semua paket, latensi bertambah, dan jika berlebihan, game salah dikira serangan lalu diblokir.

Mengapa Program keamanan memeriksa satu per satu setiap paket yang dikirim dan diterima → Akibatnya Setiap paket mendapat tambahan latensi, dan jika pemeriksaan tertinggal, paket dibuang → Di layar Ping melonjak tidak beraturan atau koneksi diblokir

Gejala: Patah-patah, Tidak bisa masuk / loading tanpa henti
Faktor: Jitter, Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Selalu, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Kelola daftar kompatibilitas program keamanan, daftarkan pengecualian game di Windows Firewall saat instalasi.
Tugas Pihak Eksternal: Imbau pemain untuk mendaftarkan game sebagai pengecualian di program keamanan, minta vendor program keamanan memperbaiki false positive jika game salah dikira serangan.
Kisaran angka: Dalam kondisi normal, waktu pemeriksaan paket biasanya kurang dari 1 ms. Masalah muncul saat modul pemeriksa tertinggal atau punya bug, dan saat komunikasi game salah dikira serangan.
Di grafik: Hanya sebagian yang tinggi · RTT dan kegagalan koneksi (per pemain)
Yang diperiksa: Bandingkan setelah program keamanan dimatikan sebentar atau game didaftarkan sebagai pengecualian. Di Windows, aktifkan Audit Filtering Platform Connection dan Audit Filtering Platform Packet Drop di kebijakan audit agar 5157 (koneksi diblokir) dan 5152 (paket diblokir) tercatat di log Security, lalu lihat jumlah paket yang dibuang di WFPv4\Packets Discarded/sec pada Performance Monitor
Cocok jika: Ada catatan pemblokiran koneksi atau paket ke alamat server game, atau ping spike dan gejala tidak bisa masuk hilang saat program keamanan dimatikan
Tidak cocok jika: Perangkat lain di rumah yang sama juga mengalami hal yang sama tanpa kaitan dengan program keamanan: mengarah ke router atau koneksi
Sarana pemeriksaan: Lingkungan pemain sendiri

6 sumber

About Windows Filtering Platform Microsoft
Arsitektur yang mengizinkan atau memblokir paket lewat hook dan filter engine di network stack Windows; vendor keamanan pihak ketiga bisa menyisipkan modul filternya sendiri (callout)
Windows Firewall Rules Microsoft
Secara default koneksi masuk diblokir sehingga aplikasi perlu aturan pengecualian, yang umumnya dibuat oleh installer aplikasi
Address false positives/negatives in Microsoft Defender for Endpoint Microsoft
Prosedur pengecualian dan pengiriman file ke Microsoft untuk dianalisis saat program normal salah dikira ancaman (false positive)
5157(F): The Windows Filtering Platform has blocked a connection. Microsoft
Event 5157: Windows Filtering Platform memblokir koneksi (Audit Filtering Platform Connection)
Audit Filtering Platform Packet Drop Microsoft
Event 5152: Windows Filtering Platform memblokir paket
Network-Related Performance Counters Microsoft
Counter WFPv4 dan WFPv6: Packets Discarded/sec

Buffer terima meluap Socket receive buffer overflow

ID co-rcvbuf · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Jika game terlalu sibuk sehingga terlambat mengambil paket dari socket (antarmuka kirim-terima jaringan yang disediakan OS), buffer OS meluap.

Mengapa Frame tertunda sehingga game terlambat membaca socket → Akibatnya Buffer terima OS penuh: UDP membuang paket, TCP mengecilkan receive window sehingga pengirim berhenti mengirim → Di layar Teleport (UDP) atau fast forward (TCP)

Gejala: Teleport, Fast forward
Faktor: Packet loss, Stall
Siapa yang mengalami: Hanya saya
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Gunakan thread khusus untuk menerima paket, sesuaikan ukuran buffer (SO_RCVBUF).
Kisaran angka: Buffer terima default berukuran puluhan hingga ratusan KB, tergantung OS dan pengaturan. Update di tempat ramai bisa mencapai ratusan KB per detik.
Di grafik: Naik mengikuti beban · Jumlah paket UDP yang dibuang di buffer terima, frame time
Yang diperiksa: Rekam Microsoft Winsock BSP\Dropped Datagrams (jumlah paket UDP yang dibuang karena buffer terima socket tidak cukup) dan UDPv4\Datagrams Received Errors di Performance Monitor Windows bersama frame time, dan di game hitung celah pada nomor urut paket yang diterima
Cocok jika: Dropped Datagrams naik di tempat ramai atau tepat setelah frame panjang, dan pada saat yang sama muncul celah di nomor urut game. Pada waktu itu tidak ada packet loss di sisi koneksi
Tidak cocok jika: Dropped Datagrams tidak berubah, tetapi ada nomor urut yang hilang: packet loss di sepanjang rute
Sarana pemeriksaan: Lingkungan pemain sendiri

5 sumber

socket(7) — Linux manual page Linux man-pages
SO_RCVBUF adalah ukuran maksimum buffer terima socket; nilai default ditentukan rmem_default dan nilai maksimum oleh rmem_max (Android juga memakai kernel Linux)
SOL_SOCKET Socket Options (Winsock2.h) Microsoft
SO_RCVBUF di Windows: ruang buffer yang disediakan untuk menerima data di setiap socket
RFC 9293: Transmission Control Protocol (TCP) IETF
Field window TCP adalah jumlah byte yang masih bisa diterima penerima; jika 0, pengirim hanya mengirim zero window probe sambil menunggu
Low Latency Workloads Management and Operations Microsoft
Dropped Datagrams dan Dropped Datagrams/sec di counter set Microsoft Winsock BSP: jumlah paket yang dibuang karena UDP datang lebih cepat dari kecepatan pemrosesan aplikasi atau buffer terima socket tidak cukup
Network-Related Performance Counters Microsoft
Counter UDPv4 dan UDPv6: Datagrams Received Errors, Microsoft Winsock BSP: Dropped Datagrams

Kekurangan memori dan swap di klien Paging / swap on client

ID co-swap · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika puluhan tab browser dan game menyala bersamaan, OS memindahkan sebagian memori game ke disk.

Mengapa RAM total tidak cukup → Akibatnya OS memindahkan memori game yang tidak sedang dipakai ke disk → Di layar Saat bagian itu dipakai lagi, game berhenti puluhan hingga ratusan ms, tergantung storage

Gejala: Freeze, Patah-patah
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Saat bergerak atau pindah area, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Kurangi pemakaian memori, tampilkan peringatan jika sisa memori sedikit.
Tugas Pihak Eksternal: Sampaikan spesifikasi minimum kepada pemain, imbau pemain untuk menutup program lain (tab browser dan sebagainya) selama bermain.
Di grafik: Melonjak acak sesekali · Hard page fault, pemakaian memori
Yang diperiksa: Rekam Memory\Pages Input/sec (jumlah halaman yang dibaca dari disk untuk menyelesaikan hard page fault) di Performance Monitor serta pemakaian memori dan commit di tab Performance pada Task Manager bersama frame time
Cocok jika: Pages Input/sec melonjak saat game berhenti dan memori hampir penuh. Hilang jika browser dan program lain ditutup
Tidak cocok jika: Memori masih longgar dan Pages Input/sec tenang: lebih mungkin “Pemuatan sinkron dan kompilasi shader di main thread” atau “Streaming aset tertinggal akibat storage lambat”
Sarana pemeriksaan: Lingkungan pemain sendiri

3 sumber

Introduction to the page file Microsoft
Page file adalah file di disk yang dipakai untuk mengeluarkan halaman memori termodifikasi yang jarang dipakai dari RAM
Working Set Microsoft
Mengakses halaman yang tidak ada di RAM menimbulkan page fault; hard fault baru selesai setelah halaman dibaca dari disk, misalnya dari page file
Chapter 12 - Detecting Memory Bottlenecks Microsoft
Memory\Pages Input/sec: jumlah halaman yang dibaca dari disk untuk menyelesaikan page fault (hard page fault)

Kekurangan memori grafis (VRAM) VRAM over-commit

ID co-vram · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Jika memori yang dibutuhkan opsi grafis lebih besar dari memori kartu grafis, OS memindahkan tekstur ke memori PC lalu mengambilnya kembali sehingga game patah-patah.

Mengapa Opsi tekstur tinggi serta beragam equipment dan efek di tempat ramai membuat memori kartu grafis penuh → Akibatnya OS memindahkan tekstur yang tidak sedang dipakai ke memori PC, lalu mengambilnya kembali lewat bus PCIe yang lambat saat dibutuhkan → Di layar Tersendat sesaat setiap kali adegan atau karakter baru terlihat, tekstur buram untuk sementara

Gejala: Patah-patah, Freeze
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Saat banyak pemain berkumpul, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Sesuaikan nilai default opsi dengan ukuran memori kartu grafis, turunkan kualitas tekstur otomatis jika melewati budget memori, sederhanakan tekstur karakter di tempat ramai.
Tugas Pihak Eksternal: Imbau pemain untuk menurunkan opsi tekstur, dan menurunkannya lagi jika menjalankan dua klien.
Kisaran angka: Memori kartu grafis membaca ratusan GB per detik, tetapi bus PCIe antara GPU dan memori PC sekitar 16–64 GB per detik tergantung generasinya, lebih dari sepuluh kali lebih lambat.
Di grafik: Mendatar di batas · Memori GPU khusus, memori GPU bersama
Yang diperiksa: Periksa grafik memori GPU khusus dan memori GPU bersama di bagian GPU pada tab Performance Task Manager (kolom per proses juga bisa ditambahkan di tab Details) bersama frame time PresentMon
Cocok jika: Selama memori GPU khusus mendatar di batasnya dan memori GPU bersama bertambah, game sering tersendat, dan gejalanya hilang jika opsi tekstur diturunkan
Tidak cocok jika: Memori khusus masih longgar: lebih mungkin “Streaming aset tertinggal akibat storage lambat” atau “Pemuatan sinkron dan kompilasi shader di main thread”
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Jika memori GPU khusus (Dedicated GPU memory) di bagian GPU pada Task Manager Windows penuh dan memori GPU bersama (Shared GPU memory) bertambah, inilah kondisinya. Jika dua klien dijalankan di PC yang sama, memori lebih cepat penuh (entri “Streaming gagal akibat kekurangan memori atau VRAM”).

4 sumber

Residency Microsoft
Setiap proses punya budget memori grafis yang bisa dipakai; jika terlampaui, kernel memindahkan sebagian heap GPU diskrit ke memori PC (ini upaya terakhir, jadi disarankan mengelola budget)
GPUs in the task manager Microsoft
Memori GPU khusus di Task Manager adalah VRAM kartu grafis, memori GPU bersama adalah memori PC yang dipakai bersama oleh GPU dan CPU
CUDA C++ Best Practices Guide NVIDIA
Bandwidth memori grafis (V100 898 GB/s) jauh lebih besar daripada PCIe x16 generasi 3 (16 GB/s), sehingga disarankan mengurangi transfer bolak-balik dengan memori PC
PresentMon Capture Application (README-CaptureApplication.md) Intel
Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame)

Pemindaian Wi-Fi di latar belakang Periodic Wi-Fi background scan

ID co-wifi-scan · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Selama OS berpindah-pindah channel secara berkala untuk mencari Wi-Fi di sekitar, komunikasi berhenti sejenak.

Mengapa OS atau driver mencari Wi-Fi di sekitar secara berkala → Akibatnya Kirim-terima berhenti sejenak selama pencarian → Di layar Ping melonjak dengan interval yang sangat teratur (misalnya setiap 60 detik)

Gejala: Patah-patah, Teleport
Faktor: Jitter
Siapa yang mengalami: Hanya saya
Kapan: Secara berkala
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Minta mode yang mengurangi pemindaian nirkabel selama bermain (di Android, mode Wi-Fi latensi rendah WIFI_MODE_FULL_LOW_LATENCY; di Windows, mode media streaming lewat WlanSetInterface; tergantung perangkat dan driver, kadang tidak berpengaruh).
Tugas Pihak Eksternal: Imbau pemain untuk memakai koneksi kabel, menyesuaikan pengaturan layanan lokasi dan pencarian Wi-Fi otomatis, serta memperbarui driver nirkabel.
Kisaran angka: Biasanya puluhan hingga ratusan ms sekali jalan. Jika polanya terlalu teratur, curigai penyebab ini lebih dulu.
Di grafik: Melonjak secara berkala · RTT ke router
Yang diperiksa: Selama bermain, ukur ping ke alamat router (default gateway di ipconfig) dengan ping /t selama beberapa menit dan catat interval lonjakannya. Ulangi pengukuran yang sama dengan koneksi kabel
Cocok jika: Ping ke router melonjak puluhan hingga ratusan ms dengan interval yang sangat teratur (misalnya 60 detik), dan hilang saat memakai kabel
Tidak cocok jika: Interval lonjakan tidak beraturan: lebih mungkin “Interferensi Wi-Fi dan sinyal lemah”. Ping ke router normal dan hanya bagian sesudahnya yang melonjak: mengarah ke koneksi atau jaringan ISP
Sarana pemeriksaan: Lingkungan pemain sendiri

5 sumber

WDI low latency connection quality Microsoft
Pemindaian dan roaming memindahkan chip nirkabel keluar dari channel yang tersambung, sehingga mode latensi rendah membatasi waktu di luar channel dan pemindaian
WlanSetInterface function (wlanapi.h) Microsoft
API Windows untuk menyalakan dan mematikan pemindaian latar belakang (wlan_intf_opcode_background_scan_enabled) dan mode media streaming
Wi-Fi low-latency mode Android (Google)
Mode latensi rendah mematikan hemat daya Wi-Fi, sedangkan optimasi pemindaian dan roaming bergantung pada implementasi produsen perangkat
ping Microsoft
/t: terus mengirim echo request sampai dihentikan
ipconfig Microsoft
Jika dijalankan tanpa parameter, menampilkan alamat IPv4 dan IPv6 serta default gateway setiap adapter

Mode hemat daya NIC dan masalah driver NIC power saving, driver bugs

ID co-driver · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika kartu LAN atau chip Wi-Fi masuk ke mode hemat daya di antara paket, butuh waktu untuk aktif kembali.

Mengapa Fitur hemat daya perangkat jaringan aktif atau driver sudah usang → Akibatnya Jeda saat bangun (wake-up), sesekali perangkat dimulai ulang → Di layar Latensi tidak beraturan, dalam kasus yang jarang berhenti beberapa detik

Gejala: Patah-patah, Freeze
Faktor: Jitter, Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Setelah lama diam, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien Android meminta mode Wi-Fi latensi rendah (WIFI_MODE_FULL_LOW_LATENCY) selama bermain untuk mematikan hemat daya Wi-Fi.
Tugas Pihak Eksternal: Imbau pemain untuk memperbarui driver jaringan dan mematikan hemat daya perangkat jaringan di Device Manager, minta pemain mencari driver penyebabnya dengan LatencyMon jika seluruh layar tersendat dan suara berderak.
Di grafik: Melonjak acak sesekali · Waktu DPC dan ISR, RTT ke router
Yang diperiksa: Rekam dengan Windows Performance Recorder (WPR), cari driver yang berjalan lama (kolom Module) di grafik DPC/ISR pada Windows Performance Analyzer (WPA), lalu periksa pengaturan manajemen daya (hemat daya) adapter jaringan di Device Manager
Cocok jika: Pada waktu tersendat, DPC dan ISR driver jaringan berjalan beberapa ms beruntun, atau latensi tidak beraturan hilang setelah hemat daya dimatikan
Tidak cocok jika: DPC singkat dan tetap sama walau hemat daya dimatikan: lebih mungkin “Interferensi Wi-Fi dan sinyal lemah” atau “Pemindaian Wi-Fi di latar belakang”
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Jika driver memakai CPU lama untuk menangani interrupt (di Windows disebut latensi DPC), selama itu thread game juga tidak bisa memakai core tersebut. Dalam kondisi ini, seluruh layar tersendat dan suara berderak walaupun pemakaian CPU rendah. Driver penyebabnya bisa dicari dengan tools seperti LatencyMon, dan driver Wi-Fi atau LAN adalah penyebab yang umum.

4 sumber

Introduction to NDIS Selective Suspend Microsoft
Windows bisa memasukkan adapter jaringan yang sedang tidak dipakai ke status daya rendah (selective suspend)
Guidelines for Writing DPC Routines Microsoft
Selama DPC berjalan, semua thread di core itu berhenti, sehingga disarankan agar satu DPC tidak melebihi 100 µs
Wi-Fi low-latency mode Android (Google)
Mode Wi-Fi latensi rendah Android membuat framework mematikan hemat daya Wi-Fi secara eksplisit
CPU Analysis Microsoft
Grafik DPC/ISR di WPA: waktu setiap bagian saat DPC dan ISR berjalan tanpa jeda, serta modul (Module) tempat fungsinya berada

Pemakaian bandwidth oleh aplikasi lain di perangkat yang sama Other apps saturating the link

ID co-other-apps · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika sinkronisasi cloud, unduhan besar, atau patch game berjalan di PC yang sama, paket game harus menunggu di antrean.

Mengapa Aplikasi lain memakai upload dan download secara maksimal → Akibatnya Paket game menumpuk di antrean PC dan router → Di layar Ping melonjak drastis, input lag, fast forward

Gejala: Input lag, Fast forward
Faktor: Latensi, Jitter
Siapa yang mengalami: Hanya saya, Satu rumah
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Hentikan atau batasi kecepatan unduhan latar belakang di launcher dan patcher kami selama game berjalan.
Tugas Pihak Eksternal: Imbau pemain untuk membatasi kecepatan unduhan dan mematikan update otomatis selama bermain.
Di grafik: Naik mengikuti beban · RTT, volume kirim-terima PC
Yang diperiksa: Rekam Network Interface\Bytes Sent/sec dan Bytes Received/sec di Performance Monitor bersama ping. Caranya sama dengan tes bufferbloat, yaitu sengaja menjalankan transfer besar sambil ping tetap berjalan
Cocok jika: Selama download atau upload mendekati kecepatan koneksi, ping naik puluhan hingga ratusan ms, dan langsung kembali normal saat transfer dihentikan
Tidak cocok jika: Volume kirim-terima PC rendah, tetapi ping naik: lebih mungkin “Bufferbloat (antrean router)” akibat perangkat lain di rumah yang sama, atau jaringan ISP
Sarana pemeriksaan: Lingkungan pemain sendiri

4 sumber

Introduction Bufferbloat.net
Jika perangkat jaringan seperti router menumpuk terlalu banyak data, latensi melonjak tajam (bufferbloat)
Delivery Optimization reference Microsoft
Unduhan Windows Update (Delivery Optimization) secara default menyesuaikan diri secara dinamis dengan bandwidth yang tersedia, dan batas bandwidth unduhan latar belakang dan latar depan bisa diatur
Network-Related Performance Counters Microsoft
Counter Network Interface: Bytes Received/sec dan Bytes Sent/sec
Tests for Bufferbloat Bufferbloat.net
Jika ping naik saat koneksi dipenuhi oleh tes kecepatan sementara ping tetap berjalan, berarti terjadi bufferbloat

Pemrosesan dibatasi saat jendela diminimalkan atau tidak aktif Minimized / unfocused window throttling

ID co-unfocused · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Saat Anda melihat jendela lain atau meminimalkan game, game dan Windows menjalankan game lebih lambat untuk menghemat daya. Saat kembali, paket yang tertunda datang sekaligus, atau koneksi sudah terputus.

Mengapa Beralih ke jendela lain dengan Alt+Tab atau meminimalkan game → Akibatnya Selama game tidak terlihat, FPS diturunkan drastis atau game dihentikan, dan Windows juga menurunkan prioritas program yang tidak terlihat → Di layar Fast forward saat kembali; jika lama diminimalkan, disconnect

Gejala: Fast forward, Patah-patah, Disconnect
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Saat melakukan aksi tertentu, Setelah lama diam
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Lanjutkan penerimaan paket dan heartbeat di thread terpisah walau jendela tidak terlihat, periksa pengaturan “Run In Background” di engine, samakan ke state terbaru sekaligus saat kembali.
Kisaran angka: Jika FPS diturunkan ke 5–10 saat jendela tidak terlihat, satu frame menjadi 100–200 ms. Game yang memproses paket per frame juga membaca paket selambat itu.
Di grafik: Kosong lalu datang sekaligus · Interval frame (sebelum dan sesudah berpindah jendela), jumlah paket yang diproses
Yang diperiksa: Coba Alt+Tab dan minimalkan game sambil PresentMon berjalan, lalu periksa interval frame saat jendela tidak terlihat. Catat waktu perubahan fokus jendela di log game dan cocokkan dengan alasan disconnect
Cocok jika: Selama jendela tidak terlihat, interval frame memanjang menjadi 100 ms atau lebih atau rekamannya terputus, lalu saat kembali paket yang tertunda diproses sekaligus sehingga terjadi fast forward. Jika lama diminimalkan, koneksi putus karena timeout heartbeat
Tidak cocok jika: Tetap sama walau jendela tetap ditampilkan: lebih mungkin “Pemakaian CPU oleh proses di latar belakang” atau sisi jaringan
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Windows 11 tidak menjamin timer 1 ms untuk program dengan jendela yang diminimalkan atau tertutup sepenuhnya dan tidak mengeluarkan suara. Di laptop yang berjalan dengan baterai, program seperti itu diturunkan ke kecepatan paling hemat daya, dan pada CPU dengan campuran jenis core, program tersebut bisa dijalankan di efficiency core yang lambat. Jika dari dua klien di PC yang sama hanya yang di latar belakang yang bermasalah, lihat juga entri “Pemrosesan dibatasi di jendela latar belakang”.

4 sumber

Quality of Service Microsoft
Program dengan jendela yang tidak terlihat dan tidak terdengar dijadwalkan sebagai Low QoS, dengan kecepatan CPU paling efisien dan efficiency core saat memakai baterai
timeBeginPeriod function (timeapi.h) Microsoft
Windows 11 tidak menjamin resolusi timer yang lebih tinggi dari default untuk proses dengan jendela yang tertutup atau diminimalkan
Application.runInBackground Unity
Default Unity adalah false sehingga game loop berhenti saat jendela masuk ke latar belakang
PresentMon Capture Application (README-CaptureApplication.md) Intel
MsBetweenPresents: waktu (ms) antara pemanggilan Present() saat ini dan pemanggilan sebelumnya

Interferensi program overlay Overlays and screen hooks

ID co-overlay · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Program messenger, launcher, perekam, dan penampil FPS menyusup ke proses rendering game (hooking) untuk menggambar UI mereka di atas layar game. Pekerjaan setiap frame bertambah, dan sesekali program itu bentrok dengan game sehingga game tersendat sesaat atau tertutup paksa.

Mengapa Overlay dari messenger, launcher game, tools kartu grafis, atau program perekam aktif → Akibatnya Setiap kali frame dikirim ke layar, overlay menyela untuk menggambar UI-nya → Di layar Frame sedikit demi sedikit terlambat, dan saat notifikasi muncul game tersendat sesaat, mengalami error grafis, atau tertutup paksa (bagi pemain terlihat seperti disconnect)

Gejala: Patah-patah, Freeze, Disconnect
Faktor: Stall
Siapa yang mengalami: Hanya saya
Kapan: Selalu, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Kumpulkan daftar overlay yang sedang berjalan bersama laporan crash dan log patah-patah.
Tugas Pihak Eksternal: Jika ada laporan, imbau pemain untuk mematikan semua overlay lalu mencoba lagi.
Di grafik: Hanya sebagian yang tinggi · Frame time dan jumlah crash (pemain yang menyalakan overlay)
Yang diperiksa: Matikan semua overlay lalu bandingkan frame time PresentMon pada adegan yang sama; jika ada crash, periksa nama modul yang error (Faulting module name) pada event ID 1000 di Event Viewer
Cocok jika: Game tidak lagi tersendat dan error grafis hilang saat overlay dimatikan, atau modul yang error pada crash adalah DLL program overlay
Tidak cocok jika: Tetap sama walau semua overlay dimatikan: mengarah ke driver grafis atau “Crash di klien”
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Jika hanya pemain tertentu yang mengalami patah-patah atau game tertutup dan spesifikasinya tidak bisa menjelaskan hal itu, curigai lebih dulu bentrokan antara overlay dan modul keamanan game.

3 sumber

Steam Overlay (Steamworks Documentation) Valve
Steam Overlay otomatis melakukan hook ke game yang dijalankan lewat Steam, dan cara kerja itu bisa memunculkan error memori dalam pemakaian API rendering oleh game sehingga terjadi crash
PresentMon Capture Application (README-CaptureApplication.md) Intel
Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame)
The application or service crashing behavior troubleshooting guidance Microsoft
Event ID 1000 di log Application berisi nama modul yang error (Faulting module name), dan kadang modul Windows tercatat sebagai modul yang error karena kerusakan yang ditimbulkan modul lain

Latensi layar, perangkat input, dan frame generation Display, input device and frame generation latency

ID co-display-input · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika ping normal tetapi kontrol terasa berat, pemrosesan gambar di TV, controller nirkabel, atau fitur frame generation mungkin menambah latensi antara input dan layar.

Mengapa Mode game TV mati, memakai controller Bluetooth atau nirkabel, atau frame generation (frame generation DLSS/FSR) aktif → Akibatnya TV mengeluarkan frame lebih lambat selama memproses kualitas gambar, input nirkabel tiba terlambat sebesar siklus pengiriman dan interferensi, dan frame generation menunggu frame berikutnya untuk membuat frame sisipan → Di layar Angka ping dan FPS bagus, tetapi ada jeda antara tombol ditekan dan hasilnya tampil di layar: input lag

Gejala: Input lag
Faktor: Latensi
Siapa yang mengalami: Hanya saya
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Jadikan frame generation sebagai opsi pilihan dan informasikan bahwa input lag bisa bertambah jika diaktifkan, integrasikan fitur latensi rendah dari produsen grafis (NVIDIA Reflex, AMD Anti-Lag 2) saat memakai frame generation, tampilkan latensi input hingga layar di sisi PC di dalam game, minta mode latensi rendah (ALLM) ke TV dengan Window.setPreferMinimalPostProcessing(true) pada build Android TV dan set-top box.
Tugas Pihak Eksternal: Imbau pemain untuk mengaktifkan mode game (ALLM) di TV atau monitor, memakai controller kabel dan mematikan frame generation untuk konten kompetitif, serta menaruh perangkat Bluetooth di dekatnya dan memakai Wi-Fi 5 GHz.
Kisaran angka: Layar 60 Hz butuh 16,7 ms hanya untuk mengirim satu frame, dan layar 120 Hz butuh 8,3 ms. Controller Xbox lama membaca dan mengirim input setiap 8 ms. Latensi tambahan dari pemrosesan gambar TV berbeda per perangkat sehingga sulit dinyatakan dengan satu angka, dan mode game adalah pengaturan untuk mengurangi pemrosesan ini. AMD menyarankan frame generation dipakai pada frame rate minimal 60 FPS sebelum frame dibuat.
Di grafik: Selalu tinggi sejak awal · Latensi dari input hingga layar
Yang diperiksa: Bandingkan MsAllInputToPhotonLatency (dari input keyboard dan mouse sampai dikirim ke layar) di PresentMon dengan frame generation dinyalakan dan dimatikan, lalu periksa dengan FrameType (hanya tercatat jika driver atau SDK melaporkannya) apakah ada frame sisipan hasil generate. Nilai ini tidak mencakup jalur nirkabel controller dan pemrosesan di dalam TV, jadi bagian itu dibandingkan dengan beralih ke mode game TV dan controller kabel
Cocok jika: Ping normal, tetapi latensi input hingga layar berkurang saat frame generation dimatikan, atau latensi yang terasa hilang setelah beralih ke mode game TV atau controller kabel
Tidak cocok jika: Tetap sama setelah semua pengaturan ini diubah, dan ping tinggi atau melonjak: mengarah ke sisi jaringan. Latensi sisi PC tinggi karena V-Sync atau antrean frame: lebih mungkin “V-Sync dan antrean render”
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Latensi jaringan terlihat di ping, tetapi latensi ini tidak tertangkap oleh ping. Karena itu, inilah tempat pertama yang diperiksa untuk laporan “ping rendah tapi tetap lag”. Frame generation menaikkan angka FPS di layar sekitar dua kali lipat, tetapi untuk membuat frame sisipan, game harus menunggu frame asli berikutnya sehingga waktu sampai input tampil di layar bertambah (AMD menyatakan latensinya memang bertambah menurut desainnya). Perangkat Bluetooth memakai pita 2,4 GHz yang sama dengan Wi-Fi, sehingga input bisa terputus atau melompat saat terkena interferensi. Untuk V-Sync dan antrean render yang menambah latensi di dalam PC, lihat entri “V-Sync dan antrean render”.

9 sumber

Auto Low Latency Mode (ALLM) HDMI Licensing Administrator
ALLM membuat perangkat mengalihkan layar ke mode latensi rendah (biasanya mode game) secara otomatis; dalam mode latensi rendah, sebagian pemrosesan gambar TV dihentikan untuk mengurangi latensi
Xbox Series X: What’s the Deal with Latency? Microsoft
Input lag adalah jumlah dari jalur controller→konsol→HDMI→TV; controller lama membaca dan mengirim input setiap 8 ms; waktu mengirim satu frame lewat HDMI 16,6 ms pada 60 Hz dan 8,3 ms pada 120 Hz; ALLM mengalihkan TV ke mode game secara otomatis
AMD FSR 3 game integrations out now + more details for developers AMD
Interpolasi frame menambah latensi menurut desainnya; disarankan dipakai pada frame rate minimal 60 sebelum interpolasi; input 60 FPS menghasilkan output hingga 120 FPS
AMD FSR Frame Generation AMD
Frame generation disarankan pada minimal 60 FPS sebelum interpolasi (di bawah 30 FPS harus dihindari); AMD Radeon Anti-Lag 2 menyelaraskan kerja CPU dan GPU untuk mengurangi latensi sistem
NVIDIA DLSS NVIDIA
DLSS Frame Generation dirancang untuk menjaga responsivitas bersama NVIDIA Reflex (fitur latensi rendah)
Resolve Wi-Fi and Bluetooth issues caused by wireless interference Apple
Interferensi nirkabel menyebabkan koneksi putus dan penurunan performa pada perangkat Wi-Fi dan Bluetooth; Bluetooth dan Wi-Fi memakai pita 2,4 GHz yang sama
PresentMon Capture Application (README-CaptureApplication.md) Intel
MsAllInputToPhotonLatency (latensi input hingga layar), DisplayLatency (frame diserahkan hingga dikirim ke monitor), FrameType (membedakan frame yang digambar aplikasi dan frame hasil interpolasi driver atau SDK)
PresentMon Console Application (README-ConsoleApplication.md) Intel
MsAllInputToPhotonLatency diukur dari input keyboard dan mouse, FrameType hanya tercatat jika aplikasi atau driver mengirim event Intel-PresentMon (--track_frame_type)
Window.setPreferMinimalPostProcessing Android (Google)
Jendela yang sensitif terhadap latensi seperti game meminta pemrosesan gambar minimum pada layar; pada koneksi HDMI, sinyal ALLM dan Game Content Type dikirim untuk mengalihkan TV ke mode latensi rendah

L3 Jaringan rumah

Interferensi Wi-Fi dan sinyal lemah Wi-Fi interference, weak signal

ID hn-wifi · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika sinyal lemah atau ada interferensi, paket dikirim ulang beberapa kali di jalur nirkabel sehingga waktu kedatangannya tidak beraturan.

Mengapa Kualitas sinyal turun karena dinding, jarak, microwave, Bluetooth, atau router tetangga → Akibatnya Pengiriman gagal di jalur nirkabel → dikirim ulang beberapa kali → Di layar Kedatangan paket tidak beraturan (jitter) sehingga karakter tersendat-sendat; jika parah, packet loss membuat karakter teleport

Gejala: Patah-patah, Teleport, Rubber banding
Faktor: Jitter, Packet loss
Siapa yang mengalami: Hanya saya, Satu rumah
Kapan: Sesekali secara acak, Selalu
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Sesuaikan panjang buffer interpolasi secara otomatis menurut kondisi koneksi, tampilkan status jaringan di layar jika jitter atau packet loss besar.
Tugas Pihak Eksternal: Imbau pemain untuk memakai koneksi kabel, memakai 5 GHz atau 6 GHz, dan memindahkan posisi router.
Kisaran angka: Satu kali retransmisi menambah sekitar 1–4 ms. Jika sinyal lemah, paket dikirim ulang berkali-kali dengan kecepatan rendah dan juga harus menunggu sampai channel kosong, sehingga latensi bisa melonjak 50–200 ms. Jebakannya, ping rata-rata terlihat normal.
Di grafik: Melonjak acak sesekali · RTT ke router
Yang diperiksa: Ukur ping ke alamat router (default gateway di ipconfig) dengan ping /t selama beberapa menit, lalu periksa kekuatan sinyal dan channel router Anda dengan netsh wlan show networks mode=bssid. Bandingkan dengan koneksi kabel di tempat yang sama
Cocok jika: Ping ke router pun sudah melonjak tidak beraturan puluhan hingga ratusan ms, sesekali terjadi packet loss, dan kekuatan sinyalnya rendah. Hilang saat memakai kabel atau di dekat router
Tidak cocok jika: Ping ke router stabil, tetapi hanya bagian sesudahnya yang melonjak: mengarah ke koneksi atau jaringan ISP. Hanya melonjak dengan interval yang sama: lebih mungkin “Pemindaian Wi-Fi di latar belakang”
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Pada mesh Wi-Fi, jika router (node) saling terhubung secara nirkabel (wireless backhaul), node perantara tidak bisa mengirim saat sedang menerima dan harus berbagi kesempatan kirim dengan segmen sebelum dan sesudahnya yang memakai channel yang sama, sehingga saat ramai throughput bisa turun dan latensi bertambah. Produk dengan pita nirkabel khusus untuk backhaul bisa lebih baik, dan jika node saling dihubungkan dengan kabel (Ethernet), segmen ini tidak lagi lewat nirkabel. Adapter powerline (PLC) juga memakai cara kirim yang memeriksa dulu apakah media kosong (CSMA/CA) seperti Wi-Fi, dan kualitasnya berubah-ubah mengikuti noise dari peralatan rumah tangga serta saat peralatan itu dinyalakan dan dimatikan, sehingga bisa terjadi retransmisi dan jitter.
Kasus nyata: Square Enix 2021: Kepadatan server saat rilis ekspansi FINAL FANTASY XIV dan error antrean login

8 sumber

Resolve Wi-Fi and Bluetooth issues caused by wireless interference Apple
Sumber interferensi seperti microwave dan telepon nirkabel; Wi-Fi dan Bluetooth memakai pita 2,4 GHz yang sama; disarankan pindah ke 5 GHz dan memilih channel dengan interferensi rendah
RFC 8325: Mapping Diffserv to IEEE 802.11 IETF
CSMA/CA pada 802.11: hanya mengirim saat channel kosong; jika sibuk, pengiriman ditunda sampai kosong lalu menunggu lagi selama random backoff
Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017) USENIX
Antrean default Wi-Fi yang sedang dibebani menimbulkan latensi ratusan ms; median latensi perangkat yang tersambung dengan kecepatan rendah (sinyal lemah) tetap di atas 200 ms walau memakai FQ-CoDel
ping Microsoft
/t: terus mengirim echo request sampai dihentikan
ipconfig Microsoft
Jika dijalankan tanpa parameter, menampilkan alamat IPv4 dan IPv6 serta default gateway setiap adapter
Wireless network connectivity issues troubleshooting Microsoft
netsh wlan show networks mode=bssid: menampilkan BSSID, kekuatan sinyal, channel, dan standar nirkabel untuk setiap Wi-Fi yang terlihat
Capacity of Ad Hoc Wireless Networks (MobiCom 2001) ACM
Jika paket diteruskan berkali-kali (multi-hop) lewat nirkabel 802.11, node tidak bisa mengirim saat sedang menerima dan segmen sebelum dan sesudahnya saling menimbulkan interferensi, sehingga throughput rute relay berantai secara teori turun hingga sepertiga (dalam simulasi sekitar sepertujuh)
Electri-Fi Your Data: Measuring and Combining Power-Line Communications with WiFi (IMC 2015) ACM
Perangkat komersial powerline communication (IEEE 1901, HomePlug AV) mengirim dengan CSMA/CA mirip Wi-Fi, dan ketidakadilan jangka pendek bisa membuat jitter membesar; kualitas channel berubah mengikuti noise dari peralatan rumah tangga serta saat peralatan itu dinyalakan dan dimatikan (dalam skala beberapa menit hingga beberapa jam)

Channel Wi-Fi padat Crowded Wi-Fi channel

ID hn-channel · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Di tempat dengan puluhan router seperti apartemen, router harus berbagi channel yang sama sehingga harus menunggu kesempatan mengirim.

Mengapa Puluhan router memakai channel 2,4 GHz yang sama → Akibatnya Untuk mengirim, harus menunggu sampai perangkat lain selesai mengirim dan channel kosong → Di layar Pada malam hari saat orang-orang pulang ke rumah, jitter (variasi selang waktu kedatangan paket) bertambah sehingga game patah-patah

Gejala: Patah-patah, Input lag
Faktor: Jitter, Latensi
Siapa yang mengalami: Satu rumah
Kapan: Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Perpanjang buffer interpolasi secara otomatis saat jitter bertambah.
Tugas Pihak Eksternal: Imbau pemain untuk memakai 5 GHz atau 6 GHz, channel yang tidak terlalu padat, atau koneksi kabel.
Di grafik: Tinggi hanya di jam tertentu · RTT dan jitter ke router
Yang diperiksa: Periksa channel dan kekuatan sinyal Wi-Fi di sekitar dengan netsh wlan show networks mode=bssid, lalu ukur ping ke router pada malam dan siang hari untuk dibandingkan
Cocok jika: Banyak router di sekitar terdeteksi di channel 2,4 GHz yang sama, dan jitter ke router hanya membesar pada malam hari. Berkurang setelah pindah ke 5 GHz, 6 GHz, atau channel yang lebih sepi
Tidak cocok jika: Melonjak tanpa kaitan dengan jam: lebih mungkin “Interferensi Wi-Fi dan sinyal lemah”. Ping ke router baik, tetapi pada malam hari hanya bagian sesudahnya yang buruk: lebih mungkin “Kongesti di jalur peering saat jam sibuk”
Sarana pemeriksaan: Lingkungan pemain sendiri

4 sumber

Recommended settings for Wi-Fi routers and access points Apple
Router dan perangkat lain yang memakai channel sama adalah sumber interferensi; untuk 2,4 GHz disarankan lebar 20 MHz; 5 GHz dan 6 GHz lebih sedikit masalah interferensinya
RFC 8325: Mapping Diffserv to IEEE 802.11 IETF
Jika channel sibuk, 802.11 menunda pengiriman sampai kosong lalu mengirim setelah random backoff (CSMA/CA)
Wireless network connectivity issues troubleshooting Microsoft
netsh wlan show networks mode=bssid: menampilkan BSSID, kekuatan sinyal, channel, dan standar nirkabel untuk setiap Wi-Fi yang terlihat
ping Microsoft
/t: terus mengirim echo request sampai dihentikan

Bufferbloat (antrean router) Bufferbloat

ID hn-bufferbloat · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Saat anggota keluarga mengunggah video atau mengunduh file besar, paket senilai ratusan ms menumpuk di antrean router, dan paket game pun menunggu di belakangnya.

Mengapa Koneksi penuh karena upload video atau backup cloud oleh keluarga, live streaming yang Anda siarkan, atau unduhan besar → Akibatnya Router atau modem menyimpan paket yang meluap di antrean yang besar → Di layar Paket game juga menunggu di belakang antrean sehingga ping melonjak hingga ratusan ms

Gejala: Input lag, Fast forward, Teleport
Faktor: Latensi, Jitter
Siapa yang mengalami: Satu rumah, Hanya saya
Kapan: Sesekali secara acak, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Jika ping tiba-tiba naik ke ratusan ms, tampilkan status jaringan di layar (beri tahu kemungkinan ada transfer besar di koneksi yang sama).
Tugas Pihak Eksternal: Imbau pemain untuk memakai router dengan SQM (fq_codel, CAKE) atau QoS, mengatur kecepatan SQM ke 90–95% dari kecepatan koneksi (agar antrean terbentuk di dalam router sehingga efektif), dan membatasi kecepatan upload.
Kisaran angka: Pada koneksi dengan upload 10 Mbps dan buffer 1 MB, antrean bisa memanjang hingga senilai 800 ms.
Di grafik: Naik mengikuti beban · RTT, pemakaian upload dan download koneksi
Yang diperiksa: Penuhi koneksi dengan tes kecepatan sambil ping tetap berjalan, atau gunakan tes web yang mengukur latensi saat koneksi dibebani (panduan Bufferbloat.net). Periksa bersama pemakaian upload dan download di halaman admin router
Cocok jika: Selama upload atau download memenuhi koneksi, ping naik ke ratusan ms dan kembali normal setelah transfer selesai (curigai jika latensi saat dibebani melebihi 50 ms). Hilang saat SQM diaktifkan
Tidak cocok jika: Ping melonjak walau koneksi sedang sepi: lebih mungkin “Interferensi Wi-Fi dan sinyal lemah” atau “Kualitas koneksi buruk”
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Arah upload sangat mudah tersumbat, karena koneksi internet TV kabel dan seluler sering punya upload yang jauh lebih sempit daripada download. Di rumah dengan koneksi fiber optik yang lega, jalur Wi-Fi menjadi bottleneck, dan hal yang sama terjadi di antrean nirkabel router. Paket game kecil sehingga hampir tidak memakai bandwidth, tetapi tetap harus menunggu di antrean. Jika hanya arah upload yang tersumbat, hanya input Anda yang terlambat, sementara gerakan pemain lain normal. Di ponsel, backup foto atau update aplikasi di ponsel yang sama memenuhi antrean modem ponsel dan BTS sehingga hal yang sama terjadi.

4 sumber

Setting up SQM for CeroWrt 3.10 Bufferbloat.net
Kecepatan SQM harus diturunkan ke 95% dari kecepatan terukur (85% jika berdasarkan kecepatan yang diiklankan) agar bottleneck pindah dari perangkat ISP ke dalam router sehingga efektif
SQM (Smart Queue Management) OpenWrt
Masukkan kecepatan download dan upload sebesar 90% dari hasil pengukuran; disarankan memakai antrean cake (fq_codel jika CPU lemah)
Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017) USENIX
Jika jalur Wi-Fi penuh, antrean nirkabel router menimbulkan latensi ratusan ms; memperbaiki antrean nirkabel menurunkan latensi saat dibebani menjadi sekitar sepersepuluhnya
Tests for Bufferbloat Bufferbloat.net
Jika ping naik saat koneksi dipenuhi tes kecepatan sambil ping tetap berjalan, berarti terjadi bufferbloat; disarankan mengambil tindakan jika latensi saat dibebani lebih dari 50 ms (atau peringkatnya di bawah B)

Mapping NAT kedaluwarsa NAT mapping timeout

ID hn-nat · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Router menghapus koneksi idle yang lama tidak dilewati paket dari tabel NAT. Ini penyebab umum disconnect tepat saat pemain mulai bergerak setelah lama diam.

Mengapa Router mencatat koneksi “perangkat di dalam ↔ server di luar” di tabel NAT (tabel translasi alamat) → Akibatnya Jika lama tidak ada paket, entri dihapus dari tabel (untuk UDP umumnya 30–120 detik) → Di layar Paket dari server tidak bisa masuk ke dalam rumah sehingga terjadi disconnect

Gejala: Disconnect
Faktor: Packet loss
Siapa yang mengalami: Hanya saya, Satu rumah
Kapan: Setelah lama diam
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek (mapping UDP hanya diperbarui dengan pasti oleh paket yang keluar dari dalam rumah, jadi klien yang mengirim), reconnect otomatis jika terputus. Server: balas heartbeat, bersihkan koneksi lebih dulu jika tidak menerima heartbeat dalam waktu tertentu, dan jika mapping terhapus sehingga alamat dan port luar berubah, pastikan pemainnya sama lewat token sesi (nomor konfirmasi yang diterima saat login) lalu lanjutkan sesinya.
Di grafik: Koneksi putus serentak · Jumlah disconnect (timeout heartbeat), waktu idle sebelum terputus
Yang diperiksa: Kumpulkan alasan disconnect di server dan waktu yang berlalu sejak paket terakhir lewat di koneksi itu sebelum terputus (waktu idle), lalu lihat distribusinya. Untuk pengujian, perpanjang interval paket UDP menjadi 30 detik, 60 detik, dan 120 detik, lalu ukur pada interval berapa respons berhenti
Cocok jika: Hanya koneksi yang diam yang terputus, dan waktu idle-nya terkumpul tepat setelah nilai tertentu seperti 30–120 detik. Hilang jika interval heartbeat dibuat lebih pendek dari itu
Tidak cocok jika: Tetap terputus saat sedang bergerak: mengarah ke koneksi atau rute. Terkumpul pada nilai pendek hanya di operator seluler tertentu: lebih mungkin “IP bersama dari ISP (CGNAT)”
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP IETF
Timer mapping UDP tidak boleh habis sebelum 2 menit dan disarankan minimal 5 menit secara default; pembaruan oleh paket keluar wajib, sedangkan pembaruan oleh paket masuk opsional
An Experimental Study of Home Gateway Characteristics (IMC 2010) ACM
Pengukuran 34 router rumahan: mapping UDP bertahan 30–691 detik dengan median 90 detik sehingga lebih dari separuhnya kurang dari 2 menit; TCP median sekitar 60 menit
RFC 9308: Applicability of the QUIC Transport Protocol IETF
Di internet dengan NAT di sepanjang rute, keep-alive dengan interval sekitar 30 detik sudah memadai; lebih sering dari itu memboroskan trafik dan daya

Router kurang bertenaga atau terlalu panas Router CPU / session table exhaustion

ID hn-router · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal)

Jika puluhan perangkat dan ribuan koneksi membebani router murah, router itu sendiri tidak sanggup memprosesnya.

Mengapa Puluhan perangkat serta P2P dan torrent membuka ribuan koneksi → Akibatnya CPU dan tabel sesi router penuh → Di layar Pemrosesan paket terlambat dan paket hilang, koneksi baru gagal

Gejala: Patah-patah, Tidak bisa masuk / loading tanpa henti, Disconnect
Faktor: Packet loss, Jitter
Siapa yang mengalami: Satu rumah
Kapan: Makin lama menyala, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal)
Tugas Pihak Eksternal: Imbau pemain untuk memulai ulang router (sementara), mengganti router, dan menutup program yang membuka banyak koneksi (P2P, torrent).
Di grafik: Mendatar di batas · CPU dan jumlah koneksi router, RTT ke router
Yang diperiksa: Periksa pemakaian CPU, jumlah koneksi (sesi), dan jumlah perangkat yang tersambung di halaman admin router (jika router mendukung), lalu bandingkan ping ke router itu sendiri sebelum dan sesudah router dimulai ulang
Cocok jika: Saat jumlah koneksi banyak, ping ke router pun sudah melonjak atau terjadi packet loss, dan koneksi baru gagal. Setelah dimulai ulang, normal untuk sementara lalu memburuk lagi
Tidak cocok jika: Ping ke router normal dan hanya bagian sesudahnya yang buruk: mengarah ke koneksi atau jaringan ISP
Sarana pemeriksaan: Lingkungan pemain sendiri

2 sumber

An Experimental Study of Home Gateway Characteristics (IMC 2010) ACM
Jumlah koneksi TCP yang diizinkan router rumahan ke satu port server adalah 16 hingga sekitar 1.024 (median 135), dan throughput perangkat murah kadang hanya beberapa Mbps
Netfilter Conntrack Sysfs variables Linux kernel
Jumlah entri maksimum tabel connection tracking Linux (nf_conntrack_max) dan nilai default waktu simpan per state

Handover antar-BTS (saat bergerak) Cellular handover

ID hn-handover · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)

Saat bepergian dengan bus atau kereta bawah tanah, komunikasi terputus selama BTS berganti.

Mengapa BTS yang tersambung berganti saat bergerak → Akibatnya Biasanya hanya jeda puluhan ms, tetapi jika sinyal buruk dan perpindahan gagal, koneksi bisa putus ratusan ms hingga beberapa detik → Di layar Berhenti lalu teleport; jika lama, disconnect

Gejala: Freeze, Teleport, Disconnect
Faktor: Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: atur timeout agar tahan terhadap putus singkat, percepat reconnect. Server: atur timeout agar pemain tidak langsung dikeluarkan walau terputus beberapa detik, sambungkan kembali ke sesi yang sama saat reconnect.
Tugas Pihak Eksternal: Informasikan kepada pemain bahwa koneksi putus saat bepergian (bus, kereta bawah tanah) disebabkan oleh perpindahan BTS.
Di grafik: Kosong lalu datang sekaligus · Jumlah paket yang diterima, RTT
Yang diperiksa: Periksa apakah laporan koneksi putus terjadi saat bepergian (bus, kereta bawah tanah), lalu periksa waktu kekosongan penerimaan di log klien serta perubahan jenis jaringan dan sinyal
Cocok jika: Hanya saat bergerak, penerimaan kosong ratusan ms hingga beberapa detik lalu datang sekaligus, dan tidak bisa direproduksi saat diam
Tidak cocok jika: Tetap sama walau diam: lebih mungkin “Sinyal seluler lemah dan area blank spot” atau “Perpindahan 5G↔LTE yang sering (di tepi jangkauan 5G)”
Sarana pemeriksaan: Lingkungan pemain sendiri

2 sumber

Report ITU-R M.2134: Requirements related to technical performance for IMT-Advanced radio interface(s) ITU
Persyaratan waktu tanpa kirim-terima data selama handover: frekuensi sama 27,5 ms, frekuensi berbeda 40–60 ms
Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption (SIGCOMM 2020) ACM
Latensi handover terukur di jaringan komersial: 4G↔4G rata-rata 30 ms, antarsel 5G (NSA) rata-rata 108 ms

Jeda transisi state RRC (hemat daya radio seluler) Radio state promotion (RRC)

ID hn-rrc · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Jika lama tidak ada komunikasi, ponsel menurunkan koneksi radio ke status daya rendah, lalu harus menaikkannya lagi saat paket berikutnya sehingga terlambat.

Mengapa Jika sebentar saja tidak ada komunikasi, ponsel mengalihkan koneksi radio ke mode hemat daya → Akibatnya Untuk mengirim paket berikutnya, koneksi harus dinaikkan lagi → Di layar Hanya aksi pertama setelah diam yang terasa sangat terlambat

Gejala: Input lag
Faktor: Latensi
Siapa yang mengalami: Hanya saya
Kapan: Setelah lama diam
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Jaga koneksi tetap aktif dengan pengiriman berkala yang ringan (sebagai gantinya baterai lebih boros).
Kisaran angka: LTE biasanya turun ke mode hemat daya jika tidak ada komunikasi sekitar 10 detik, dan butuh puluhan hingga ratusan ms untuk naik lagi (contoh pengukuran: sekitar 0,3–0,6 detik). 3G butuh 1 detik atau lebih.
Di grafik: Hanya sebagian yang tinggi · RTT permintaan pertama setelah idle (mobile)
Yang diperiksa: Kelompokkan RTT di dalam game menurut jarak waktu dari komunikasi sebelumnya. Di mobile, bandingkan RTT paket pertama yang dikirim setelah diam lebih dari 10 detik dengan paket yang dikirim beruntun
Cocok jika: Di jaringan seluler, hanya paket pertama setelah diam yang terlambat ratusan ms, sedangkan paket yang langsung menyusul normal. Di Wi-Fi tidak ada perbedaan
Tidak cocok jika: Tetap terlambat walau dikirim beruntun: mengarah ke sinyal, koneksi, atau rute
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance (SIGCOMM 2013) ACM
Timer peralihan ke hemat daya (tail) di jaringan LTE yang diukur 10 detik; median latensi untuk naik lagi dari hemat daya 435 ms (persentil 25–75: 319–558 ms); 3G sekitar 1,5–2 detik
Optimize network access Android (Google)
Latensi transisi state radio dan waktu tail berbeda menurut teknologi radio (3G, LTE, 5G) dan pengaturan operator; contoh 3G: daya rendah→daya penuh sekitar 1,5 detik, idle→daya penuh lebih dari 2 detik
Report ITU-R M.2134: Requirements related to technical performance for IMT-Advanced radio interface(s) ITU
Persyaratan latensi control plane dari state idle ke aktif kurang dari 100 ms (tidak termasuk paging dan jalur kabel)

Sinyal seluler lemah dan area blank spot Weak cellular signal

ID hn-weak-cell · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Di lift, ruang bawah tanah, atau bagian dalam gedung, retransmisi bertambah, kecepatan turun, dan akhirnya terjadi disconnect.

Mengapa Berpindah ke tempat dengan sinyal lemah → Akibatnya Retransmisi radio bertambah, kecepatan turun, koneksi putus sesaat → Di layar Jitter dan packet loss menyebabkan patah-patah dan teleport, akhirnya disconnect

Gejala: Patah-patah, Teleport, Disconnect
Faktor: Jitter, Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Rapikan alur reconnect, tampilkan kualitas jaringan.
Tugas Pihak Eksternal: Informasikan kepada pemain bahwa masalah ini terjadi di tempat dengan sinyal lemah (lift, ruang bawah tanah, bagian dalam gedung).
Di grafik: Hanya sebagian yang tinggi · RTT dan packet loss (per pemain mobile)
Yang diperiksa: Periksa lokasi saat laporan disconnect (lift, ruang bawah tanah, dalam gedung) dan indikator sinyal ponsel, lalu ulangi aksi yang sama di tempat dengan sinyal bagus untuk dibandingkan
Cocok jika: RTT dan packet loss naik lalu koneksi putus hanya di tempat dengan sinyal lemah, dan hilang setelah pindah ke tempat dengan sinyal bagus
Tidak cocok jika: Tetap sama walau sinyal bagus: mengarah ke jaringan ISP atau sisi server
Sarana pemeriksaan: Lingkungan pemain sendiri

1 sumber

An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance (SIGCOMM 2013) ACM
LTE menyembunyikan packet loss di jalur radio dengan retransmisi di lapisan fisik dan MAC; bandwidth yang tersedia berubah drastis dalam hitungan detik mengikuti kekuatan sinyal dan faktor lainnya

Perpindahan 5G↔LTE yang sering (di tepi jangkauan 5G) 5G NSA / LTE switching

ID hn-5g-flip · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Di dalam gedung dengan sinyal 5G lemah atau di tepi jangkauan 5G, ponsel sering berpindah antara 5G dan LTE, dan setiap kali berpindah ping melonjak atau komunikasi terputus sejenak.

Mengapa Berada di tempat dengan sinyal 5G yang naik turun (dalam gedung, tepi jangkauan 5G) → Akibatnya Ponsel sering berpindah antara 5G dan LTE, dan setiap kali itu muncul jeda singkat → Di layar Ping melonjak tanpa pola walau diam, sesekali freeze atau teleport

Gejala: Patah-patah, Teleport, Freeze
Faktor: Jitter, Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Sesekali secara acak, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Perpanjang buffer interpolasi secara otomatis saat jitter bertambah, sertakan perubahan jenis jaringan (5G/LTE) di log saat terjadi lag untuk membedakan penyebabnya.
Tugas Pihak Eksternal: Imbau pemain untuk beralih ke mode yang mengutamakan LTE di pengaturan sebagai pembanding, sarankan memakai Wi-Fi.
Kisaran angka: Satu kali perpindahan memakan puluhan hingga ratusan ms. 5G di Korea kebanyakan memakai cara yang digabung dengan LTE (NSA), sehingga koneksi 5G-nya mudah tersambung dan terlepas.
Di grafik: Melonjak acak sesekali · RTT, perubahan jenis jaringan (5G/LTE)
Yang diperiksa: Ubah pengaturan ponsel agar mengutamakan LTE lalu bandingkan di tempat yang sama. Lebih pasti jika klien mencatat perubahan indikator jaringan di TelephonyDisplayInfo Android (OVERRIDE_NETWORK_TYPE_NR_NSA dan sebagainya) bersama RTT
Cocok jika: Waktu RTT melonjak bertepatan dengan waktu indikator 5G↔LTE berubah, dan lonjakan hilang di mode yang mengutamakan LTE
Tidak cocok jika: Tetap melonjak walau indikator jaringan tidak berubah: lebih mungkin “Sinyal seluler lemah dan area blank spot” atau sisi koneksi
Sarana pemeriksaan: Lingkungan pemain sendiri

3 sumber

Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption (SIGCOMM 2020) ACM
5G NSA menyerahkan kontrol ke LTE, sehingga saat berganti sel 5G, ponsel melepas 5G, lewat LTE, lalu tersambung lagi: rata-rata 108 ms (4G→5G 80 ms); throughput TCP turun 73–83% tepat setelah perpindahan yang melibatkan 5G
5G 통신서비스 품질평가 결과 발표 과학기술정보통신부
Berdasarkan pengumuman tahun 2020, 5G di Korea disediakan dengan cara NSA dan peralihan ke SA masih dalam tahap rencana
TelephonyDisplayInfo Android (Google)
OVERRIDE_NETWORK_TYPE_NR_NSA: indikator jaringan saat tersambung ke LTE dan dapat atau sedang tersambung ganda (EN-DC) dengan 5G (NR)

Pembatasan di Wi-Fi publik dan jaringan kantor Captive portal, restrictive network

ID hn-captive · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)

Halaman login Wi-Fi kafe atau firewall kantor memblokir koneksi game.

Mengapa Belum lolos autentikasi di halaman login, atau firewall memblokir port game dan UDP → Akibatnya Upaya koneksi itu sendiri diblokir, atau hanya sebagian yang lolos → Di layar Tidak bisa masuk; login berhasil, tetapi gagal masuk ke game

Gejala: Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: tampilkan pesan yang menjelaskan alasan saat diblokir (belum autentikasi di halaman login, UDP diblokir, dan sebagainya), beralih otomatis ke rute cadangan jika UDP diblokir. Server: sediakan rute cadangan seperti TCP 443.
Tugas Pihak Eksternal: Imbau pemain untuk menyelesaikan autentikasi di halaman login lebih dulu saat memakai Wi-Fi publik, dan memakai jaringan lain di tempat yang dibatasi seperti jaringan kantor.
Di grafik: Hanya sebagian yang tinggi · Jumlah kegagalan koneksi (per jaringan)
Yang diperiksa: Minta pemain yang gagal mencoba tersambung lewat jaringan lain seperti data seluler, lalu periksa di log koneksi server apakah paket UDP pertama sampai dan apakah koneksi lewat rute cadangan TCP 443 berhasil
Cocok jika: Hanya gagal di Wi-Fi tertentu (kafe, kantor) dan langsung tersambung di jaringan lain. Belum autentikasi di halaman login, atau hanya UDP yang tidak sampai ke server
Tidak cocok jika: Gagal di jaringan mana pun: mengarah ke akun, server, atau “Gangguan dan latensi DNS”. Gagal di seluruh negara atau ISP tertentu: lebih mungkin “Pembatasan UDP dan inspeksi paket per negara atau ISP”
Sarana pemeriksaan: Lingkungan pemain sendiri

2 sumber

RFC 8952: Captive Portal Architecture IETF
Captive portal: jaringan yang membatasi akses sampai syarat seperti persetujuan ketentuan atau autentikasi dipenuhi
RFC 9308: Applicability of the QUIC Transport Protocol IETF
Menurut studi pengukuran, 3–5% jaringan memblokir UDP sepenuhnya, sehingga aplikasi berbasis UDP harus menyiapkan rute cadangan TCP (TLS)

L4 Jalur internet

Latensi propagasi (jarak fisik) Propagation delay

ID isp-distance · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)

Di kabel serat optik, cahaya pun hanya menempuh sekitar 200.000 km per detik. Server yang jauh tetap lambat, sebagus apa pun servernya.

Mengapa Server berada jauh (server luar negeri, benua lain) → Akibatnya Waktu pulang-pergi bertambah sebanding dengan jarak (minimal 10 ms per 1.000 km) → Di layar Input lag yang tetap di setiap aksi, pemain dirugikan dalam keputusan server

Gejala: Input lag
Faktor: Latensi
Siapa yang mengalami: Wilayah/ISP tertentu
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Hanya bisa diredam karena hukum fisika tidak bisa diperbaiki lewat kode, sediakan pilihan region agar pemain memakai server region terdekat, kurangi kerugian dalam keputusan server dengan lag compensation (memutar mundur waktu).
Tugas Tim Infrastruktur: Server/OS: tempatkan server per region di wilayah yang banyak pemainnya. Jaringan: tempatkan titik akses (edge) di lokasi yang dekat, pilih jalur dan rute yang sedikit memutar.
Kisaran angka: Seoul–Tokyo sekitar 30 ms, Seoul–Singapura sekitar 75 ms, Seoul–AS bagian barat sekitar 140 ms, Seoul–Eropa sekitar 230–270 ms (pulang-pergi, berdasarkan rute sebenarnya). Ke Eropa hampir tidak ada kabel besar yang membentang lurus, sehingga rutenya memutar lewat Asia Tenggara dan Suez atau lewat AS, dan latensinya jauh lebih besar daripada perkiraan dari jarak.
Di grafik: Selalu tinggi sejak awal · RTT (per negara dan wilayah)
Yang diperiksa: Tandai IP pemain dengan negaranya dan periksa distribusi RTT per negara, lalu ukur dengan ping dan traceroute ke server dari VM di region cloud wilayah itu atau dari probe RIPE Atlas (dipilih berdasarkan negara dan ASN)
Cocok jika: RTT dari negara yang jauh selalu tinggi tanpa kaitan dengan jam, dan nilainya mendekati latensi minimum yang dihitung dari jarak (10 ms pulang-pergi per 1.000 km) serta statistik latensi publik
Tidak cocok jika: Jauh lebih tinggi daripada nilai yang bisa dijelaskan oleh jarak: lebih mungkin “Routing memutar”. Hanya naik pada malam hari: lebih mungkin “Kongesti di jalur peering saat jam sibuk”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Kasus nyata: Riot Games 2015: Trafik League of Legends yang memutar jauh dan Riot Direct

4 sumber

ITU-T G.114: One-way transmission time ITU
Nilai perencanaan latensi propagasi di kabel serat optik 5 µs/km (sekitar 200.000 km per detik, 10 ms pulang-pergi per 1.000 km)
Azure network round-trip latency statistics Microsoft Azure
Median pulang-pergi terukur dari Seoul (Korea Central): Tokyo 30 ms, Singapura 68 ms, AS bagian barat 124–136 ms, Eropa 234–244 ms
AAE-1 & SMW5 cable cuts impact millions of users across multiple countries Cloudflare
Trafik antara Eropa dan Asia umumnya lewat kabel bawah laut yang melintasi Mesir (Suez)
Probe Selection (RIPE Atlas REST API) RIPE NCC
Memilih probe untuk pengukuran RIPE Atlas berdasarkan negara, wilayah, ASN, atau blok alamat, lalu menjalankan ping dan traceroute

Internet satelit (orbit rendah dan geostasioner) Satellite internet (LEO, GEO)

ID isp-satellite · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)

Pada internet satelit, sinyal harus bolak-balik ke luar angkasa. Dengan satelit geostasioner, pulang-pergi saja sudah lebih dari 0,5 detik. Satelit orbit rendah seperti Starlink biasanya cepat, tetapi saat rute dialokasikan ulang, latensinya berfluktuasi dan koneksi kadang putus sesaat.

Mengapa Terhubung dari rumah, kapal, atau pesawat lewat internet satelit geostasioner atau orbit rendah, atau lewat Wi-Fi pesawat yang memakai satelit → Akibatnya Satelit geostasioner berada di ketinggian sekitar 36.000 km sehingga jarak tempuhnya memang panjang; satelit orbit rendah mengalokasikan ulang rute terminal, satelit, dan stasiun bumi dalam siklus pendek, dan pada saat itu muncul latensi dan packet loss sesaat → Di layar Geostasioner: input lag besar di setiap aksi. Orbit rendah: biasanya normal, tetapi secara berkala terjadi patah-patah atau teleport

Gejala: Input lag, Patah-patah, Teleport
Faktor: Latensi, Jitter, Packet loss
Siapa yang mengalami: Hanya saya, Satu rumah, Wilayah/ISP tertentu
Kapan: Selalu, Secara berkala
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: perpanjang buffer interpolasi secara otomatis mengikuti jitter, kirim input secara duplikat agar tahan terhadap packet loss singkat, tampilkan kualitas koneksi. Server: perhitungkan latensi koneksi satelit saat menentukan timing window dan batas lag compensation, pakai timeout yang tidak langsung mengeluarkan pemain karena jeda kosong sekitar 1 detik.
Tugas Pihak Eksternal: Beri tahu pemain bahwa internet satelit bisa memiliki latensi besar atau melonjak secara berkala, imbau pemain untuk memakai jaringan kabel darat untuk konten kompetitif bila memungkinkan.
Kisaran angka: Pada satelit geostasioner (ketinggian 36.000 km), perjalanan sinyal melintasi luar angkasa saja sudah 260 ms satu arah sehingga pulang-pergi lebih dari 520 ms (ITU-T G.114). Untuk Starlink yang memakai orbit rendah, data resmi (nilai rata-rata 15 detik) menunjukkan median 33 ms pada jam sibuk di AS, dan 1% terburuk (p99) pun di bawah 65 ms (2024). Dalam studi pengukuran, latensi berubah setiap kali rute dialokasikan ulang tiap 15 detik, dan muncul putus singkat kurang dari 1 detik. Dalam pengukuran internet di pesawat tahun 2018, latensi pulang-pergi sistem satelit rata-rata 750 ms.
Di grafik: Hanya sebagian yang tinggi · RTT dan jitter (per ASN penyedia internet satelit)
Yang diperiksa: Periksa apakah ASN dari IP pemain milik penyedia internet satelit, lalu gambar distribusi dan deret waktu RTT pemain penyedia itu secara terpisah. Ukur ping terus-menerus selama beberapa menit dari probe RIPE Atlas di ASN itu ke server, atau minta pemain menjalankan ping dan mengukur interval lonjakannya
Cocok jika: Penyedia geostasioner: RTT selalu di atas 500 ms. Penyedia orbit rendah: RTT biasanya puluhan ms, lalu berubah atau putus singkat dengan interval sekitar 15 detik
Tidak cocok jika: Penyedianya tidak memakai satelit, tetapi RTT selalu tinggi: lebih mungkin “Latensi propagasi (jarak fisik)” atau “Routing memutar”. Melonjak tidak beraturan: mengarah ke sinyal Wi-Fi atau seluler
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Karena jarak ke satelit orbit rendah pendek (Starlink 1,8–3,6 ms per segmen), latensi sehari-harinya bisa mirip dengan koneksi darat. Namun, jika titik keluar ke internet dari stasiun bumi (PoP) jauh dari server game, rutenya bertambah panjang, dan jika rute memutar lewat laser link antarsatelit, latensinya bertambah lagi. Menurut studi pengukuran, fluktuasi dengan siklus 15 detik berasal dari realokasi rute yang terjadi pada waktu yang sama di seluruh dunia dan tidak berkaitan dengan perpindahan antarsatelit. Latensi Wi-Fi pesawat sangat berbeda menurut sistemnya (satelit atau BTS darat), dan sistem yang memakai satelit geostasioner menghasilkan waktu pulang-pergi panjang seperti di atas.

5 sumber

ITU-T G.114: One-way transmission time ITU
Nilai perencanaan latensi propagasi satu arah di segmen satelit: ketinggian 400 km 12 ms, 14.000 km 110 ms, 36.000 km (geostasioner) 260 ms
Improving Starlink’s Latency Starlink
Median jam sibuk di AS 48,5 ms→33 ms, 1% paling lambat (p99) di atas 150 ms→di bawah 65 ms (2024); propagasi per segmen satelit 1,8–3,6 ms; latensi bertambah jika rute memutar lewat laser link, dan jarak dari stasiun bumi ke titik akses internet (PoP) juga menambah latensi
A Multifaceted Look at Starlink Performance (WWW 2024) ACM
Starlink mengalokasikan ulang rute setiap 15 detik pada waktu yang sama di seluruh dunia; di batas itu latensi dan throughput berfluktuasi dan muncul putus singkat kurang dari 1 detik (penyebabnya tidak terkait perpindahan antarsatelit); latensi segmen terminal↔satelit↔stasiun bumi sekitar 40 ms
Mile High WiFi: A First Look at In-Flight Internet Connectivity (WWW 2018) ACM
Pengukuran internet di pesawat selama 45 jam: latensi pulang-pergi rata-rata 200 ms untuk sistem BTS darat dan 750 ms untuk sistem satelit; median tingkat packet loss sistem satelit 7%
Probe Selection (RIPE Atlas REST API) RIPE NCC
Memilih probe untuk pengukuran RIPE Atlas berdasarkan negara, wilayah, ASN, atau blok alamat, lalu menjalankan ping dan traceroute

Routing memutar Suboptimal routing

ID isp-routing · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Karena kontrak interkoneksi antar-ISP, rute ke server yang dekat pun bisa memutar lewat tempat yang jauh.

Mengapa ISP Anda dan ISP di sisi server tidak terhubung langsung → Akibatnya Rute melewati negara atau kota lain sehingga jarak dan jumlah perangkat yang dilewati bertambah → Di layar Hanya pelanggan ISP tertentu yang ping-nya sangat tinggi

Gejala: Input lag
Faktor: Latensi
Siapa yang mengalami: Wilayah/ISP tertentu
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Infrastruktur: Hubungkan ke beberapa ISP (multihoming), pantau ping per ISP untuk menemukan ISP yang rutenya memutar, rundingkan penyesuaian rute dengan ISP.
Tugas Pihak Eksternal: Minta ISP terkait untuk menyesuaikan rute.
Kisaran angka: Bahkan di dalam satu negara, ping bisa berbeda dua sampai tiga kali lipat tergantung rutenya.
Di grafik: Selalu tinggi sejak awal · RTT (per ISP dan ASN)
Yang diperiksa: Bandingkan RTT per ISP (ASN), lalu periksa negara dan kota yang dilewati rute dengan traceroute atau mtr dari probe RIPE Atlas di ISP yang lambat atau dari pemain. Ukur IPv4 dan IPv6 secara terpisah (mtr -4, -6)
Cocok jika: Di wilayah yang sama, hanya ISP tertentu yang selalu tinggi, dan rutenya melewati negara lain atau kota yang jauh. Atau hanya salah satu versi alamat (IPv4 atau IPv6) yang tinggi
Tidak cocok jika: Semua ISP sama-sama tinggi: lebih mungkin “Latensi propagasi (jarak fisik)”. Tinggi hanya pada malam hari: lebih mungkin “Kongesti di jalur peering saat jam sibuk”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Rute IPv4 dan IPv6 ditentukan secara terpisah, sehingga untuk server yang sama pun salah satunya bisa memutar jauh dan menjadi lambat (pengukuran APNIC 2016: di dalam satu ISP muncul kelompok pengguna yang IPv6-nya lebih lambat 15, 25, atau 75 ms daripada IPv4). Aplikasi dengan Happy Eyeballs (RFC 8305), yaitu cara yang memakai IPv6 atau IPv4 mana pun yang lebih dulu tersambung, mencoba IPv6 lebih dulu, dan jika IPv6 tersambung dalam 250 ms (nilai yang disarankan), IPv4 tidak dicoba. Karena itu, meski IPv6 sedikit lebih lambat, koneksi cenderung tersambung lewat rute IPv6. Jika ping tinggi hanya di ISP tertentu, ukur IPv4 dan IPv6 secara terpisah.
Kasus nyata: Riot Games 2015: Trafik League of Legends yang memutar jauh dan Riot Direct

6 sumber

Quantifying the Causes of Path Inflation (SIGCOMM 2003) ACM
Analisis 65 ISP: kebijakan peering antar-ISP dan routing antardomain sangat memperpanjang rute
The Internet at the Speed of Light (HotNets 2014) ACM
Rute router sebenarnya memiliki median sekitar 1,5 kali panjang garis lurus kabel serat optik; ada juga kasus paket antara dua titik yang berdekatan memutar ke sisi lain bumi (hairpinning)
Probe Selection (RIPE Atlas REST API) RIPE NCC
Memilih probe untuk pengukuran RIPE Atlas berdasarkan negara, wilayah, ASN, atau blok alamat, lalu menjalankan ping dan traceroute
mtr(8) manual page source mtr
Dengan -4 atau -6, rute diukur hanya lewat IPv4 atau hanya lewat IPv6
RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency IETF
Alamat atau versi alamat (IPv4, IPv6) bisa diblokir, rusak, atau lambat tergantung jaringannya; IPv6 dicoba lebih dulu, dan percobaan koneksi berikutnya menunggu 250 ms sesuai rekomendasi
IPv6 Performance – Revisited APNIC
Perbandingan waktu pulang-pergi IPv6 dan IPv4 pada pengguna dual-stack yang sama: jaringan akses bisa memproses paket IPv6 dengan cara yang sangat berbeda, sehingga di dalam satu ISP muncul kelompok yang IPv6-nya lebih lambat 15, 25, atau 75 ms

Kongesti di jalur peering saat jam sibuk Peak-hour congestion at peering

ID isp-peak · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Sekitar pukul 21.00–23.00, trafik video melonjak sehingga jalur interkoneksi antar-ISP (peering) mudah padat.

Mengapa Streaming dan unduhan menumpuk pada malam hari → Akibatnya Terjadi antrean dan packet loss di jalur peering → Di layar Hanya pada malam hari, pelanggan ISP tertentu mengalami patah-patah atau teleport

Gejala: Patah-patah, Teleport, Rubber banding
Faktor: Jitter, Packet loss, Latensi
Siapa yang mengalami: Wilayah/ISP tertentu
Kapan: Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Infrastruktur: Tambah koneksi langsung dengan ISP terkait, alihkan rute yang padat, pantau packet loss dan ping per ISP pada malam hari.
Tugas Pihak Eksternal: Minta ISP terkait untuk menambah kapasitas jalur peering.
Di grafik: Tinggi hanya di jam tertentu · RTT dan packet loss (per ISP)
Yang diperiksa: Gambar RTT dan packet loss per ISP (ASN) menurut jam, lalu ambil hasil mtr dari probe RIPE Atlas di ISP itu atau dari pemain, masing-masing pada malam dan siang hari, untuk melihat segmen tempat packet loss mulai muncul
Cocok jika: Hanya ISP tertentu yang RTT dan packet loss-nya naik setiap malam sekitar pukul 21.00–23.00, dan di mtr packet loss serta latensi muncul terus dari segmen interkoneksi antar-ISP sampai ke tujuan
Tidak cocok jika: Semua ISP naik bersamaan: mengarah ke jalur atau server kami. Hanya satu rumah yang buruk pada malam hari: lebih mungkin “Channel Wi-Fi padat”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

2 sumber

Inferring Persistent Interdomain Congestion (SIGCOMM 2018) ACM
Kongesti berulang yang menaikkan latensi setiap jam sibuk di sebagian segmen interkoneksi antar-ISP; pada jam kongesti, tingkat packet loss juga naik
Probe Selection (RIPE Atlas REST API) RIPE NCC
Memilih probe untuk pengukuran RIPE Atlas berdasarkan negara, wilayah, ASN, atau blok alamat, lalu menjalankan ping dan traceroute

Gangguan kabel bawah laut dan jalur internasional Submarine cable fault

ID isp-cable · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)

Jika kabel bawah laut putus, trafik harus memutar lewat rute yang jauh selama beberapa minggu (jika lama, beberapa bulan) sampai kabel diperbaiki, dan jalur yang tersisa menjadi padat.

Mengapa Kabel putus atau perangkat rusak → Akibatnya Trafik menumpuk di rute memutar yang jauh dan di jalur yang tersisa → Di layar Ping pemain dari luar negeri melonjak dan packet loss berlangsung beberapa hari hingga beberapa minggu

Gejala: Input lag, Teleport
Faktor: Latensi, Packet loss
Siapa yang mengalami: Wilayah/ISP tertentu
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Infrastruktur: Siapkan jalur di rute lain, pindahkan trafik ke rute itu saat terjadi gangguan.
Tugas Pihak Eksternal: Umumkan penyebab dan perkiraan waktu pemulihan kepada pemain dari luar negeri, minta penyedia jalur untuk mengonfirmasi jadwal pemulihan.
Di grafik: Naik seperti anak tangga · RTT (per negara di luar negeri)
Yang diperiksa: Cari waktu kenaikan di grafik RTT dan packet loss per negara, cocokkan dengan ringkasan gangguan internet di Cloudflare Radar dan pengumuman operator kabel bawah laut, lalu pastikan dengan traceroute apakah rute memutar lewat benua lain
Cocok jika: Sejak saat tertentu, RTT ke wilayah tertentu di luar negeri naik satu tingkat dan bertahan beberapa hari hingga beberapa minggu, dan pada periode yang sama ada laporan gangguan kabel. Rute berubah menjadi rute memutar yang jauh dan berbeda dari biasanya
Tidak cocok jika: Kembali normal dalam beberapa hari dan tidak ada laporan gangguan: lebih mungkin “Perubahan rute dan konvergensi BGP” atau segmen ISP
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

AAE-1 & SMW5 cable cuts impact millions of users across multiple countries Cloudflare
Perbaikan kabel bawah laut memerlukan kapal perbaikan sehingga biasanya butuh beberapa hari hingga beberapa minggu (kasus Tonga 38 hari); saat kabel putus, latensi dan packet loss di segmen Eropa–Asia meningkat
Q2 2024 Internet disruption summary Cloudflare
Kabel Laut Merah yang rusak pada Februari 2024 masih diperbaiki pada bulan Juli (wilayah konflik); kabel EASSy dan Seacom yang putus pada bulan Mei pulih dalam 19 hari
Q1 2024 Internet disruption summary Cloudflare
Kabel di Afrika Barat yang putus (14 Maret) pulih 3–6 minggu kemudian; selama itu trafik dipindahkan ke kabel lain

Perubahan rute dan konvergensi BGP Route change / BGP convergence

ID isp-bgp · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)

Saat informasi rute internet berubah, paket hilang selama beberapa detik hingga puluhan detik (dalam kasus yang jarang, sampai beberapa menit) sampai rute kembali konvergen.

Mengapa Informasi rute di segmen salah satu ISP berubah → Akibatnya Selama beberapa detik hingga puluhan detik, paket hilang atau dialihkan ke rute baru → Di layar Tiba-tiba freeze beberapa detik, lalu angka ping berubah (misalnya 40 → 70 ms)

Gejala: Freeze, Teleport
Faktor: Packet loss, Latensi
Siapa yang mengalami: Wilayah/ISP tertentu
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Pakai timeout yang tahan terhadap putus singkat (jangan langsung memutus koneksi yang terhenti beberapa detik).
Tugas Tim Infrastruktur: Pantau rute (awasi perubahan rute dan ping untuk blok IP kami), deteksi gangguan jalur kami dalam 1 detik dengan BFD lalu alihkan (hold time default BGP 90–180 detik), pindahkan trafik ke jalur lain jika rute berubah ke rute yang jauh dan tidak kembali.
Tugas Pihak Eksternal: Untuk segmen ISP yang rutenya sering berubah, minta ISP terkait memeriksa penyebabnya.
Di grafik: Naik seperti anak tangga · RTT, rute traceroute
Yang diperiksa: Bandingkan rute traceroute dan mtr sebelum dan sesudah RTT berubah, lalu periksa riwayat perubahan rute BGP untuk blok alamat (prefix) kami di RIPEstat BGPlay
Cocok jika: Bersamaan dengan koneksi yang terhenti beberapa detik, RTT pindah ke nilai lain, dan pada waktu yang sama ada update BGP dan perubahan AS path
Tidak cocok jika: Tidak ada riwayat perubahan rute, tetapi hanya naik pada malam hari: lebih mungkin “Kongesti di jalur peering saat jam sibuk”. Hanya sebagian koneksi yang buruk: lebih mungkin “Satu jalur ECMP bermasalah”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Kasus nyata: Cloudflare 2020: Trafik hilang di sebagian kota akibat kesalahan konfigurasi backbone Cloudflare
Meta 2021: Gangguan Facebook: satu perintah di backbone sampai menghilangkan DNS
Cloudflare 2025: Gangguan DNS publik Cloudflare 1.1.1.1

4 sumber

RFC 4271: A Border Gateway Protocol 4 (BGP-4) IETF
Nilai default hold time BGP yang disarankan 90 detik (jika tidak ada pesan dari peer selama waktu ini, sesi diputus)
BGP updates in 2024 APNIC
Waktu sampai rute yang tidak stabil kembali stabil: rata-rata harian 25–35 detik (IPv4) dan 40–50 detik (IPv6)
Delayed Internet Routing Convergence (SIGCOMM 2000) ACM
Setelah gangguan rute, konvergensi bisa memakan waktu sampai beberapa menit, dan selama itu packet loss serta latensi meningkat (pengukuran tahun 2000)
BGPlay (RIPEstat Data API) RIPE NCC
Menampilkan rute BGP suatu blok alamat (prefix) pada awal periode, update BGP yang teramati selama periode itu, dan informasi AS di sepanjang rute

Satu jalur ECMP bermasalah ECMP / link bundle member fault

ID isp-ecmp · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)

ISP dan data center menyiapkan beberapa jalur ke tujuan yang sama dan menetapkan satu jalur untuk setiap koneksi. Jika hanya satu jalur yang rusak, hanya pemain yang mendapat jalur itu yang terus mengalami lag.

Mengapa Di segmen yang menggabungkan beberapa jalur, satu jalur atau satu perangkat rusak atau padat → Akibatnya Jalur ditentukan dari kombinasi alamat dan port (hash), sehingga hanya koneksi yang mendapat jalur itu yang mengalami packet loss dan latensi → Di layar Di wilayah dan ISP yang sama, hanya sebagian pemain yang terus-menerus teleport. Kadang normal kembali setelah reconnect

Gejala: Teleport, Rubber banding, Patah-patah
Faktor: Packet loss, Jitter
Siapa yang mengalami: Hanya saya, Wilayah/ISP tertentu
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Catat statistik packet loss dan retransmisi per koneksi agar IP, port, dan waktu dari pemain yang mengalaminya bisa diambil (untuk TCP dari jumlah retransmisi di TCP_INFO, untuk UDP dihitung dari nomor urut paket yang hilang).
Tugas Tim Infrastruktur: Kumpulkan IP, port, dan waktu dari pemain yang mengalaminya lalu teruskan ke ISP atau data center, pantau packet loss per jalur, ukur rute dengan protokol dan port yang sama dengan game (mtr --tcp atau --udp dengan --port), keluarkan jalur atau perangkat yang rusak dari grup jika jalurnya ada di perangkat kami.
Tugas Pihak Eksternal: Minta ISP memeriksa dan mengganti jalur yang rusak, imbau pemain untuk reconnect sebagai solusi sementara (jika port berubah saat reconnect).
Kisaran angka: Jika ada 4 jalur, hanya sekitar seperempat pemain yang mengalaminya. Pengukuran ping bisa lewat jalur yang berbeda dari game, sehingga hasilnya terlihat normal.
Di grafik: Hanya sebagian yang tinggi · Packet loss dan retransmisi per koneksi (per IP dan port)
Yang diperiksa: Pisahkan packet loss dan retransmisi per koneksi berdasarkan IP dan port asal, lalu ukur dengan mtr lewat UDP (-u) ke port game (-P) dengan port asal tetap (-L), dan ulangi beberapa kali dengan port asal berbeda. Jika hanya -P tanpa -L, port asal berubah di setiap permintaan sehingga beberapa jalur tercampur
Cocok jika: Di dalam wilayah dan ISP yang sama, hanya kombinasi port asal (atau alamat) tertentu yang terus mengalami packet loss, dan normal kembali setelah reconnect mengubah port
Tidak cocok jika: Semua tetap buruk walau port diganti: mengarah ke kongesti atau gangguan di satu segmen secara keseluruhan
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Agar urutan paket dalam satu koneksi tidak teracak, perangkat (ECMP, LAG) mengunci jalur untuk setiap koneksi berdasarkan nilai yang dihitung dari alamat dan port, atau hanya dari alamat tergantung konfigurasi perangkat. Di tempat yang hanya memakai alamat, reconnect tetap lewat jalur yang sama sehingga tidak membaik. Karena itu, jika laporan seperti “ping normal tetapi game lag” dan “setelah login ulang membaik” masuk bersamaan, curigai penyebab ini.

3 sumber

RFC 7424: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks IETF
LAG dan ECMP menetapkan satu link untuk setiap flow berdasarkan hash field header agar urutan paket terjaga (pemetaan flow→link banyak-ke-satu)
RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
Kriteria pembeda flow berbeda per implementasi (hanya alamat tujuan, pasangan alamat, atau sampai port); pada multipath, hasil ping dan traceroute sulit dipercaya
mtr(8) manual page source mtr
Opsi -u (UDP), -P (port tujuan), -L (port asal UDP); jika hanya -P yang diberikan, nomor urut permintaan dimasukkan ke port asal sehingga port asal berubah di setiap permintaan

Pembatasan kecepatan dan manajemen trafik oleh ISP Traffic shaping, data caps

ID isp-shaping · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)

Jika kuota data terlampaui atau layanan internet mengelola trafik tertentu, paket ditunda atau dibuang.

Mengapa Kecepatan dibatasi setelah kuota data habis, atau trafik tertentu dibatasi → Akibatnya Paket menunggu di antrean atau dibuang → Di layar Lag setelah pemakaian tertentu, terutama di seluler

Gejala: Input lag, Teleport
Faktor: Latensi, Packet loss
Siapa yang mengalami: Hanya saya, Wilayah/ISP tertentu
Kapan: Selalu, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Pengembang Game: Kurangi trafik game (kompresi, kirim hanya yang diperlukan).
Tugas Tim Infrastruktur: Jika trafik game ditunda atau dibuang hanya di ISP tertentu, kumpulkan data lalu eskalasikan ke ISP.
Tugas Pihak Eksternal: Imbau pemain untuk memeriksa apakah kuota datanya habis atau kecepatannya dibatasi dan apakah aplikasi lain di ponsel yang sama sedang dipakai, minta ISP memastikan apakah trafik game dibatasi.
Kisaran angka: Di Korea, paket data seluler yang kuotanya habis biasanya dibatasi ke 1–5 Mbps, dan paket yang murah ke ratusan kbps. Game memang ringan, tetapi jika aplikasi lain di ponsel yang sama memakai koneksi, antrean terbentuk di depan perangkat pembatas kecepatan.
Di grafik: Mendatar di batas · Throughput, RTT
Yang diperiksa: Minta pemain memeriksa sisa kuota dan status pembatasan kecepatan di aplikasi ISP, lalu ukur kecepatan maksimum dengan tes kecepatan. Di sisi server, bandingkan packet loss dan RTT per ISP
Cocok jika: Throughput tidak naik melewati satu nilai seperti 1–5 Mbps atau ratusan kbps, dan sejak itu RTT dan packet loss bertambah saat aplikasi lain di ponsel yang sama memakai koneksi. Hilang setelah kuota diisi ulang atau setelah pindah ke Wi-Fi
Tidak cocok jika: Tidak ada pembatasan kecepatan, tetapi hanya ISP tertentu yang buruk: lebih mungkin “Kongesti di jalur peering saat jam sibuk” atau “Routing memutar”
Sarana pemeriksaan: Lingkungan pemain sendiri

2 sumber

SKT, 고객 선택권과 혜택 강화한 신규 5G 요금제 출시 SK텔레콤
Contoh kontrol kecepatan setelah kuota dasar paket data 5G habis: maksimal 400 kbps, 1 Mbps, 3 Mbps
SKT, 요금제 개편 SK텔레콤
Setelah kuota dasar habis, internet tetap bisa dipakai dengan kecepatan maksimal 400 kbps (program “data aman untuk seluruh warga”)

Pembatasan UDP dan inspeksi paket per negara atau ISP UDP blocking, throttling and inspection by networks

ID isp-udp-block · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)

Sebagian jaringan memblokir alamat dan port UDP tertentu atau membatasi kecepatan UDP, dan perangkat inspeksi paket menyaring protokol yang tidak dikenalinya. Game yang berkomunikasi lewat UDP tidak bisa tersambung atau sering terputus di jaringan itu.

Mengapa Terhubung dari jaringan ISP yang membatasi kecepatan UDP, atau dari jaringan yang memiliki perangkat inspeksi trafik (sensor) di tingkat negara atau ISP → Akibatnya Memblokir alamat dan port UDP tertentu, membatasi kecepatan UDP pada jam ramai, menyaring port dan protokol yang tidak ada di allowlist, atau hanya meloloskan beberapa paket pertama lalu memblokir → Di layar Hanya pemain dari negara atau ISP tertentu yang tidak bisa masuk atau mengalami loading tanpa henti, disconnect tak lama setelah tersambung, atau teleport karena packet loss pada jam ramai

Gejala: Tidak bisa masuk / loading tanpa henti, Disconnect, Teleport
Faktor: Packet loss
Siapa yang mengalami: Wilayah/ISP tertentu
Kapan: Tepat setelah login atau maintenance, Selalu, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Pengembang Game: Klien: beralih otomatis ke rute cadangan TCP/TLS 443 jika UDP tidak tersambung dalam beberapa detik, deteksi juga kasus yang awalnya tersambung lalu segera putus dan coba lagi lewat rute cadangan, catat di log rute mana yang dipakai. Server: terima protokol game yang sama juga lewat TCP 443 (TLS), sesuaikan timeout karena rute cadangan bisa menambah latensi.
Tugas Tim Infrastruktur: Sebelum membuka layanan di negara baru, ukur apakah UDP bisa sampai dan seberapa besar packet loss pada jam sibuk di jaringan ISP setempat, tempatkan relay atau gateway yang menerima rute cadangan TCP 443 di dekat negara itu, pantau tingkat keberhasilan koneksi UDP dan TCP per negara dan ASN, kumpulkan data lalu eskalasikan untuk ISP yang terbukti membatasi kecepatan UDP.
Tugas Pihak Eksternal: Tanyakan kriteria pembatasan UDP dan kemungkinan pelonggarannya ke ISP atau lembaga terkait, imbau pemain untuk mencoba tersambung dari jaringan lain sebagai pembanding.
Kisaran angka: Menurut pengukuran yang dikutip dokumen IETF, 3–5% jaringan memblokir semua UDP. Pada 2016 Google meninjau hasil pemakaian QUIC (berbasis UDP) dan mendapati 4,4% klien tidak bisa memakainya karena UDP atau QUIC diblokir atau path MTU terlalu kecil. Sebagian besar klien itu berada di balik firewall perusahaan, dan tidak ditemukan kasus pemblokiran oleh seluruh jaringan satu ISP. Lalu 0,3% klien berada di jaringan yang tampaknya membatasi kecepatan UDP karena packet loss melonjak pada jam sibuk; angka ini turun dari 1% pada 2015 setelah Google meminta ISP terkait.
Di grafik: Hanya sebagian yang tinggi · Tingkat keberhasilan koneksi UDP (per negara dan ASN)
Yang diperiksa: Pisahkan tingkat keberhasilan koneksi UDP dan tingkat keberhasilan rute cadangan TCP 443 per negara dan ASN. Uji koneksi ke port UDP game dan ke TCP 443 masing-masing dari VM cloud atau PC pemain di jaringan ISP itu, lalu bandingkan dengan mtr -u -P (port game) dan mtr -T -P 443 untuk melihat dari segmen mana respons hilang
Cocok jika: Hanya di negara atau ASN tertentu, respons pertama UDP tidak datang atau koneksi putus dalam beberapa detik, sedangkan TCP 443 dari tempat yang sama normal. Jika berupa pembatasan kecepatan, packet loss UDP jelas bertambah hanya pada jam sibuk dan TCP tidak banyak terpengaruh
Tidak cocok jika: TCP juga gagal: mengarah ke gangguan rute, pemblokiran IP, atau “Gangguan dan latensi DNS”. Sama di semua negara: mengarah ke konfigurasi server atau firewall kami. Packet loss hanya muncul saat volume kirim sesaat besar, baik UDP maupun TCP: lebih mungkin “Policer membuang trafik berlebih”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Perangkat inspeksi paket bisa memilih flow UDP berdasarkan alamat, port, dan protokol lalu memblokirnya, atau memakai allowlist, yaitu memblokir semua protokol selain yang diizinkan (menurut dokumen survei IRTF). Jika perangkat menilai hanya dari sebagian field paket, perubahan kecil pada protokol saja bisa membuatnya diblokir. Pada masa awal QUIC, sebuah firewall meloloskan beberapa paket pertama setelah 1 bit di header berubah lalu memblokir paket sesudahnya, sehingga logika klien untuk beralih ke TCP tidak berjalan. Saat membuka layanan di negara baru, masalah ini bisa muncul lewat laporan seperti “di Korea normal, tetapi hanya sebagian ISP di negara itu yang tidak bisa tersambung”. Jika pemblokiran hanya terjadi di jaringan satu tempat seperti kafe atau kantor, lihat entri “Pembatasan di Wi-Fi publik dan jaringan kantor”.

4 sumber

RFC 9308: Applicability of the QUIC Transport Protocol IETF
Menurut studi pengukuran, 3–5% jaringan memblokir semua UDP sehingga aplikasi berbasis UDP harus menerima kegagalan koneksi atau menyiapkan rute cadangan TCP (TLS); port yang tidak terkait layanan terdaftar bisa diblokir firewall
The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017) ACM
2016: 4,4% klien tidak bisa memakai QUIC berbasis UDP (UDP atau QUIC diblokir, atau path MTU kecil; umumnya di balik firewall perusahaan; pemblokiran oleh seluruh jaringan ISP tidak teramati); 0,3% berada di jaringan yang tampaknya membatasi kecepatan UDP (packet loss naik pada jam sibuk; turun dari 1% pada 2015 setelah meminta ISP); ada kasus firewall yang hanya meloloskan beberapa paket pertama setelah 1 bit header berubah lalu memblokir sisanya sehingga logika cadangan TCP tidak berfungsi
RFC 9505: A Survey of Worldwide Censorship Techniques IRTF
Perangkat inspeksi di jaringan bisa memilih flow TCP dan UDP berdasarkan alamat, port, dan protokol lalu memblokirnya (pemblokiran endpoint UDP teramati pada QUIC); cara yang memblokir semua protokol selain yang diizinkan menyebabkan pemblokiran berlebihan; pembatasan kecepatan trafik tertentu juga dipakai
mtr(8) manual page source mtr
Mengukur rute dengan protokol dan port yang sama dengan game: -u mengirim UDP, -T mengirim TCP SYN, dan -P menentukan port tujuan

Kualitas koneksi buruk Faulty last-mile line / modem

ID isp-line · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal)

Konektor yang kontaknya buruk, kabel yang sudah tua, atau modem yang bermasalah menimbulkan packet loss terus-menerus dan koneksi yang putus secara berkala.

Mengapa Kabel rusak, kontak buruk, modem atau ONT bermasalah → Akibatnya Paket dibuang karena bit error; sesekali koneksi terputus beberapa detik hingga sekitar 1 menit karena sedang tersambung ulang → Di layar Packet loss kecil yang terus-menerus, sesekali freeze beberapa detik atau disconnect

Gejala: Teleport, Freeze, Disconnect
Faktor: Packet loss
Siapa yang mengalami: Satu rumah
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal)
Tugas Pihak Eksternal: Imbau pemain untuk memeriksa apakah game lain dan panggilan video juga terputus, dan jika ya, meminta ISP memeriksa koneksinya.
Di grafik: Melonjak acak sesekali · Tingkat packet loss, riwayat koneksi ulang
Yang diperiksa: Ukur packet loss sampai hop pertama ISP selama beberapa menit dengan pathping (atau mtr), lalu periksa waktu koneksi ulang di riwayat koneksi internet (WAN) di halaman admin router
Cocok jika: Packet loss terus muncul mulai dari hop pertama ISP walau koneksi sedang sepi, dan waktu koneksi ulang di log router bertepatan dengan waktu freeze atau disconnect. Game lain dan panggilan video juga ikut terputus
Tidak cocok jika: Packet loss mulai di jalur nirkabel ke router: lebih mungkin “Interferensi Wi-Fi dan sinyal lemah”. Mulai di hop ISP yang jauh: mengarah ke rute ISP
Sarana pemeriksaan: Lingkungan pemain sendiri

3 sumber

RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
Frame yang tidak lolos pemeriksaan frame (FCS) dihitung sebagai error FCS (dot3StatsFCSErrors) dan dijumlahkan ke error input (ifInErrors)
Understanding and Mitigating Packet Corruption in Data Center Networks (SIGCOMM 2017) ACM
Penyebab utama paket rusak adalah modul optik rusak, serat optik rusak, konektor kotor, dan pemasangan yang salah; tingkat packet loss akibat kerusakan tetap stabil tanpa kaitan dengan pemakaian
pathping Microsoft
Mengirim ping ke setiap hop selama waktu tertentu dan menghitung tingkat packet loss per router dan link untuk menunjukkan di segmen mana packet loss terjadi

Gangguan dan latensi DNS DNS failure / slowness

ID isp-dns · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika DNS, yang menerjemahkan nama server menjadi alamat, lambat atau gagal, server login dan server patch tidak bisa ditemukan.

Mengapa DNS ISP mengalami gangguan atau salah konfigurasi → Akibatnya Alamat server login dan server patch tidak ditemukan → Di layar Menunggu lama setelah menekan tombol masuk, atau tidak bisa masuk. Pemain yang sudah tersambung tetap normal

Gejala: Tidak bisa masuk / loading tanpa henti
Faktor: Latensi, Packet loss
Siapa yang mengalami: Wilayah/ISP tertentu, Hanya saya
Kapan: Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Simpan cache alamat (ingat alamat server terakhir yang berhasil dipakai untuk login), siapkan beberapa DNS (jika satu gagal, lakukan lookup ulang ke DNS lain).
Tugas Pihak Eksternal: Imbau pemain untuk mencoba mengganti DNS, misalnya ke DNS publik.
Di grafik: Hanya sebagian yang tinggi · Jumlah login gagal (per ISP), waktu lookup DNS
Yang diperiksa: Tanyakan nama server login ke DNS ISP dan ke DNS publik masing-masing dengan Resolve-DnsName -Server (atau nslookup), lalu bandingkan waktu respons dan hasilnya
Cocok jika: Hanya DNS ISP yang tidak merespons atau lama merespons, dan begitu diganti ke DNS publik langsung bisa masuk. Pemain yang sudah tersambung tetap normal
Tidak cocok jika: Alamat langsung didapat dari DNS mana pun, tetapi tetap tidak bisa masuk: mengarah ke rute, firewall, atau server
Sarana pemeriksaan: Lingkungan pemain sendiri
Kasus nyata: Meta 2021: Gangguan Facebook: satu perintah di backbone sampai menghilangkan DNS
Cloudflare 2025: Gangguan DNS publik Cloudflare 1.1.1.1
AWS 2025: Gangguan DNS DynamoDB di AWS us-east-1 dan pemulihan yang lama

4 sumber

Cloudflare 1.1.1.1 Incident on July 14, 2025 Cloudflare
Saat resolver DNS publik berhenti selama 62 menit, pengguna yang tidak bisa me-resolve nama praktis tidak bisa memakai layanan internet apa pun
RFC 8767: Serving Stale Data to Improve DNS Resiliency IETF
Cara bertahan saat gangguan dengan terus memakai record cache yang sudah kedaluwarsa ketika server otoritatif tidak bisa dijangkau (serve-stale)
Resolve-DnsName Microsoft
Menentukan server DNS yang ditanya dengan -Server, lalu me-lookup nama
nslookup Microsoft
Perintah untuk me-lookup nama langsung ke server DNS

Jalur bersama penuh akibat DDoS DDoS saturating shared links

ID isp-ddos-path · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Serangan besar yang ditujukan ke perusahaan game atau ke pihak lain di jaringan yang sama memenuhi jalur bersama.

Mengapa Muncul trafik serangan dalam jumlah besar → Akibatnya Trafik normal yang memakai jalur yang sama ikut tertahan dan dibuang → Di layar Banyak pemain sekaligus mengalami teleport, disconnect, atau tidak bisa masuk

Gejala: Teleport, Disconnect, Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss, Latensi
Siapa yang mengalami: Seluruh server, Wilayah/ISP tertentu
Kapan: Sesekali secara acak, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Infrastruktur: Pakai layanan proteksi DDoS, alihkan trafik saat terjadi serangan, sembunyikan alamat server (tempatkan di belakang perangkat proteksi agar alamat aslinya tidak terekspos).
Tugas Pihak Eksternal: Jika serangannya ditujukan ke pihak lain di jaringan yang sama, minta ISP memblokirnya di segmen upstream.
Di grafik: Mendatar di batas · Volume terima jalur (bps, pps), drop di interface
Yang diperiksa: Periksa volume terima di interface jalur dan perangkat kami, jumlah paket yang dibuang, dan log deteksi serangan dari layanan proteksi DDoS, bersama waktu ketika disconnect menumpuk
Cocok jika: Volume terima jalur menempel di kapasitas jalur dan mendatar, drop bertambah, dan pada waktu yang sama pemain dari banyak wilayah dan ISP sekaligus mengalami teleport atau disconnect
Tidak cocok jika: Jalur masih longgar, tetapi hanya sebagian ISP yang buruk: mengarah ke kongesti atau masalah rute di segmen ISP
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Infrastructure layer attacks AWS
Serangan besar seperti UDP reflection dan SYN flood membuat kapasitas jaringan meluap atau menghabiskan sumber daya firewall dan load balancer
Obfuscating AWS resources (BP1, BP4, BP5) AWS
Tempatkan layanan edge seperti CloudFront atau load balancer di depan server origin untuk mengurangi paparan langsung
RFC 7999: BLACKHOLE Community IETF
BLACKHOLE community, yaitu pengumuman lewat BGP yang meminta ISP tetangga membuang trafik ke alamat tertentu

IP bersama dari ISP (CGNAT) Carrier-grade NAT

ID isp-cgnat · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)

Jaringan seluler dan sebagian ISP membuat banyak pelanggan berbagi satu IP, dan mapping koneksi idle dihapus dalam waktu singkat.

Mengapa Perangkat ISP mengelola tabel sesi untuk banyak sekali pelanggan → Akibatnya Batas tabel sesi, idle timeout yang pendek → Di layar Disconnect setelah lama diam, false positive yang memblokir sekaligus semua orang yang memakai IP yang sama

Gejala: Disconnect, Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss
Siapa yang mengalami: Wilayah/ISP tertentu
Kapan: Setelah lama diam
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Pengembang Game: Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek, yang di jaringan seluler bisa sekitar 30 detik (mapping CGNAT ISP hanya diperbarui dengan pasti oleh paket yang keluar dari dalam, jadi klien yang mengirim), reconnect otomatis jika terputus. Server: balas heartbeat, bersihkan koneksi lebih dulu jika tidak menerima heartbeat dalam waktu tertentu, lanjutkan sesi pemain yang sama lewat token sesi walau mapping berubah dan alamat serta port berbeda, terapkan kebijakan pemblokiran berbasis IP dengan hati-hati karena satu IP bisa dipakai banyak orang (nilai bersama kriteria akun dan perangkat).
Tugas Tim Infrastruktur: Sesuaikan batas jumlah koneksi per IP dan jumlah koneksi baru per detik di firewall dan perangkat proteksi DDoS dengan IP bersama dari ISP (naikkan ambang atau beri pengecualian untuk blok alamat operator seluler).
Kisaran angka: Idle timeout UDP di jaringan seluler ada yang hanya sekitar 30 detik.
Di grafik: Koneksi putus serentak · Jumlah disconnect (timeout heartbeat), waktu idle sebelum terputus (per ISP)
Yang diperiksa: Periksa jumlah akun yang tersambung bersamaan dari satu IP dan ISP-nya (ASN) di log koneksi, lalu kumpulkan waktu idle koneksi yang terputus setelah idle per ISP. Di sisi pemain, periksa alamat internet (WAN) di halaman admin router
Cocok jika: Di blok alamat operator seluler, banyak akun tersambung dari satu IP, dan waktu idle sebelum terputus terkumpul pendek di sekitar 30–60 detik. Alamat WAN router berada di 100.64.0.0/10 (alamat bersama untuk NAT ISP) atau berbeda dari alamat yang dilihat server
Tidak cocok jika: Terkumpul pada pengguna router rumahan tanpa kaitan dengan ISP: lebih mungkin “Mapping NAT kedaluwarsa”
Sarana pemeriksaan: Log dan metrik server atau klien game

4 sumber

A Multi-perspective Analysis of Carrier-Grade NAT Deployment (IMC 2016) ACM
Waktu bertahan mapping UDP pada NAT yang diukur 10–200 detik, 74% maksimal 1 menit; median CGN 65 detik di jaringan seluler dan 35 detik di jaringan kabel
RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs) IETF
CGN harus mendukung pembatasan jumlah port eksternal per pelanggan dan pembatasan laju pembuatan mapping baru
RFC 6269: Issues with IP Address Sharing IETF
Jika satu alamat dipakai bersama, pemblokiran berbasis IP (penalty box) juga memblokir pelanggan lain di alamat yang sama
RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space IETF
100.64.0.0/10 adalah blok alamat bersama yang dipakai antara perangkat NAT ISP (CGN) dan router pelanggan

Rute lewat VPN atau game booster VPN / game accelerator detour

ID isp-vpn · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)

Jika VPN atau game booster diaktifkan, paket melewati server relay milik perusahaan itu. Jika server relay jauh atau padat, koneksi malah menjadi lebih lambat.

Mengapa VPN atau game booster mengalihkan semua paket game ke server relay → Akibatnya Jarak dan kongesti sampai server relay ikut bertambah, dan header tunnel juga mengurangi MTU (ukuran paket yang bisa dikirim sekaligus) → Di layar Ping naik dan packet loss, atau tidak bisa masuk karena ikut diblokir bersama orang lain yang memakai alamat relay yang sama

Gejala: Input lag, Teleport, Tidak bisa masuk / loading tanpa henti
Faktor: Latensi, Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Selalu, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Jaga paket UDP maksimal 1.200 byte (agar tidak terfragmentasi walau MTU berkurang karena header tunnel), nilai pemblokiran berbasis IP bersama kriteria akun dan perangkat dengan memperhitungkan alamat relay bersama milik VPN dan game booster.
Tugas Tim Infrastruktur: Jika banyak pemain dari luar negeri, tempatkan sendiri titik akses di dekat mereka, periksa rute ISP yang pelanggannya banyak melaporkan “setelah game booster dinyalakan jadi lebih baik”.
Tugas Pihak Eksternal: Imbau pemain untuk mematikan VPN atau game booster lalu membandingkan hasilnya.
Kisaran angka: Jika server relay dekat, tambahannya beberapa ms; jika memutar lewat negara lain, tambahannya puluhan ms hingga lebih dari 100 ms.
Di grafik: Hanya sebagian yang tinggi · RTT (per pemain), penyedia IP pemain
Yang diperiksa: Periksa apakah ASN dari IP pemain milik penyedia VPN, game booster, atau hosting, lalu minta pemain mematikan VPN atau game booster dan membandingkan ping serta traceroute
Cocok jika: RTT dan packet loss bertambah atau koneksi diblokir hanya saat VPN atau game booster aktif, dan traceroute menunjukkan segmen yang melewati server relay
Tidak cocok jika: Sama saja saat dimatikan atau dinyalakan: mengarah ke koneksi atau segmen ISP. Lebih baik saat dinyalakan: masalahnya ada di rute ISP asli (“Routing memutar”, “Kongesti di jalur peering saat jam sibuk”)
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Sebaliknya, saat rute ISP buruk, game booster bisa memutar lewat rute yang lebih baik sehingga ping turun. Laporan “setelah game booster dinyalakan jadi lebih baik” adalah petunjuk adanya masalah rute ISP, seperti routing memutar atau kongesti malam hari.

3 sumber

RFC 4459: MTU and Fragmentation Issues with In-the-Network Tunneling IETF
Masalah fragmentasi dan path MTU yang muncul karena header enkapsulasi dari tunnel di tengah jaringan mengurangi ukuran yang bisa dikirim
RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports IETF
1.200 byte disarankan sebagai ukuran aman dasar (BASE_PLPMTU) untuk transport datagram seperti UDP
Azure network round-trip latency statistics Microsoft Azure
Besarnya latensi pulang-pergi yang bertambah saat lewat titik akses di negara lain: Seoul–Tokyo 30 ms, Seoul–Hong Kong 39 ms, Seoul–Singapura 68 ms

L5 Perangkat jaringan data center

Tabel sesi firewall penuh Firewall session table exhaustion

ID dc-firewall · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)

Firewall mencatat dan melacak setiap koneksi yang diloloskannya di tabel sesi. Jika tabelnya penuh, koneksi baru tidak bisa diterima.

Mengapa Jumlah sesi mencapai batas karena lonjakan koneksi atau serangan → Akibatnya Koneksi baru ditolak karena tidak ada entri kosong untuk mencatatnya → Di layar Pemain yang baru mau masuk tidak bisa masuk atau mengalami loading tanpa henti, dan sebagian koneksi yang sudah ada juga disconnect

Gejala: Tidak bisa masuk / loading tanpa henti, Disconnect
Faktor: Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Tepat setelah login atau maintenance, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: atur lonjakan koneksi dengan sistem antrean login, pakai ulang koneksi agar tidak berulang kali membuka koneksi singkat, bersihkan lebih dulu koneksi yang heartbeat-nya berhenti (agar koneksi mati tidak lama memakai tabel sesi). Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek, reconnect otomatis jika terputus dengan interval percobaan ulang yang makin panjang dan disebar secara acak (agar tidak menyerbu bersamaan lagi).
Tugas Tim Infrastruktur: Perbesar tabel sesi, bersihkan cepat koneksi yang berakhir singkat (perpendek timeout sesi yang sudah ditutup), beri tahu Tim Pengembang Game nilai idle timeout sesi saat memperpendeknya agar interval heartbeat disesuaikan, blokir serangan, pasang alert utilisasi jumlah sesi.
Di grafik: Mendatar di batas · Jumlah sesi firewall, jumlah koneksi baru yang gagal
Yang diperiksa: Lihat grafik jumlah sesi bersamaan di perangkat firewall bersama batas sesinya, lalu cari log paket yang dibuang karena sesi tidak bisa dibuat. Untuk firewall Linux, bandingkan nf_conntrack_count dengan nf_conntrack_max dan cari “nf_conntrack: table full, dropping packet” di dmesg; untuk instance AWS, periksa conntrack_allowance_exceeded di ethtool -S
Cocok jika: Sejak jumlah sesi mendatar di batas, koneksi baru yang gagal bertambah, dan log kegagalan pembuatan sesi atau counter drop ikut naik
Tidak cocok jika: Jumlah sesi masih jauh di bawah batas, tetapi tetap tidak bisa masuk: lebih mungkin “Antrean koneksi (backlog) meluap” atau server login. Hanya koneksi idle yang terputus: lebih mungkin “Connection tracking di security group cloud kedaluwarsa”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

5 sumber

Netfilter Conntrack Sysfs variables Linux kernel
Jumlah entri maksimum tabel connection tracking (nf_conntrack_max), lama penyimpanan koneksi yang sedang ditutup (TIME_WAIT dan FIN_WAIT default 120 detik), TCP yang sudah terbentuk default 5 hari, jumlah entri saat ini (nf_conntrack_count)
Amazon EC2 security group connection tracking AWS
Jika jumlah koneksi yang bisa dilacak per instance terlampaui, paket koneksi baru dibuang; koneksi idle bisa menghabiskan tabel pelacakan
Infrastructure layer attacks AWS
Serangan seperti SYN flood menghabiskan sumber daya server, firewall, dan load balancer
net/netfilter/nf_conntrack_core.c (Linux v6.12) Linux kernel
Jika tabel connection tracking penuh, kernel mencatat “nf_conntrack: table full, dropping packet” dan membuang paket koneksi baru
Monitor network performance for ENA settings on your EC2 instance AWS
conntrack_allowance_exceeded: jumlah paket yang dibuang karena melewati batas connection tracking instance, diperiksa dengan ethtool -S

Rute lewat proteksi DDoS dan false positive DDoS scrubbing latency, false positives

ID dc-ddos · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Saat trafik dialihkan ke scrubbing center untuk menangkal serangan, rutenya menjadi lebih panjang, dan pemain yang normal kadang salah dikira serangan lalu diblokir.

Mengapa Setelah serangan terdeteksi (atau terus-menerus), trafik masuk dialihkan ke scrubbing center → Akibatnya Rute bertambah panjang, dan sebagian paket normal dinilai sebagai serangan → Di layar Ping semua pemain naik, hanya wilayah atau ISP tertentu yang tidak bisa masuk

Gejala: Input lag, Tidak bisa masuk / loading tanpa henti, Teleport
Faktor: Latensi, Packet loss
Siapa yang mengalami: Seluruh server, Wilayah/ISP tertentu
Kapan: Saat banyak pemain berkumpul, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Rangkum pola trafik game (port, ukuran paket, jumlah paket per detik) lalu bagikan ke Tim Infrastruktur, jaga paket UDP maksimal 1.200 byte.
Tugas Tim Infrastruktur: Buat aturan proteksi yang sesuai dengan pola trafik game, siapkan lokasi scrubbing per region, perkecil ukuran paket TCP di segmen tunnel (penyesuaian MSS), periksa false positive dari tingkat kegagalan koneksi per wilayah dan ISP.
Kisaran angka: Jika lokasi scrubbing ada di negara yang sama, tambahannya beberapa ms; jika lewat lokasi di negara lain, tambahannya 30 ms hingga lebih dari 100 ms. Biasanya hanya trafik masuk yang memutar, sedangkan respons server langsung keluar. Jika trafik yang sudah disaring dikembalikan lewat tunnel, ukuran yang bisa dikirim sekaligus (MTU) juga berkurang dan bisa berujung pada masalah hanya paket besar yang hilang.
Di grafik: Naik seperti anak tangga · RTT (ping), tingkat kegagalan koneksi per wilayah dan ISP
Yang diperiksa: Letakkan log mulai dan selesainya pengalihan (scrubbing) serta log pemblokiran dari perangkat atau layanan proteksi pada sumbu waktu yang sama dengan grafik RTT dan tingkat kegagalan koneksi per wilayah dan ISP. Dari wilayah yang bermasalah, pastikan dengan mtr atau traceroute apakah lokasi scrubbing ada di rute
Cocok jika: Saat pengalihan aktif, RTT naik satu tingkat dan bertahan, lalu kembali setelah pengalihan dimatikan. Atau alamat pemain normal muncul di log pemblokiran dan hanya wilayah atau ISP itu yang tingkat kegagalan koneksinya naik
Tidak cocok jika: RTT naik pada saat tidak ada log pengalihan atau pemblokiran: lebih mungkin “Routing memutar” atau “Perubahan rute dan konvergensi BGP”. Hanya paket besar yang hilang: lebih mungkin “MTU tidak cocok (hanya paket besar yang hilang)”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

2 sumber

Maximum transmission unit and maximum segment size Cloudflare
Trafik masuk diteruskan lewat tunnel GRE (MTU 1.476) setelah disaring, respons keluar langsung ke internet (DSR); disarankan membatasi TCP MSS maksimal 1.436, dan jika tidak disesuaikan, paket besar dibuang atau terfragmentasi
Azure network round-trip latency statistics Microsoft Azure
Besarnya latensi pulang-pergi menurut lokasi: Seoul–wilayah Busan 8 ms, Seoul–Tokyo 30 ms, Seoul–Singapura 68 ms

Idle timeout load balancer Load balancer idle timeout

ID dc-lb-idle · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)

Load balancer menghapus koneksi idle setelah waktu tertentu. Game masih menganggap koneksinya tersambung, lalu pemain disconnect.

Mengapa Pemain tidak mengirim paket apa pun selama beberapa waktu (membuka jendela dialog, AFK) → Akibatnya Load balancer membersihkan koneksi idle (nilai default umum 60–350 detik) → Di layar Disconnect tepat saat pemain mulai bergerak lagi

Gejala: Disconnect
Faktor: Packet loss
Siapa yang mengalami: Hanya saya, Seluruh server
Kapan: Setelah lama diam
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek (jika ALB 60 detik, maksimal 30 detik), reconnect otomatis jika terputus. Server: balas heartbeat, bersihkan koneksi lebih dulu jika tidak menerima heartbeat dalam waktu tertentu, lanjutkan sesi lewat token sesi.
Tugas Tim Infrastruktur: Periksa nilai idle timeout load balancer di sepanjang rute lalu bagikan ke Tim Pengembang Game, dan perpanjang jika perlu.
Kisaran angka: Nilai default AWS ALB 60 detik, NLB 350 detik untuk TCP dan 120 detik untuk UDP, dan Azure Load Balancer 4 menit untuk TCP. Nilai TCP pada ALB dan NLB bisa diubah, tetapi nilai UDP 120 detik pada NLB tidak bisa diubah. Saat waktunya habis, ALB juga menutup koneksi ke server, sedangkan NLB menghapusnya diam-diam sehingga server sering tidak tahu.
Di grafik: Koneksi putus serentak · Jumlah disconnect, waktu idle sebelum terputus
Yang diperiksa: Periksa nilai konfigurasi idle timeout load balancer di sepanjang rute, lalu kumpulkan waktu dari paket terakhir sampai terputus untuk setiap koneksi yang terputus. Untuk AWS NLB, periksa juga TCP_ELB_Reset_Count (jumlah RST yang dikirim load balancer) di CloudWatch
Cocok jika: Waktu idle koneksi yang terputus terkumpul tepat setelah nilai konfigurasi (ALB 60 detik, NLB TCP 350 detik, dan sebagainya), dan masalah muncul lagi jika pemain diam lebih lama dari itu lalu bergerak. Pada NLB, TCP_ELB_Reset_Count naik pada saat itu
Tidak cocok jika: Terputus tanpa kaitan dengan waktu idle: bukan penyebab ini. Terkumpul di sekitar 350 detik pada server yang tersambung langsung tanpa load balancer: lebih mungkin “Connection tracking di security group cloud kedaluwarsa”. Terjadi di router rumah pemain: lebih mungkin “Mapping NAT kedaluwarsa”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

Edit attributes for your Application Load Balancer AWS
Idle timeout ALB default 60 detik (1–4.000 detik); jika koneksi klien dan target diam selama waktu ini, load balancer menutup koneksi
Network Load Balancers AWS
Idle TCP NLB default 350 detik (60–6.000 detik); setelah lewat, NLB hanya berhenti melacak, dan data yang datang sesudahnya dibalas RST; flow UDP 120 detik tidak bisa diubah
Configure load balancer TCP reset and idle timeout Microsoft Azure
Idle timeout Azure Load Balancer default 4 menit (4–100 menit); jika terlampaui, sesi tidak dijamin tetap ada; TCP reset adalah pengaturan opsional
CloudWatch metrics for your Network Load Balancer AWS
TCP_ELB_Reset_Count: jumlah paket RST yang dibuat dan dikirim load balancer

Connection tracking di security group cloud kedaluwarsa Cloud security group connection tracking timeout

ID dc-cloud-conntrack · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)

Firewall yang terpasang di server cloud (security group) juga melacak koneksi, dan entri pelacakan untuk koneksi idle kedaluwarsa setelah waktu tertentu. Server yang tersambung langsung tanpa load balancer pun bisa membuat pemain yang lama diam terputus.

Mengapa Konfigurasi yang membuat security group melacak koneksi game (hanya mengizinkan alamat tertentu, membatasi aturan outbound, lewat NLB, dan sebagainya) → Akibatnya Entri pelacakan untuk koneksi yang idle cukup lama kedaluwarsa, lalu security group membuang diam-diam paket yang datang sesudahnya → Di layar Setelah AFK, pemain bergerak lagi tetapi tidak ada respons, lalu disconnect. Program server baru menyadarinya lama kemudian

Gejala: Disconnect
Faktor: Packet loss
Siapa yang mengalami: Hanya saya, Seluruh server
Kapan: Setelah lama diam
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek (jika TCP 350 detik, maksimal 175 detik; jika UDP stream 180 detik, maksimal 90 detik), reconnect otomatis jika terputus. Server: balas heartbeat, bersihkan koneksi lebih dulu jika tidak menerima heartbeat dalam waktu tertentu, lanjutkan sesi lewat token sesi.
Tugas Tim Infrastruktur: Periksa waktu connection tracking instance (TcpEstablishedTimeout) dan perpanjang jika perlu (UDP tidak bisa diperpanjang karena maksimal 180 detik), tinjau konfigurasi security group yang tidak memicu pelacakan (izinkan semua alamat untuk port game, izinkan semua trafik outbound; koneksi lewat NLB tetap dilacak), jalankan uji koneksi idle saat pindah ke generasi instance yang baru.
Kisaran angka: Di AWS, tipe instance Nitro v6 menghapus entri pelacakan koneksi TCP idle setelah 350 detik secara default (tipe lain 5 hari). Untuk UDP, defaultnya 180 detik untuk flow yang request dan response-nya bolak-balik beberapa kali (stream), dan 30 detik untuk flow yang hanya satu arah atau hanya satu kali request dan response.
Di grafik: Koneksi putus serentak · Jumlah disconnect, waktu idle sebelum terputus
Yang diperiksa: Periksa konfigurasi waktu connection tracking instance dan aturan security group (apakah konfigurasinya memicu pelacakan), lalu kumpulkan waktu idle koneksi yang terputus. Segera setelah terputus, jalankan ss -tnoi di server dan periksa apakah koneksi itu masih ESTABLISHED dengan timer retransmisi (timer:(on,…)) berjalan dan backoff yang terus membesar
Cocok jika: Waktu idle koneksi yang terputus terkumpul tepat setelah 350 detik untuk TCP, 180 detik untuk UDP stream, dan 30 detik untuk UDP satu arah, dan socket di sisi server tetap ESTABLISHED tanpa mendeteksi putusnya koneksi (jika server punya data untuk dikirim, ia hanya terus mengirim ulang)
Tidak cocok jika: Konfigurasi security group tidak memicu pelacakan (port game diizinkan untuk semua alamat, aturan outbound mengizinkan semua, tidak lewat NLB): bukan penyebab ini. Jika lewat NLB, bandingkan nilainya dengan “Idle timeout load balancer”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Amazon EC2 security group connection tracking AWS
Pelacakan TCP idle default 350 detik (Nitro v6; tipe lain 432.000 detik = 5 hari), UDP satu arah 30 detik dan stream 180 detik (maksimal 180); tidak dilacak jika aturannya mengizinkan semua alamat; koneksi lewat NLB selalu dilacak
Update the TCP idle timeout for your Network Load Balancer listener AWS
Jika idle timeout NLB lebih panjang daripada waktu connection tracking instance target, sisi instance lebih dulu membuang status koneksi secara diam-diam
ss(8) — Linux manual page iproute2
timer:(on,…) pada -o adalah timer retransmisi, dan backoff pada -i adalah berapa kali waktu tunggu retransmisi digandakan

Batas koneksi dan port NAT gateway cloud Cloud NAT gateway connection / port limits

ID dc-nat-gateway · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Koneksi dari server di subnet privat ke luar (autentikasi platform, pembayaran, API eksternal) dikirim keluar oleh NAT gateway setelah alamat dan portnya diganti. Jika koneksi bersamaan ke tujuan yang sama melebihi batas port gateway, koneksi baru gagal.

Mengapa Server-server membuka banyak koneksi singkat ke alamat eksternal yang sama, seperti autentikasi platform atau pembayaran, atau membiarkan koneksi terbuka lama → Akibatnya NAT gateway tidak bisa lagi mengalokasikan port sumber untuk tujuan itu sehingga koneksi baru gagal → Di layar Di dalam game normal, tetapi hanya fitur yang memanggil layanan eksternal seperti login, pembayaran, dan pemberian hadiah yang gagal atau lambat (tidak bisa masuk / loading tanpa henti, aksi hilang / rollback)

Gejala: Tidak bisa masuk / loading tanpa henti, Aksi hilang / rollback
Faktor: Packet loss, Latensi
Siapa yang mengalami: Fitur tertentu saja, Seluruh server
Kapan: Tepat setelah login atau maintenance, Jam sibuk malam hari, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pakai ulang koneksi ke API eksternal (HTTP keep-alive, connection pool) dan jangan membuka koneksi baru untuk setiap request, kirim keepalive untuk koneksi idle di pool dengan interval lebih pendek dari idle timeout NAT (AWS 350 detik) atau tutup lebih dulu, jika gagal coba lagi dengan interval yang makin panjang dan disebar secara acak, catat tingkat kegagalan dan latensi per panggilan eksternal.
Tugas Tim Infrastruktur: Tambah alamat IP ke NAT gateway (NAT gateway publik AWS secara default hanya bisa memasang hingga 2 Elastic IP, jadi untuk lebih dari itu ajukan kenaikan kuota), pisahkan gateway per availability zone dan subnet, pasang alert untuk metrik kegagalan alokasi port (AWS ErrorPortAllocation, Failed pada Azure SNAT Connection Count, OUT_OF_RESOURCES pada Google Cloud dropped_sent_packets_count), untuk Google Cloud NAT naikkan jumlah port minimum per VM atau pakai alokasi port dinamis.
Kisaran angka: AWS NAT gateway bisa membuka hingga 55.000 koneksi bersamaan ke tujuan yang sama (IP, port, protokol) per satu alamat IP, dan kapasitasnya bisa ditambah dengan memasang hingga 8 IP. Koneksi yang diam selama 350 detik dihapus, dan paket yang dikirim lewat koneksi itu sesudahnya dibalas RST. Azure NAT Gateway menyediakan 64.512 port SNAT per IP publik (maksimal 16 IP). Google Cloud NAT membagi 64.512 port per NAT IP ke setiap VM, tetapi nilai default port minimum per VM adalah 64 (alokasi statis), sehingga dengan pengaturan default, koneksi bersamaan dari satu VM ke tujuan yang sama umumnya terbatas pada 64.
Di grafik: Mendatar di batas · Jumlah koneksi bersamaan NAT gateway, jumlah kegagalan alokasi port
Yang diperiksa: Untuk AWS, letakkan metrik NAT gateway ErrorPortAllocation, ActiveConnectionCount, dan PacketsDropCount di CloudWatch (Azure: SNAT Connection Count yang difilter ke status Failed serta Dropped Packets; Google Cloud: dropped_sent_packets_count dengan reason OUT_OF_RESOURCES) berdampingan dengan waktu kegagalan panggilan eksternal dari server game
Cocok jika: Pada saat panggilan eksternal gagal, ErrorPortAllocation (Azure: SNAT Connection Count berstatus Failed, Google Cloud: drop OUT_OF_RESOURCES) lebih dari 0, dan kegagalan terkumpul pada panggilan ke satu atau dua tujuan yang menerima banyak koneksi, seperti server autentikasi atau pembayaran
Tidak cocok jika: Kegagalan alokasi port 0, tetapi connect dari server game gagal dengan EADDRNOTAVAIL dan TIME_WAIT mendekati rentang port ephemeral: lebih mungkin “Port ephemeral habis pada koneksi antarserver”. Koneksi berhasil tetapi responsnya saja yang lambat: lebih mungkin “Ketergantungan pada layanan eksternal”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Berbeda dengan “Port ephemeral habis pada koneksi antarserver”, yaitu habisnya port ephemeral di satu server, batas ini berlaku di NAT gateway dan dipakai bersama oleh server-server di belakang gateway (Google Cloud NAT membaginya per VM). Jika TIME_WAIT dan rentang port ephemeral di sisi server masih longgar tetapi hanya panggilan ke luar yang gagal, penyebabnya ada di sini. Port dari koneksi yang sudah ditutup juga tidak langsung dipakai lagi untuk tujuan yang sama (di Azure ada cooldown, di Google Cloud tidak bisa dipakai selama TIME_WAIT), sehingga makin sering koneksi singkat diulang, makin cepat batasnya tercapai.

7 sumber

NAT gateway basics AWS
55.000 koneksi bersamaan ke tujuan yang sama (IP, port, dan protokol tujuan) per alamat IPv4, bisa ditambah dengan memasang hingga 8 IP (Elastic IP pada NAT gateway publik default 2, ditambah lewat permintaan kenaikan kuota); bandwidth naik otomatis dari 5 Gbps hingga 100 Gbps dan throughput dari 1 juta hingga 10 juta paket per detik, dan paket dibuang jika batas itu terlampaui
NAT gateway metrics and dimensions AWS
ErrorPortAllocation: berapa kali port sumber gagal dialokasikan (jika lebih dari 0, koneksi bersamaan terlalu banyak), ActiveConnectionCount, IdleTimeoutCount (koneksi yang dibersihkan karena idle 350 detik), PacketsDropCount
Troubleshoot NAT gateways AWS
Jika idle 350 detik, koneksi kedaluwarsa dan pengiriman berikutnya dibalas RST; disarankan keepalive lebih pendek dari 350 detik; jika batas koneksi tercapai, tambah gateway per availability zone, tambah IP, atau kurangi jumlah koneksi
Source Network Address Translation (SNAT) with Azure NAT Gateway Microsoft Azure
64.512 port SNAT per IP publik (maksimal 16 IP); setiap koneksi ke tujuan yang sama memerlukan port yang berbeda; port yang sudah ditutup melewati cooldown sebelum dipakai lagi untuk tujuan yang sama
Metrics and alerts for Azure NAT Gateway Microsoft Azure
Jika SNAT Connection Count yang difilter ke status Failed lebih dari 0, kemungkinan port SNAT habis; Dropped Packets
IP addresses and ports Google Cloud
64.512 port masing-masing untuk TCP dan UDP per NAT IP; default port minimum per VM 64 (alokasi statis) dan 32 (alokasi dinamis); jumlah port yang dicadangkan untuk VM membatasi jumlah koneksi bersamaan ke tujuan yang sama; port dari koneksi yang sudah ditutup tidak bisa dipakai selama TIME_WAIT
Logs and metrics Google Cloud
dropped_sent_packets_count dengan reason OUT_OF_RESOURCES: paket yang dibuang karena NAT IP atau port tidak cukup

Distribusi load balancer timpang dan health check keliru LB imbalance, bad health checks

ID dc-lb-imbalance · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Koneksi menumpuk di satu server saja, atau pemain terus dikirim ke server yang sudah mati.

Mengapa Aturan distribusi tidak sesuai, atau health check tidak melihat kondisi sebenarnya → Akibatnya Hanya satu server yang kelebihan beban, atau ada percobaan koneksi ke server yang sudah mati → Di layar Hanya sebagian channel atau sebagian pemain yang mengalami slow motion, tidak bisa masuk, atau loading tanpa henti

Gejala: Slow motion, Tidak bisa masuk / loading tanpa henti
Faktor: Stall, Packet loss
Siapa yang mengalami: Lokasi/channel tertentu
Kapan: Tepat setelah login atau maintenance, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Implementasikan health check yang menjawab permintaan pemeriksaan dari load balancer berdasarkan kondisi game sebenarnya (tick berjalan, koneksi DB), sertakan juga nilai beban server.
Tugas Tim Infrastruktur: Ganti health check ke cara yang memeriksa respons game sebenarnya, distribusikan berdasarkan beban server, pantau selisih jumlah koneksi antarserver.
Di grafik: Hanya sebagian yang tinggi · Jumlah koneksi dan utilisasi CPU per server
Yang diperiksa: Tumpangkan jumlah koneksi (ss -s) dan utilisasi CPU setiap server di belakang load balancer dalam satu grafik, lalu bandingkan status kesehatan target di load balancer (AWS: HealthyHostCount dan UnHealthyHostCount di CloudWatch) dengan kondisi server game yang sebenarnya
Cocok jika: Hanya satu atau dua server yang jumlah koneksi dan CPU-nya jauh lebih tinggi daripada server lain, atau server yang tick-nya berhenti tetap berstatus “sehat” dan terus menerima koneksi baru
Tidak cocok jika: Jumlah koneksi per server merata, tetapi hanya satu channel yang lambat: mengarah ke beban di dalam channel itu (“Kelebihan beban di area single-thread (hotspot)”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Kasus nyata: AWS 2025: Gangguan DNS DynamoDB di AWS us-east-1 dan pemulihan yang lama

3 sumber

Load Balancing in the Datacenter Google
Round robin sederhana membuat penggunaan CPU antar-task berbeda hingga 2 kali lipat; distribusi berbobot dengan backend menyertakan beban di respons dan health check; status lame duck yang menyatakan tidak mau menerima request lagi
Health checks for Network Load Balancer target groups AWS
Health check default berinterval 30 detik dan target dikeluarkan setelah 2 kali gagal; layanan UDP diperiksa dengan health check TCP atau HTTP, jadi disarankan mengonfigurasinya agar mencerminkan kondisi layanan sebenarnya
CloudWatch metrics for your Network Load Balancer AWS
HealthyHostCount dan UnHealthyHostCount: jumlah target yang dinilai sehat dan tidak sehat

Microburst di switch Switch microburst drops

ID dc-microburst · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur), Infrastruktur server (Tim Infrastruktur)

Jika beberapa server sekaligus mengirim paket ke ribuan pemain pada saat yang sama, buffer kecil di port switch tempat trafik itu bertemu meluap dalam waktu kurang dari 1 ms.

Mengapa Kemunculan world boss, skill berskala besar, atau tick beberapa server yang bertepatan di saat yang sama membuat pengiriman terjadi sekaligus → Akibatnya Buffer (ratusan KB hingga beberapa MB per port) di titik tempat beberapa port bertemu di satu port, atau tempat trafik pindah dari port cepat ke port lambat, penuh sesaat → Di layar Sebagian paket dibuang, banyak pemain sekaligus mengalami teleport atau skill tidak keluar

Gejala: Teleport, Aksi hilang / rollback
Faktor: Packet loss
Siapa yang mengalami: Lokasi/channel tertentu
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur), Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Bagi pengiriman secara merata di dalam satu tick (pacing), geser sedikit waktu mulai tick di setiap server.
Tugas Tim Infrastruktur: Jaringan: pakai switch dengan buffer besar, sebar trafik (tempatkan server di beberapa switch dan port), pantau counter drop per port switch. Server/OS: batasi kecepatan kirim total server (shaper tc Linux).
Kisaran angka: Jumlah data yang bisa dikirim port 10 Gbps dalam 1 ms sekitar 1,25 MB. Jika trafik dua port masuk bersamaan ke satu port, 1,25 MB menumpuk setiap 1 ms. Walau utilisasi rata-rata per 1 detik hanya 10%, buffer bisa meluap pada skala 1 ms.
Di grafik: Naik mengikuti beban · Jumlah drop output port switch
Yang diperiksa: Kumpulkan counter drop output (ifOutDiscards, atau output drops tergantung perangkat) dari port switch tempat server terhubung dan port tempat trafiknya bertemu dengan interval sependek mungkin, lalu cocokkan dengan waktu kemunculan boss atau pertempuran besar. Tidak terlihat hanya dari grafik utilisasi rata-rata per 1 detik atau 1 menit
Cocok jika: Utilisasi rata-rata rendah, tetapi drop output bertambah setiap kali pemain berkumpul di satu tempat, dan pada saat itu banyak pemain sekaligus melaporkan teleport atau skill tidak keluar
Tidak cocok jika: Drop terus bertambah pada jam ketika utilisasi rata-rata tinggi: lebih mungkin “Jalur data center penuh”. Error input (CRC) bertambah: lebih mungkin “Kabel rusak dan error port”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

High-Resolution Measurement of Data Center Microbursts (IMC 2017) ACM
Lebih dari 70% burst di data center selesai dalam puluhan µs; paket dibuang karena burst bahkan di port dengan utilisasi rata-rata sekitar 9%
Data Center TCP (DCTCP) (SIGCOMM 2010) ACM
Switch umum memiliki buffer dangkal (48 port berbagi 4 MB, satu port bisa memakai hingga sekitar 700 KB); jika banyak flow masuk ke satu port dalam waktu singkat, terjadi packet loss
RFC 2863: The Interfaces Group MIB IETF
ifOutDiscards: jumlah paket yang tidak bisa dikirim dan dibuang walau tidak ada error, misalnya untuk mengosongkan ruang buffer

Jalur data center penuh Uplink saturation

ID dc-uplink · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika deploy patch, pengiriman log, dan backup memakai jalur yang sama dengan game, jalurnya penuh.

Mengapa Transfer besar memakai jalur yang sama → Akibatnya Antrean dan packet loss di jalur bertambah → Di layar Ping seluruh server naik dan pemain teleport

Gejala: Input lag, Teleport
Faktor: Latensi, Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Secara berkala, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Jaringan: prioritaskan trafik game (QoS), pisahkan jalur untuk transfer besar, pasang alert utilisasi jalur. Server/OS: batasi kecepatan backup, pengiriman log, dan deploy lalu jalankan di jam sepi.
Di grafik: Mendatar di batas · Utilisasi jalur, RTT (ping)
Yang diperiksa: Letakkan utilisasi interface uplink data center, yang dihitung dari SNMP ifHCInOctets dan ifHCOutOctets, dan drop output (ifOutDiscards) pada sumbu waktu yang sama dengan jadwal backup, deploy, dan pengiriman log
Cocok jika: Pada saat utilisasi jalur menempel di batas bandwidth dan mendatar, RTT dan drop seluruh server naik, dan waktunya bertepatan dengan pekerjaan transfer besar
Tidak cocok jika: Utilisasi per menit masih jauh di bawah batas, tetapi ada drop: lebih mungkin “Microburst di switch”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

RFC 4594: Configuration Guidelines for DiffServ Service Classes IETF
Trafik interaktif real-time seperti game dan transfer besar seperti backup diproses di kelas layanan yang berbeda
RFC 7567: IETF Recommendations Regarding Active Queue Management IETF
Jika jumlah yang masuk ke perangkat melebihi kecepatan kirimnya, antrean menumpuk, dan antrean yang berlebihan adalah penyebab utama latensi
RFC 2863: The Interfaces Group MIB IETF
ifHCInOctets dan ifHCOutOctets: jumlah byte yang diterima dan dikirim interface (64 bit); ifOutDiscards: jumlah paket yang tidak bisa dikirim dan dibuang

Failover perangkat jaringan Network device failover

ID dc-failover · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)

Saat satu router atau firewall rusak dan dialihkan ke perangkat cadangan (failover), semua pemain mengalami freeze selama beberapa detik.

Mengapa Dialihkan ke perangkat cadangan karena perangkat rusak atau maintenance → Akibatnya Peralihan memakan waktu beberapa detik, dan jika informasi sesi tidak tersinkronisasi, koneksi di-reset → Di layar Semua pemain di server mengalami freeze bersamaan, disconnect massal

Gejala: Freeze, Disconnect
Faktor: Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: pakai timeout yang tahan terhadap putus singkat (beberapa detik), dan jika terputus lalu reconnect, lanjutkan sesi lewat token sesi. Klien: reconnect otomatis jika terputus (sebar interval percobaan ulang secara acak agar tidak menyerbu bersamaan).
Tugas Tim Infrastruktur: Pakai redundansi yang berbagi status koneksi, deteksi kerusakan dalam 1 detik dengan BFD, uji failover secara berkala.
Kisaran angka: Jika perangkat langsung mendeteksi kerusakan, sekitar 1–3 detik. Jika hanya mengandalkan timer default BGP tanpa deteksi kerusakan cepat (BFD), rute bisa terputus selama 90–180 detik sampai perangkat tetangga mendeteksinya.
Di grafik: Koneksi putus serentak · Jumlah koneksi, volume kirim dan terima seluruh server
Yang diperiksa: Periksa log event router dan firewall (perubahan peran VRRP, sesi BFD atau BGP down, catatan failover) bersama jumlah koneksi dan volume kirim-terima seluruh server pada waktu yang sama
Cocok jika: Pada waktu failover di log perangkat, trafik semua server di belakang perangkat itu menjadi 0 selama beberapa detik atau jumlah koneksi turun bersamaan
Tidak cocok jika: Hanya koneksi satu server yang turun: lebih mungkin “Crash di server” atau “Masalah driver dan firmware NIC”. Log perangkat bersih dan server yang berhenti adalah satu virtual machine di cloud: lebih mungkin “Maintenance host cloud dan live migration”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

RFC 5880: Bidirectional Forwarding Detection (BFD) IETF
Metode Hello pada protokol routing butuh lebih dari 1 detik untuk mendeteksi kerusakan, sehingga dibuat BFD untuk mendeteksinya dalam waktu lebih singkat
RFC 7938: Use of BGP for Routing in Large-Scale Data Centers IETF
Jika hanya mengandalkan keepalive BGP, konvergensi lambat; jika link down langsung diterima dan sesi diputus, kerusakan terdeteksi dalam skala ms lalu rute konvergen ulang
RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 IETF
Advertisement VRRP default 1 detik; perangkat cadangan mengambil alih peran jika advertisement berhenti lebih dari sekitar 3 kali intervalnya (dengan pengaturan default, sedikit di atas 3 detik)

Kabel rusak dan error port Bad cable / optics (CRC errors)

ID dc-bad-cable · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur)

Jika modul optik atau kabel rusak, sebagian paket yang lewat jalur itu rusak dengan persentase tertentu.

Mengapa Bit error karena modul optik atau kabel rusak → Akibatnya Paket yang rusak dibuang diam-diam oleh perangkat → Di layar Hanya sebagian server dan pemain yang memakai jalur itu yang terus mengalami packet loss sehingga terjadi teleport atau rubber banding

Gejala: Teleport, Rubber banding
Faktor: Packet loss
Siapa yang mengalami: Lokasi/channel tertentu
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Infrastruktur: Pantau counter error port (CRC) dan pasang alert, ganti komponen seperti modul optik dan kabel, keluarkan link yang bermasalah dan alihkan trafik sampai komponen diganti.
Di grafik: Hanya sebagian yang tinggi · Jumlah error CRC per port, tingkat packet loss per server dan rute
Yang diperiksa: Periksa counter CRC di kedua ujung link. Di switch: error FCS port (dot3StatsFCSErrors) dan error input (ifInErrors); di server: crc di antara RX errors pada ip -s -s link (statistik kernel rx_crc_errors)
Cocok jika: Error CRC di satu port terus bertambah tanpa kaitan dengan volume trafik dan jam, dan hanya server serta pemain yang lewat port itu yang mengalami packet loss
Tidak cocok jika: Tidak ada error CRC dan hanya drop output yang bertambah: mengarah ke kongesti (“Microburst di switch”, “Jalur data center penuh”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Understanding and Mitigating Packet Corruption in Data Center Networks (SIGCOMM 2017) ACM
Analisis 350.000 link di data center: penyebab kerusakan paket adalah modul optik rusak, serat optik rusak, dan konektor kotor; tingkat kerusakan stabil tanpa kaitan dengan pemakaian; link bermasalah dikeluarkan lalu diperbaiki sambil menjaga jumlah jalur
RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
Counter kegagalan pemeriksaan frame FCS (dot3StatsFCSErrors); error ini dijumlahkan ke error input (ifInErrors)
Interface statistics Linux kernel
rx_crc_errors: jumlah paket yang diterima dengan error CRC; jenis error bisa diperiksa satu per satu dengan ip -s -s link

MTU tidak cocok (hanya paket besar yang hilang) MTU black hole

ID dc-mtu · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)

Jika MTU (ukuran yang bisa dikirim sekaligus) di segmen tengah mengecil tetapi notifikasi ukuran terlampaui diblokir, hanya paket besar yang terus hilang.

Mengapa MTU mengecil di segmen tunnel atau VPN → Akibatnya Notifikasi ukuran terlampaui (ICMP) diblokir firewall sehingga pengirim tidak tahu → Di layar Freeze hanya saat membuka layar besar seperti inventory atau daftar karakter, lalu disconnect

Gejala: Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss
Siapa yang mengalami: Wilayah/ISP tertentu, Hanya saya
Kapan: Saat melakukan aksi tertentu, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Untuk menurunkannya langsung dari sisi server, atur ukuran segmen maksimum socket dengan TCP_MAXSEG (memecah pesan menjadi kecil di kode game saja tidak mencegahnya), jaga paket UDP maksimal 1.200 byte.
Tugas Tim Infrastruktur: Jaringan: perkecil ukuran paket TCP di segmen tunnel (penyesuaian MSS), izinkan notifikasi ukuran terlampaui (ICMP) di firewall dan network ACL cloud. Server/OS: izinkan juga notifikasi ukuran terlampaui (ICMP) di firewall server dan security group cloud, aktifkan MTU probing di kernel server dengan tcp_mtu_probing=1 (jaring pengaman terakhir yang baru bekerja setelah koneksi terhenti beberapa detik).
Kisaran angka: Biasanya 1.500 byte, dan menyusut ke sekitar 1.400 setelah lewat tunnel.
Di grafik: Hanya sebagian yang tinggi · Disconnect per wilayah dan ISP, kegagalan respons besar
Yang diperiksa: Dari PC pemain yang bermasalah, kirim ping ke server dengan tanda jangan-fragmentasi (DF) aktif sambil mengubah ukurannya. Di Windows ping /f /l 1472 SERVER_IP, di Linux ping -M do -s 1472 SERVER_IP (1.472 adalah MTU 1.500 dikurangi header IP 20 byte dan header ICMP 8 byte). Kecilkan ukurannya bertahap untuk menemukan ukuran maksimum yang lolos, lalu pastikan security group dan firewall di sisi server mengizinkan notifikasi ICMP ukuran terlampaui (Fragmentation Needed)
Cocok jika: Ping kecil berhasil, tetapi ping DF 1.472 byte gagal (tidak ada respons atau ada error yang menyatakan perlu fragmentasi), dan ukuran maksimum yang lolos kecil, sekitar 1.400. Pemain di wilayah yang sama mengalami freeze hanya saat membuka layar besar
Tidak cocok jika: Ping DF 1.472 byte juga lancar: bukan masalah path MTU. Ping kecil pun gagal: ICMP sendiri diblokir sehingga cara ini tidak bisa dipakai untuk menilai
Sarana pemeriksaan: Lingkungan pemain sendiri

5 sumber

RFC 2923: TCP Problems with Path MTU Discovery IETF
Jika firewall memblokir ICMP (Fragmentation Needed), path MTU discovery gagal dan hanya paket besar yang terus hilang (black hole); ping dan komunikasi kecil tetap berjalan sehingga sulit didiagnosis
Maximum transmission unit and maximum segment size Cloudflare
Path MTU internet 1.500, menjadi 1.476 setelah lewat tunnel GRE; disarankan membatasi TCP MSS maksimal 1.436
IP Sysctl Linux kernel
Dengan tcp_mtu_probing=1, TCP path MTU discovery biasanya nonaktif dan baru diaktifkan saat ICMP black hole terdeteksi
ping(8) — Linux manual page iputils
-M do mengaktifkan tanda DF dan menolak paket yang lebih besar dari path MTU; -s menentukan ukuran data (default 56 byte ditambah header ICMP 8 byte)
ping Microsoft
/f mengaktifkan tanda DF untuk mencari masalah path MTU, /l menentukan ukuran data

L6 Kartu jaringan server

Interrupt NIC terpusat di satu core Single-queue NIC / no RSS

ID nic-irq · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Jika NIC hanya mengirim interrupt kedatangan paket ke satu core CPU, core itu menjadi bottleneck.

Mengapa Hanya ada satu antrean terima (RX queue), atau RSS, yang menyebar paket ke beberapa core, dimatikan → Akibatnya Satu core mencapai 100% sehingga paket tidak diambil tepat waktu → Di layar Saat pemain berkumpul, terjadi packet loss dan latensi di seluruh server (teleport, input lag)

Gejala: Teleport, Rubber banding, Input lag
Faktor: Packet loss, Latensi
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Konfigurasikan RSS (disebar oleh NIC) dan RPS (disebar oleh kernel), sebar interrupt ke beberapa core, atur agar antrean untuk UDP dibagi sampai ke port (rx-flow-hash udp4 sdfn pada ethtool -N), pisahkan core pemroses interrupt dari core thread tick game, pantau %soft per core.
Kisaran angka: Jumlah paket yang bisa diproses satu core lewat kernel kira-kira ratusan ribu paket per detik, tergantung ukuran paket dan konfigurasi. Jika di utilisasi per core porsi pemrosesan paket masuk (%soft pada mpstat) hanya menumpuk di satu core, inilah penyebabnya.
Di grafik: Mendatar di batas · %soft per core, jumlah paket diterima per detik
Yang diperiksa: Periksa %soft (persentase pemrosesan software interrupt) per core dengan mpstat -P ALL 1, lalu pastikan ke core mana interrupt setiap antrean NIC pergi dengan /proc/interrupts, jumlah antrean dengan ethtool -l, dan jumlah paket per antrean dengan ethtool -S (namanya berbeda per driver)
Cocok jika: Hanya satu core yang %soft-nya menempel di dekat 100% sementara core lain longgar, dan interrupt serta paket menumpuk di satu antrean. Sejak itu jumlah paket diterima per detik tidak bisa naik lagi
Tidak cocok jika: %soft tersebar merata di beberapa core: bukan penyebab ini. CPU longgar tetapi ada packet loss: lebih mungkin “Batas PPS cloud terlampaui” atau “Ring buffer terlalu kecil”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Walau ada beberapa antrean, jika sebagian besar trafik datang dari sedikit alamat seperti gateway atau proxy, trafik menumpuk di satu antrean. Untuk UDP, konfigurasi default NIC kadang membagi antrean hanya berdasarkan alamat, jadi harus diubah agar port juga diperhitungkan supaya trafik tersebar merata.

4 sumber

Scaling in the Linux Networking Stack Linux kernel
RSS (NIC menyebar ke beberapa antrean terima) dan RPS (kernel yang menyebar), konfigurasi yang memberi interrupt terpisah untuk setiap antrean dan membaginya ke beberapa core; jika pemrosesan interrupt terima menjadi bottleneck, disarankan RSS
How to receive a million packets per second Cloudflare
Pengukuran ketika satu antrean terima hanya diproses satu core: core itu mentok di sekitar 350.000–430.000 paket per detik; kasus NIC yang meng-hash UDP hanya dengan alamat IP sehingga trafik menumpuk di satu antrean
ethtool(8) — Linux manual page ethtool
Opsi ethtool -N rx-flow-hash udp4 untuk memasukkan port (f, n) ke hash UDP
mpstat(1) — Linux manual page sysstat
%soft: persentase waktu CPU yang dipakai untuk memproses software interrupt; per core dengan -P ALL

Ring buffer terlalu kecil RX ring buffer overflow

ID nic-ring · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Jika ring buffer, tempat NIC menampung paket sementara, terlalu kecil, buffer meluap saat paket datang serentak dan paket dibuang.

Mengapa Ring buffer kecil karena masih memakai nilai default (256–2.048 slot, tergantung driver) → Akibatnya Saat burst, buffer meluap sebelum CPU sempat mengambil paket → Di layar Packet loss hanya pada saat burst (teleport, skill tidak keluar). Tidak ada jejak di log server game

Gejala: Teleport, Aksi hilang / rollback
Faktor: Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Perbesar ring buffer (ethtool -G), pantau counter drop (rx_missed_errors dan lainnya di ethtool -S, namanya berbeda per driver).
Kisaran angka: Jika 1 juta paket per detik datang serentak, 1.024 slot penuh dalam sekitar 1 ms. Jika CPU terlambat sekali saja di sela itu, buffer meluap. Sebagian besar NIC bisa diperbesar sampai ribuan slot.
Di grafik: Melonjak acak sesekali · Counter drop terima NIC
Yang diperiksa: Kumpulkan counter drop terima di ethtool -S (rx_missed_errors, rx_fifo_errors, dan lainnya; namanya berbeda per driver) dan missed di ip -s -s link dengan interval pendek, lalu periksa ukuran ring saat ini dan nilai maksimumnya dengan ethtool -g
Cocok jika: Counter drop bertambah pada saat burst, dan ukuran ring saat ini jauh lebih kecil daripada nilai maksimum. Drop berkurang setelah ring diperbesar
Tidak cocok jika: Counter drop tidak berubah tetapi ada packet loss: mengarah ke tahap kernel berikutnya (“Buffer socket kernel terlalu kecil”) atau segmen jaringan. %soft di satu core 100%: lebih mungkin “Interrupt NIC terpusat di satu core”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

Linux Base Driver for Intel(R) Ethernet Network Connection (e1000) Linux kernel
Receive descriptor (slot ring) e1000 default 256, bisa diperbesar sampai 4.096
drivers/net/ethernet/intel/ice/ice.h (Linux v6.12) Linux kernel
Receive descriptor driver ice default 2.048, maksimal 8.160
Interface statistics Linux kernel
Paket yang dibuang perangkat karena buffer tidak cukup dihitung sebagai rx_missed_errors; statistik per driver diperiksa dengan ethtool -S
ethtool(8) — Linux manual page ethtool
-g memeriksa ukuran ring (nilai saat ini dan maksimum), -G mengubahnya, -S menampilkan statistik per driver

Interrupt coalescing berlebihan Interrupt coalescing

ID nic-coalesce · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Jika NIC mengumpulkan paket lalu memberi tahu CPU sekaligus untuk mengurangi beban CPU, paket terlambat selama waktu pengumpulan itu.

Mengapa NIC mengumpulkan paket selama waktu atau jumlah tertentu lalu memberi tahu CPU → Akibatnya Paket menunggu selama dikumpulkan → Di layar Latensi bertambah sedikit. Biasanya kecil, tetapi jika berlebihan bisa mencapai skala ms

Gejala: Input lag
Faktor: Latensi
Siapa yang mengalami: Seluruh server
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Pakai coalescing adaptif, sesuaikan nilainya agar cocok untuk server game (ethtool -C).
Kisaran angka: Biasanya puluhan hingga ratusan µs. Untuk game umumnya bisa diabaikan, tetapi jika pengaturannya berlebihan bisa membesar sampai skala ms.
Di grafik: Selalu tinggi sejak awal · Waktu pulang-pergi di dalam data center yang sama
Yang diperiksa: Periksa konfigurasi coalescing saat ini (adaptive-rx, rx-usecs, rx-frames) dengan ethtool -c, lalu bandingkan waktu pulang-pergi ping ke server lain di data center yang sama sebelum dan sesudah konfigurasi diubah
Cocok jika: rx-usecs diatur besar, ratusan µs atau lebih, dan jika nilainya diturunkan, waktu pulang-pergi di dalam data center yang sama berkurang sebanding
Tidak cocok jika: Waktu pulang-pergi tidak berubah walau nilainya diturunkan: bukan penyebab ini
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Linux Driver for Intel(R) Ethernet Network Connection (e1000e) Linux kernel
Secara default, interrupt moderation adaptif menghasilkan 4.000–20.000 interrupt per detik (interval 50–250 µs); mengurangi interrupt menghemat CPU tetapi menambah latensi
Linux Base Driver for Intel(R) Ethernet Network Connection (e1000) Linux kernel
RxIntDelay bisa menunda interrupt terima dalam satuan 1,024 µs hingga maksimal 65.535 (sekitar 67 ms); makin besar nilainya, makin besar latensi terima
ethtool(8) — Linux manual page ethtool
Pengaturan adaptive-rx, rx-usecs, dan rx-frames pada ethtool -C

Batas PPS cloud terlampaui Cloud PPS / bandwidth allowance

ID nic-cloud-pps · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)

Server cloud memiliki batas jumlah paket per detik dan bandwidth per tipe instance, dan jika terlampaui, paket dibuang diam-diam.

Mengapa Jumlah pemain online bersamaan bertambah sehingga jumlah paket per detik melewati batas instance → Akibatnya Jaringan cloud membuang kelebihannya → Di layar Teleport dan skill tidak keluar karena packet loss yang penyebabnya tidak jelas. CPU server masih longgar

Gejala: Teleport, Aksi hilang / rollback
Faktor: Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Gabungkan paket (pesan dalam satu tick dimasukkan ke satu paket), jangan terlalu sering mengirim paket yang sangat kecil.
Tugas Tim Infrastruktur: Periksa counter pelampauan batas (di AWS: pps_allowance_exceeded, conntrack_allowance_exceeded, dan lainnya) dan pasang alert, pakai instance yang lebih besar, hindari batas connection tracking dengan konfigurasi security group yang tidak memicu pelacakan.
Tugas Pihak Eksternal: Tanyakan ke penyedia cloud batas jumlah paket per detik dan batas connection tracking per tipe instance.
Kisaran angka: Batasnya berbeda per ukuran instance, dan batas jumlah paket per detik sering tidak dipublikasikan. “Hingga 10 Gbps” pada instance kecil adalah kecepatan burst yang hanya bisa dipakai selama kreditnya masih ada (biasanya 5–60 menit), sedangkan kecepatan dasar sehari-hari jauh lebih rendah.
Di grafik: Mendatar di batas · Jumlah paket per detik, counter pelampauan allowance
Yang diperiksa: Kumpulkan counter ENA pps_allowance_exceeded, bw_in_allowance_exceeded, bw_out_allowance_exceeded, dan conntrack_allowance_exceeded di ethtool -S dengan interval pendek, lalu lihat bersama jumlah paket per detik. Counter ini juga bisa dikirim ke CloudWatch lewat CloudWatch agent untuk dipasangi alert
Cocok jika: Pada saat packet loss terjadi, counter pelampauan allowance bertambah, dan jumlah paket per detik tidak bisa naik melewati nilai tertentu. CPU server masih longgar
Tidak cocok jika: Counter pelampauan tidak berubah: bukan penyebab ini. %soft di satu core 100%: lebih mungkin “Interrupt NIC terpusat di satu core”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: conntrack_allowance_exceeded menunjukkan kasus ketika tabel connection tracking penuh sehingga koneksi baru dibuang. Jika tabelnya masih longgar tetapi hanya koneksi idle yang terputus karena entri pelacakannya kedaluwarsa, lihat entri “Connection tracking di security group cloud kedaluwarsa”.

2 sumber

Monitor network performance for ENA settings on your EC2 instance AWS
Setiap instance punya batas bandwidth, PPS, dan connection tracking; jika terlampaui, paket ditampung di antrean lalu dibuang; counter pps_allowance_exceeded dan conntrack_allowance_exceeded
Amazon EC2 instance network bandwidth AWS
“Hingga N Gbps” pada instance dengan 16 vCPU atau kurang adalah burst yang memakai kredit I/O jaringan (biasanya 5–60 menit); jika kredit habis, kecepatan kembali ke bandwidth dasar

Bandwidth NIC penuh NIC bandwidth saturation

ID nic-saturate · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika kartu 1 Gbps atau 10 Gbps dipakai sampai batasnya, antrean kirim memanjang dan akhirnya paket dibuang.

Mengapa Broadcast bertambah sehingga volume kirim mencapai batas kartu → Akibatnya Antrean kirim memanjang, dan jika meluap, paket dibuang → Di layar Latensi dan packet loss di seluruh server (input lag, teleport)

Gejala: Input lag, Teleport
Faktor: Latensi, Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Kurangi volume kirim (area of interest, kompresi, kirim perubahan saja).
Tugas Tim Infrastruktur: Tingkatkan kartu (NIC yang lebih cepat, di cloud instance yang lebih besar), pasang alert utilisasi NIC.
Di grafik: Mendatar di batas · Volume kirim NIC, drop kirim
Yang diperiksa: Bandingkan txkB/s dan %ifutil (utilisasi terhadap kecepatan interface) dari sar -n DEV 1 dengan kecepatan NIC dan bandwidth instance, lalu lihat juga TX dropped di ip -s link
Cocok jika: Volume kirim mendatar di sekitar bandwidth NIC atau instance, dan sejak itu drop kirim dan latensi seluruh server bertambah
Tidak cocok jika: Bandwidth masih longgar: bukan penyebab ini. Banyak paket kecil dan ada packet loss: lebih mungkin “Batas PPS cloud terlampaui”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Interface statistics Linux kernel
tx_dropped: jumlah paket yang dibuang di tengah pengiriman karena sumber daya tidak cukup
Amazon EC2 instance network bandwidth AWS
Bandwidth yang bisa dipakai instance ditentukan oleh jumlah vCPU (ukuran instance)
sar(1) — Linux manual page sysstat
rxkB/s, txkB/s, dan %ifutil (utilisasi terhadap kecepatan interface) pada -n DEV

Overhead virtualisasi dan noisy neighbor Noisy neighbors in virtualization

ID nic-noisy · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Jika virtual machine lain di server fisik yang sama banyak memakai jaringan atau CPU, pemrosesan di server Anda tertunda secara tidak beraturan.

Mengapa Virtual machine lain di server fisik yang sama banyak memakai sumber daya → Akibatnya Pemrosesan paket di virtual machine Anda tertunda secara tidak beraturan → Di layar Tanpa penyebab yang jelas, sesekali muncul jitter (variasi selang waktu kedatangan paket) sehingga game patah-patah

Gejala: Patah-patah
Faktor: Jitter
Siapa yang mengalami: Seluruh server
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Infrastruktur: Pakai dedicated host atau instance dengan performa terjamin, hentikan lalu jalankan ulang instance yang jitter-nya terus berlanjut agar pindah ke host lain.
Tugas Pihak Eksternal: Laporkan host yang bermasalah ke penyedia cloud.
Di grafik: Melonjak acak sesekali · Jitter waktu pulang-pergi di dalam data center yang sama, %steal
Yang diperiksa: Kirim ping terus-menerus ke server lain di data center yang sama untuk mencatat jitter waktu pulang-pergi, lalu bandingkan bersama %steal dari mpstat dengan instance lain berkonfigurasi sama
Cocok jika: Hanya instance ini yang jitter waktu pulang-pergi atau %steal-nya melonjak tidak beraturan, sedangkan instance lain berkonfigurasi sama tenang. Hilang setelah instance dihentikan lalu dijalankan ulang dan pindah ke host lain
Tidak cocok jika: Semua instance berkonfigurasi sama melonjak dengan cara yang sama: bukan masalah host. Periksa beban di sisi server game atau segmen jaringan
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

2 sumber

How EC2 instance stop and start works AWS
Jika instance dihentikan lalu dijalankan lagi, sebagian besar akan dipindahkan ke host baru (kecuali dedicated host)
mpstat(1) — Linux manual page sysstat
%steal: persentase waktu vCPU ini terpaksa menunggu selama hypervisor menjalankan vCPU lain

Maintenance host cloud dan live migration Cloud host maintenance / live migration

ID nic-host-maintenance · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)

Saat penyedia cloud melakukan maintenance pada server fisik (host), virtual machine dipindahkan ke host lain (live migration) atau dihentikan sementara. Selama itu seluruh server terhenti, dan jika jedanya lama, koneksi terputus.

Mengapa Penyedia memindahkan virtual machine ke host lain atau menjedanya sementara karena maintenance host atau prediksi kerusakan → Akibatnya Selama dipindahkan, CPU, memori, dan jaringan melambat, dan di akhir proses virtual machine berhenti total sesaat (kurang dari 1 detik hingga sekitar 30 detik, tergantung penyedia dan caranya) → Di layar Semua pemain di server mengalami freeze bersamaan lalu fast forward atau teleport; jika jedanya lebih lama dari timeout, terjadi disconnect massal

Gejala: Freeze, Fast forward, Teleport, Disconnect
Faktor: Stall, Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Pakai timeout yang tahan terhadap jeda beberapa detik, batasi jumlah tick yang dikejar setelah jeda, hitung waktu yang berlalu dengan monotonic clock, siapkan prosedur untuk menyimpan progres dan memindahkan pemain ke server lain saat menerima pemberitahuan maintenance.
Tugas Tim Infrastruktur: Berlangganan pemberitahuan maintenance dan pasang alert (Google Cloud maintenance-event, AWS scheduled event dan AWS Health, Azure Scheduled Events), ganti server lebih awal di jam sepi pemain saat menerima pemberitahuan, atur waktu maintenance jika penyedia mengizinkan (Azure Maintenance Configuration, AWS scheduled event tergantung jenisnya), cocokkan catatan maintenance dengan catatan insiden.
Tugas Pihak Eksternal: Pastikan jadwal dan cakupan dampak maintenance ke penyedia cloud, laporkan jika jeda berulang di instance yang sama.
Kisaran angka: Google Compute Engine menyatakan jeda live migration biasanya jauh lebih singkat dari 1 detik, dan selama jeda, jam sistem bisa melompat maju hingga 5 detik. Nilai maintenance-event di metadata berubah 60 detik sebelum pemindahan (jika nilai ini sudah pernah di-query minimal sekali sebelumnya). Untuk maintenance yang tidak memerlukan reboot, Azure hampir selalu berhenti kurang dari 10 detik dan dalam kasus yang jarang (untuk ukuran umum maksimal sekali dalam 18 bulan) sekitar 30 detik, sedangkan live migration biasanya tidak lebih dari 5 detik. Azure Scheduled Events memberi tahu jeda seperti ini (Freeze) minimal 15 menit sebelumnya. Namun, jika hardware host tiba-tiba rusak, pemulihan langsung dimulai tanpa pemberitahuan.
Di grafik: Kosong lalu datang sekaligus · Jumlah paket kirim dan terima server, interval tick
Yang diperiksa: Cocokkan waktu jeda dengan catatan penyedia. Google Cloud: compute.instances.migrateOnHostMaintenance di audit log; AWS: scheduled event di describe-instance-status dan AWS Health; Azure: Microsoft.Compute/virtualMachines/liveMigration/action di Activity Log dan waktu ketika metrik ketersediaan VM (VmAvailabilityMetric) turun ke 0. Di dalam server, periksa apakah metrik dan log kosong selama jeda dan apakah jam melompat sesudahnya (log sinkronisasi waktu)
Cocok jika: Waktu seluruh server berhenti bertepatan dengan waktu maintenance atau migrasi yang dicatat penyedia, dan selama beberapa detik itu semua metrik dan log di dalam server kosong
Tidak cocok jika: Tidak ada di catatan penyedia dan jeda singkat sering berulang: lebih mungkin “CPU steal (virtual machine)”. Ada catatan reset NIC di log kernel: lebih mungkin “Masalah driver dan firmware NIC”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: AWS memberi tahu lewat scheduled event. system-reboot berarti instance di-reboot sambil dipindahkan ke host baru, dan system-maintenance berarti instance bisa terdampak sesaat oleh maintenance jaringan atau listrik. Walau jedanya hanya beberapa detik, klien yang tidak menerima ACK untuk paket yang dikirim ke server selama itu menggandakan waktu tunggu retransmisi berulang kali, sehingga koneksi TCP bisa tetap terhenti lebih lama walau server sudah berjalan lagi (“RTO TCP dan exponential backoff”). Setelah bangun dari jeda, jam bisa melompat dan berlanjut ke “Lompatan jam sistem (NTP step)”, dan health check load balancer bisa gagal sehingga server itu dikeluarkan sementara. Instance yang tidak bisa dipindahkan (seperti instance bare metal di Google Cloud) dihentikan atau dijalankan ulang saat maintenance.

6 sumber

Live migration process during maintenance events Google Cloud
Jeda live migration biasanya jauh lebih singkat dari 1 detik; selama jeda, jam sistem melompat maju hingga 5 detik; performa disk, CPU, memori, dan jaringan turun sementara selama pemindahan; VM yang tidak menjalani live migration dimatikan saat maintenance (instance bare metal tidak didukung)
Query metadata server for maintenance event notices Google Cloud
Nilai metadata maintenance-event berubah 60 detik sebelum live migration (jika VM diatur untuk live migration dan nilai ini sudah di-query minimal sekali sejak maintenance terakhir)
Monitor and plan for a host maintenance event Google Cloud
Saat maintenance, system event compute.instances.migrateOnHostMaintenance tercatat di audit log
Scheduled events for Amazon EC2 instances AWS
Jenis scheduled event (system-reboot: di-reboot sambil dipindahkan ke host baru; system-maintenance: terdampak sesaat oleh maintenance jaringan atau listrik), pemberitahuan lewat email dan AWS Health, diperiksa dengan describe-instance-status, waktunya bisa diatur tergantung jenisnya
Maintenance and updates Microsoft Azure
Maintenance tanpa reboot hampir selalu berhenti kurang dari 10 detik, dalam kasus yang jarang (untuk ukuran umum maksimal sekali dalam 18 bulan) sekitar 30 detik; live migration biasanya maksimal 5 detik; jam disinkronkan otomatis setelah jeda; koneksi TCP yang berumur panjang bisa terputus, atau pihak lawan mengirim ulang data yang ditujukan ke VM yang terhenti dengan exponential backoff sehingga pemulihan makin lambat; health check load balancer menilai tidak sehat dalam sekitar 10 detik; diperiksa lewat Microsoft.Compute/virtualMachines/liveMigration/action di Activity Log dan VmAvailabilityMetric yang menjadi 0 selama jeda; waktu penerapan dipilih dengan Maintenance Configuration
Scheduled Events for Linux VMs in Azure Microsoft Azure
Freeze (jeda beberapa detik, CPU dan jaringan bisa berhenti) diberitahukan minimal 15 menit sebelumnya; saat hardware host rusak, pemulihan langsung dimulai tanpa masa pemberitahuan

Masalah driver dan firmware NIC NIC hang / reset

ID nic-reset · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Selama kartu berhenti dan dimulai ulang karena bug driver atau fitur yang tidak berfungsi dengan benar, semua pengiriman dan penerimaan terputus.

Mengapa Bug driver, fitur offload tidak berfungsi dengan benar → Akibatnya NIC berhenti lalu dimulai ulang (beberapa detik) → Di layar Semua pemain di server itu mengalami freeze bersamaan lalu teleport atau disconnect

Gejala: Freeze, Disconnect
Faktor: Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Sesekali secara acak, Makin lama menyala
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Periksa catatan “transmit queue … timed out” dan “Link is Down” di log kernel dan pasang alert, update driver dan firmware, matikan fitur yang bermasalah (offload dan sebagainya).
Di grafik: Kosong lalu datang sekaligus · Jumlah paket kirim dan terima server
Yang diperiksa: Cari catatan “NETDEV WATCHDOG … transmit queue N timed out”, reset driver, serta “Link is Down” dan “Link is Up” di log kernel dengan dmesg, lalu periksa jumlah paket kirim dan terima server pada waktu itu
Cocok jika: Pada waktu jeda, ada catatan timeout antrean kirim atau link down dan up di log kernel, dan selama beberapa detik itu jumlah paket kirim dan terima 0
Tidak cocok jika: Log kernel bersih dan port di sisi switch juga normal: mengarah ke proses server game yang berhenti (“Jeda GC stop-the-world di server”, “Deadlock”) atau “Failover perangkat jaringan”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

net/sched/sch_generic.c (Linux v6.12) Linux kernel
Jika antrean kirim berhenti, watchdog kernel mencatat “NETDEV WATCHDOG … transmit queue N timed out” dan memanggil fungsi reset driver
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c (Linux v6.12) Linux kernel
Driver ixgbe me-reset adapter saat pengiriman berhenti, dan mencatat “NIC Link is Down” jika link terputus
ethtool(8) — Linux manual page ethtool
Opsi ethtool -K untuk mematikan fitur offload satu per satu

Jeda tunggu penggabungan GRO/LRO GRO/LRO batching

ID nic-offload · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Fitur ini menggabungkan beberapa paket menjadi satu untuk mengurangi beban CPU. Tergantung konfigurasinya, paket game yang kecil kadang menunggu sebentar paket berikutnya untuk digabung bersama.

Mengapa NIC atau kernel menggabungkan paket yang datang lalu memprosesnya sekaligus → Akibatnya Jika penggabungan di hardware (LRO) atau pengaturan waktu tunggu penggabungan aktif, paket menunggu sebentar paket berikutnya → Di layar Latensi bertambah sedikit (umumnya puluhan µs atau kurang)

Gejala: Input lag
Faktor: Latensi
Siapa yang mengalami: Seluruh server
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Sesuaikan dengan trafik game (matikan LRO, periksa pengaturan waktu tunggu penggabungan), periksa setelah penyebab lain karena dampaknya umumnya kecil.
Di grafik: Selalu tinggi sejak awal · Waktu pulang-pergi di dalam data center yang sama
Yang diperiksa: Periksa status lro dan gro dengan ethtool -k serta nilai gro_flush_timeout di pengaturan sysfs perangkat, lalu bandingkan waktu pulang-pergi paket kecil di dalam data center yang sama sebelum dan sesudah diubah
Cocok jika: LRO aktif atau gro_flush_timeout lebih dari 0, dan jika dimatikan atau diatur ke 0, waktu pulang-pergi paket kecil berkurang
Tidak cocok jika: Selisihnya hanya beberapa µs walau diubah: bukan penyebab ini
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

NAPI Linux kernel
Jika gro_flush_timeout diatur besar, paket diproses berkelompok, tetapi imbalannya muncul latensi saat beban rendah
Linux Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Adapters (ixgbe) Linux kernel
GRO adalah fitur yang menggabungkan trafik masuk menjadi potongan besar untuk menghemat CPU, dan merupakan pengembangan dari LRO
ethtool(8) — Linux manual page ethtool
Pengaturan gro dan lro on|off pada ethtool -K

L7 OS server (kernel)

Antrean koneksi (backlog) meluap Listen backlog / SYN queue overflow

ID so-backlog · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)

Jika puluhan ribu pemain login bersamaan tepat setelah maintenance, antrean koneksi (backlog) di kernel meluap dan upaya koneksi dibuang.

Mengapa Begitu maintenance selesai, koneksi berdatangan lebih cepat daripada kecepatan server game memprosesnya dengan accept → Akibatnya Antrean koneksi kernel (backlog, yaitu nilai yang lebih kecil antara nilai yang diberikan kode server ke listen dan batas atas kernel) penuh → Di layar Upaya koneksi dibuang dan percobaan ulang terus berulang, sehingga pemain tidak bisa masuk atau mengalami loading tanpa henti

Gejala: Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: naikkan nilai listen yang diberikan di kode, jaga agar thread yang menerima koneksi tidak tertahan oleh pekerjaan lain, gunakan sistem antrean login. Klien: perpanjang interval percobaan ulang (disebar secara acak).
Tugas Tim Infrastruktur: Naikkan somaxconn di kernel (baru efektif jika nilai listen di kode server juga dinaikkan), biarkan SYN cookie tetap aktif, pantau jumlah overflow (TcpExtListenOverflows di nstat).
Kisaran angka: Batas atas kernel Linux (somaxconn) secara default 4.096 sejak versi 5.4 (sebelumnya 128), tetapi jika kode server memberikan nilai yang lebih kecil ke listen, nilai itulah yang menjadi batasnya. Saat antrean penuh, Linux membuang permintaan koneksi diam-diam tanpa error. OS klien mengirim ulang permintaan beberapa kali mulai 1 detik kemudian, sehingga yang dilihat pemain adalah loading yang lama, tanpa pesan “Koneksi gagal”. Server Windows mengirim balik respons penolakan, sehingga klien langsung melihat “Koneksi gagal”.
Di grafik: Melonjak tepat setelah server dibuka · Jumlah overflow antrean koneksi (ListenOverflows), jumlah upaya koneksi
Yang diperiksa: Periksa kenaikan TcpExtListenOverflows dan TcpExtListenDrops di nstat -az, lalu dengan ss -ltn bandingkan Recv-Q (jumlah koneksi yang menunggu accept) dan Send-Q (batas backlog) pada socket listen
Cocok jika: ListenOverflows naik saat koneksi membanjir, dan Recv-Q socket listen menempel di nilai Send-Q
Tidak cocok jika: ListenOverflows tidak berubah: bukan penyebab ini. Koneksi sudah terbentuk tetapi loading tidak selesai: lebih mungkin “Lonjakan login dan N+1 query”. Tertahan tepat di jumlah pemain tertentu: lebih mungkin “Batas file descriptor”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

5 sumber

listen(2) — Linux manual page Linux man-pages
backlog pada listen dipotong diam-diam jika melebihi somaxconn; somaxconn default 4.096 (sejak 5.4, sebelumnya 128); saat antrean penuh, permintaan bisa diabaikan dan diserahkan ke percobaan ulang klien
IP Sysctl Linux kernel
tcp_syn_retries: permintaan koneksi (SYN) dikirim ulang beberapa kali dengan jeda retransmisi pertama 1 detik; tcp_abort_on_overflow default nonaktif (tidak ada respons penolakan walaupun antrean meluap); tcp_syncookies default aktif
listen function (winsock2.h) Microsoft
Di Windows, jika antrean penuh, klien menerima error WSAECONNREFUSED
SNMP counter Linux kernel
TcpExtListenOverflows: jumlah permintaan koneksi (SYN) yang dibuang karena antrean accept penuh; saat itu TcpExtListenDrops juga ikut naik
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK

Batas file descriptor File descriptor limit (ulimit)

ID so-fd · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Setiap koneksi membutuhkan satu file descriptor (fd, nomor yang diberikan OS untuk file dan socket yang terbuka), dan jumlah fd yang bisa dibuka oleh satu proses dibatasi.

Mengapa Jumlah pemain online bersamaan mencapai batas file descriptor proses → Akibatnya Server tidak bisa menerima koneksi baru (Too many open files). Membuka file log dan koneksi DB juga ikut gagal → Di layar Begitu jumlah pemain mencapai angka tertentu, tidak ada lagi yang bisa masuk: pemain baru gagal masuk atau terjebak loading tanpa henti

Gejala: Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Tepat setelah login atau maintenance, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Tutup socket dengan pasti saat koneksi diakhiri (mencegah kebocoran fd), jika accept gagal dengan EMFILE (fd habis) hentikan sementara penerimaan koneksi atau terima koneksi dengan fd cadangan yang sudah disisihkan lalu langsung tutup (agar CPU tidak terbuang untuk memproses notifikasi koneksi yang sama berulang-ulang).
Tugas Tim Infrastruktur: Periksa ulimit dan konfigurasi service (LimitNOFILE di systemd), pasang alert saat mendekati batas.
Kisaran angka: Di Linux, jika service tidak dikonfigurasi khusus, batasnya masih sering 1.024. Server game biasanya menaikkannya ke puluhan ribu hingga ratusan ribu. Windows tidak punya batas default serendah ini.
Di grafik: Mendatar di batas · Jumlah fd terbuka pada proses, jumlah koneksi bersamaan
Yang diperiksa: Periksa fd-nr (jumlah file descriptor yang terbuka) proses server game dengan pidstat -v dan batas jumlah file terbuka di /proc/PID/limits, lalu cari kegagalan accept (EMFILE, Too many open files) di log server
Cocok jika: Jumlah fd mendatar di nilai batas, dan sejak saat itu accept gagal dengan EMFILE
Tidak cocok jika: Jumlah fd masih jauh di bawah batas: bukan penyebab ini. Permintaan koneksi dibuang di kernel: lebih mungkin “Antrean koneksi (backlog) meluap”. Masalahnya di connection tracking: lebih mungkin “Tabel conntrack server penuh”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Koneksi yang tidak diterima tetap tertinggal di antrean koneksi (backlog) kernel. Akibatnya, tergantung kodenya, server bisa terus menerima notifikasi “ada koneksi baru” dan membuang-buang CPU.

5 sumber

systemd-system.conf(5) — Linux manual page systemd
Nilai default DefaultLimitNOFILE untuk service adalah 1024:524288 (soft limit 1.024)
accept(2) — Linux manual page Linux man-pages
Saat batas fd proses tercapai, accept gagal dengan EMFILE
Maximum Number of Sockets Supported Microsoft
Winsock di Windows membatasi jumlah socket hanya berdasarkan memori yang tersedia
pidstat(1) — Linux manual page sysstat
fd-nr pada -v: jumlah file descriptor yang dibuka proses
proc_pid_limits(5) — Linux manual page Linux man-pages
/proc/PID/limits berisi nilai soft dan hard batas sumber daya per proses

Buffer socket kernel terlalu kecil Small socket buffers

ID so-sockbuf · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika buffer kirim dan buffer terima kecil, saat burst trafik datang paket yang diterima lewat UDP dibuang, dan pengiriman TCP tertahan karena buffer tidak punya ruang.

Mengapa SO_SNDBUF dan SO_RCVBUF masih default atau terlalu kecil → Akibatnya Saat burst atau saat thread penerima tertahan sebentar, buffer terima UDP meluap dan paket dibuang; TCP menunggu karena buffer kirim tidak punya ruang → Di layar Teleport (packet loss UDP) atau fast forward (TCP menunggu)

Gejala: Teleport, Fast forward
Faktor: Packet loss, Stall
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Atur ukuran buffer (SO_SNDBUF, SO_RCVBUF) di kode sesuai trafik, ingat bahwa untuk TCP menetapkan ukuran secara manual mematikan auto-tuning Linux, jangan pakai ukuran terlalu besar karena data lama menumpuk di buffer dan latensi bertambah, jaga agar thread penerima tidak tertahan.
Tugas Tim Infrastruktur: Sesuaikan batas atas kernel (rmem_max dan wmem_max; ukuran buffer yang diatur di kode juga tidak bisa melewati nilai ini) dan nilai default (rmem_default), pantau counter buffer meluap (RcvbufErrors).
Kisaran angka: Default buffer terima UDP di Linux sekitar 208 KB. Satu paket kecil pun memakan memori kernel jauh lebih besar dari ukuran aslinya, jadi puluhan hingga ratusan paket sudah cukup untuk memenuhinya. Di server yang menerima 100.000 paket per detik, buffer meluap walaupun thread penerima hanya tertahan beberapa ms.
Di grafik: Melonjak acak sesekali · Buffer terima UDP meluap (UdpRcvbufErrors)
Yang diperiksa: Periksa kenaikan UdpRcvbufErrors di nstat -az dan skmem di ss -uamn (rb adalah ukuran buffer terima, d adalah jumlah paket yang dibuang karena tidak bisa dimasukkan ke socket). Untuk TCP, periksa skmem di ss -tm, apakah memori antrean kirim (w) sudah mencapai ukuran buffer kirim (tb)
Cocok jika: UdpRcvbufErrors (atau d pada socket) naik saat burst atau saat thread penerima tertahan, dan rb di sekitar nilai default (kira-kira 208 KB). Untuk TCP, w menempel di tb dan send tertahan
Tidak cocok jika: Counter tidak berubah tetapi ada packet loss: lebih mungkin di tahap NIC (“Ring buffer terlalu kecil”) atau di jalur jaringan
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

6 sumber

socket(7) — Linux manual page Linux man-pages
Default SO_RCVBUF dan SO_SNDBUF adalah rmem_default dan wmem_default, batas atasnya rmem_max dan wmem_max; kernel menggandakan nilai yang diatur
include/net/sock.h (Linux v6.18) Linux kernel
Buffer socket default didefinisikan sebesar 256 paket berukuran 256 byte termasuk overhead sk_buff (SKB_TRUESIZE(256)×256); frame kecil pun dihitung sebesar sk_buff+MTU (sekitar 208 KB adalah hasil hitungan untuk x86-64)
IP Sysctl Linux kernel
tcp_rmem dan tcp_wmem: jika SO_RCVBUF dan SO_SNDBUF ditetapkan langsung, auto-tuning ukuran untuk socket itu mati
net/ipv4/udp.c (Linux v6.12) Linux kernel
Jika antrean terima UDP melebihi ukuran buffer socket, paket langsung dibuang dan RcvbufErrors naik
net/ipv4/proc.c (Linux v6.12) Linux kernel
Nama counter yang ditampilkan nstat: RcvbufErrors dan SndbufErrors di grup Udp
ss(8) — Linux manual page iproute2
skmem pada -m: rb ukuran buffer terima, tb ukuran buffer kirim, w memori antrean kirim, d jumlah paket yang dibuang sebelum masuk ke socket

Thread berlebihan dan context switching Thread oversubscription, context switching

ID so-context · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika jumlah thread jauh melebihi jumlah core, OS menghabiskan CPU hanya untuk menjalankan thread-thread itu secara bergiliran.

Mengapa Ada ratusan hingga ribuan thread, misalnya karena setiap koneksi dibuatkan thread sendiri → Akibatnya Biaya context switching (pergantian thread yang berjalan) dan cache miss meningkat → Di layar CPU sibuk tetapi throughput rendah dan tick tidak beraturan, sehingga terjadi patah-patah atau slow motion

Gejala: Patah-patah, Slow motion
Faktor: Stall, Jitter
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Sesuaikan jumlah thread dengan jumlah core, gunakan I/O asinkron (epoll, IOCP).
Tugas Tim Infrastruktur: Pantau jumlah context switching dan jumlah thread yang menunggu dijalankan (cs dan r di vmstat).
Kisaran angka: Satu kali context switching memakan beberapa µs, dan menjadi lebih besar jika ditambah biaya cache miss sesudahnya.
Di grafik: Naik mengikuti beban · Jumlah context switching per detik, jumlah thread yang menunggu dijalankan
Yang diperiksa: Bandingkan cs (context switching per detik) dan r (jumlah yang sedang berjalan atau menunggu CPU) di vmstat 1 dengan jumlah core, lalu periksa context switching voluntary (cswch/s) dan involuntary (nvcswch/s) per thread server game dengan pidstat -w -t
Cocok jika: Saat jumlah pemain online bertambah, r naik jauh melebihi jumlah core dan cs ikut melonjak, serta ada ratusan thread dengan banyak context switching involuntary
Tidak cocok jika: r tetap sama dengan atau di bawah jumlah core: bukan penyebab ini. Hanya context switching voluntary yang banyak: thread sedang menunggu lock atau I/O (“Perebutan lock”, “Arsitektur I/O blocking”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

Quantifying The Cost of Context Switch (ExpCS 2007) ACM
Biaya langsung context switching sekitar 3,8 µs; biaya tidak langsung termasuk efek cache berkisar dari beberapa µs hingga lebih dari 1.000 µs (sesuai lingkungan pengukuran)
vmstat(8) — Linux manual page procps-ng
Kolom cs (jumlah context switching per detik) dan r (jumlah proses yang sedang berjalan atau menunggu dijalankan)
I/O Completion Ports Microsoft
Memproses banyak I/O asinkron dengan thread pool yang dibuat lebih dulu dan IOCP, serta menyesuaikan jumlah thread yang berjalan bersamaan dengan konkurensi CPU
pidstat(1) — Linux manual page sysstat
cswch/s pada -w adalah context switching voluntary (thread berhenti sendiri karena menunggu sumber daya), nvcswch/s adalah context switching involuntary (dipaksa berganti karena time slice habis), -t untuk melihat per thread

CPU steal (virtual machine) CPU steal time

ID so-steal · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Server game berhenti selama server fisik (hypervisor) sementara memberikan waktu CPU milik virtual machine ini ke virtual machine lain (CPU steal).

Mengapa Virtual machine lain di host yang sama memakai banyak CPU → Akibatnya Virtual machine server game kehilangan jatah eksekusi selama beberapa hingga puluhan ms setiap kali → Di layar Waktu tick melonjak tanpa sebab yang jelas, sehingga terjadi patah-patah atau freeze

Gejala: Patah-patah, Freeze
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Infrastruktur: Pantau metrik steal (st di top dan vmstat), gunakan core atau host khusus (dedicated), hindari instance burstable yang melambat saat kredit CPU habis, hentikan lalu jalankan lagi instance yang steal-nya terus tinggi agar pindah ke host lain.
Tugas Pihak Eksternal: Laporkan ke penyedia cloud host yang steal-nya terus tinggi.
Di grafik: Melonjak acak sesekali · %steal, waktu tick server
Yang diperiksa: Tampilkan %steal dari mpstat -P ALL 1 pada sumbu waktu yang sama dengan waktu tick server
Cocok jika: %steal ikut melonjak saat tick melonjak, dan turun setelah instance dihentikan lalu dijalankan lagi sehingga pindah ke host lain
Tidak cocok jika: %steal mendekati 0 tetapi tick tetap melonjak: penyebabnya di dalam server game (“Jeda GC stop-the-world di server”, “Perebutan lock”). Jika memakai container: lebih mungkin “CPU throttling di container (kuota CFS)”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

proc_stat(5) — Linux manual page Linux man-pages
steal: waktu yang direbut karena sistem operasi lain sedang berjalan di lingkungan virtualisasi
Standard mode for burstable performance instances AWS
Instance burstable memakai kredit untuk melampaui performa dasar (baseline), dan saat kredit habis, utilisasi CPU turun ke tingkat baseline
How EC2 instance stop and start works AWS
Jika instance dihentikan lalu dijalankan lagi, sebagian besar akan dipindahkan ke host baru
mpstat(1) — Linux manual page sysstat
%steal: persentase waktu vCPU ini terpaksa menunggu selama hypervisor menjalankan vCPU lain

CPU throttling di container (kuota CFS) Container CPU throttling (CFS quota)

ID so-cpu-quota · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika container diberi batas CPU, begitu kuota dalam satu periode (biasanya 100 ms) habis, container dipaksa berhenti selama sisa periode itu (throttling).

Mengapa Batas CPU (limit) dipasang pada container server game, misalnya di Kubernetes → Akibatnya Saat perhitungan tick menumpuk, kuota habis dan proses berhenti puluhan ms sampai periode berikutnya → Di layar Rata-rata CPU rendah tetapi tick melonjak secara berkala, sehingga terjadi patah-patah atau slow motion

Gejala: Patah-patah, Slow motion
Faktor: Stall, Jitter
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Sesuaikan jumlah worker thread dengan batas CPU (agar runtime tidak membuat thread sebanyak seluruh core host).
Tugas Tim Infrastruktur: Beri batas CPU yang longgar atau hapus batasnya dan alokasikan core khusus, pantau jumlah throttling (nr_throttled).
Kisaran angka: Pada server dengan batas 2 core, jika 8 thread bekerja bersamaan, kuota periode 100 ms habis dalam 25 ms dan proses berhenti selama 75 ms.
Di grafik: Naik mengikuti beban · Jumlah throttling (nr_throttled), waktu tick server
Yang diperiksa: Periksa kenaikan nr_throttled dan throttled_usec (di cgroup v1: nr_throttled dan throttled_time) di cpu.stat cgroup container bersama waktu tick server
Cocok jika: Rata-rata utilisasi CPU di bawah batas, tetapi nr_throttled dan throttled_usec terus naik dan waktunya bertepatan dengan lonjakan tick
Tidak cocok jika: nr_throttled tidak naik: bukan penyebab ini. Virtual machine itu sendiri yang tertahan: lebih mungkin “CPU steal (virtual machine)”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

CFS Bandwidth Control Linux kernel
Jika kuota yang diterima di setiap periode habis, thread berhenti sampai periode berikutnya (throttling); periode default 100 ms; statistik nr_throttled
Control Group v2 Linux kernel
cpu.max berformat “$MAX $PERIOD” (kuota, periode), dengan nilai default “max 100000” (periode 100 ms)
Resource Management for Pods and Containers Kubernetes
CPU limit pada container adalah batas keras (hard limit) yang ditegakkan kernel melalui CPU throttling

Lonjakan latensi akibat manajemen daya server (C-state, pengaturan frekuensi) CPU power management latency (C-states, frequency scaling)

ID so-cstate · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Core CPU yang sedang menganggur masuk ke mode hemat daya yang dalam (C-state) dan menurunkan frekuensinya untuk menghemat listrik. Saat paket atau timer datang, core butuh waktu untuk bangun dan menaikkan frekuensi, sehingga pemrosesan paket kecil mendapat tambahan latensi.

Mengapa Kebijakan pengaturan frekuensi OS (governor) atau pengaturan daya BIOS mengizinkan C-state yang dalam dan frekuensi rendah → Akibatnya Setiap kali core yang menganggur bangun dari mode hemat daya yang dalam, ada keterlambatan hingga ratusan µs; jika frekuensi tertahan rendah, perhitungan tick itu sendiri menjadi lambat → Di layar Biasanya sulit dirasakan, tetapi jika pemanggilan antarserver banyak, keterlambatan menumpuk dan muncul input lag yang justru terjadi saat server sepi. Jika frekuensi tertahan rendah, tick tertinggal saat pemain ramai dan terjadi slow motion

Gejala: Input lag, Slow motion
Faktor: Latensi, Jitter, Stall
Siapa yang mengalami: Seluruh server
Kapan: Selalu, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Atur daya BIOS ke mode performa, set governor OS ke performance (scaling_governor di cpufreq), batasi C-state yang dalam pada server yang peka latensi (profil tuned latency-performance, /dev/cpu_dma_latency di PM QoS, parameter kernel intel_idle.max_cstate), setelah diubah bandingkan waktu pulang-pergi di dalam data center yang sama, jitter waktu tick, dan pemakaian daya.
Kisaran angka: Menurut tabel driver intel_idle di Linux 6.12, C1 yang dangkal pada CPU server Intel butuh 1–2 µs untuk bangun, sedangkan C6 yang dalam butuh 133 µs (Skylake-SP) hingga 290 µs (Sapphire Rapids). Sekali saja memang kecil, tetapi jika satu permintaan melewati beberapa server, keterlambatan itu menumpuk sebanyak jumlah servernya. Kernel memilih state yang makin dalam jika waktu idle yang diperkirakan makin panjang, jadi gejala ini lebih sering muncul di server sepi yang paketnya datang jarang-jarang. Governor powersave pada cpufreq umum mengunci frekuensi di nilai terendah dalam rentang yang diizinkan (algoritma intel_pstate dengan nama yang sama mengatur frekuensi sesuai beban).
Di grafik: Selalu tinggi sejak awal · Waktu pulang-pergi di dalam data center yang sama, frekuensi core
Yang diperiksa: Periksa persentase waktu di setiap C-state per core dan frekuensi sebenarnya dengan cpupower monitor, lalu periksa name, latency (µs yang dibutuhkan untuk bangun), dan usage tiap state di bawah /sys/devices/system/cpu/cpu0/cpuidle/, scaling_governor di cpufreq, serta profil aktif dengan tuned-adm active
Cocok jika: Saat sepi, core lama berada di C-state terdalam atau frekuensinya tertahan di dekat nilai terendah, dan setelah diganti ke governor performance dan C-state dangkal, waktu pulang-pergi dan jitter permintaan kecil berkurang
Tidak cocok jika: Setelah diubah selisihnya hanya puluhan µs atau kurang: penyebab ini bisa diabaikan. Melonjak dalam satuan ms: lebih mungkin “CPU steal (virtual machine)” atau lapisan lain
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Untuk server bare metal di data center, periksa pengaturan daya BIOS (firmware) bersama pengaturan OS. Di cloud, hanya sebagian jenis instance yang mengizinkan OS mengubah C-state dan frekuensi; di AWS, pengaturan default mengutamakan performa maksimum, jadi sebagian besar bisa dibiarkan apa adanya. Profil tuned latency-performance di keluarga Red Hat menetapkan governor ke performance dan memakai PM QoS agar hanya C-state dangkal yang dipakai. Mematikan fitur hemat daya menaikkan konsumsi listrik, jadi terapkan hanya pada server yang peka terhadap latensi.

7 sumber

CPU Idle Time Management Linux kernel
Setiap mode hemat daya punya waktu bangun (exit latency) dan waktu tinggal minimum (target residency), dan state yang dalam dipilih sesuai waktu idle yang diperkirakan; latency, usage, dan time per state ada di sysfs; state yang dalam dibatasi dengan PM QoS (/dev/cpu_dma_latency) dan intel_idle.max_cstate
drivers/idle/intel_idle.c (Linux v6.12) Linux kernel
Waktu bangun per C-state pada CPU server Intel: Skylake-SP C1 2 µs, C1E 10 µs, C6 133 µs; Ice Lake C6 170 µs; Sapphire Rapids C1 1 µs, C6 290 µs
CPU Performance Scaling Linux kernel
Periksa dan ubah governor dengan scaling_governor; performance meminta frekuensi tertinggi dalam rentang yang diizinkan, powersave meminta frekuensi terendah
intel_pstate CPU Performance Scaling Driver Linux kernel
Algoritma powersave pada intel_pstate berbeda dari governor powersave umum karena mengatur frekuensi sesuai beban (mirip schedutil dan ondemand)
Chapter 2. Getting started with TuneD Red Hat
Profil latency-performance mematikan fitur hemat daya, menetapkan governor ke performance, dan memakai PM QoS agar hanya C-state dangkal yang dipakai; profil aktif diperiksa dengan tuned-adm active
tools/power/cpupower/man/cpupower-monitor.1 (Linux v6.12) Linux kernel
cpupower monitor: statistik frekuensi dan mode hemat daya per core
Processor state control for Amazon EC2 Linux instances AWS
Hanya sebagian jenis instance yang mengizinkan OS mengontrol C-state dan P-state, dan keduanya bisa diubah untuk menurunkan latensi; pengaturan default adalah performa maksimum sehingga cocok untuk sebagian besar beban kerja; Graviton memakai frekuensi tetap sehingga OS tidak mengontrolnya

OOM killer Out-of-memory killer

ID so-oom · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Saat memori habis, Linux memilih proses yang memakai memori paling banyak lalu mematikannya secara paksa. Biasanya proses itu adalah server game.

Mengapa Memori habis karena kebocoran atau lonjakan pemakaian, atau batas memori container tercapai → Akibatnya Kernel menghentikan paksa proses server game → Di layar Semua pemain di server itu disconnect bersamaan, dan progres terakhir bisa hilang karena rollback

Gejala: Disconnect, Aksi hilang / rollback
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Makin lama menyala, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Perbaiki kebocoran, tetapkan batas atas pemakaian memori dan siapkan prosedur untuk menyimpan data lalu mematikan server secara normal saat batas itu mendekat.
Tugas Tim Infrastruktur: Pasang alert memori, atur batas memori container sesuai pemakaian sebenarnya, sesuaikan urutan proses yang dimatikan lebih dulu (oom_score_adj).
Kisaran angka: Log kernel (dmesg) mencatat “Out of memory: Killed process”, dan di Kubernetes terlihat sebagai OOMKilled. Windows tidak punya OOM killer; yang sering terjadi adalah alokasi memori gagal lalu server mati karena error.
Di grafik: Koneksi putus serentak · Jumlah koneksi, pemakaian memori
Yang diperiksa: Cocokkan catatan “Out of memory: Killed process” di dmesg, status OOMKilled pada pod (di Kubernetes), atau kenaikan oom_kill di memory.events (di cgroup v2) dengan waktu koneksi terputus
Cocok jika: Pada waktu koneksi putus serentak, ada catatan proses server game dimatikan, dan sampai sesaat sebelumnya pemakaian memori naik hingga batas
Tidak cocok jika: Tidak ada catatan OOM tetapi prosesnya mati: periksa log crash dan core dump yang dibahas di “Crash di server”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

mm/oom_kill.c (Linux v6.12) Linux kernel
Skor dihitung sehingga proses yang memakai memori paling banyak mendapat skor tertinggi (oom_score_adj ikut diperhitungkan), dan saat mematikan proses dicatat “Out of memory: Killed process …”
Assign Memory Resources to Containers and Pods Kubernetes
Jika container terus memakai memori melebihi limit, container dihentikan dan statusnya ditampilkan sebagai OOMKilled
Pushing the Limits of Windows: Virtual Memory Microsoft
Di Windows, saat commit limit tercapai, alokasi yang meng-commit memori gagal, dan ini bisa berujung pada error aplikasi atau gangguan sistem
Control Group v2 Linux kernel
oom_kill di memory.events: jumlah proses yang dimatikan OOM killer di cgroup ini

Jeda akibat reclaim dan compaction memori Memory compaction / reclaim stalls (THP)

ID so-reclaim · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Proses berhenti selama OS memadatkan memori (compaction) untuk membuat halaman besar (huge page) atau mengambil kembali memori (reclaim) agar tersedia ruang kosong.

Mengapa Memori kosong menipis, atau fitur halaman besar (THP) menjalankan compaction memori → Akibatnya Thread yang meminta memori menunggu sampai reclaim dan compaction selesai → Di layar Server berhenti secara tidak teratur (beberapa ms hingga ratusan ms)

Gejala: Freeze, Patah-patah
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Makin lama menyala, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Kurangi alokasi memori besar saat server berjalan (alokasikan lebih dulu saat startup lalu pakai ulang).
Tugas Tim Infrastruktur: Atur halaman besar (THP) agar hanya dipakai di tempat yang membutuhkannya (madvise), naikkan batas memori kosong (vm.min_free_kbytes dan lainnya).
Di grafik: Melonjak acak sesekali · Waktu tick server, PSI memori
Yang diperiksa: Periksa some dan full di /proc/pressure/memory (persentase waktu berhenti karena menunggu memori) serta kenaikan compact_stall di /proc/vmstat bersama waktu tick server, lalu periksa pengaturan /sys/kernel/mm/transparent_hugepage/defrag
Cocok jika: PSI memori naik dan compact_stall bertambah saat tick melonjak. defrag bernilai always
Tidak cocok jika: PSI dan compact_stall tidak berubah: bukan penyebab ini. Pemakaian swap naik: lebih mungkin “Swap”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Transparent Hugepage Support Linux kernel
Jika defrag=always, saat alokasi THP gagal, reclaim dan compaction memori dilakukan saat itu juga sehingga proses berhenti; madvise hanya melakukannya untuk area yang memintanya
Documentation for /proc/sys/vm/ Linux kernel
min_free_kbytes: batas memori kosong minimum (watermark) yang disisakan kernel
PSI - Pressure Stall Information Linux kernel
some (persentase waktu sebagian tugas berhenti karena menunggu memori) dan full (persentase waktu semua tugas berhenti) di /proc/pressure/memory

Lompatan jam sistem (NTP step) Wall-clock jump (NTP step)

ID so-timejump · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika jam server disesuaikan beberapa detik maju atau mundur sekaligus, timer yang bergantung pada jam sistem terpicu bersamaan atau berhenti.

Mengapa Sinkronisasi waktu menggeser jam dalam jumlah besar sekaligus → Akibatnya Timer terpicu bertumpuk atau berhenti, dan timeout dinilai keliru → Di layar Buff dan cooldown kacau, disconnect serentak, fast forward

Gejala: Fast forward, Disconnect, Aksi hilang / rollback
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Hitung waktu berlalu, timeout, dan cooldown dengan monotonic clock yang tidak melompat atau mundur, pakai wall clock hanya untuk tampilan dan pencatatan.
Tugas Tim Infrastruktur: Sesuaikan jam secara perlahan (makestep di chrony hanya tepat setelah dinyalakan), pantau status sinkronisasi waktu (selisih jam).
Kisaran angka: ntpd langsung menyamakan jam sekaligus jika selisihnya lebih dari 0,128 detik; jika lebih kecil, jam disesuaikan perlahan dengan kecepatan yang butuh lebih dari 30 menit untuk menghapus selisih 1 detik. chrony, yang kini banyak dipakai, dengan pengaturan yang disarankan (makestep) hanya menyamakan sekaligus beberapa kali tepat setelah dinyalakan, lalu menyesuaikan perlahan sesudahnya. Jam juga melompat saat virtual machine berhenti sebentar lalu berjalan lagi.
Di grafik: Melonjak acak sesekali · Jumlah timer terpicu dan jumlah disconnect, catatan penyesuaian jam
Yang diperiksa: Cari catatan penyesuaian jam yang besar sekaligus di log layanan sinkronisasi waktu, lalu cocokkan dengan waktu terjadinya anomali. chrony mencatat ke syslog jika penyesuaian lebih besar dari nilai logchange (default 1 detik)
Cocok jika: Ada catatan penyesuaian jam pada waktu buff dan cooldown kacau, disconnect serentak, atau fast forward terjadi, dan besar penyesuaiannya mirip dengan besar anomali
Tidak cocok jika: Tidak ada catatan penyesuaian jam: bukan penyebab ini. Jika memakai virtual machine, periksa juga kemungkinan VM berhenti lalu berjalan lagi (“Maintenance host cloud dan live migration”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

ntpd - Network Time Protocol (NTP) daemon Network Time Foundation
Jika selisih melewati ambang step 128 ms, jam disamakan sekaligus; jika lebih kecil, disesuaikan perlahan dengan kecepatan 0,5 ms per detik, sehingga menyamakan 1 detik butuh 2.000 detik (sekitar 33 menit)
chrony – Frequently Asked Questions chrony
Disarankan hanya mengizinkan step beberapa kali tepat setelah start, seperti makestep 1 3; virtual machine yang berhenti lalu dilanjutkan bisa bangun dengan jam yang sudah meleset
clock_gettime(2) — Linux manual page Linux man-pages
CLOCK_MONOTONIC tidak terpengaruh lompatan tidak kontinu pada jam sistem dan tidak berjalan mundur
chrony.conf(5) chrony
logchange: jika jam disesuaikan lebih besar dari nilai ini (default 1 detik), penyesuaian dicatat ke syslog

Tugas terjadwal Cron jobs (log rotation, backup, scans)

ID so-cron · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Kompresi log, backup, dan pemindaian keamanan yang berjalan pada jam yang sama setiap hari menyita CPU dan disk.

Mengapa Tugas OS dijalankan pada waktu yang sudah ditentukan → Akibatnya Server game harus berbagi CPU dan disk dengan tugas tersebut → Di layar Patah-patah atau slow motion pada waktu tertentu, misalnya setiap pukul 04.00 dini hari

Gejala: Patah-patah, Slow motion
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Secara berkala
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Sebar waktu eksekusi tugas, turunkan prioritasnya (nice, ionice), pisahkan dari server game (jalankan di server terpisah).
Di grafik: Melonjak secara berkala · Utilisasi CPU, antrean disk, waktu tick server
Yang diperiksa: Kumpulkan waktu eksekusi tugas terjadwal dari crontab dan systemctl list-timers, lalu pada waktu tick melonjak periksa proses mana yang memakai CPU dan disk dengan pidstat -u -d
Cocok jika: Tick melonjak di jam yang sama setiap hari (atau setiap jam), dan pada saat itu proses tugas terjadwal menyita CPU dan disk
Tidak cocok jika: Waktu lonjakan tidak cocok dengan jam yang sama setiap hari: bukan penyebab ini. Melonjak dengan interval beberapa detik atau beberapa menit: lebih mungkin “Jeda GC stop-the-world di server” atau “Timer terpicu serentak”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

ionice(1) — Linux manual page util-linux
Tugas dengan kelas idle hanya mendapat I/O saat program lain tidak memakai disk
systemd.timer(5) — Linux manual page systemd
RandomizedDelaySec menunda waktu tugas terjadwal secara acak untuk mengurangi penumpukan beban
systemctl(1) — Linux manual page systemd
list-timers: menampilkan unit timer menurut urutan waktu eksekusi berikutnya
pidstat(1) — Linux manual page sysstat
-u menampilkan CPU, -d menampilkan I/O disk per proses

Perubahan performa setelah update OS, kernel, driver, atau firmware Performance regression after OS / kernel / driver / firmware update

ID so-os-update · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Kode game tidak berubah, tetapi server menjadi lambat sejak OS, kernel, driver, atau firmware server diperbarui. Update bisa mengubah nilai default, scheduler, mitigasi kerentanan CPU (mitigations), dan perilaku driver.

Mengapa Kernel, driver, atau firmware berubah karena patch keamanan rutin atau image server baru → Akibatnya Nilai default atau scheduler berubah, atau mitigasi kerentanan baru aktif, sehingga pekerjaan yang sama butuh waktu CPU lebih banyak dan urutan thread mendapat jatah CPU berubah → Di layar Server yang tadinya lancar selalu sedikit lebih lambat sejak hari update, sehingga terjadi input lag, dan saat pemain ramai terjadi patah-patah atau slow motion

Gejala: Input lag, Patah-patah, Slow motion
Faktor: Latensi, Stall, Jitter
Siapa yang mengalami: Seluruh server
Kapan: Selalu, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Terapkan update ke sebagian server lebih dulu dan bandingkan waktu tick, latensi, dan utilisasi CPU dengan versi sebelumnya sebelum diperluas, deploy di hari yang berbeda dari patch game, catat versi kernel, driver, dan firmware serta nilai sysctl penting sebelum dan sesudah update, jika muncul masalah boot dengan kernel sebelumnya untuk memastikan, putuskan pengaturan yang mematikan mitigasi (mitigations=off) setelah menimbang risiko keamanannya.
Kisaran angka: Jika versi kernel berubah, perilaku default juga berubah. Misalnya, sejak 6.6 Linux mulai beralih dari scheduler CFS ke EEVDF, dan nilai default batas antrean koneksi (somaxconn) berubah dari 128 menjadi 4.096 sejak 5.4. Mitigasi kerentanan CPU menambah pekerjaan, misalnya mengosongkan buffer internal CPU saat kembali dari kernel ke program (setiap kali system call selesai) serta saat context switching dan peralihan virtual machine. Akibatnya, server jaringan yang memanggil system call untuk setiap paket lebih terpengaruh. Untuk menutup sebagian kerentanan secara penuh, SMT (fitur yang membuat satu core bekerja seperti dua thread) harus dimatikan, dan mematikan SMT bisa menurunkan performa secara drastis tergantung beban kerjanya. Parameter kernel mitigations=off mematikan semua mitigasi ini sehingga performa kembali, tetapi server terbuka terhadap kerentanan.
Di grafik: Naik seperti anak tangga · Waktu tick server, utilisasi CPU, latensi pada beban yang sama
Yang diperiksa: Cocokkan riwayat update di package manager dan waktu reboot, versi kernel dari uname -r, serta informasi driver NIC dari ethtool -i dengan waktu latensi naik. Bandingkan server yang sudah dan belum diperbarui pada beban yang sama dengan mpstat dan pidstat, lalu bandingkan juga status mitigasi di /sys/devices/system/cpu/vulnerabilities/
Cocok jika: Latensi dan utilisasi CPU naik satu tingkat sejak reboot setelah update lalu tetap di sana, dan pada beban yang sama hanya server yang sudah diperbarui yang tinggi. Kembali normal jika boot dengan kernel atau driver sebelumnya
Tidak cocok jika: Server yang sudah dan belum diperbarui sama lambatnya pada beban yang sama: bukan penyebab ini. Patch game juga dirilis di hari yang sama dan jumlah atau ukuran paket per pemain berubah: lebih mungkin “Pola trafik berubah akibat patch”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Status mitigasi diperiksa di file-file di bawah /sys/devices/system/cpu/vulnerabilities/. Nilai default (mitigations=auto) melakukan mitigasi dengan SMT tetap aktif, tetapi dengan auto,nosmt SMT dimatikan pada CPU yang rentan, sehingga setelah kernel diperbarui jumlah core logis bisa berkurang setengah. Jika OS diperbarui di hari yang sama dengan patch game, penyebabnya sulit dibedakan, jadi deploy keduanya secara terpisah.

6 sumber

The kernel’s command-line parameters Linux kernel
mitigations=: off mematikan semua mitigasi kerentanan CPU untuk menaikkan performa tetapi membuka celah kerentanan; default auto melakukan mitigasi dengan SMT tetap aktif; auto,nosmt mematikan SMT jika perlu
MDS - Microarchitectural Data Sampling Linux kernel
Mitigasi mengosongkan buffer CPU saat kembali dari kernel ke user space dan saat masuk ke virtual machine; status kerentanan dan mitigasi diperiksa lewat file di bawah /sys/devices/system/cpu/vulnerabilities/; pada banyak CPU, perlindungan penuh mengharuskan SMT dimatikan, dan mematikan SMT berdampak besar pada performa tergantung beban kerjanya
Spectre Side Channels Linux kernel
Untuk mitigasi, buffer branch prediction dikosongkan saat context switching dan peralihan virtual machine; mitigasi yang kuat menambah overhead pada semua program
EEVDF Scheduler Linux kernel
Sejak 6.6, Linux mulai beralih dari CFS ke scheduler EEVDF
listen(2) — Linux manual page Linux man-pages
Nilai default somaxconn berubah dari 128 menjadi 4.096 sejak Linux 5.4
ethtool(8) — Linux manual page ethtool
Melihat informasi driver perangkat jaringan dengan ethtool -i

Tabel conntrack server penuh conntrack table full

ID so-conntrack · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)

Jika tabel connection tracking (conntrack), tempat firewall Linux mencatat semua koneksi, mencapai batasnya, paket baru dibuang.

Mengapa Catatan koneksi bertambah karena lonjakan koneksi atau koneksi pendek yang berulang → Akibatnya Tabel penuh sehingga koneksi baru dan sebagian paket dibuang → Di layar Tidak bisa masuk, teleport akibat packet loss tanpa sebab yang jelas

Gejala: Tidak bisa masuk / loading tanpa henti, Teleport
Faktor: Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Tepat setelah login atau maintenance, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: kurangi koneksi pendek (pakai ulang koneksi untuk pemanggilan antarserver). Klien: jika koneksi gagal atau terputus, perpanjang interval percobaan ulang secara bertahap dan sebar secara acak.
Tugas Tim Infrastruktur: Perbesar ukuran tabel (nf_conntrack_max), kecualikan port game dari pelacakan (NOTRACK di tabel raw), pasang alert pemakaian.
Kisaran angka: Batas default sekitar 60.000–260.000 entri, tergantung memori server. Jika meluap, log kernel mencatat “nf_conntrack: table full, dropping packet”.
Di grafik: Mendatar di batas · Jumlah entri conntrack (nf_conntrack_count)
Yang diperiksa: Tampilkan net.netfilter.nf_conntrack_count (jumlah entri saat ini) dari sysctl dalam satu grafik dengan nf_conntrack_max, lalu cari “nf_conntrack: table full, dropping packet” di dmesg
Cocok jika: nf_conntrack_count mendatar di nilai max, dan sejak saat itu log kernel mencatat table full
Tidak cocok jika: Jumlah entri masih jauh di bawah max: bukan penyebab ini. Batas connection tracking milik instance AWS itu sendiri diperiksa lewat conntrack_allowance_exceeded di “Batas PPS cloud terlampaui”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Netfilter Conntrack Sysfs variables Linux kernel
Nilai default nf_conntrack_max sama dengan jumlah hash bucket (nf_conntrack_buckets), dan jumlah bucket ditentukan oleh ukuran memori
net/netfilter/nf_conntrack_core.c (Linux v6.12) Linux kernel
Ukuran default 65.536 jika memori lebih dari 1 GB, 262.144 jika lebih dari 4 GB (64-bit); jika penuh, paket dibuang dengan catatan “nf_conntrack: table full, dropping packet”
iptables-extensions(8) — Linux manual page netfilter
Mengecualikan dari connection tracking dengan CT --notrack di tabel raw

Port ephemeral habis pada koneksi antarserver Ephemeral port exhaustion (TIME_WAIT)

ID so-ports · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika server game sering membuka dan menutup koneksi singkat ke DB atau server lain, koneksi yang sudah ditutup tetap menahan port untuk sementara sehingga koneksi baru tidak bisa dibuka.

Mengapa Koneksi baru dibuka dan ditutup untuk setiap permintaan → Akibatnya Pihak yang menutup koneksi lebih dulu menahan port selama sekitar 60 detik (Linux) dalam status TIME_WAIT, sehingga port yang bisa dipakai habis → Di layar Permintaan internal gagal, sehingga penyimpanan data gagal dan fitur mengalami error

Gejala: Aksi hilang / rollback, Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss
Siapa yang mengalami: Seluruh server, Fitur tertentu saja
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Pakai ulang koneksi (connection pool), jangan membuka dan menutup koneksi baru untuk setiap permintaan.
Tugas Tim Infrastruktur: Perluas rentang port (ip_local_port_range), pertimbangkan pemakaian ulang TIME_WAIT untuk koneksi keluar (tcp_tw_reuse di Linux), pantau jumlah TIME_WAIT.
Kisaran angka: Rentang port default Linux (32768–60999) berisi sekitar 28.000 port. Jika koneksi baru ke alamat tujuan yang sama dibuat lebih dari 470 kali per detik, port akan habis. Windows punya sekitar 16.000 port default (49152–65535) dan TIME_WAIT-nya juga lebih lama, sehingga lebih cepat habis.
Di grafik: Mendatar di batas · Jumlah socket TIME_WAIT, jumlah kegagalan koneksi internal
Yang diperiksa: Hitung socket TIME_WAIT per alamat tujuan dengan ss -tan state time-wait, lalu cari kegagalan connect (EADDRNOTAVAIL) di log server game
Cocok jika: TIME_WAIT ke tujuan yang sama (misalnya DB) mendatar di dekat batas rentang port ephemeral (default sekitar 28.000), dan connect gagal dengan EADDRNOTAVAIL
Tidak cocok jika: TIME_WAIT sedikit tetapi hanya koneksi keluar yang gagal: lebih mungkin “Batas koneksi dan port NAT gateway cloud”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: TIME_WAIT 60 detik di Linux adalah nilai tetap di kernel. Menurunkan tcp_fin_timeout, yang namanya mirip, tidak memperpendek TIME_WAIT.

5 sumber

IP Sysctl Linux kernel
ip_local_port_range default 32768–60999, tcp_tw_reuse, tcp_fin_timeout adalah lama status FIN_WAIT_2 dipertahankan
include/net/tcp.h (Linux v6.12) Linux kernel
TCP_TIMEWAIT_LEN(60*HZ): TIME_WAIT sekitar 60 detik adalah konstanta kernel
TCP/IP port exhaustion troubleshooting Microsoft
Port dinamis Windows default 49152–65535; koneksi yang sudah ditutup menahan port dalam status TIME_WAIT selama 4 menit secara default
ss(8) — Linux manual page iproute2
Filter status state time-wait hanya menampilkan socket TIME_WAIT
connect(2) — Linux manual page Linux man-pages
EADDRNOTAVAIL: koneksi tidak bisa dibuka karena semua port di rentang port ephemeral sedang dipakai

L8 Socket dan protokol

HOL blocking pada TCP Head-of-line blocking

ID sk-hol · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Untuk menjaga urutan, TCP tidak menyerahkan paket yang datang belakangan ke game sampai satu paket yang hilang diterima ulang.

Mengapa Satu paket hilang → Akibatnya Paket-paket sesudahnya sudah tiba, tetapi menunggu di buffer terima → Di layar Berhenti, lalu semuanya dilepas sekaligus sehingga terjadi fast forward

Gejala: Freeze, Fast forward
Faktor: Packet loss, Stall
Siapa yang mengalami: Hanya saya
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: kirim posisi real-time lewat UDP, gunakan pengiriman reliable hanya untuk data yang benar-benar perlu, pecah menjadi beberapa stream. Klien: ubah pemrosesan jaringan ke cara yang sama dengan server (UDP, pemisahan channel).
Kisaran angka: Jika satu paket hilang, game berhenti minimal selama RTT + α; jika paket retransmisinya juga hilang, berhentinya bisa ratusan ms hingga beberapa detik.
Di grafik: Kosong lalu datang sekaligus · Jumlah data diterima per koneksi, jumlah retransmisi
Yang diperiksa: Periksa paket retransmisi dan jeda kosong sebelum dan sesudahnya pada koneksi pemain tersebut lewat packet capture di sisi server (tcpdump, Wireshark); untuk seluruh server, periksa kenaikan TcpRetransSegs di nstat -az
Cocok jika: Bagian yang berhenti dimulai dengan retransmisi satu paket, dan tepat setelah paket retransmisi tiba, data yang tertahan diproses sekaligus (data diterima 0 lalu datang bertumpuk)
Tidak cocok jika: Game berkomunikasi lewat UDP: tidak berlaku. Tidak ada retransmisi tetapi tetap berhenti: periksa sisi tick server (“Tick melewati budget (tick overrun)”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

RFC 9293: Transmission Control Protocol (TCP) IETF
TCP adalah layanan byte stream yang reliable dan menjaga urutan
RFC 5681: TCP Congestion Control IETF
Packet loss dideteksi dari 3 duplicate ACK lalu dilakukan fast retransmit; jika tidak, TCP menunggu timer retransmisi
RFC 6298: Computing TCP's Retransmission Timer IETF
Backoff yang menggandakan timer retransmisi setiap kali timer habis
net/ipv4/proc.c (Linux v6.12) Linux kernel
Nama counter yang ditampilkan nstat: RetransSegs di grup Tcp (jumlah segmen yang dikirim ulang)

RTO TCP dan exponential backoff RTO and exponential backoff

ID sk-rto · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Setiap kali retransmisi gagal lagi, waktu tunggu berlipat dua, sehingga koneksi yang putus sebentar berujung pada jeda yang lama.

Mengapa Koneksi putus sebentar sehingga retransmisi pun gagal berturut-turut → Akibatnya Waktu tunggu sampai percobaan berikutnya berlipat dua: 0,3 → 0,6 → 1,2 → 2,4 detik (untuk ping 100 ms) → Di layar Koneksi hanya putus 1 detik, tetapi game freeze lebih dari 2 detik. Jika putusnya lebih lama, akhirnya disconnect

Gejala: Freeze, Disconnect
Faktor: Packet loss, Stall
Siapa yang mengalami: Hanya saya
Kapan: Sesekali secara acak, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: balas heartbeat dan putuskan koneksi lebih dulu jika tidak ada heartbeat dalam waktu tertentu (percepat titik menyerah dengan TCP_USER_TIMEOUT), lanjutkan sesi dengan token sesi, gunakan reliable UDP. Klien: kirim heartbeat dengan interval pendek, dan jika respons berhenti, segera reconnect tanpa menunggu retransmisi TCP.
Kisaran angka: RTO (waktu tunggu retransmisi) di Linux minimal “ping + 200 ms”, dan saat koneksi dibuat, RTO dimulai dari 1 detik. Dengan pengaturan default (tcp_retries2=15), walaupun retransmisi terus gagal, koneksi baru dilepas setelah sekitar 15 menit.
Di grafik: Kosong lalu datang sekaligus · RTO dan backoff per koneksi, jumlah RTO habis
Yang diperiksa: Periksa rto (waktu tunggu retransmisi dalam ms) dan backoff (jumlah RTO habis berturut-turut) pada koneksi yang berhenti dengan ss -ti; untuk seluruh server, periksa kenaikan TcpExtTCPTimeouts (jumlah timer retransmisi habis) di nstat -az
Cocok jika: backoff pada koneksi yang berhenti bernilai 1 atau lebih, rto membesar hingga satuan detik, dan TCPTimeouts naik pada saat itu
Tidak cocok jika: Retransmisi selesai lewat fast retransmit dan tidak ada RTO yang habis: berhentinya singkat, dan dalam kasus itu lebih mungkin “HOL blocking pada TCP”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

6 sumber

RFC 6298: Computing TCP's Retransmission Timer IETF
RTO awal 1 detik, RTO digandakan setiap kali timer habis (exponential backoff)
net/ipv4/tcp_input.c (Linux v6.12) Linux kernel
RTO di Linux = smoothed RTT + variasi RTT, dan batas bawah variasinya adalah tcp_rto_min (200 ms), sehingga RTO minimal RTT+200 ms
IP Sysctl Linux kernel
tcp_rto_min_us default 200 ms, RTO pertama untuk permintaan koneksi 1 detik, dengan tcp_retries2=15 waktu sampai menyerah minimal 924,6 detik (sekitar 15 menit)
ss(8) — Linux manual page iproute2
rto (timer retransmisi, ms) dan backoff (jumlah exponential backoff) pada -i
net/ipv4/proc.c (Linux v6.12) Linux kernel
Nama counter yang ditampilkan nstat: TCPTimeouts di grup TcpExt
net/ipv4/tcp_timer.c (Linux v6.12) Linux kernel
Setiap kali timer retransmisi habis, TCPTimeouts naik, backoff bertambah satu, dan RTO digandakan (sampai nilai maksimum)

Algoritma Nagle + delayed ACK Nagle + delayed ACK (TCP_NODELAY off)

ID sk-nagle · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Algoritma Nagle yang mengumpulkan paket kecil sebelum dikirim dan delayed ACK yang menunda pengiriman ACK saling mengunci, sehingga setiap kali pesan ditulis terpisah-pisah terjadi keterlambatan 40–200 ms.

Mengapa Pesan kecil ditulis terpisah-pisah tanpa mengaktifkan TCP_NODELAY → Akibatnya Pengirim menunggu ACK, sedangkan penerima menunda pengiriman ACK → Di layar Ping koneksi rendah, tetapi semua aksi terasa lamban secara konsisten (input lag)

Gejala: Input lag
Faktor: Latensi
Siapa yang mengalami: Seluruh server, Hanya saya
Kapan: Selalu, Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: aktifkan TCP_NODELAY, kumpulkan pesan selama satu tick lalu tulis sekaligus, jangan mengandalkan cara mematikan delayed ACK di sisi penerima (TCP_QUICKACK di Linux hanya bertahan sebentar, di Windows registry harus diubah di setiap PC) karena game tidak bisa mengendalikannya dengan pasti. Klien: aktifkan TCP_NODELAY, kumpulkan pesan selama satu frame lalu tulis sekaligus.
Kisaran angka: Delayed ACK di Linux biasanya 40 ms (hingga 200 ms tergantung situasi). Di Windows, versi lama memakai 200 ms dan versi sekarang 40 ms (template default Windows Server 2019: 40 ms). Delayed ACK ditentukan oleh OS penerima, jadi jika server mengirim pesan terpisah-pisah dengan Nagle aktif, keterlambatannya bisa 40–200 ms tergantung PC penerimanya.
Di grafik: Selalu tinggi sejak awal · Waktu respons aksi (RTT di dalam game)
Yang diperiksa: Periksa jeda antara permintaan dan respons di packet capture sisi server (tcpdump, Wireshark), lalu pastikan kode server dan klien mengaktifkan TCP_NODELAY
Cocok jika: Ping koneksi rendah, tetapi jeda kosong sekitar 40 ms (200 ms di Windows versi lama) berulang di antara paket kecil, dan jeda itu berakhir tepat setelah ACK dari pihak lawan datang. Hilang setelah TCP_NODELAY diaktifkan
Tidak cocok jika: Jeda respons mirip dengan ping koneksi: bukan penyebab ini. Server game terlambat membuat respons: masalahnya di pemrosesan server (“Penumpukan antrean pesan”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

5 sumber

RFC 9293: Transmission Control Protocol (TCP) IETF
Nagle menahan data kecil selama masih ada data yang belum mendapat ACK; harus bisa dimatikan per koneksi; delayed ACK kurang dari 0,5 detik; masalah saat keduanya saling mengunci
include/net/tcp.h (Linux v6.12) Linux kernel
Delayed ACK di Linux minimal TCP_DELACK_MIN (HZ/25 = 40 ms), maksimal TCP_DELACK_MAX (HZ/5 = 200 ms)
TCP improvements in the Windows network stack (IETF 98 TCPM) Microsoft
Timeout delayed ACK default di Windows diubah menjadi 40 ms (diumumkan tahun 2017)
TCP Templates for Windows Server 2019 – How to tune your Windows Server Transports (Advanced users only 😉) Microsoft
Template Server 2019: DelayedAckTimeout 40 ms, MaxSynRetransmissions 2, InitialRto 3000 ms
Design issues - Sending small data segments over TCP with Winsock Microsoft
TCP Windows versi lama memasang timer delayed ACK 200 ms setiap kali menerima data, dan Nagle aktif secara default sehingga paket kecil menunggu ACK; diatasi dengan TCP_NODELAY

Pengiriman blocking akibat klien lambat Blocking send on a full socket

ID sk-block-send · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika buffer kirim untuk satu pemain dengan koneksi lambat sudah penuh, lalu server mengirim dengan cara blocking (pemanggilan yang tidak kembali sampai buffer punya ruang), thread server ikut menunggu pemain itu.

Mengapa Buffer kirim untuk klien yang lambat penuh → Akibatnya Karena pengirimannya blocking, thread server menunggu sampai buffer punya ruang → Di layar Semua pemain yang ditangani thread itu mengalami freeze atau slow motion

Gejala: Freeze, Slow motion
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu, Seluruh server
Kapan: Sesekali secara acak, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Gunakan pengiriman non-blocking, batasi antrean kirim per klien, buang update yang sudah lama.
Di grafik: Melonjak acak sesekali · Waktu tick server, Send-Q per koneksi
Yang diperiksa: Cari koneksi yang Send-Q-nya (byte yang belum mendapat ACK atau belum terkirim) sudah sebesar buffer kirim dengan ss -tn, lalu periksa di thread dump (stack) server game saat tick melonjak apakah ada thread yang tertahan di pemanggilan send
Cocok jika: Saat ada koneksi lambat dengan Send-Q penuh, thread yang menangani koneksi itu tertahan di send, dan hanya pemain yang ditangani thread yang sama ikut berhenti
Tidak cocok jika: Thread yang berhenti menunggu di luar send (lock, pemanggilan DB): lebih mungkin “Perebutan lock” atau “Pemanggilan sinkron di thread game”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

send(2) — Linux manual page Linux man-pages
Jika buffer kirim tidak punya ruang, send() memblok; dalam mode non-blocking, send() langsung kembali dengan EAGAIN
send function (winsock2.h) Microsoft
Winsock juga memblok send jika ruang buffer tidak ada, kecuali dalam mode non-blocking
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK

Kebijakan penanganan klien lambat (slow consumer) Slow-consumer policy

ID sk-slow-client · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Untuk klien yang data kirimannya terus menumpuk, server membuang update lama atau memutus koneksinya.

Mengapa Koneksi klien tidak sanggup mengimbangi jumlah data yang dikirim server → Akibatnya Server membuang update lama atau memutus koneksi saat batas terlampaui → Di layar Hanya pemain itu yang mengalami teleport atau disconnect

Gejala: Teleport, Disconnect
Faktor: Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Kurangi jumlah data yang dikirim (frekuensi update berdasarkan jarak), turunkan kualitas tetapi tetap kirim, kurangi data yang ditumpuk di kernel (TCP_NOTSENT_LOWAT di Linux).
Kisaran angka: Jika buffer kirim 256 KB, pada koneksi 30 KB/s data yang tertunda lebih dari 8 detik bisa menumpuk. Linux bahkan bisa membesarkan buffer ini secara otomatis hingga beberapa MB.
Di grafik: Hanya sebagian yang tinggi · Send-Q per koneksi, jumlah update yang dibuang per klien
Yang diperiksa: Periksa panjang antrean kirim per klien, jumlah update yang dibuang, dan alasan putus yang dicatat server game, lalu di server periksa Send-Q dan cwnd koneksi itu dengan ss -tni
Cocok jika: Hanya koneksi pemain yang melonjak atau putus yang Send-Q-nya terus penuh, dan log game mencatat update pemain itu dibuang atau koneksinya diputus karena antrean kirim melewati batas
Tidak cocok jika: Send-Q kosong tetapi pemain teleport: masalahnya ada di luar sisi kirim server. Lebih mungkin packet loss pada koneksi pemain itu (“Packet loss di jalur nirkabel”) atau interpolasi di layar
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

IP Sysctl Linux kernel
tcp_wmem: batas maksimum buffer kirim yang diatur otomatis default 64 KB–4 MB (tergantung memori); jumlah data yang belum terkirim dibatasi dengan tcp_notsent_lowat dan TCP_NOTSENT_LOWAT
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK

Nilai default keepalive 2 jam TCP keepalive defaults

ID sk-keepalive · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)

Jika pihak lawan menghilang tanpa sinyal penutupan, TCP baru mendeteksinya lama kemudian. keepalive (fitur TCP untuk memeriksa apakah koneksi idle masih hidup) nonaktif secara default, dan walaupun diaktifkan, pemeriksaan baru dimulai setelah koneksi idle selama 2 jam.

Mengapa Klien menghilang tanpa sinyal penutupan karena perangkat mati atau koneksi putus → Akibatnya Server menganggap koneksi masih hidup (keepalive default 7.200 detik; jika ada data yang sedang dikirim, sekitar 15 menit sampai retransmisi menyerah) → Di layar Karakter hantu tertinggal, dan saat login ulang muncul error “Sudah terhubung”

Gejala: Tidak bisa masuk / loading tanpa henti, Tidak terlihat / objek hantu
Faktor: Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Setelah lama diam, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Server: balas heartbeat dan putuskan koneksi lebih dulu jika tidak ada heartbeat dalam waktu tertentu (sesuaikan TCP_KEEPIDLE dan TCP_USER_TIMEOUT), saat pemain reconnect ganti sesi lama lewat token sesi agar sesi berlanjut. Klien: kirim heartbeat di level game dengan interval beberapa hingga puluhan detik (maksimal setengah dari idle timeout terpendek), reconnect otomatis jika terputus.
Tugas Tim Infrastruktur: Turunkan nilai default kernel (tcp_keepalive_time dan lainnya) untuk socket yang tidak mengaturnya sendiri di kode (hanya berlaku untuk socket yang mengaktifkan SO_KEEPALIVE).
Kisaran angka: Default Linux: pemeriksaan dimulai setelah koneksi idle 7.200 detik, probe dikirim 9 kali dengan interval 75 detik, dan jika sampai akhir tidak ada respons, koneksi diputus. Totalnya sekitar 2 jam 11 menit. Windows juga secara default baru memulai pemeriksaan setelah koneksi idle 2 jam.
Di grafik: Hanya sebagian yang tinggi · Waktu berlalu sejak data terakhir diterima per koneksi
Yang diperiksa: Periksa lastrcv (ms sejak data terakhir diterima) dan timer keepalive (timer:(keepalive,…)) per koneksi dengan ss -tnoi, lalu cocokkan dengan catatan penolakan “Sudah terhubung” di server game
Cocok jika: Masih ada koneksi ESTABLISHED dengan lastrcv beberapa menit hingga beberapa jam, dan reconnect akun tersebut ditolak dengan “Sudah terhubung”
Tidak cocok jika: Tidak ada koneksi yang lama diam tetapi “Sudah terhubung” tetap muncul: masalahnya di kode pembersihan sesi server game
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

tcp(7) — Linux manual page Linux man-pages
Setelah idle 7.200 detik, probe dikirim 9 kali dengan interval 75 detik (tambahan sekitar 11 menit); hanya berlaku untuk socket yang mengaktifkan SO_KEEPALIVE; TCP_KEEPIDLE dan TCP_USER_TIMEOUT
RFC 9293: Transmission Control Protocol (TCP) IETF
keepalive harus nonaktif secara default, dan interval idle default minimal 2 jam
SO_KEEPALIVE socket option Microsoft
Timeout default TCP keepalive di Windows 2 jam
ss(8) — Linux manual page iproute2
lastrcv pada -i (ms sejak data terakhir diterima), timer:(keepalive,…) pada -o

Fragmentasi IP pada paket UDP IP fragmentation of large UDP

ID sk-fragment · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Paket UDP yang melebihi MTU (ukuran maksimum yang bisa dikirim sekaligus) difragmentasi di lapisan IP, dan jika satu fragmen saja hilang, seluruh paket dibuang.

Mengapa Snapshot di tempat ramai melebihi 1.500 byte → Akibatnya Paket dikirim terpecah menjadi beberapa fragmen; jika satu saja hilang, seluruhnya dibuang → Di layar Makin besar paketnya, tingkat packet loss naik beberapa kali lipat. Teleport hanya terjadi di tempat ramai

Gejala: Teleport
Faktor: Packet loss
Siapa yang mengalami: Lokasi/channel tertentu, Wilayah/ISP tertentu
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pecah sendiri paket menjadi maksimal 1.200 byte, kirim hanya bagian yang berubah.
Kisaran angka: Pada koneksi dengan packet loss 2%, paket yang terpecah menjadi 4 fragmen hilang sekitar 8%. Ada juga firewall dan ISP yang membuang semua paket terfragmentasi, sehingga pemain tersebut tidak menerima satu pun paket besar.
Di grafik: Naik mengikuti beban · Jumlah fragmentasi IP (IpFragCreates), ukuran snapshot
Yang diperiksa: Periksa kenaikan IpFragCreates (jumlah fragmen yang dibuat saat mengirim) di nstat -az pada server, dan IpReasmFails (jumlah kegagalan penyusunan ulang fragmen) di sisi penerima. Periksa distribusi ukuran paket UDP dari log server game atau packet capture
Cocok jika: IpFragCreates naik di tempat ramai, ada paket UDP yang melebihi 1.500 byte, dan laporan teleport bertambah pada saat itu
Tidak cocok jika: IpFragCreates tidak naik: tidak ada fragmentasi di sisi kirim server
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

RFC 8085: UDP Usage Guidelines IETF
Jika satu fragmen hilang, penyusunan ulang gagal dan seluruh paket hilang; aplikasi UDP harus menghindari fragmentasi IP
RFC 8900: IP Fragmentation Considered Fragile IETF
Contoh firewall dan sebagian jaringan yang membuang fragmen IP
net/ipv4/proc.c (Linux v6.12) Linux kernel
Nama counter yang ditampilkan nstat: FragCreates (jumlah fragmen yang dibuat) dan ReasmFails (jumlah kegagalan penyusunan ulang) di grup Ip

Pengaturan retransmisi reliable UDP Reliable-UDP tuning (KCP, ENet…)

ID sk-reliable-udp · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika aturan retransmisi yang dibuat sendiri di atas UDP terlalu konservatif, pemulihan terlambat; jika terlalu agresif, jalur makin padat.

Mengapa Pengaturan interval retransmisi, jumlah percobaan, dan ukuran window tidak sesuai dengan koneksi → Akibatnya Pemulihan terlambat, atau pengiriman duplikat memperparah kongesti → Di layar Skill tidak keluar, fast forward, lag yang makin parah saat jalur padat

Gejala: Aksi hilang / rollback, Fast forward
Faktor: Packet loss, Latensi
Siapa yang mengalami: Hanya saya
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: lakukan retransmisi berdasarkan round-trip time yang diukur, pisahkan channel menurut tingkat kepentingan. Klien: terapkan pengaturan retransmisi dan channel yang sama dengan server.
Di grafik: Melonjak acak sesekali · Rasio retransmisi reliable UDP, RTT di dalam game
Yang diperiksa: Catat statistik per koneksi dari library yang dipakai (jumlah retransmisi, perkiraan round-trip time, waktu tunggu retransmisi) di server dan klien, lalu bandingkan dengan tingkat packet loss koneksi sebenarnya dari pemain yang sama (diukur dengan mtr)
Cocok jika: Rasio retransmisi beberapa kali lebih tinggi dari tingkat packet loss sebenarnya: pengaturan terlalu agresif. Waktu tunggu retransmisi beberapa kali lipat dari round-trip time terukur: pengaturan terlalu konservatif
Tidak cocok jika: Rasio retransmisi mirip dengan tingkat packet loss koneksi dan waktu tunggu sesuai round-trip time: masalahnya di luar pengaturan. Periksa packet loss pada koneksinya sendiri
Sarana pemeriksaan: Log dan metrik server atau klien game

1 sumber

RFC 8085: UDP Usage Guidelines IETF
Retransmisi bisa memperparah kongesti sehingga harus tunduk pada congestion control; round-trip time diperkirakan dari rata-rata beberapa pengukuran (EWMA); nilai awal 1 detik; laju kirim diturunkan saat timer habis

Slow start setelah idle Slow start after idle

ID sk-slowstart · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika koneksi idle cukup lama, TCP kembali mengecilkan congestion window (jumlah data yang bisa dikirim sekaligus), sehingga data besar yang tiba-tiba dikirim harus dipecah menjadi beberapa kali kirim.

Mengapa Data besar, misalnya saat masuk ke kota, dikirim lewat koneksi yang tadinya idle → Akibatnya Congestion window sedang kecil sehingga data dikirim terbagi dalam beberapa kali pulang-pergi → Di layar Tepat setelah masuk, karakter dan NPC di sekitar muncul terlambat beberapa kali waktu pulang-pergi (makin jauh servernya, makin terasa)

Gejala: Input lag, Tidak terlihat / objek hantu
Faktor: Latensi
Siapa yang mengalami: Hanya saya
Kapan: Saat bergerak atau pindah area, Setelah lama diam
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Kurangi data saat masuk (kirim yang paling penting lebih dulu).
Tugas Tim Infrastruktur: Matikan tcp_slow_start_after_idle (Linux, pengaturan untuk seluruh server).
Kisaran angka: Jika koneksi idle lebih lama dari RTO, congestion window mulai mengecil, dan setelah idle lama bisa turun sampai sekitar 14 KB (10 paket). Akibatnya, 100 KB tidak bisa dikirim sekaligus dan harus dibagi dalam 3 kali pulang-pergi.
Di grafik: Hanya sebagian yang tinggi · Waktu kirim tepat setelah masuk (pemain dengan RTT panjang)
Yang diperiksa: Periksa nilai sysctl net.ipv4.tcp_slow_start_after_idle, lalu saat pemain masuk ke suatu area setelah idle, periksa di ss -ti apakah cwnd (congestion window) koneksinya mengecil
Cocok jika: Nilainya 1 (default), dan saat masuk setelah idle cwnd turun ke sekitar 10 sehingga pengiriman terbagi dalam beberapa kali pulang-pergi. Makin panjang RTT pemain, makin lambat objek muncul, dan gejalanya hilang setelah nilainya diubah ke 0
Tidak cocok jika: cwnd tetap besar tetapi objek tetap terlambat muncul: lebih mungkin pemrosesan masuk di sisi server (“Lonjakan spawn saat masuk area padat”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

IP Sysctl Linux kernel
tcp_slow_start_after_idle default aktif; jika idle selama RTO, congestion window dikecilkan (cara RFC 2861)
RFC 5681: TCP Congestion Control IETF
Jika data tidak dikirim lebih lama dari RTO, congestion window dikecilkan ke restart window min(IW, cwnd) atau lebih kecil, lalu slow start
RFC 6928: Increasing TCP's Initial Window IETF
Initial window 10 segmen, maksimal 14.600 byte
ss(8) — Linux manual page iproute2
cwnd (congestion window) dan ssthresh (ambang slow start) pada -i

Laju kirim anjlok akibat congestion control Congestion control backoff

ID sk-congestion · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

TCP menganggap packet loss sebagai tanda kongesti dan menurunkan kecepatan kirim 30–50%. TCP bereaksi sama terhadap packet loss di Wi-Fi.

Mengapa Saat data yang dikirim banyak, terjadi sedikit packet loss di Wi-Fi atau di jalur koneksi → Akibatnya TCP menurunkan kecepatan kirim secara drastis lalu pulih perlahan (CUBIC, default di Linux dan Windows, menurunkannya 30%) → Di layar Di tempat ramai, update tertunda sehingga terjadi fast forward atau input lag

Gejala: Fast forward, Input lag
Faktor: Latensi, Stall
Siapa yang mengalami: Hanya saya
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Kurangi data yang dikirim (area of interest, hanya bagian yang berubah), kirim terbagi agar tidak menumpuk sekaligus.
Tugas Tim Infrastruktur: Ganti ke congestion control seperti BBR (tcp_congestion_control).
Di grafik: Naik perlahan lalu anjlok · Congestion window (cwnd) dan laju kirim per koneksi
Yang diperiksa: Ambil ss -ti beberapa kali untuk koneksi pemain yang update-nya tertunda, lalu periksa perubahan cwnd dan ssthresh, nama congestion control (cubic, bbr), dan apakah Send-Q menumpuk
Cocok jika: Setelah packet loss, cwnd turun drastis lalu naik perlahan secara berulang, dan selama cwnd kecil Send-Q menumpuk, bertepatan dengan waktu laporan fast forward atau input lag
Tidak cocok jika: cwnd cukup besar tetapi tetap tertunda: lebih mungkin window di sisi penerima (“Zero window (jeda yang terlihat seperti retransmisi)”) atau sisi kirim server
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

5 sumber

RFC 9438: CUBIC for Fast and Long-Distance Networks IETF
Saat packet loss, CUBIC mengecilkan window menjadi 0,7 kali (turun 30%), Reno 0,5 kali; CUBIC adalah default di Linux, Windows, dan Apple
TCP BBR congestion control comes to GCP – your Internet just got faster Google Cloud
Congestion control berbasis packet loss menurunkan laju kirim secara drastis bahkan untuk packet loss yang tidak disebabkan kongesti; BBR menilai dari laju pengiriman (delivery rate) dan RTT
IP Sysctl Linux kernel
Memilih algoritma congestion control untuk koneksi baru dengan tcp_congestion_control
ss(8) — Linux manual page iproute2
cwnd, ssthresh, dan nama algoritma congestion control pada -i
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK

Data terakhir hilang akibat penutupan paksa dengan RST SO_LINGER, abrupt RST

ID sk-linger · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika server memutus koneksi secara mendadak, pesan pemberitahuan atau sinyal penyimpanan selesai yang dikirim terakhir ikut hilang.

Mengapa Server menutup koneksi dengan penutupan paksa (RST). Terjadi jika SO_LINGER diatur ke 0 detik, atau socket ditutup sebelum semua data yang diterima dibaca → Akibatnya Alasan kick dan data terakhir yang masih dalam pengiriman dibuang → Di layar Muncul pesan “Koneksi terputus karena error yang tidak diketahui” tanpa alasan yang jelas

Gejala: Disconnect
Faktor: Packet loss
Siapa yang mengalami: Hanya saya
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Setelah mengirim alasan, tutup arah kirim lebih dulu (shutdown), baca semua data yang diterima sampai pihak lawan menutup koneksi, baru tutup socket, hindari SO_LINGER 0 detik.
Di grafik: Melonjak acak sesekali · Jumlah koneksi yang berakhir dengan RST
Yang diperiksa: Periksa kenaikan TcpExtTCPAbortOnData (ditutup dengan RST saat masih ada data yang akan dikirim, SO_LINGER 0 detik) dan TcpExtTCPAbortOnClose (ditutup saat masih ada data yang belum dibaca) di nstat -az, lalu periksa di packet capture sisi server saat koneksi putus apakah server mengirim RST tanpa FIN
Cocok jika: Pada waktu laporan “Koneksi terputus karena error yang tidak diketahui”, server mengirim RST, dan AbortOnData serta AbortOnClose naik
Tidak cocok jika: Server menutup koneksi secara normal dengan FIN tetapi alasannya tidak terlihat: masalahnya di penanganan penutupan koneksi di klien
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

closesocket function (winsock.h) Microsoft
Jika SO_LINGER diaktifkan dengan waktu 0, penutupan menjadi paksa: koneksi langsung direset dan data yang belum terkirim hilang
RFC 9293: Transmission Control Protocol (TCP) IETF
Jika socket ditutup saat masih ada data diterima yang belum dibaca, RST dikirim untuk memberi tahu bahwa data hilang
Graceful Shutdown, Linger Options, and Socket Closure Microsoft
Urutannya: tutup arah kirim lebih dulu dengan shutdown, lalu tutup socket setelah menerima notifikasi penutupan dari pihak lawan
SNMP counter Linux kernel
TcpExtTCPAbortOnData: ditutup dengan RST saat masih ada data yang akan dikirim, misalnya karena SO_LINGER 0 detik; TcpExtTCPAbortOnClose: RST dikirim karena socket ditutup saat masih ada data yang belum dibaca

Arsitektur I/O blocking Blocking I/O model

ID sk-blocking-io · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Pada arsitektur yang membuat thread tidak bisa mengerjakan hal lain selama menunggu satu socket, seluruh server makin lambat seiring bertambahnya pemain.

Mengapa Cara kerja yang menunggu baca dan tulis untuk setiap koneksi → Akibatnya Keterlambatan satu koneksi merembet ke koneksi lain di thread yang sama → Di layar Makin banyak pemain online, seluruh server makin terasa slow motion dan input lag

Gejala: Slow motion, Input lag
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Beralih ke I/O asinkron berbasis epoll, IOCP, atau io_uring.
Di grafik: Naik mengikuti beban · Waktu respons, jumlah thread
Yang diperiksa: Periksa jumlah thread server game dan context switching voluntary per thread (cswch/s, jumlah thread berhenti karena menunggu sumber daya) dengan pidstat -w -t, lalu bandingkan dengan waktu respons menurut jumlah pemain online
Cocok jika: Makin banyak pemain online, waktu respons naik tajam, dan sebagian besar thread yang bertambah sebanyak jumlah koneksi hanya banyak melakukan context switching voluntary dan hampir tidak memakai CPU (menunggu socket)
Tidak cocok jika: Thread terus memakai CPU tanpa menunggu: lebih mungkin beban komputasi berlebih (“Tick melewati budget (tick overrun)”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

epoll(7) — Linux manual page Linux man-pages
Notifikasi event I/O yang dapat diskalakan untuk memantau banyak fd sekaligus
I/O Completion Ports Microsoft
Cara Windows memproses banyak I/O asinkron dengan thread pool yang dibuat lebih dulu
pidstat(1) — Linux manual page sysstat
cswch/s pada -w: context switching voluntary (thread berhenti sendiri karena menunggu sumber daya), -t untuk melihat per thread

Distribusi SO_REUSEPORT tidak merata SO_REUSEPORT imbalance, stuck worker

ID sk-reuseport · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika beberapa proses berbagi satu port, kernel menetapkan proses yang menangani setiap koneksi berdasarkan hash alamat dan tidak mengubahnya. Jika satu proses itu berhenti, hanya pemain yang dialokasikan ke proses tersebut yang menunggu.

Mengapa Gateway atau server login menjalankan beberapa proses dengan SO_REUSEPORT → Akibatnya Walaupun satu proses berhenti karena GC atau kelebihan beban, koneksi baru dan paket UDP yang dialokasikan ke proses itu tidak dialihkan ke proses lain → Di layar Hanya sebagian pemain yang tidak bisa masuk atau freeze. Saat restart yang mengubah jumlah proses, sebagian sesi UDP terputus

Gejala: Tidak bisa masuk / loading tanpa henti, Freeze, Disconnect
Faktor: Stall, Packet loss
Siapa yang mengalami: Hanya saya, Seluruh server
Kapan: Tepat setelah login atau maintenance, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Pastikan thread penerima tidak pernah tertahan, implementasikan prosedur serah terima sesi saat restart.
Tugas Tim Infrastruktur: Pantau antrean koneksi per proses (Recv-Q di ss), pastikan prosedur serah terima sesi diikuti jika jumlah proses diubah saat deploy.
Di grafik: Hanya sebagian yang tinggi · Antrean koneksi (Recv-Q) per socket listen
Yang diperiksa: Periksa Recv-Q (jumlah koneksi yang menunggu accept) dan proses yang menangani setiap socket listen pada port yang sama dengan ss -ltnp, lalu bandingkan throughput per proses
Cocok jika: Di antara beberapa socket pada port yang sama, hanya satu yang Recv-Q-nya terus menumpuk, dan proses itu sedang berhenti atau throughput-nya mendekati 0
Tidak cocok jika: Recv-Q semua socket menumpuk merata: lebih mungkin kelebihan beban secara keseluruhan (“Antrean koneksi (backlog) meluap”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

socket(7) — Linux manual page Linux man-pages
Dengan SO_REUSEPORT, beberapa socket bind ke alamat yang sama dan berbagi koneksi TCP serta paket UDP
net/core/sock_reuseport.c (Linux v6.12) Linux kernel
Tanpa program BPF, socket yang menangani dipilih dengan membagi nilai hash paket sesuai jumlah socket dalam grup
Why does one NGINX worker take all the load? Cloudflare
SO_REUSEPORT membagi antrean per worker dengan hash sederhana, sehingga jika satu worker tertahan, semua koneksi yang menumpuk di antreannya ikut berhenti
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK

Error WSAECONNRESET pada socket UDP Windows WSAECONNRESET on a Windows UDP socket

ID sk-udp-connreset · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika server Windows mengirim UDP ke klien yang sudah pergi, notifikasi “port tidak ada” (ICMP) dikirim balik. Notifikasi itu membuat pemanggilan terima berikutnya berakhir dengan error. Jika kode server memperlakukan error ini sebagai kerusakan socket itu sendiri, semua pemain yang memakai socket tersebut ikut terdampak.

Mengapa UDP terus dikirim ke alamat klien yang baru saja keluar, sehingga notifikasi “port tidak ada” (ICMP) dikirim balik → Akibatnya Windows mengakhiri pemanggilan terima berikutnya dengan error WSAECONNRESET (10054), lalu kode server berhenti menerima atau menutup socket → Di layar Semua pemain yang memakai socket itu freeze atau disconnect bersamaan

Gejala: Disconnect, Freeze
Faktor: Packet loss, Stall
Siapa yang mengalami: Seluruh server
Kapan: Sesekali secara acak, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Matikan SIO_UDP_CONNRESET dengan WSAIoctl agar notifikasi ini tidak diterima, dan jika terjadi error terima, cukup catat di log lalu lanjutkan menerima.
Di grafik: Koneksi putus serentak · Jumlah koneksi, log error terima
Yang diperiksa: Cari kode error terima UDP (WSAECONNRESET, 10054) dan catatan loop terima berhenti atau socket ditutup di log server game, lalu periksa di packet capture sisi server apakah ICMP Port Unreachable tiba sesaat sebelumnya
Cocok jika: Sesaat sebelum koneksi putus serentak, error terima WSAECONNRESET tercatat, dan sebelumnya ICMP Port Unreachable datang dari alamat klien yang baru saja keluar
Tidak cocok jika: Server Linux, atau kode sudah mematikan SIO_UDP_CONNRESET: tidak berlaku
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Winsock IOCTLs Microsoft
SIO_UDP_CONNRESET mengaktifkan dan menonaktifkan pelaporan notifikasi UDP “port tidak ada” (PORT_UNREACHABLE)
recvfrom function (winsock.h) Microsoft
WSAECONNRESET pada socket UDP berarti pengiriman sebelumnya menerima ICMP Port Unreachable
Windows Sockets Error Codes Microsoft
Nomor error WSAECONNRESET adalah 10054

L9 Proses game di server

Tick melewati budget (tick overrun) Tick overrun

ID sp-tick-overrun · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika pekerjaan dalam satu tick melewati tick budget (batas waktu per tick), interval tick server memanjang, dan seluruh area itu berjalan lambat atau patah-patah.

Mengapa Pekerjaan yang harus diproses dalam satu tick (misalnya 50 ms) melewati budget → Akibatnya State game yang seharusnya dihitung 20 kali per detik hanya dihitung 8 kali → Di layar Seluruh area itu slow motion (atau patah-patah, tergantung desain server), respons skill terlambat

Gejala: Slow motion, Input lag, Patah-patah
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu, Seluruh server
Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Kurangi komputasi yang mahal, bagi tick ke beberapa thread, sebar pemain (channel), catat waktu pemrosesan tick sebagai metrik.
Tugas Tim Infrastruktur: Tambahkan waktu tick dan utilisasi CPU per core ke monitoring dan alert, pertimbangkan CPU atau instance dengan performa single-core (clock) tinggi.
Kisaran angka: Budget server 20 tick adalah 50 ms, server 30 tick 33 ms, dan server 60 tick 16,7 ms. Untuk berjaga-jaga saat beban tiba-tiba melonjak, lebih aman menyisakan ruang dengan hanya memakai sekitar separuh budget di waktu biasa.
Di grafik: Naik mengikuti beban · Waktu tick server, jumlah pemain per zona dan channel, CPU thread game
Yang diperiksa: Tampilkan waktu pemrosesan tick (p99) dan jumlah tick overrun yang dicatat server dalam satu grafik dengan jumlah pemain per zona dan channel. Jika tidak ada metrik tick, periksa utilisasi CPU satu thread game dengan pidstat -t 1
Cocok jika: Saat pemain berkumpul, waktu tick melewati budget (50 ms untuk server 20 tick), dan selama itu utilisasi CPU thread game menempel di dekat 100%
Tidak cocok jika: Tick melewati budget tetapi CPU thread game rendah: penyebabnya sesuatu yang ditunggu (jeda GC, lock, pemanggilan sinkron). Latensi run queue di bcc runqlat panjang: thread tidak mendapat jatah CPU, jadi lebih mungkin CPU kurang atau thread berlebihan
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Wujud tick yang terlambat berbeda menurut desain server. Server yang memajukan state game sebesar waktu tetap (misalnya 50 ms) setiap tick membuat waktu game itu sendiri melambat, sehingga terjadi slow motion. Server yang menggerakkan objek sekaligus sebesar waktu yang benar-benar berlalu tetap menjaga kecepatan jalannya game, tetapi paket menjadi jarang dan gerakannya melompat besar, sehingga terlihat patah-patah atau teleport. Pada kedua cara itu, respons input tetap terlambat. Jika satu thread game menangani seluruh server, seluruh server melambat; jika thread dibagi per area, hanya area itu yang melambat. Ada juga game seperti EVE Online yang sengaja memperlambat waktu game hingga 10 kali (Time Dilation) dalam pertempuran besar agar komputasi bisa mengejar.
Kasus nyata: CCP Games 2014: Kelebihan beban server dalam pertempuran armada besar HED-GP di EVE Online

5 sumber

VALORANT's 128-Tick Servers Riot Games
Server 128 tick harus menyelesaikan satu frame dalam 7,8125 ms; frame time server diukur per subsistem dan budget-nya dibagi lalu dikelola
HED-GP Technical Retrospective: What a HED-ache CCP Games
Saat kelebihan beban, EVE Online memperlambat waktu game dengan Time Dilation dengan batas bawah 10% (10 kali lebih lambat); di waktu biasa, CPU node di bawah 80%
Handling variation in time Unity
Jika simulasi berinterval tetap tertinggal, langkah pengejaran dijalankan bertumpuk, dan waktu yang melewati batas dibuang sehingga waktu game berjalan lebih lambat dari waktu nyata
pidstat(1) — Linux manual page sysstat
-t menampilkan sekaligus statistik per thread milik proses (utilisasi CPU dan lainnya)
Demonstrations of runqlat, the Linux eBPF/bcc version IO Visor
Menampilkan latensi run queue scheduler (waktu tunggu sampai tugas mendapat jatah CPU) dalam bentuk histogram

Lonjakan perhitungan jarak pandang (AOI, N²) Area-of-interest explosion

ID sp-aoi · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika siapa bisa melihat siapa dihitung dengan membandingkan semua pemain satu sama lain, saat jumlah pemain naik 10 kali, perhitungannya naik 100 kali.

Mengapa Jarak dibandingkan antara semua karakter, atau walaupun sudah dibagi dengan grid, ratusan pemain berkumpul di dekat satu sel → Akibatnya 100 pemain berarti sekitar 10.000 perbandingan, 1.000 pemain sekitar 1 juta perbandingan → Di layar Di tempat ramai seperti world boss atau siege, waktu tick melonjak sehingga terjadi slow motion atau patah-patah

Gejala: Slow motion, Patah-patah
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu, Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Bagi dengan grid atau zona dan bandingkan hanya objek di sekitar, perbarui objek yang jauh lebih jarang, batasi jumlah pemain yang bisa dilihat satu pemain.
Kisaran angka: Jika perbandingan jarak dan pembaruan daftar terlihat/tidak terlihat dihitung 0,1 µs (sepersepuluh juta detik) per pasangan, 1.000 pemain (sekitar 1 juta pasangan) butuh 100 ms per tick. Itu dua kali budget server 20 tick (50 ms).
Di grafik: Naik mengikuti beban · Waktu tick server, jumlah pemain di satu tempat
Yang diperiksa: Tampilkan jumlah pemain per zona dan channel dalam satu grafik dengan waktu tick, beserta waktu yang dipakai untuk perhitungan jarak pandang di dalam tick yang diukur terpisah. Jika tidak ada pengukuran terpisah, periksa porsi CPU per fungsi proses game dengan perf top -p
Cocok jika: Saat jumlah pemain di satu tempat naik 2 kali, waktu tick naik hampir 4 kali, dan fungsi perhitungan jarak pandang dan jarak memakan sebagian besar waktu CPU
Tidak cocok jika: Waktu tick naik sebanding dengan jumlah pemain, atau porsi fungsi pengiriman dan serialisasi besar: lebih mungkin lonjakan broadcast atau biaya serialisasi dan kompresi
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Comparing Interest Management Algorithms for Massively Multiplayer Games ACM
Paper NetGames 2006 (versi yang dipublikasikan penulis). Cara mengukur jarak semua pasangan tidak sanggup menampung pemain yang bertambah; jika dibagi dengan grid persegi, cukup periksa 9 sel di sekitarnya
Replication Graph in Unreal Engine Epic Games
Cara dasar yang memeriksa semua koneksi untuk setiap actor menjadi bottleneck CPU server jika pemain dan actor banyak; MMORPG dan sejenisnya membagi dunia dengan grid dan memakai ulang daftar per sel
perf-top(1) — Linux manual page perf
Menampilkan porsi pemakaian CPU per fungsi (simbol) secara real-time untuk proses (-p) atau thread (-t) yang sedang berjalan

Lonjakan broadcast Broadcast fan-out (N×N)

ID sp-broadcast · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika gerakan satu pemain dikirim ke semua yang melihatnya, jumlah update yang harus dikirim menjadi kuadrat dari jumlah pemain yang berkumpul.

Mengapa Perubahan satu pemain dikirim ke semua yang bisa melihatnya → Akibatnya Jika 1.000 pemain saling melihat, ada 1 juta update setiap tick → Di layar Antrean kirim dan bandwidth jenuh sehingga terjadi keterlambatan dan packet loss (input lag, fast forward, teleport)

Gejala: Input lag, Teleport, Fast forward
Faktor: Latensi, Packet loss
Siapa yang mengalami: Lokasi/channel tertentu, Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Turunkan frekuensi update menurut jarak dan tingkat kepentingan (musuh dekat setiap tick, pemain jauh beberapa kali per detik), batasi jumlah data yang dikirim ke satu pemain dan isi mulai dari yang paling penting, gabungkan beberapa update dalam satu paket, batasi jumlah pemain yang ditampilkan.
Tugas Tim Infrastruktur: Bandingkan bandwidth kirim dan jumlah paket per detik setiap server dengan batas jaringan NIC dan instance lalu pasang alert, pastikan ada ruang yang cukup sebelum event besar.
Kisaran angka: 1.000 pemain × 1.000 pemain × 20 tick = 20 juta update per detik. Jika satu update 40 byte, totalnya sekitar 6,4 Gbps untuk seluruh server dan sekitar 6,4 Mbps per penerima. Jika jumlah pemain yang terlihat dibatasi 150, totalnya sekitar 1 Gbps dan sekitar 1 Mbps per pemain.
Di grafik: Naik mengikuti beban · Paket dan byte yang dikirim server, jumlah pemain di satu tempat
Yang diperiksa: Tampilkan txpck/s dan txkB/s (paket dan KB yang dikirim NIC server per detik) dari sar -n DEV 1 bersama grafik jumlah pemain. Untuk instance cloud, periksa counter batas terlampaui di ethtool -S (di AWS ENA: bw_out_allowance_exceeded dan pps_allowance_exceeded)
Cocok jika: Saat pemain yang berkumpul bertambah, paket dan byte kirim naik lebih tajam dari jumlah pemain (mendekati kuadrat), dan sejak menyentuh batas, counter batas terlampaui atau paket kirim yang dibuang bertambah
Tidak cocok jika: Volume kirim tidak berubah tetapi hanya waktu tick yang naik: lebih mungkin perhitungan jarak pandang atau logika game
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Kasus nyata: CCP Games 2014: Kelebihan beban server dalam pertempuran armada besar HED-GP di EVE Online

5 sumber

HED-GP Technical Retrospective: What a HED-ache CCP Games
Pengiriman O(n²), yaitu aksi n pemain harus dilihat oleh n pemain, adalah faktor pembatas yang tidak terhindarkan dalam pertempuran armada besar
Actor Priority in Unreal Engine Epic Games
Jika bandwidth koneksi jenuh, setiap actor diberi prioritas (jarak, arah pandang, waktu sejak pengiriman terakhir) dan bandwidth dibagikan mulai dari yang paling penting
Detailed Actor Replication Flow in Unreal Engine Epic Games
Frekuensi update per actor ditetapkan dengan NetUpdateFrequency; actor dikirim menurut urutan prioritas, dan jika koneksi jenuh, sisanya ditunda ke tick berikutnya
sar(1) — Linux manual page sysstat
rxpck/s dan txpck/s (paket diterima dan dikirim per detik), rxkB/s dan txkB/s (KB diterima dan dikirim per detik) pada sar -n DEV
Monitor network performance for ENA settings on your EC2 instance AWS
Jumlah paket yang masuk antrean atau dibuang karena bw_out_allowance_exceeded (batas bandwidth kirim terlampaui) dan pps_allowance_exceeded (batas PPS terlampaui)

Kelebihan beban di area single-thread (hotspot) Single-threaded hot zone

ID sp-hotzone · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Pada arsitektur yang menugaskan satu thread untuk setiap area, jika pemain berkumpul di satu tempat, hanya satu core itu yang mencapai 100%.

Mengapa Satu area (channel) ditangani oleh satu thread → Akibatnya Jika pemain berkumpul di satu tempat, hanya core itu yang jenuh, sedangkan core lain masih longgar → Di layar Hanya area itu yang lag, area lain normal

Gejala: Slow motion, Input lag
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Sebar ke beberapa channel, paralelkan pemrosesan di dalam area, batasi jumlah pemain.
Tugas Tim Infrastruktur: Tambahkan utilisasi CPU per core ke monitoring dan alert (satu core yang jenuh tertutup oleh rata-rata seluruh server).
Kisaran angka: Di server 16 core, walaupun satu core 100%, utilisasi CPU seluruh server hanya terlihat sekitar 6%. Masalah ini baru ketahuan jika utilisasi per core diperiksa.
Di grafik: Naik mengikuti beban · Utilisasi CPU per core, CPU per thread
Yang diperiksa: Periksa utilisasi per core dengan mpstat -P ALL 1 dan CPU per thread proses game dengan pidstat -t 1, lalu bandingkan dengan jumlah pemain di zona yang ditangani thread tersibuk
Cocok jika: CPU seluruh server rendah, tetapi hanya satu thread (satu core) yang menempel di dekat 100%, dan pada saat itu pemain berkumpul di zona yang ditangani thread tersebut
Tidak cocok jika: Beberapa core tinggi secara merata: kelebihan beban seluruh server. Hanya %soft (pemrosesan paket masuk) di satu core yang tinggi: lebih mungkin interrupt NIC terpusat di satu core
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Area lain tetap normal hanya jika tick dijalankan terpisah per area. Jika thread-thread area saling menunggu setiap tick lalu bersama-sama maju ke tick berikutnya, satu area yang paling sibuk memperlambat tick seluruh server.
Kasus nyata: CCP Games 2014: Kelebihan beban server dalam pertempuran armada besar HED-GP di EVE Online

3 sumber

Time Dilation – How’s That Going? CCP Games
Time Dilation di EVE Online berlaku per node, sehingga sistem bintang jauh yang berada di node yang sama ikut melambat; pertempuran besar diproses di node yang diperkuat yang hanya memuat 4 sistem bintang
mpstat(1) — Linux manual page sysstat
Menampilkan utilisasi per prosesor dan rata-rata keseluruhan secara terpisah (-P ALL); %soft adalah persentase waktu untuk memproses software interrupt
pidstat(1) — Linux manual page sysstat
-t menampilkan sekaligus statistik per thread milik proses (utilisasi CPU dan lainnya)

Perebutan lock Lock contention

ID sp-lock · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika beberapa thread menunggu satu lock untuk menulis data yang sama, walaupun thread ditambah, hanya satu yang berjalan pada satu waktu.

Mengapa Beberapa thread memakai data bersama secara bersamaan, misalnya balai lelang atau gudang guild → Akibatnya Thread lain menunggu sampai thread yang memegang lock selesai → Di layar Hanya fitur tertentu yang lambat; jika parah, tick seluruh server tertunda

Gejala: Input lag, Freeze
Faktor: Stall
Siapa yang mengalami: Fitur tertentu saja, Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pecah lock menjadi lebih kecil, kurangi pekerjaan di dalam lock, gunakan arsitektur berbasis pesan (tetapkan thread penanggung jawab untuk setiap data, thread lain hanya mengirim permintaan lewat pesan).
Kisaran angka: Jika pekerjaan di dalam lock 20% dari total, throughput maksimal hanya 5 kali throughput satu thread berapa pun thread ditambah; jika 40%, berhenti di 2,5 kali.
Di grafik: Naik mengikuti beban · Waktu pemrosesan permintaan, CPU dan context switching per thread
Yang diperiksa: Periksa context switching voluntary per thread (cswch/s, jumlah thread berhenti karena menunggu sumber daya) dengan pidstat -w -t 1, dan di mana thread menunggu setelah meninggalkan CPU (waktu tunggu per call stack) dengan bcc offcputime -p. Untuk .NET, periksa jumlah lock contention di dotnet-counters (.NET 9 ke atas: dotnet.monitor.lock_contentions, 8 ke bawah: Monitor Lock Contention Count)
Cocok jika: Beban naik tetapi utilisasi CPU tetap rendah sementara waktu pemrosesan naik, sebagian besar waktu tunggu terkumpul di call stack yang mencoba mengambil lock, dan jumlah lock contention ikut naik
Tidak cocok jika: CPU penuh: masalah volume komputasi (tick melewati budget, kelebihan beban di area single-thread). Tempat menunggunya pemanggilan DB atau file: lebih mungkin pemanggilan sinkron di thread game
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Masalah ini muncul pada arsitektur yang membuat beberapa thread mengubah data game bersama-sama. Arsitektur yang menugaskan satu thread per area atau fitur dan hanya bertukar pesan hampir tidak memakai lock, tetapi harus waspada terhadap pekerjaan yang menumpuk di satu thread (kelebihan beban di area single-thread). Jika thread game menunggu lock yang dipegang oleh operasi penyimpanan yang lambat, seluruh tick itu berhenti.
Kasus nyata: Roblox 2021: Gangguan 73 jam di Roblox: perebutan sumber daya di cluster service discovery (Consul)

6 sumber

Amdahl's Law in the Multicore Era IEEE
Paper IEEE Computer 2008 (versi yang dipublikasikan penulis). Jika porsi yang tidak bisa diparalelkan adalah 1−f, berapa pun core ditambah, percepatannya tidak bisa melewati 1/(1−f) (hukum Amdahl)
Request scheduling Microsoft
Grain (actor) di Orleans memakai model eksekusi single-thread yang memproses permintaan satu per satu sampai selesai, sehingga state tidak diubah bersamaan; jika saling menunggu respons, deadlock bisa terjadi
pidstat(1) — Linux manual page sysstat
cswch/s pada -w adalah jumlah context switching voluntary karena menunggu sumber daya, -t untuk menampilkan per thread
Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
Menjumlahkan waktu thread berhenti dan meninggalkan CPU (off-CPU) per call stack, -p untuk menentukan proses
Well-known EventCounters in .NET Microsoft
Monitor Lock Contention Count (monitor-lock-contention-count): jumlah lock contention yang terjadi saat mencoba mengambil monitor lock
.NET runtime metrics .NET
dotnet.monitor.lock_contentions sejak .NET 9: jumlah lock contention yang terjadi saat mencoba mengambil monitor lock sejak proses dimulai

Deadlock Deadlock

ID sp-deadlock · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika dua thread saling menunggu lock yang dipegang thread lainnya, keduanya berhenti selamanya.

Mengapa Thread A memegang lock 1 dan menunggu lock 2, sedangkan thread B memegang lock 2 dan menunggu lock 1 → Akibatnya Keduanya berhenti selamanya, dan thread lain yang terkait ikut berhenti satu per satu → Di layar Seluruh server berhenti, lalu watchdog memulai ulang server sehingga semua pemain disconnect

Gejala: Freeze, Disconnect
Faktor: Stall
Siapa yang mengalami: Seluruh server, Fitur tertentu saja
Kapan: Sesekali secara acak, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Tetapkan aturan urutan pengambilan lock, pakai lock dengan timeout, pasang watchdog dan simpan thread dump pada saat server berhenti.
Di grafik: Koneksi putus serentak · Jumlah koneksi, volume kirim server
Yang diperiksa: Ambil call stack semua thread selama server berhenti. Gunakan jstack untuk JVM (otomatis menemukan dan menandai deadlock), dotnet-stack untuk .NET, dan thread apply all bt di gdb untuk server native, atau ambil core file dengan gcore, mulai ulang server, lalu analisis
Cocok jika: Dua thread atau lebih berhenti dengan stack yang saling menunggu lock yang dipegang thread lainnya, dan selama itu utilisasi CPU proses mendekati 0
Tidak cocok jika: Selama server berhenti, satu thread terus berputar dengan CPU 100%: infinite loop. Thread-thread menunggu respons DB atau layanan eksternal: lebih mungkin pemanggilan sinkron atau thread pool habis
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

6 sumber

Runtime locking correctness validator Linux kernel
Jika dua lock diambil dengan urutan yang berlawanan, terjadi penantian melingkar sehingga muncul deadlock (lock inversion deadlock); kernel Linux memeriksa urutan lock dan memberi peringatan lebih awal
Liveness, Readiness, and Startup Probes Kubernetes
Kondisi deadlock, yaitu proses masih berjalan tetapi tidak bisa maju, dideteksi oleh liveness probe lalu container dimulai ulang
Diagnostic Tools (Java SE 21 Troubleshooting Guide) Oracle
jstack mencetak stack semua thread di JVM yang sedang berjalan, sekaligus menemukan dan menandai deadlock (Found one Java-level deadlock)
dotnet-stack diagnostic tool - .NET CLI Microsoft
Menangkap dan mencetak managed stack semua thread di proses .NET
Threads (Debugging with GDB) GNU Project
thread apply all menjalankan perintah yang sama (bt: mencetak call stack) di semua thread
gcore(1) — Linux manual page gdb
Membuat core file dari program yang sedang berjalan; setelah itu program tetap berjalan seperti biasa

Pemanggilan sinkron di thread game Synchronous DB / file I/O on the game loop

ID sp-sync-call · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika di tengah tick server menunggu respons DB atau penulisan file, seluruh jalannya game di server berhenti selama waktu itu.

Mengapa Di dalam tick, server menunggu query dan penyimpanan DB, penulisan log, atau pemanggilan API eksternal → Akibatnya Jika DB butuh 100 ms, tick juga berhenti 100 ms → Di layar Setiap kali DB atau disk melambat, seluruh field tersendat sesaat

Gejala: Freeze, Patah-patah
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu, Seluruh server
Kapan: Saat melakukan aksi tertentu, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Alihkan semua pekerjaan lambat (query dan penyimpanan DB, penulisan log, pemanggilan API eksternal) ke pemrosesan asinkron dan terapkan hasilnya di tick berikutnya (jika hanya memasang timeout, server tetap berhenti selama menunggu).
Kisaran angka: Pulang-pergi ke DB di data center yang sama hanya 0,5 ms, tetapi jika dipanggil 100 kali dalam satu tick, totalnya 50 ms. Itu saja sudah menghabiskan seluruh budget server 20 tick.
Di grafik: Melonjak acak sesekali · Waktu tick server, latensi query DB
Yang diperiksa: Tampilkan grafik waktu tick bersama latensi query DB (slow query log dan sebagainya) dan latensi disk pada sumbu waktu yang sama. Jika tidak ada metrik tick, periksa di mana thread game menunggu dengan bcc offcputime -p
Cocok jika: Waktu lonjakan tick bertepatan dengan waktu lonjakan latensi DB atau file, dan waktu tunggu thread game terkumpul di call stack penerimaan respons DB atau penulisan file
Tidak cocok jika: Latensi DB dan disk tenang tetapi tick melonjak: lebih mungkin jeda GC atau perebutan lock
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Designs, Lessons and Advice from Building Large Distributed Systems Google
Keynote LADIS 2009 (Jeff Dean). Pulang-pergi di dalam data center yang sama sekitar 0,5 ms (500.000 ns)
ASP.NET Core Best Practices Microsoft
Akses data, I/O, dan pekerjaan yang lama dipanggil secara asinkron; pemanggilan blocking yang sinkron menyebabkan thread pool habis dan respons terlambat
Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
Menjumlahkan waktu thread berhenti dan meninggalkan CPU (off-CPU) per call stack, -p untuk menentukan proses

Penumpukan antrean pesan Mailbox / job queue backlog

ID sp-queue · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika permintaan masuk lebih cepat daripada kecepatan pemrosesan dan menumpuk di antrean, permintaan di belakang baru diproses beberapa detik kemudian atau dibuang.

Mengapa Permintaan datang lebih cepat daripada kecepatan pemrosesan → Akibatnya Antrean memanjang, dan permintaan dibuang begitu melewati batas → Di layar Respons skill dan trade terlambat, atau aksinya hilang

Gejala: Input lag, Aksi hilang / rollback
Faktor: Latensi, Packet loss
Siapa yang mengalami: Lokasi/channel tertentu, Fitur tertentu saja
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pantau panjang antrean, terapkan kebijakan membuang permintaan lama lebih dulu, paralelkan pemrosesan.
Di grafik: Mendatar di batas · Panjang antrean dan umur pesan tertua, jumlah yang diproses per detik
Yang diperiksa: Periksa panjang setiap antrean, umur pesan tertua, serta jumlah pesan yang masuk, diproses, dan dibuang per detik yang dicatat server. Jika tidak ada metrik di kode, periksa Recv-Q socket game (data yang sudah diterima kernel tetapi belum dibaca proses) dengan ss (atau netstat)
Cocok jika: Selama jumlah yang masuk melebihi jumlah yang diproses, jumlah yang diproses tertahan di satu nilai dan tidak naik lagi, sedangkan panjang dan umur antrean serta jumlah yang dibuang terus bertambah
Tidak cocok jika: Antrean pendek dan umur pesan kecil tetapi respons tetap terlambat: lebih mungkin latensi koneksi atau keterlambatan tick itu sendiri
Sarana pemeriksaan: Log dan metrik server atau klien game
Kasus nyata: CCP Games 2014: Kelebihan beban server dalam pertempuran armada besar HED-GP di EVE Online

4 sumber

Avoiding insurmountable queue backlogs AWS
Amazon Builders' Library. Penumpukan dipantau lewat umur pesan yang menunggu; sistem real-time memproses data baru lebih dulu (mendekati LIFO) dan kadang membuang pesan lama
Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
Jika permintaan datang lebih cepat daripada kecepatan pemrosesan, antrean penuh dan latensi naik; permintaan lama yang sudah tidak berguna dikurangi dengan LIFO atau CoDel sebagai pengganti FIFO
ss(8) — Linux manual page iproute2
Tool untuk menampilkan statistik socket (informasinya mirip netstat); -p menampilkan proses yang memakai socket
netstat(8) — Linux manual page net-tools
Recv-Q: jumlah byte di socket yang terhubung yang belum diambil oleh program pengguna

Timer terpicu serentak Synchronized timers

ID sp-timer-burst · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika respawn semua monster, berakhirnya semua buff, dan hadiah tepat di pergantian jam menumpuk di tick yang sama, tick itu saja menjadi puluhan kali lebih berat.

Mengapa Timer respawn, kedaluwarsa, hadiah, dan simpan otomatis diatur ke waktu yang sama → Akibatnya Dalam satu tick itu, pekerjaannya puluhan kali lipat dari biasanya → Di layar Tersendat sesaat setiap kali waktu yang ditentukan tiba

Gejala: Freeze, Patah-patah
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu, Seluruh server
Kapan: Secara berkala
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Sebar waktu timer sedikit demi sedikit secara acak, bagi pemrosesannya ke beberapa tick.
Di grafik: Melonjak secara berkala · Waktu tick server
Yang diperiksa: Kumpulkan waktu-waktu lonjakan tick dan periksa intervalnya (tepat di pergantian jam, setiap 5 menit, dan sebagainya). Cocokkan dengan daftar timer respawn, berakhirnya buff, hadiah, dan simpan otomatis yang berjalan pada waktu yang sama
Cocok jika: Tick selalu melonjak pada waktu yang sama atau dengan interval yang sama, dan pada waktu itu ada pekerjaan timer game yang terpicu bersamaan
Tidak cocok jika: Ada periodenya, tetapi bertepatan dengan waktu jeda di log GC atau waktu cron dan backup server: lebih mungkin jeda GC stop-the-world di server atau tugas terjadwal
Sarana pemeriksaan: Log dan metrik server atau klien game

1 sumber

Timeouts, retries, and backoff with jitter AWS
Amazon Builders' Library. Tambahkan jitter ke semua timer, pekerjaan berkala, dan pekerjaan tertunda untuk menyebar beban yang menumpuk di waktu yang sama; ada contoh kasus permintaan berperiode 1 menit dari banyak server yang menumpuk di beberapa detik pertama setiap menit

Lonjakan pathfinding Pathfinding storms

ID sp-pathfinding · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika ratusan monster mengejar pemain secara bersamaan sambil menghitung rute, pemakaian CPU menjadi sangat besar.

Mengapa Monster mengejar secara bersamaan saat mob pulling (menarik banyak monster sekaligus) atau spawn besar-besaran → Akibatnya Pathfinding dihitung untuk setiap monster → Di layar Hanya area berburu itu yang slow motion

Gejala: Slow motion
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Simpan rute di cache, batasi jumlah perhitungan, bagi ke beberapa tick.
Di grafik: Naik mengikuti beban · Waktu tick server, jumlah monster per zona
Yang diperiksa: Periksa jumlah monster yang sedang mengejar pemain per zona dan waktu tick. Jika tidak ada hitungan terpisah, periksa porsi CPU per fungsi proses game dengan perf top -p
Cocok jika: Saat mob pulling atau spawn besar-besaran, waktu tick naik, dan fungsi pathfinding (pencarian rute) memakan porsi besar dari waktu CPU
Tidak cocok jika: Monster sedikit dan hanya pemain yang banyak, tetapi tick naik: lebih mungkin perhitungan jarak pandang atau broadcast
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

AI.NavMesh.pathfindingIterationsPerFrame Unity
Pathfinding hanya diproses sebanyak jumlah node tertentu per frame sehingga terbagi ke beberapa frame; game tetap mulus walaupun rutenya panjang atau permintaannya banyak sekaligus
perf-top(1) — Linux manual page perf
Menampilkan porsi pemakaian CPU per fungsi (simbol) secara real-time untuk proses (-p) yang sedang berjalan

Biaya serialisasi dan kompresi Serialization / compression cost

ID sp-serialize · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Mengubah data yang akan dikirim menjadi byte dan mengompresinya juga memakan CPU, dan biaya ini melonjak saat pemain banyak.

Mengapa Setiap update, struct diubah menjadi byte lalu dikompresi → Akibatnya Biaya naik sebanding dengan kuadrat jumlah pemain → Di layar Pengiriman terlambat sehingga terjadi input lag

Gejala: Input lag
Faktor: Stall, Latensi
Siapa yang mengalami: Lokasi/channel tertentu
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pakai ulang paket yang sudah dibuat sekali untuk banyak pemain, gunakan format yang ringan.
Di grafik: Naik mengikuti beban · Utilisasi CPU server, CPU thread yang membuat paket
Yang diperiksa: Dengan perf top -p, bandingkan porsi fungsi serialisasi, kompresi, dan enkripsi (termasuk fungsi library seperti zlib, LZ4, OpenSSL) dalam waktu CPU proses game saat pemain sedikit dan saat pemain berkumpul
Cocok jika: Makin banyak pemain berkumpul, makin besar porsi fungsi serialisasi, kompresi, dan enkripsi, dan CPU thread yang membuat paket jenuh lebih dulu
Tidak cocok jika: Porsi fungsi-fungsi ini kecil: lebih mungkin perhitungan jarak pandang atau logika game
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Pada koneksi yang mengenkripsi paket (TLS, DTLS, dan sebagainya), enkripsi dan dekripsi juga memakai CPU. Enkripsi dilakukan terpisah untuk setiap koneksi, jadi walaupun paket yang sudah dibuat sekali dipakai ulang untuk banyak pemain, biaya enkripsinya tetap sebanyak jumlah penerima. Cipher simetris seperti AES-GCM cukup cepat sehingga satu core bisa memproses beberapa GB per detik, dan porsinya biasanya kecil. Namun, kecepatannya sangat bergantung pada ukuran unit yang dienkripsi sekaligus (record), sehingga pada game dengan banyak paket kecil, biaya per byte menjadi besar. Pada handshake yang dilakukan sekali per koneksi, server menandatangani dengan kunci sertifikat dan menghitung pertukaran kunci (ECDHE). Satu core hanya sanggup melakukan sekitar 1.100 (RSA 2048) hingga 18.000 (ECDSA P-256) tanda tangan per detik dan sekitar 9.000 pertukaran kunci per detik, sehingga menjadi beban saat login menumpuk.

4 sumber

Introduction to Iris in Unreal Engine Epic Games
State yang akan direplikasi disimpan sebagai satu salinan terkuantisasi sehingga pekerjaan yang mahal berkurang, dan hasil pekerjaan itu dipakai bersama oleh banyak koneksi
VALORANT's 128-Tick Servers Riot Games
Cara membandingkan variabel replikasi untuk setiap klien di setiap frame lalu mengemas nilai yang berubah adalah pekerjaan lambat yang membaca memori secara acak, sehingga memakan banyak CPU server
How "expensive" is crypto anyway? Cloudflare
Pengukuran BoringSSL: AES-128-GCM sekitar 3,7 GB per detik (sangat bergantung pada ukuran record); per detik, satu core sanggup melakukan tanda tangan RSA 2048 sebanyak 1.120 kali, tanda tangan ECDSA P-256 sebanyak 18.477 kali, dan ECDHE P-256 sebanyak 9.394 kali; di server edge Cloudflare, CPU yang dipakai library TLS sekitar 1,8%
perf-top(1) — Linux manual page perf
Menampilkan porsi pemakaian CPU per fungsi (simbol) secara real-time untuk proses (-p) yang sedang berjalan

Crash di server Server process crash

ID sp-crash · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika proses server mati karena error yang tidak tertangani, semua pemain di server itu disconnect bersamaan.

Mengapa Error fatal seperti error yang menunjuk objek yang tidak ada (null reference), data yang salah, atau memori habis → Akibatnya Proses server (atau zona) mati → Di layar Semua pemain disconnect bersamaan, dan progres bisa kembali ke kondisi saat penyimpanan terakhir (rollback)

Gejala: Disconnect, Aksi hilang / rollback
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu, Seluruh server
Kapan: Sesekali secara acak, Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Analisis crash dump dan perbaiki penyebabnya, simpan lebih sering.
Tugas Tim Infrastruktur: Siapkan restart otomatis untuk proses, lingkungan untuk mengumpulkan dan menyimpan crash dump, alert segera saat server down.
Di grafik: Koneksi putus serentak · Jumlah koneksi, jumlah restart proses
Yang diperiksa: Periksa catatan core dump di coredumpctl list (waktu, PID, sinyal terminasi) dan catatan terminasi abnormal serta restart di service manager (systemd). Untuk server Windows, periksa file dump yang ditinggalkan WER
Cocok jika: Pada saat jumlah koneksi sesaat anjlok hingga mendekati 0, ada terminasi abnormal proses server game dan core dump
Tidak cocok jika: Proses tetap hidup tetapi koneksi terputus: lebih mungkin perangkat jaringan atau idle timeout. Ada catatan restart oleh watchdog setelah server lama berhenti: lebih mungkin infinite loop atau deadlock
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Collecting User-Mode Dumps Microsoft
Konfigurasi Windows Error Reporting (WER) agar full dump atau mini dump dikumpulkan secara lokal saat program user mode crash
systemd.service(5) — Linux manual page systemd
Restart=on-failure memulai ulang service secara otomatis saat terjadi terminasi abnormal, terminasi oleh sinyal (termasuk core dump), atau timeout watchdog; dianjurkan untuk service yang berjalan lama
coredumpctl(1) — Linux manual page systemd
Menampilkan daftar core dump yang disimpan systemd-coredump dengan list, beserta waktu crash, PID, dan sinyal penyebab crash

Thread pool habis Thread pool starvation

ID sp-threadpool · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika semua worker thread tertahan oleh pekerjaan lambat, permintaan baru hanya bisa menunggu tanpa kepastian.

Mengapa Worker thread tertahan karena menunggu respons API eksternal atau DB → Akibatnya Tidak ada thread yang bisa ditugaskan untuk permintaan baru → Di layar Fitur tertentu seperti login atau toko mengalami loading tanpa henti

Gejala: Tidak bisa masuk / loading tanpa henti, Input lag, Freeze
Faktor: Stall
Siapa yang mengalami: Fitur tertentu saja, Seluruh server
Kapan: Saat banyak pemain berkumpul, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pasang timeout pada pemanggilan yang lambat, pisahkan thread pool per fitur, ubah ke asinkron.
Di grafik: Mendatar di batas · Jumlah thread dan panjang antrean thread pool, waktu pemrosesan permintaan
Yang diperiksa: Untuk .NET, periksa jumlah thread dan panjang antrean thread pool di dotnet-counters monitor (.NET 9 ke atas: dotnet.thread_pool.thread.count dan dotnet.thread_pool.queue.length, 8 ke bawah: ThreadPool Thread Count dan ThreadPool Queue Length), lalu cek di mana worker thread menunggu dengan dotnet-stack. Untuk JVM dan server native, cek hal yang sama dengan thread dump
Cocok jika: Utilisasi CPU jauh di bawah 100%, tetapi jumlah thread terus naik perlahan atau menempel di batas atas, antrean menumpuk, dan sebagian besar worker menunggu respons dari pemanggilan eksternal yang sama (DB, HTTP)
Tidak cocok jika: Antrean kosong tetapi tetap lambat: tujuan pemanggilannya sendiri yang lambat, jadi lebih mungkin kegagalan berantai atau ketergantungan pada layanan eksternal
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Pada arsitektur yang memakai worker thread pool yang sama untuk menerima paket dan menjalankan logika game, begitu beberapa pekerjaan lambat menahan semua worker, pemrosesan paket di seluruh server berhenti.
Kasus nyata: Riot Games 2021: Gangguan 5 jam di League of Legends EUW: satu DB pendukung menghentikan seluruh server

5 sumber

Debug ThreadPool Starvation Microsoft
Jika tidak ada thread tersisa di pool dan pekerjaan baru harus menunggu, respons melambat; penyebabnya kode blocking yang menahan thread. Di dotnet-counters, CPU jauh di bawah 100% tetapi dotnet.thread_pool.thread.count terus naik perlahan adalah tanda thread pool habis (dotnet.thread_pool.queue.length juga sering besar); tempat thread menunggu dicek dengan dotnet-stack
Avoiding insurmountable queue backlogs AWS
Jumlah pemrosesan bersamaan = laju kedatangan × latensi (hukum Little). Pada 100 permintaan per detik, jika latensi naik dari 100 ms menjadi 10 detik, kebutuhan thread naik dari 10 menjadi 1.000 sehingga pool habis
Bulkhead Pattern Microsoft Azure
Jika connection pool dan thread pool dipisah untuk setiap tujuan pemanggilan, gangguan di satu tujuan hanya memblokir pool miliknya
.NET runtime metrics .NET
dotnet.thread_pool.thread.count (jumlah thread di thread pool) dan dotnet.thread_pool.queue.length (jumlah pekerjaan yang menunggu) tersedia sejak .NET 9
Well-known EventCounters in .NET Microsoft
ThreadPool Thread Count (threadpool-thread-count) dan ThreadPool Queue Length (threadpool-queue-length) untuk .NET 8 ke bawah

Infinite loop dan logika lepas kendali Infinite loop / runaway logic

ID sp-infinite-loop · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika satu tick tidak pernah selesai karena bug, server berhenti, lalu watchdog memulai ulang server secara paksa.

Mengapa Perulangan tidak pernah selesai karena kondisi yang salah, atau rekursi lepas kendali → Akibatnya Tick tidak selesai sehingga server berhenti → Di layar Game freeze, lalu semua pemain disconnect

Gejala: Freeze, Disconnect
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu, Seluruh server
Kapan: Saat melakukan aksi tertentu, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Batasi jumlah perulangan, pasang watchdog, buat tes yang mereproduksi input bermasalah.
Di grafik: Koneksi putus serentak · Jumlah koneksi, CPU per thread
Yang diperiksa: Selama server berhenti, periksa CPU per thread dengan pidstat -t 1, lalu cek di fungsi mana thread yang berputar 100% itu berjalan dengan perf top -t (ID thread) atau gdb. Jika server sudah dimulai ulang, periksa catatan timeout watchdog (WatchdogSec di systemd, liveness probe Kubernetes yang gagal)
Cocok jika: Selama server berhenti, satu thread game menempel di CPU 100%, dan stack-nya terus berputar di dalam fungsi atau perulangan yang sama
Tidak cocok jika: Selama server berhenti CPU mendekati 0: lebih mungkin deadlock atau menunggu respons eksternal
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

systemd.service(5) — Linux manual page systemd
WatchdogSec=: jika service tidak mengirim sinyal hidup (WATCHDOG=1) dalam waktu yang ditentukan, service dianggap gagal lalu dihentikan, dan dimulai ulang otomatis sesuai pengaturan Restart=
Liveness, Readiness, and Startup Probes Kubernetes
Kondisi proses masih berjalan tetapi tidak bisa maju dideteksi oleh liveness probe lalu dimulai ulang; secara default, pemeriksaan dilakukan setiap 10 detik dan restart terjadi setelah 3 kali gagal berturut-turut
pidstat(1) — Linux manual page sysstat
-t menampilkan sekaligus statistik per thread milik proses (utilisasi CPU dan lainnya)
perf-top(1) — Linux manual page perf
Menampilkan porsi pemakaian CPU per fungsi (simbol) secara real-time untuk thread (-t) atau proses (-p) yang sedang berjalan

Pertempuran terpusat pada satu target (world boss) Hot entity / combat event fan-out

ID sp-hot-entity · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika ratusan pemain menyerang satu boss secara bersamaan, perhitungan untuk boss itu terpusat di satu tempat, dan informasi setiap serangan dikirim ke semua yang melihatnya.

Mengapa Ratusan pemain terus-menerus memakai skill, buff, dan debuff pada satu boss → Akibatnya Perhitungan HP, daftar aggro, dan debuff boss terpusat di satu tempat, dan setiap serangan mengirim paket angka damage dan efek ke semua yang melihat → Di layar Skill terlambat masuk dan angka damage muncul sekaligus, hanya area sekitar boss yang slow motion

Gejala: Input lag, Fast forward, Slow motion
Faktor: Stall, Latensi
Siapa yang mengalami: Lokasi/channel tertentu
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Gabungkan atau hilangkan angka damage dan efek milik pemain lain, batasi jumlah debuff pada satu target, bagi pemrosesan serangan ke beberapa tick.
Kisaran angka: Jika 800 pemain masing-masing menyerang 2 kali per detik, ada 1.600 serangan per detik. Jika semuanya diberitahukan ke 800 pemain yang melihat, jumlahnya 1,28 juta pesan per detik.
Di grafik: Naik mengikuti beban · Waktu tick server, jumlah pesan yang dikirim
Yang diperiksa: Periksa waktu tick dan jumlah paket kirim pada saat pertarungan boss bersama jumlah pemain di sekitar boss, dan jika memungkinkan, jumlah event (serangan, buff, debuff) per detik untuk setiap target
Cocok jika: Saat pemain di sekitar boss bertambah, waktu tick dan volume kirim naik tajam, dan jumlah event per detik pada satu boss puluhan kali lebih banyak daripada target lain
Tidak cocok jika: Pemain yang hanya berkumpul di satu tempat tanpa boss pun melambat dengan cara yang sama: lebih mungkin perhitungan jarak pandang atau lonjakan broadcast
Sarana pemeriksaan: Log dan metrik server atau klien game

1 sumber

HED-GP Technical Retrospective: What a HED-ache CCP Games
Satu serangan pun harus diberitahukan ke semua klien yang melihat, sehingga muncul beban O(n²), yaitu n pemain memberi tahu n pemain; serangan drone yang menghasilkan banyak pesan membuat beban ini membesar lebih cepat

Lonjakan spawn saat masuk area padat Spawn burst when entering a crowd

ID sp-spawn-burst · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Saat pemain memakai teleportasi ke kota yang ramai, server harus mengirim tampilan, perlengkapan, dan status ratusan pemain yang baru terlihat sekaligus.

Mengapa Pemain tiba-tiba muncul di tempat ramai karena teleportasi, login, atau pindah channel → Akibatnya Server membuat dan mengirim informasi lengkap ratusan pemain sekaligus, dan PC Anda juga memuat semuanya sekaligus → Di layar Layar freeze sebentar tepat setelah tiba, karakter muncul satu per satu dengan terlambat, dan terjadi input lag

Gejala: Freeze, Input lag, Fast forward
Faktor: Stall, Latensi
Siapa yang mengalami: Hanya saya, Lokasi/channel tertentu
Kapan: Saat bergerak atau pindah area, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: kirim bertahap ke beberapa tick mulai dari yang terdekat, simpan informasi tampilan di cache. Klien: terima data lebih dulu selama layar loading, buat karakter yang diterima secara bertahap di beberapa frame.
Kisaran angka: Jika informasi tampilan, perlengkapan, dan buff satu pemain 300 byte, 500 pemain berarti sekitar 150 KB. Dalam sekejap, data sebesar puluhan kali lipat volume kirim satu tick biasa (beberapa KB) menumpuk sekaligus.
Di grafik: Melonjak tepat setelah server dibuka · Byte kirim per koneksi, frame time klien
Yang diperiksa: Periksa jumlah byte dan paket yang dikirim ke koneksi itu selama beberapa detik setelah tiba di tempat ramai (log server) serta frame time klien (net graph, log klien)
Cocok jika: Tepat setelah tiba, volume kirim koneksi itu melonjak hingga puluhan kali lipat satu tick biasa lalu turun kembali, dan pada saat yang sama frame time klien juga melonjak
Tidak cocok jika: Tetap freeze dengan cara yang sama walaupun pindah ke tempat sepi: lebih mungkin pindah zona (handoff antarserver) atau loading di klien
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

Detailed Actor Replication Flow in Unreal Engine Epic Games
Saat actor channel pertama kali dibuka, informasi seperti posisi dan rotasi awal ikut dikirim; jika koneksi jenuh, actor sisanya ditunda ke tick berikutnya
Actor Priority in Unreal Engine Epic Games
Prioritas ditentukan berdasarkan jarak dan arah pandang, lalu actor yang dekat dan terlihat dikirim lebih dulu

Penumpukan objek (item dan summon yang tidak dibersihkan) Entity / timer buildup over uptime

ID sp-entity-buildup · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika item di tanah, summon, dan timer yang sudah selesai tidak dibersihkan dan terus menumpuk, makin lama server menyala, makin banyak pekerjaan di setiap tick.

Mengapa Item di tanah, summon, timer kedaluwarsa, dan data party kosong tidak dihapus tepat waktu → Akibatnya Daftar yang ditelusuri setiap tick makin panjang setiap hari → Di layar Normal tepat setelah maintenance, tetapi setelah beberapa hari hanya server atau area itu yang makin lamban

Gejala: Slow motion, Patah-patah, Input lag
Faktor: Stall
Siapa yang mengalami: Seluruh server, Lokasi/channel tertentu
Kapan: Makin lama menyala
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Catat jumlah objek per area sebagai metrik dan pantau trennya, tetapkan umur untuk setiap objek dan batas jumlahnya, bersihkan secara berkala.
Kisaran angka: Pada server yang menelusuri semua objek sekali setiap tick, jika jumlah objek naik dua kali lipat, waktu tick untuk bagian itu juga naik dua kali lipat.
Di grafik: Naik perlahan lalu anjlok · Jumlah objek per zona, waktu tick server
Yang diperiksa: Tampilkan jumlah objek per zona dan server (item di tanah, summon, timer) serta waktu tick dalam rentang yang lebih panjang dari siklus maintenance (beberapa minggu)
Cocok jika: Jumlah objek dan waktu tick yang mulai rendah tepat setelah maintenance naik setiap hari, lalu anjlok saat maintenance atau restart, berulang terus, dan selama itu memori tetap longgar
Tidak cocok jika: Tick tidak berubah tetapi hanya memori yang terus naik: lebih mungkin kebocoran memori
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Seperti kebocoran memori, kondisinya makin buruk makin lama server menyala. Bedanya, memori masih longgar dan hanya waktu tick yang naik. Jika grafik jumlah objek berbentuk gigi gergaji mengikuti siklus maintenance, inilah penyebabnya.

2 sumber

Actor Ticking in Unreal Engine Epic Games
Actor dan component menjalankan tick sekali setiap frame jika intervalnya tidak ditetapkan, dan tick bisa dimatikan jika tidak diperlukan
AActor::SetLifeSpan Epic Games
Jika umur ditetapkan pada actor, actor itu otomatis dihancurkan saat umurnya habis

Pola trafik berubah akibat patch Patch changes traffic pattern

ID sp-patch-traffic · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur)

Jika konten, efek, dan data sinkronisasi baru memperbesar ukuran dan frekuensi paket, server yang tadinya lancar mulai terbentur batas MTU, bandwidth, dan jumlah paket setelah patch.

Mengapa Patch menambah efek skill, data sinkronisasi, dan informasi item baru sehingga paket menjadi lebih besar atau lebih sering → Akibatnya Paket besar melewati MTU sehingga terfragmentasi, dan volume yang bertambah terbentur bandwidth, batas PPS cloud, dan buffer kirim → Di layar Sejak tepat setelah patch, terjadi teleport, skill tidak keluar, dan input lag di tempat ramai. Infrastruktur tidak diubah sama sekali, tetapi packet loss bertambah

Gejala: Teleport, Aksi hilang / rollback, Input lag
Faktor: Packet loss, Latensi
Siapa yang mengalami: Seluruh server, Lokasi/channel tertentu, Wilayah/ISP tertentu
Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari, Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Pengembang Game: Pecah sendiri paket menjadi maksimal 1.200 byte, kirim hanya perubahan untuk data sinkronisasi baru dan turunkan frekuensinya menurut jarak dan tingkat kepentingan, sebelum deploy bandingkan paket dan byte per detik per pemain serta ukuran paket terbesar dengan build sebelumnya di server uji, catat versi build di metrik trafik.
Tugas Tim Infrastruktur: Server/OS: tandai waktu deploy di grafik dan bandingkan paket dan byte per detik per pemain serta ukuran paket rata-rata sebelum dan sesudah deploy, pasang alert pada counter batas instance terlampaui, pindah ke instance yang lebih besar jika perlu. Jaringan: periksa batas pemrosesan firewall, load balancer, dan perangkat proteksi DDoS, serta apakah fragmen diblokir.
Kisaran angka: Paket UDP aman jika berukuran maksimal 1.200 byte. MTU jalur internet biasanya 1.500 byte dan lebih kecil jika melewati tunnel (1.476 byte untuk tunnel GRE). Paket yang melewati MTU jalur akan terfragmentasi atau dibuang, dan paket yang terfragmentasi hilang seluruhnya walaupun hanya satu fragmen yang hilang. Jika paket per detik per pemain naik 20%, total di server juga naik 20%, sehingga instance yang sudah dipakai mendekati batas langsung melewatinya.
Di grafik: Naik seperti anak tangga · Paket dan byte per detik per pemain, ukuran paket rata-rata
Yang diperiksa: Bagi paket dan byte per detik di NIC server (rxpck/s, txpck/s, rxkB/s, txkB/s dari sar -n DEV; di EC2: NetworkPacketsOut dan NetworkOut) dengan jumlah pemain online bersamaan, lalu bandingkan sebelum dan sesudah waktu deploy. Hitung ukuran paket rata-rata dengan byte ÷ paket, dan lihat distribusi ukurannya dari packet capture lewat statistik Packet Lengths di Wireshark
Cocok jika: Sejak tepat setelah deploy, paket dan byte per pemain atau ukuran paket rata-rata naik satu tingkat lalu bertahan, dan sejak waktu yang sama jumlah fragmen yang dibuat server (fragcrt/s di sar -n IP) atau counter batas instance terlampaui (pps_allowance_exceeded dan bw_out_allowance_exceeded di AWS ENA) bertambah
Tidak cocok jika: Pola trafik sama sebelum dan sesudah deploy, tetapi hanya latensi dan packet loss yang naik: periksa perubahan infrastruktur pada waktu yang sama (konfigurasi, rute, perangkat, update OS dan kernel)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Jika ada laporan “sebelum patch lancar-lancar saja”, inilah penyebab dari sisi game yang perlu diperiksa lebih dulu bersama perubahan infrastruktur. Walaupun catatan patch tidak menyebut perubahan jaringan, di tempat ramai satu efek atau data sinkronisasi baru dikalikan ratusan pemain. Titik tempat trafik tambahan itu benar-benar terbentur dibahas di entri “Fragmentasi IP pada paket UDP”, “Batas PPS cloud terlampaui”, “Bandwidth NIC penuh”, “Buffer socket kernel terlalu kecil”, dan “Batas pemrosesan perangkat perantara terlampaui (firewall, IPS, proteksi DDoS)”. Entri ini membahas kasus ketika titik awal yang membuat batas itu tersentuh adalah patch game, jadi kurangi dulu trafik yang bertambah akibat patch sebelum menaikkan batas. Jika OS dan kernel juga diperbarui pada waktu yang sama, bedakan dari “Perubahan performa setelah update OS, kernel, driver, atau firmware” dengan melihat apakah trafik per pemain berubah.

7 sumber

RFC 8085: UDP Usage Guidelines IETF
Aplikasi UDP sebaiknya tidak mengirim datagram yang melewati MTU jalur (SHOULD NOT); jika satu fragmen hilang, seluruh paket yang terfragmentasi ikut hilang, dan sebagian NAT dan firewall membuang semua fragmen
RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports IETF
1.200 byte disarankan sebagai ukuran aman dasar (BASE_PLPMTU) untuk transport datagram seperti UDP
Maximum transmission unit and maximum segment size Cloudflare
MTU jalur internet 1.500, atau 1.476 jika melewati tunnel GRE
Monitor network performance for ENA settings on your EC2 instance AWS
pps_allowance_exceeded dan bw_out_allowance_exceeded: jumlah paket yang masuk antrean atau dibuang karena melewati batas PPS atau bandwidth kirim instance
sar(1) — Linux manual page sysstat
rxpck/s dan txpck/s (paket per detik) serta rxkB/s dan txkB/s (KB per detik) di sar -n DEV; fragcrt/s (fragmen IP yang dibuat per detik, ipFragCreates) di sar -n IP
CloudWatch metrics that are available for your instances AWS
NetworkPacketsOut (jumlah paket yang dikirim instance lewat semua network interface) dan NetworkOut (jumlah byte yang dikirim)
8.7. Packet Lengths Wireshark
Membagi paket yang ditangkap ke dalam rentang panjang dan menampilkan jumlah, rata-rata, minimum, dan maksimumnya

L10 Memori

Jeda GC stop-the-world di server Stop-the-world GC pause

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

Selama server Java atau C# menghentikan semua thread untuk mengumpulkan garbage (stop-the-world), seluruh server berhenti.

Mengapa Heap penuh, GC dimulai → Akibatnya Semua thread game dihentikan untuk pengumpulan garbage (makin banyak data hidup, makin lama) → Di layar Semua pemain di server berhenti bersamaan, lalu fast forward

Gejala: Freeze, Fast forward
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Secara berkala, Makin lama menyala
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Tetapkan GC dengan jeda singkat (ZGC, Shenandoah, G1 dengan target jeda lebih kecil) secara eksplisit lewat opsi startup, kurangi alokasi, sesuaikan ukuran heap.
Tugas Tim Infrastruktur: Pilih instance dengan memori yang cukup untuk heap yang longgar, alokasikan minimal 2 CPU dan memori minimal sekitar 1,8 GB untuk container (JDK 26 dan versi sebelumnya memilih Serial GC sebagai default jika kurang dari itu), pantau waktu jeda GC.
Kisaran angka: Minor GC, yang hanya mengumpulkan objek baru (young generation), butuh beberapa hingga puluhan ms. Full GC yang mengumpulkan seluruh heap dengan data hidup beberapa GB bisa memakan lebih dari 1 detik. Jeda ZGC kurang dari 1 ms dan hampir tidak bergantung pada ukuran heap. Jeda Shenandoah juga singkat karena tidak sebanding dengan ukuran heap.
Di grafik: Melonjak secara berkala · Waktu tick server, waktu jeda GC
Yang diperiksa: Aktifkan log GC, lalu tumpangkan waktu dan lama jeda di grafik waktu tick server. Java: baris Pause dari opsi startup -Xlog:gc* (JDK 8 ke bawah: -XX:+PrintGCDetails); .NET: metrik jeda GC di dotnet-counters (.NET 9 ke atas: dotnet.gc.pause.time, 8 ke bawah: % Time in GC since last GC); Go: baris yang ditulis GODEBUG=gctrace=1 setiap kali GC berjalan
Cocok jika: Lonjakan tick dan jeda GC terjadi di waktu yang sama, lama jeda kira-kira sama dengan lama lonjakan. Semua zona dan channel di server melonjak bersamaan
Tidak cocok jika: Tidak ada jeda panjang di log GC, tetapi tick tetap melonjak: lebih mungkin penyebab lain seperti lock, pemanggilan sinkron, atau penulisan disk. Hanya satu zona yang melonjak: lebih mungkin GC engine skrip (mem-script-gc) atau beban di zona itu
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Target jeda G1 di Java secara default 200 ms per jeda, setara dengan 4 tick di server 20 tick. Jika container diberi kurang dari 2 CPU atau memori kurang dari sekitar 1,8 GB, Java versi JDK 26 dan sebelumnya memilih Serial GC sebagai GC default. Serial GC mengumpulkan garbage dengan satu thread, sehingga jedanya jauh lebih panjang. Server C# (.NET) biasanya mengaktifkan server GC dan background GC, tetapi pengumpulan generasi 0 dan 1 (Gen0/1) yang menampung objek baru, serta Full GC yang disertai kompaksi, tetap menghentikan semua thread. Jeda GC di Go biasanya kurang dari 1 ms, tetapi jika alokasinya banyak, pihak yang meminta memori harus ikut mengerjakan sebagian tugas GC sehingga tick melambat. Apa pun mekanismenya, jika alokasi lebih cepat daripada pengumpulan, thread game akhirnya tetap berhenti. G1 beralih ke Full GC, sedangkan ZGC menghentikan thread yang meminta memori sampai pengumpulan selesai.
Kasus nyata: Riot Games 2021: Gangguan 5 jam di League of Legends EUW: satu DB pendukung menghentikan seluruh server

10 sumber

Garbage-First (G1) Garbage Collector Oracle
Target jeda G1 default 200 ms (MaxGCPauseMillis); jika memori habis saat pengumpulan, G1 beralih ke Full GC yang menghentikan semua thread dan melakukan kompaksi pada seluruh heap
JEP 523: Make G1 the Default Garbage Collector in All Environments OpenJDK
Selama ini Serial GC dipilih sebagai default jika CPU hanya 1 atau memori kurang dari 1.792 MB; mulai JDK 27, G1 menjadi default di semua lingkungan
JEP 439: Generational ZGC OpenJDK
Jeda ZGC maksimal 1 ms dan tidak bergantung pada ukuran heap, jeda G1 beberapa ms hingga beberapa detik. Jika alokasi lebih cepat daripada pengambilan kembali memori, ada risiko allocation stall
JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental) OpenJDK
Waktu jeda Shenandoah kurang lebih sama, baik untuk heap 200 MB maupun 200 GB
Background garbage collection .NET
Background GC hanya berlaku untuk pengumpulan generasi 2; pengumpulan generasi 0 dan 1 (foreground GC) menghentikan semua managed thread
A Guide to the Go Garbage Collector Go
GC Go sebagian besar berjalan secara konkuren dan hanya punya jeda stop-the-world yang singkat; jika alokasinya banyak, goroutine ikut mengerjakan tugas GC (assist) sehingga timbul keterlambatan
JEP 271: Unified GC Logging OpenJDK
Sejak JDK 9, log GC diimplementasikan ulang dengan unified logging (-Xlog); -Xlog:gc menulis satu baris per GC seperti -XX:+PrintGC versi lama
The java Command Oracle
Tabel padanan opsi log GC lama ke -Xlog: -XX:+PrintGCDetails menjadi -Xlog:gc*
dotnet-counters diagnostic tool .NET
.NET 9 ke atas menampilkan meter System.Runtime (dotnet.gc.pause.time dan lainnya), .NET 8 ke bawah menampilkan EventCounter lama (% Time in GC since last GC dan lainnya)
runtime package Go
GODEBUG=gctrace=1: satu baris per GC, berisi wall clock time per fase, ukuran heap di awal dan akhir GC, serta target heap

Jeda GC di engine skrip Scripting VM GC (Lua, etc.)

ID mem-script-gc · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Walaupun servernya ditulis dengan C++, jika quest, AI, dan skill dijalankan dengan skrip seperti Lua, zona itu berhenti selama GC engine skrip berjalan.

Mengapa Engine skrip di setiap zona menjalankan quest, AI, dan event sambil membuat objek sementara dalam jumlah besar → Akibatnya Saat GC engine skrip mengumpulkan banyak garbage sekaligus, tick zona itu terhenti → Di layar Tersendat sesaat secara berkala, hanya di zona tertentu atau selama event tertentu

Gejala: Patah-patah, Freeze
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu
Kapan: Saat banyak pemain berkumpul, Secara berkala
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Atur GC ke mode incremental atau generational, jalankan GC sedikit demi sedikit di setiap tick, kurangi objek sementara di skrip.
Kisaran angka: Jika heap skrip membesar hingga ratusan MB, pengumpulan sekaligus (saat pengumpulan incremental dimatikan, atau pengumpulan penuh di mode generational) bisa memakan puluhan hingga ratusan ms.
Di grafik: Melonjak secara berkala · Waktu tick per zona, memori engine skrip
Yang diperiksa: Catat waktu tick per zona dan penggunaan memori engine skrip di zona itu (Lua: collectgarbage("count")) di setiap tick, lalu tumpangkan dalam satu grafik
Cocok jika: Memori skrip anjlok (pengumpulan sekaligus) tepat saat tick zona itu melonjak, sementara zona lain normal
Tidak cocok jika: Tick melonjak tanpa perubahan memori skrip: lebih mungkin beban atau lock di zona itu. Semua zona di server melonjak bersamaan: lebih mungkin GC server (mem-gc) atau swap (mem-swap)
Sarana pemeriksaan: Log dan metrik server atau klien game

1 sumber

Lua 5.4 Reference Manual Lua.org
Mode incremental membagi pengumpulan menjadi langkah-langkah kecil yang diselipkan di antara eksekusi program (jika langkahnya dibuat besar, menjadi stop-the-world); pengumpulan major di mode generational adalah stop-the-world yang menelusuri semua objek; collectgarbage("count") mengembalikan total memori yang dipakai Lua (KB)

Lonjakan alokasi Allocation storms

ID mem-alloc · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika objek sementara dibuat dalam jumlah besar selama event, GC berjalan jauh lebih sering daripada biasanya.

Mengapa Objek sementara melonjak karena drop item, log pertempuran, dan hadiah event → Akibatnya GC berjalan beberapa kali lebih sering, dan objek yang belum sempat dibuang pindah ke old generation sehingga Full GC juga datang lebih cepat → Di layar Tersendat sesaat secara berkala, hanya saat event

Gejala: Patah-patah, Freeze
Faktor: Stall
Siapa yang mengalami: Seluruh server, Lokasi/channel tertentu
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Gunakan object pool, pakai ulang buffer, lakukan profiling alokasi.
Di grafik: Naik mengikuti beban · Jumlah GC, laju alokasi
Yang diperiksa: Hitung jumlah GC per menit dari log GC (Java: -Xlog:gc, Go: GODEBUG=gctrace=1); untuk .NET, periksa volume alokasi dan jumlah GC di dotnet-counters (.NET 9 ke atas: dotnet.gc.heap.total_allocated dan dotnet.gc.collections, 8 ke bawah: Allocation Rate dan Gen 0 GC Count). Tumpangkan dengan jumlah pemain online bersamaan dan waktu event
Cocok jika: Begitu event dimulai, laju alokasi dan jumlah GC naik lebih tajam daripada kenaikan jumlah pemain, dan jeda singkat makin sering. Setelah event selesai, kembali normal
Tidak cocok jika: Jumlah GC tetap, tetapi setiap jeda makin panjang: mengarah ke data hidup yang bertambah (mem-gc-thrash, mem-leak)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Garbage Collector Implementation Oracle
Saat young generation penuh terjadi minor GC; sebagian objek yang bertahan dipindahkan ke old generation, dan saat old generation penuh, seluruh heap dikumpulkan (jauh lebih lama daripada minor GC); -Xlog:gc mencatat satu baris per GC
A Guide to the Go Garbage Collector Go
Makin tinggi laju alokasi, makin sering siklus GC; output trace GC dengan GODEBUG=gctrace=1
dotnet-counters diagnostic tool .NET
.NET 9 ke atas menampilkan dotnet.gc.heap.total_allocated dan dotnet.gc.collections, .NET 8 ke bawah menampilkan Allocation Rate dan Gen 0 GC Count

Kebocoran memori Memory leak

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

Memori yang tidak dibebaskan menumpuk sedikit demi sedikit, lalu beberapa hari kemudian berujung pada GC yang berjalan tanpa henti, swap, atau proses yang dihentikan paksa.

Mengapa Data karakter yang sudah logout dan event handler tidak dibebaskan → Akibatnya Memori bebas berkurang selama beberapa hari → Di layar Normal tepat setelah maintenance, makin hari makin lag, akhirnya server down

Gejala: Slow motion, Freeze, Disconnect
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Makin lama menyala, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Analisis heap dump, jalankan load test jangka panjang.
Tugas Tim Infrastruktur: Pantau tren penggunaan memori per proses dan pasang alert.
Di grafik: Naik perlahan · Memori proses (RSS), heap tepat setelah GC
Yang diperiksa: Periksa memori proses server game (RSS di pidstat -r) dalam rentang beberapa hari, dan untuk server yang memakai GC, periksa heap yang tersisa tepat setelah GC. Java: nilai setelah GC dari pasangan penggunaan sebelum dan sesudah GC di baris -Xlog:gc; .NET: ukuran heap setelah GC di dotnet-counters (.NET 9 ke atas: dotnet.gc.last_collection.heap.size, 8 ke bawah: GC Heap Size)
Cocok jika: Heap yang tersisa tepat setelah GC (garis dasar) naik setiap hari sejak restart, dan tetap tidak turun pada dini hari saat pemain sedikit
Tidak cocok jika: Garis dasar heap datar tetapi hanya RSS yang naik: lebih mungkin fragmentasi (mem-fragment) atau native memory. Naik turun mengikuti jumlah pemain: penggunaan normal
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Jika server dimulai ulang setiap minggu saat maintenance rutin, kebocoran tertutupi dan lama tidak ketahuan. Kebocoran sering baru muncul tiba-tiba saat maintenance tertunda sekali saja, atau saat jumlah pemain bertambah karena event.

5 sumber

Troubleshoot Memory Leaks Oracle
Jika eksekusi makin lambat, curigai kebocoran; akhirnya memori habis dan terjadi terminasi abnormal. Data utama untuk analisis kebocoran adalah heap dump
Debug a memory leak in .NET .NET
Walaupun ada GC, objek yang tidak diperlukan tetapi terus direferensikan menjadi kebocoran, yang menyebabkan penurunan performa dan OutOfMemoryException. Memeriksa tren memori dan menganalisis dump
Garbage Collector Implementation Oracle
Baris -Xlog:gc berformat “penggunaan sebelum GC->penggunaan setelah GC (ukuran heap)”
dotnet-counters diagnostic tool .NET
.NET 9 ke atas menampilkan dotnet.gc.last_collection.heap.size, .NET 8 ke bawah menampilkan GC Heap Size
pidstat(1) — Linux manual page sysstat
-r: RSS per proses (memori yang benar-benar ada di RAM) dan page fault

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

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

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)

5 sumber

The Parallel Collector Oracle
Parallel GC memunculkan OutOfMemoryError jika lebih dari 98% total waktu dipakai untuk GC tetapi heap yang dibebaskan kurang dari 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
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
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
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

Swap Swapping

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

Jika memori kurang dan OS memindahkan sebagiannya ke disk, setiap kali memori itu dipakai, proses harus menunggu disk yang lebih dari 1.000 kali lebih lambat.

Mengapa Memori yang dipakai melebihi RAM fisik → Akibatnya OS memindahkan sebagian memori ke disk dan membacanya lagi saat dibutuhkan → Di layar Tick melonjak hingga ratusan ms, sehingga semua pemain di server mengalami slow motion dan freeze

Gejala: Slow motion, Freeze
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Makin lama menyala, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Beri batas atas penggunaan memori proses (ukuran heap dan sebagainya), periksa kebocoran.
Tugas Tim Infrastruktur: Atur server game agar tidak memakai swap, tangani lewat alert memori, sediakan RAM yang lebih longgar daripada penggunaan puncak karena tanpa swap proses langsung dihentikan paksa (OOM) begitu memori kurang.
Kisaran angka: Baca RAM sekitar 100 ns, baca ulang dari SSD sekitar 100 µs (1.000 kali), disk cloud di seberang jaringan sekitar 1 ms (10.000 kali), HDD 10 ms (100.000 kali).
Di grafik: Naik perlahan · Penggunaan swap, swap in/out
Yang diperiksa: Tumpangkan kolom si dan so di vmstat 1 (jumlah yang dibaca dari swap dan dikirim ke swap per detik), some dan full di /proc/pressure/memory (rasio waktu tertahan karena menunggu memori), serta majflt/s dari pidstat -r untuk proses server game (page fault yang harus dibaca dari disk) dengan waktu tick
Cocok jika: Saat lag terjadi, si lebih besar dari 0, dan majflt/s server game serta nilai full di PSI memory ikut naik
Tidak cocok jika: si dan so 0, dan tekanan memori (PSI memory) juga mendekati 0: swap bukan penyebabnya. Tidak ada swap tetapi majflt/s dan PSI naik: memori habis sehingga code page dibaca ulang, jadi tambah memori terlebih dahulu
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Server yang memakai GC membaca berbagai bagian heap saat pengumpulan, jadi walaupun hanya sebagian heap yang masuk swap, satu kali GC bisa memanjang menjadi beberapa hingga puluhan detik. Jika swap dimatikan, server langsung dihentikan paksa (OOM) tanpa melewati tahap melambat karena swap, jadi sediakan memori cadangan terlebih dahulu. Walaupun tanpa swap, jika memori hampir habis, OS juga mengeluarkan code page file executable dari memori lalu membacanya lagi, sehingga seluruh server bisa sangat lambat untuk beberapa waktu sebelum dihentikan paksa.

8 sumber

Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
“Numbers Everyone Should Know”: referensi main memory 100 ns, seek disk 10 ms (data tahun 2009)
Documentation for /proc/sys/vm/ Linux kernel
swappiness: biaya relatif antara swap dan pengambilan kembali file page; swap mahal karena berupa I/O acak
Concepts overview Linux kernel
Kernel mengambil kembali page cache yang aslinya tersimpan di disk dan page yang bisa di-swap; jika masih kurang, OOM killer mematikan proses
Solidigm™ D7-P5520 and D7-P5620 Product Brief Solidigm
Latensi 99,99% (four-nines latency) SSD NVMe server 130 µs: dasar bahwa satu kali baca SSD sekitar 100 µs
Amazon EBS General Purpose SSD volumes AWS
Latensi disk standar cloud (gp3) dalam kisaran satu digit ms
vmstat(8) — Linux manual page procps-ng
si: memori yang dibaca dari swap per detik, so: memori yang dikirim ke swap per detik
PSI - Pressure Stall Information Linux kernel
some (rasio waktu sebagian task tertahan) dan full (rasio waktu semua task tertahan bersamaan) di /proc/pressure/memory
pidstat(1) — Linux manual page sysstat
-r: majflt/s (jumlah fault yang mengharuskan page dibaca dari disk)

Cache miss CPU cache misses

ID mem-cache-miss · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika data tersebar di berbagai tempat di memori, CPU harus menunggu setiap kali mengambilnya dari RAM yang lambat.

Mengapa Objek tersebar lewat pointer dan diakses tanpa urutan → Akibatnya Data tidak ada di cache CPU sehingga setiap kali harus dibaca dari RAM (sekitar 100 kali lebih lambat) → Di layar Untuk pekerjaan yang sama, biaya tick menjadi beberapa kali lipat; jika parah, terjadi slow motion

Gejala: Slow motion
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Selalu, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Letakkan data yang sering dipakai bersama secara berurutan di memori (data-oriented design).
Di grafik: Selalu tinggi sejak awal · Waktu tick, utilisasi CPU
Yang diperiksa: Jalankan perf stat -d -p PID pada proses server game untuk mengukur jumlah instruksi per siklus (insn per cycle) serta cache miss L1 dan LLC, lalu bandingkan dengan waktu tick dan utilisasi CPU
Cocok jika: CPU terus sibuk, tetapi insn per cycle rendah dan LLC miss banyak. Pasti penyebab ini jika build dengan tata letak data yang diubah menurunkan waktu tick secara drastis pada jumlah pemain yang sama
Tidak cocok jika: Utilisasi CPU rendah tetapi tick lambat: lebih mungkin penyebab yang menunggu di luar CPU, seperti lock atau menunggu I/O
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

2 sumber

Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
Cache L1 0,5 ns, cache L2 7 ns, main memory 100 ns (data tahun 2009): akses sampai RAM satu atau dua orde besaran lebih lambat daripada cache
perf-stat(1) — Linux manual page perf
-p menghitung event hardware dari proses yang sedang berjalan dan menampilkan insn per cycle; -d menambahkan event data cache L1 dan LLC

Fragmentasi memori Heap fragmentation

ID mem-fragment · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika alokasi dan pembebasan yang berulang memecah ruang kosong menjadi potongan kecil, proses menahan memori jauh lebih banyak daripada yang benar-benar dipakai.

Mengapa Banyak thread mengalokasikan dan membebaskan memori berukuran beragam dalam waktu lama → Akibatnya Ruang kosong tersebar dalam potongan kecil sehingga tidak bisa dikembalikan ke OS, dan penggunaan memori terus naik seperti kebocoran → Di layar Makin lama menyala, makin lambat karena swap atau kehabisan memori, lalu dihentikan paksa

Gejala: Slow motion, Disconnect
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Makin lama menyala
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Gunakan memory pool per ukuran dan allocator yang tahan fragmentasi (jemalloc, mimalloc, dan lainnya).
Di grafik: Naik perlahan · Memori proses (RSS)
Yang diperiksa: Jalankan dua server dengan build yang sama; pada salah satunya saja, kurangi jumlah arena glibc dengan environment variable MALLOC_ARENA_MAX atau ganti ke allocator lain seperti jemalloc, lalu bandingkan RSS di pidstat -r selama beberapa hari
Cocok jika: Jumlah pemain dan objek kurang lebih sama, tetapi hanya server yang diubah yang kenaikan RSS-nya berhenti atau turun drastis
Tidak cocok jika: RSS tetap naik dengan cara yang sama walaupun allocator diganti: mengarah ke memori yang tidak dibebaskan (mem-leak)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Polanya sama dengan kebocoran, tetapi analisis heap tidak menemukan titik kebocorannya. Allocator default Linux (glibc) sangat rentan pada server dengan banyak thread, sehingga mengganti allocator saja kadang sudah menurunkan penggunaan memori secara drastis.

3 sumber

mallopt(3) — Linux manual page Linux man-pages
glibc malloc membuat arena hingga kelipatan jumlah CPU untuk mengurangi perebutan di antara thread, dan makin banyak arena, makin besar penggunaan memori (dibatasi dengan M_ARENA_MAX, bisa juga diatur lewat environment variable MALLOC_ARENA_MAX)
jemalloc memory allocator jemalloc
Implementasi malloc serbaguna yang mengutamakan penghindaran fragmentasi dan skalabilitas konkurensi
pidstat(1) — Linux manual page sysstat
-r: RSS per proses (memori yang benar-benar ada di RAM)

Akses memori NUMA remote Remote NUMA access

ID mem-numa · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Pada server dengan dua CPU, akses memori melambat jika thread memakai memori yang terpasang pada CPU seberang.

Mengapa Thread dan memori ditempatkan di socket CPU yang berbeda → Akibatnya Akses memori melambat (1,5–2 kali, tergantung perangkat) → Di layar Spesifikasi sama, tetapi performa berbeda di setiap proses

Gejala: Slow motion
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Kunci proses dan memori di satu socket (numactl); jika ada dua socket, jalankan proses server game terpisah untuk setiap socket.
Di grafik: Hanya sebagian yang tinggi · Waktu tick per proses, memori per node
Yang diperiksa: Dengan numastat -p PID, periksa di node NUMA mana memori proses server game berada dan apakah numa_miss dan other_node di numastat bertambah, lalu bandingkan dengan node CPU tempat proses itu berjalan
Cocok jika: Hanya proses yang lambat yang sebagian besar memorinya ada di node yang berbeda dari CPU tempatnya berjalan, dan perbedaannya hilang setelah proses dijalankan ulang dengan CPU dan memori dikunci di satu node menggunakan numactl
Tidak cocok jika: Penempatan node sama dengan proses yang cepat tetapi tetap lambat: lebih mungkin penyebab lain seperti noisy neighbor, CPU throttling, atau beban proses itu sendiri
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

What is NUMA? Linux kernel
Memori di cell yang sama lebih cepat dan bandwidth-nya lebih besar, sedangkan akses ke memori di cell lain (remote) lebih lambat
numactl(8) — Linux manual page numactl
--cpunodebind dan --membind mengunci CPU dan memori proses ke node NUMA tertentu
numastat(8) — Linux manual page numactl
Counter numa_miss (dialokasikan di node selain yang diinginkan) dan other_node (dialokasikan di node ini oleh proses yang berjalan di node lain); -p menampilkan memori proses per node

L11 Disk

Penulisan log sinkron Synchronous logging

ID dk-sync-log · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika thread game menunggu disk selesai menulis untuk setiap baris log, jalannya game ikut berhenti saat disk sibuk.

Mengapa Log pertempuran dan trade langsung ditulis ke file dari thread game → Akibatnya Jika penyimpanan pasti (fsync) diminta atau buffer tulis OS (page cache) mencapai batasnya, satu kali penulisan butuh puluhan ms saat disk sibuk → Di layar Tersendat sesaat dalam pertempuran yang menghasilkan banyak log

Gejala: Patah-patah, Freeze
Faktor: Stall
Siapa yang mengalami: Lokasi/channel tertentu, Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Gunakan logging asinkron (buffer memori + thread terpisah), kurangi volume log, jangan memanggil fsync di thread game.
Tugas Tim Infrastruktur: Jalankan rotasi dan kompresi log dengan prioritas I/O rendah, simpan log di disk yang terpisah dari data, pantau latensi tulis disk.
Di grafik: Melonjak acak sesekali · Waktu tick server, latensi tulis disk
Yang diperiksa: Tumpangkan w_await dan aqu-sz di iostat -x 1 dengan waktu tick, lalu dengan perf trace -p PID --duration 10 cari pemanggilan write dan fsync di server game yang memakan lebih dari 10 ms beserta thread-nya
Cocok jika: Saat tick melonjak, pemanggilan write dan fsync di thread game memakan puluhan ms, dan latensi tulis disk juga melonjak di saat yang sama. Sering bertepatan dengan waktu rotasi atau kompresi log
Tidak cocok jika: Tidak ada system call yang lama di thread game tetapi tick melonjak: lebih mungkin penyebab lain seperti GC, lock, atau tick yang melewati budget. Hanya thread khusus log yang lama: tidak memengaruhi jalannya game
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Biasanya OS menampung penulisan di memori (page cache) lebih dulu dan baru menuliskannya ke disk belakangan, jadi satu baris log umumnya langsung selesai. Jeda terjadi saat penyimpanan pasti diminta dengan fsync, saat penulisan yang tertunda melewati batas sehingga OS memblokir pemanggilan write, dan saat file log dirotasi atau dikompresi. Karena itu, tick normal di waktu biasa dan baru melonjak saat disk sedang sibuk.

5 sumber

fsync(2) — Linux manual page Linux man-pages
fsync menuliskan data yang berubah sampai ke disk (termasuk cache disk) dan memblokir sampai perangkat melaporkan selesai
Documentation for /proc/sys/vm/ Linux kernel
Jika penulisan yang tertunda (dirty) mencapai dirty_ratio, proses yang menulis harus menuliskan data ke disk sendiri
ionice(1) — Linux manual page util-linux
Tugas yang dijalankan dengan prioritas I/O idle hanya mendapat waktu disk saat program lain tidak memakai disk
iostat(1) — Linux manual page sysstat
-x: w_await (rata-rata waktu pemrosesan permintaan tulis, termasuk waktu menunggu di antrean), aqu-sz (rata-rata panjang antrean, nama lamanya avgqu-sz)
perf-trace(1) — Linux manual page perf
-p melacak system call proses yang sedang berjalan; --duration hanya menampilkan pemanggilan yang lebih lama dari jumlah ms yang ditentukan

Lonjakan fsync fsync storms

ID dk-fsync · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur DB (Tim Infrastruktur)

Permintaan agar data ditulis ke disk secara “pasti” memakan 0,1 ms hingga puluhan ms per kali tergantung disknya, dan jika permintaan menumpuk, antreannya memanjang.

Mengapa Permintaan penulisan pasti menumpuk karena penyimpanan berkala dan gelombang logout → Akibatnya Antrean disk memanjang → Di layar Lag setiap kali waktu penyimpanan tiba, logout dan pindah channel tertunda

Gejala: Patah-patah, Input lag
Faktor: Stall, Latensi
Siapa yang mengalami: Seluruh server
Kapan: Secara berkala, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Gabungkan penyimpanan (beberapa penyimpanan dengan satu fsync), sebar waktu penyimpanan.
Tugas Tim Infrastruktur: Server/OS: gunakan SSD server dengan power-loss protection, pantau panjang antrean disk dan latensi fsync. Server DB: jika penyimpanan masuk ke DB, gunakan SSD yang sama untuk disk log DB, pantau latensi commit.
Kisaran angka: Waktu per kali berbeda di setiap perangkat, tetapi kira-kira: SSD server (dengan power-loss protection) 0,1 ms, SSD biasa 1 hingga beberapa ms, disk cloud 1–2 ms, HDD minimal 10 ms. Jika satu thread menunggu satu per satu, HDD bahkan tidak sanggup 100 kali per detik.
Di grafik: Melonjak secara berkala · Panjang antrean disk, latensi flush dan tulis
Yang diperiksa: Tumpangkan f/s dan f_await (jumlah flush yang diproses disk dan waktunya), serta w/s, aqu-sz, dan w_await di iostat -x 1 dengan waktu penyimpanan berkala dan logout. sysstat versi lama menampilkan aqu-sz sebagai avgqu-sz. Untuk disk cloud, periksa VolumeQueueLength dan VolumeAvgWriteLatency di EBS
Cocok jika: Setiap waktu penyimpanan dan gelombang logout, jumlah flush dan panjang antrean melonjak bersamaan, dan w_await serta f_await menjadi beberapa kali lipat dari biasanya. Saat itu penyimpanan dan pindah channel melambat
Tidak cocok jika: Antrean melonjak di waktu yang tidak berkaitan dengan penyimpanan atau logout: lebih mungkin backup dan kompresi (dk-backup) atau batas IOPS (dk-iops). Jumlah flush tetap tetapi melambat: lebih mungkin burst credit habis (dk-burst)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

6 sumber

fsync(2) — Linux manual page Linux man-pages
fsync juga mengosongkan cache disk dan memblokir sampai perangkat melaporkan selesai
Reliability (PostgreSQL Documentation) PostgreSQL
Disk SATA biasa dan banyak SSD punya cache tulis yang isinya hilang saat listrik padam, sehingga penyimpanan yang pasti membutuhkan cache dengan baterai atau power-loss protection
Amazon EBS General Purpose SSD volumes AWS
Latensi disk standar cloud (gp3) dalam kisaran satu digit ms, io2 Block Express rata-rata kurang dari 500 µs untuk I/O 16 KiB
Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
Satu kali seek HDD 10 ms
iostat(1) — Linux manual page sysstat
-x: f/s dan f_await (jumlah permintaan flush yang diproses disk dan waktu rata-ratanya), w/s, w_await, aqu-sz (nama lamanya avgqu-sz)
Amazon CloudWatch metrics for Amazon EBS AWS
VolumeQueueLength (jumlah permintaan yang menunggu selesai), VolumeAvgWriteLatency (rata-rata latensi tulis per 1 menit, instance Nitro)

Burst credit disk cloud habis Burst credit depletion

ID dk-burst · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Sebagian disk cloud dan spesifikasi server kecil punya burst credit yang memungkinkan kinerja di atas baseline untuk sementara. Jika masa sibuk berlangsung lama dan kreditnya habis, kecepatannya tiba-tiba turun.

Mengapa Dipakai di atas performa baseline dalam waktu lama → Akibatnya Burst credit habis, performa anjlok ke baseline → Di layar Setiap malam, lag baru mulai setelah beberapa jam berlalu

Gejala: Patah-patah, Slow motion, Input lag
Faktor: Stall, Latensi
Siapa yang mengalami: Seluruh server
Kapan: Jam sibuk malam hari, Makin lama menyala
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Infrastruktur: Server/OS: gunakan disk dengan performa terjamin (gp3, tipe provisioned IOPS), pasang alert saldo kredit, periksa juga batas burst bandwidth disk instance dan CPU credit. Server DB: ganti juga disk DB, termasuk managed DB, ke tipe dengan performa terjamin, pasang alert saldo kredit.
Kisaran angka: Disk AWS gp2 100 GB biasanya 300 IOPS dan 3.000 IOPS saat burst, dan jika kreditnya penuh, burst bertahan sekitar 30 menit. gp3 selalu 3.000 IOPS tanpa kredit. Premium SSD Azure yang kecil juga bisa burst hingga 30 menit dengan kredit.
Di grafik: Mendatar di batas · IOPS, saldo burst credit
Yang diperiksa: Periksa EBS BurstBalance (gp2, st1, sc1) di CloudWatch, EBSIOBalance% dan EBSByteBalance% milik instance (sebagian instance yang bisa burst), serta CPUCreditBalance pada instance burstable. Di Azure, periksa metrik persentase pemakaian burst credit seperti Data Disk Used Burst IO Credits Percentage
Cocok jika: Sejak saldo turun mendekati 0, IOPS (VolumeReadOps, VolumeWriteOps) mendatar di performa baseline, dan VolumeQueueLength serta lag ikut naik. Dimulai setelah jam sibuk berlangsung beberapa jam
Tidak cocok jika: Semua saldo masih banyak tetapi IOPS mendatar: lebih mungkin batas tetap volume atau instance (dk-iops)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Walaupun disknya baik-baik saja, VM kecil punya batas burst pada bandwidth disk instance itu sendiri (misalnya minimal 30 menit per hari), sehingga polanya sama. Server murah yang memakai CPU credit juga melambat sampai performa baseline jika kreditnya habis.

7 sumber

Amazon EBS General Purpose SSD volumes AWS
Performa baseline gp2 adalah 3 IOPS per GiB (minimal 100), bisa burst hingga 3.000 IOPS dengan I/O credit, dan 5,4 juta kredit cukup untuk minimal 30 menit. gp3 selalu 3.000 IOPS tanpa burst
Managed disk bursting Microsoft Azure
Premium SSD P20 ke bawah memakai burst berbasis kredit; jika kreditnya penuh, bisa berjalan 30 menit dengan kecepatan burst maksimum
Amazon EBS-optimized instance types AWS
Sebagian instance hanya mempertahankan performa EBS maksimum selama 30 menit sekali dalam 24 jam, lalu kembali ke performa baseline
Standard mode for burstable performance instances AWS
Instance burstable dalam mode standar menurunkan utilisasi CPU ke level baseline secara bertahap (agar tidak anjlok) saat CPU credit habis
Amazon CloudWatch metrics for Amazon EBS AWS
BurstBalance: saldo I/O credit gp2 dan saldo throughput credit st1 serta sc1 (%), VolumeReadOps, VolumeWriteOps, VolumeQueueLength
CloudWatch metrics that are available for your instances AWS
EBSIOBalance% dan EBSByteBalance%: saldo kredit EBS pada sebagian instance yang bisa burst 30 menit sekali dalam 24 jam; CPUCreditBalance: saldo CPU credit pada instance burstable
Disk metrics Microsoft Azure
Persentase pemakaian burst credit disk dan VM, seperti Data Disk Used Burst IO Credits Percentage (interval 5 menit)

Batas IOPS dan antrean jenuh IOPS limit / queue saturation

ID dk-iops · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur DB (Tim Infrastruktur)

Jika permintaan melebihi jumlah yang bisa diproses disk per detik, antrean memanjang dan latensi melonjak tajam.

Mengapa Permintaan baca dan tulis mendekati kemampuan proses disk → Akibatnya Antrean memanjang (biasanya melonjak tajam saat utilisasi 90% atau lebih) → Di layar Penyimpanan dan loading tertunda; jika pemanggilannya sinkron, terjadi freeze

Gejala: Input lag, Freeze
Faktor: Latensi, Stall
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Gabungkan permintaan, simpan data yang sering dibaca di cache, gunakan I/O asinkron agar thread game tidak menunggu disk.
Tugas Tim Infrastruktur: Server/OS: gunakan disk yang lebih cepat, periksa batas bandwidth disk dan IOPS per tipe instance, pasang alert utilisasi dan antrean disk, salin file besar di jam sepi. Server DB: pasang alert utilisasi IOPS dan throughput untuk disk DB juga, periksa batas disk pada spesifikasi instance DB.
Kisaran angka: HDD sekitar 150 IOPS, SSD SATA puluhan ribu, NVMe ratusan ribu IOPS. Disk standar cloud (AWS gp3) 3.000 IOPS dan 125 MiB per detik. Batas throughput per detik ini terpisah dari IOPS, dan jika salinan file besar menghabiskannya, penulisan kecil pun ikut tertahan.
Di grafik: Mendatar di batas · IOPS, panjang antrean disk
Yang diperiksa: Periksa r/s dan w/s, rkB/s dan wkB/s, aqu-sz, serta r_await dan w_await di iostat -x 1. Di cloud, periksa VolumeReadOps, VolumeWriteOps, dan VolumeQueueLength di EBS, indikator pelampauan batas VolumeIOPSExceededCheck dan VolumeThroughputExceededCheck, serta InstanceEBSIOPSExceededCheck dan InstanceEBSThroughputExceededCheck di sisi instance
Cocok jika: Jumlah permintaan per detik atau throughput mendatar di nilai batas, dan aqu-sz serta await melonjak bersamaan. Di cloud, metrik pemeriksaan pelampauan bernilai 1
Tidak cocok jika: %util 100% tetapi await rendah: mungkin masih ada ruang. Pada SSD dan RAID yang memproses permintaan secara paralel, %util tidak menunjukkan batas. Belum mencapai batas tetapi hanya await yang tinggi: lebih mungkin latensi disk itu sendiri (dk-hdd) atau fsync (dk-fsync)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Di cloud, selain batas disk, setiap spesifikasi server (tipe instance) juga punya batas bandwidth disk dan IOPS. Walaupun disk mahal dipasang, jika servernya kecil, kinerjanya tertahan di batas instance.

8 sumber

Exos X18 Data Sheet Seagate
Baca acak 4K pada HDD server 7.200 rpm: 170 IOPS (QD16)
D3-S4520 SSD Solidigm
Baca/tulis acak 4 KB pada SSD SATA server: maksimal 92K/48K IOPS
Solidigm™ D7-P5520 and D7-P5620 Product Brief Solidigm
Baca/tulis acak pada SSD NVMe server: 1.000K/200K IOPS
Amazon EBS General Purpose SSD volumes AWS
Performa dasar gp3 3.000 IOPS dan 125 MiB/s; keduanya batas terpisah yang bisa dinaikkan masing-masing
Amazon EBS-optimized instance types AWS
Setiap tipe instance punya batas baseline dan maksimum tersendiri untuk bandwidth, throughput, dan IOPS EBS
iostat(1) — Linux manual page sysstat
-x: r/s dan w/s, rkB/s dan wkB/s, aqu-sz (nama lamanya avgqu-sz), r_await dan w_await, %util. Pada RAID dan SSD modern yang memproses permintaan secara paralel, %util tidak menunjukkan batas performa
Amazon CloudWatch metrics for Amazon EBS AWS
VolumeIOPSExceededCheck dan VolumeThroughputExceededCheck: bernilai 1 jika ada upaya melewati batas IOPS atau throughput volume (instance Nitro), VolumeQueueLength
CloudWatch metrics that are available for your instances AWS
InstanceEBSIOPSExceededCheck dan InstanceEBSThroughputExceededCheck: bernilai 1 jika ada upaya melewati batas IOPS atau throughput EBS instance

Disk penuh Disk full

ID dk-full · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)

Jika log dan dump menumpuk hingga disk penuh, penulisan gagal, dan tanpa penanganan, server crash.

Mengapa Log, dump, dan file sementara menumpuk hingga 100% → Akibatnya Penulisan gagal. Tanpa penanganan error, server crash; dengan penanganan error, penyimpanan gagal → Di layar Disconnect, rollback progres

Gejala: Disconnect, Aksi hilang / rollback
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Makin lama menyala
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Tangani kegagalan penulisan dengan mencoba ulang penyimpanan dan memicu alert agar server tidak crash, kurangi log dan dump yang tidak perlu.
Tugas Tim Infrastruktur: Server/OS: rotasi log, alert kapasitas, pisahkan disk log dan data. Server DB: pantau agar log transaksi DB (WAL, binlog) tidak menumpuk akibat replikasi terhenti atau backup log terlewat.
Di grafik: Naik perlahan · Penggunaan ruang disk
Yang diperiksa: Periksa persentase penggunaan di df -h dan penggunaan inode di df -i, lalu cari error ENOSPC di log server dan DB. Untuk DB, periksa slot dengan active bernilai false di pg_replication_slots (PostgreSQL), jumlah dan ukuran file di SHOW BINARY LOGS (MySQL), log_reuse_wait_desc di sys.databases (SQL Server), dan FreeStorageSpace (RDS)
Cocok jika: Penggunaan naik terus selama beberapa hari, dan saat mencapai 100% bertepatan dengan waktu crash atau gagal simpan; ENOSPC tercatat di log
Tidak cocok jika: Ruang masih lega tetapi penulisan gagal: lebih mungkin penyebab lain seperti izin atau batas ukuran file
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Log transaksi DB (WAL, binlog, dan lainnya) tidak terhapus dan terus menumpuk jika replika berhenti atau backup log terlewat. Jika disk ini penuh, semua penulisan di DB berhenti sehingga penyimpanan dan trade gagal serentak.

8 sumber

write(2) — Linux manual page Linux man-pages
Jika perangkat kehabisan ruang, penulisan gagal dengan error ENOSPC
Monitoring Disk Usage (PostgreSQL Documentation) PostgreSQL
Jika disk WAL penuh, server DB bisa berhenti karena panic
Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
Replication slot tidak menghapus WAL sampai replika menerimanya, sehingga bisa memenuhi ruang pg_wal (dibatasi dengan max_slot_wal_keep_size)
Troubleshoot a full transaction log (SQL Server Error 9002) Microsoft SQL Server
Jika log penuh, DB hanya bisa dibaca dan tidak bisa diubah; penyebab umum yang menghalangi pembersihan log adalah backup log yang terlewat, replication lag, dan transaksi panjang; penghalangnya bisa dilihat di log_reuse_wait_desc pada sys.databases
df(1) — Linux manual page coreutils
Penggunaan per file system; -i menampilkan penggunaan inode sebagai pengganti blok
pg_replication_slots (PostgreSQL Documentation) PostgreSQL
active: apakah slot sedang melakukan streaming; wal_status: apakah WAL yang ditahan slot sudah melewati max_wal_size
SHOW BINARY LOGS Statement MySQL
Daftar file binary log di server dan ukuran filenya (File_size)
Amazon CloudWatch metrics for Amazon RDS AWS
FreeStorageSpace: sisa ruang penyimpanan instance DB

Tugas backup, kompresi, dan pemindaian Backup / compression / scans

ID dk-backup · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Jika backup dini hari, kompresi log, dan pemindaian keamanan memonopoli disk, pembacaan dan penulisan server game tertunda.

Mengapa Tugas backup dan kompresi terjadwal dimulai → Akibatnya Menghabiskan sebagian besar bandwidth disk dan IOPS → Di layar Lag di jam yang sama setiap hari

Gejala: Patah-patah, Input lag
Faktor: Stall, Latensi
Siapa yang mengalami: Seluruh server
Kapan: Secara berkala
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Infrastruktur: Server/OS: turunkan prioritas I/O untuk tugas backup, kompresi, dan pemindaian, sebar jadwalnya. Server DB: lakukan backup dari replika.
Di grafik: Melonjak secara berkala · Utilisasi disk, waktu tunggu disk
Yang diperiksa: Tumpangkan %util, await, dan aqu-sz dari catatan beberapa hari terakhir di sar -d (file harian di /var/log/sa; sadc harus mengumpulkan data disk dengan -S DISK) per tanggal, lalu pada jam itu cari proses dengan kB_rd/s dan kB_wr/s terbesar menggunakan pidstat -d 1, dan cocokkan dengan jadwal cron dan systemd timer
Cocok jika: Setiap hari di jam yang sama await dan %util melonjak, dan saat itu proses backup, kompresi, atau pemindaian memakai sebagian besar pembacaan dan penulisan disk
Tidak cocok jika: Jam lonjakan berbeda setiap hari: kecil kemungkinan tugas terjadwal. Sebagian besar I/O pada jam itu berasal dari server game sendiri: lebih mungkin penyimpanan atau log (dk-fsync, dk-sync-log)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

ionice(1) — Linux manual page util-linux
Tugas yang dijalankan dengan kelas idle hanya mendapat waktu disk saat program lain tidak memakai disk
Using Replication for Backups MySQL
Backup dengan menghentikan replika tidak memengaruhi operasi DB primer
sar(1) — Linux manual page sysstat
-d: await, aqu-sz, dan %util per perangkat dari file catatan harian (default /var/log/sa); data disk harus dikumpulkan dengan opsi -S DISK di sadc
pidstat(1) — Linux manual page sysstat
-d: kB_rd/s dan kB_wr/s per proses (volume baca dan tulis disk per detik)

Lazy loading di server Lazy loading on the server

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

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.

5 sumber

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
Amazon EBS fast snapshot restore AWS
Fast snapshot restore memberikan volume yang sudah terinisialisasi sejak dibuat, sehingga latensi akses pertama hilang
pidstat(1) — Linux manual page sysstat
-d: kB_rd/s per proses (volume baca disk per detik)
perf-trace(1) — Linux manual page perf
Hanya menampilkan system call yang lebih lama dari jumlah ms yang ditentukan dengan --duration
Amazon CloudWatch metrics for Amazon EBS AWS
VolumeAvgReadLatency: rata-rata latensi baca per 1 menit (instance Nitro)

Penulisan core dump Core dump writing

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

Saat server crash, memori sebesar beberapa GB ditulis ke disk, sehingga restart bisa tertunda beberapa menit.

Mengapa Server crash, seluruh memori ditulis ke file → Akibatnya Restart tidak bisa dilakukan selama beberapa GB ditulis → Di layar Server crash sehingga pemain disconnect, lalu untuk waktu lama tidak bisa masuk

Gejala: Tidak bisa masuk / loading tanpa henti
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pertimbangkan dump kecil yang hanya berisi memori yang diperlukan (minidump), perbaiki penyebab crash.
Tugas Tim Infrastruktur: Batasi ukuran dump (pengaturan core dump di OS), gunakan disk cepat, pisahkan restart dari dump (kompresi dan upload dump diproses terpisah setelah restart).
Di grafik: Koneksi putus serentak · Jumlah koneksi, waktu restart server
Yang diperiksa: Jajarkan waktu crash, ukuran file core (coredumpctl list dan info, atau file di lokasi yang ditunjuk core_pattern), waktu file selesai ditulis, dan waktu service aktif kembali, lalu periksa wkB/s di iostat -x selama rentang itu
Cocok jika: Setelah crash, penulisan disk menempel di dekat batas selama file core berukuran beberapa GB ditulis, dan restart baru dimulai setelah penulisan selesai
Tidak cocok jika: Core dump nonaktif atau hasilnya kecil tetapi restart tetap lambat: lebih mungkin proses startup server, seperti loading map atau cold cache DB (db-cold-cache)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

core(5) — Linux manual page Linux man-pages
RLIMIT_CORE membatasi ukuran file core, coredump_filter memilih area memori yang disertakan, dan core dump bisa dikirim lewat pipe ke program untuk diproses terpisah
Minidump Files Microsoft
Minidump hanya memuat sebagian informasi crash dump yang berguna, sehingga cepat dibuat dan berukuran kecil
coredumpctl(1) — Linux manual page systemd
list: daftar core dump yang tercatat di journal (TIME adalah waktu crash yang dilaporkan kernel); info: detail tiap dump dan ukuran yang ditulis ke disk
iostat(1) — Linux manual page sysstat
-x: wkB/s (volume tulis disk per detik)

Latensi seek HDD HDD seek latency

ID dk-hdd · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)

Pada HDD, head harus bergerak di atas piringan (platter) untuk mencari posisi data (seek), sehingga membaca atau menulis data yang tersebar memakan hampir 10 ms per kali.

Mengapa Server lama atau storage murah memakai HDD → Akibatnya Sekitar 10 ms untuk setiap baca atau tulis yang tersebar → Di layar Penyimpanan dan loading melambat secara umum

Gejala: Input lag
Faktor: Latensi
Siapa yang mengalami: Seluruh server
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Rancang agar penulisan sebagian besar berurutan (sequential write).
Tugas Tim Infrastruktur: Server/OS: ganti ke SSD (mulai dari disk penyimpanan dengan banyak baca/tulis acak). Server DB: ganti lebih dulu disk DB dengan baca/tulis acak terbanyak ke SSD.
Di grafik: Selalu tinggi sejak awal · Latensi baca/tulis disk (r_await, w_await)
Yang diperiksa: Periksa dengan lsblk -d -o NAME,ROTA apakah disk berputar (HDD), lalu periksa r/s dan w/s serta r_await dan w_await di iostat -x 1. Untuk VM, periksa jenis disk di spesifikasi cloud atau storage
Cocok jika: Disk berputar, dan walaupun permintaan per detik hanya puluhan hingga sekitar seratus, r_await dan w_await selalu beberapa hingga puluhan ms
Tidak cocok jika: SSD tetapi latensinya tinggi: lebih mungkin antrean jenuh (dk-iops) atau burst credit habis (dk-burst)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

5 sumber

Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
Satu kali seek disk 10 ms, baca berurutan 1 MB dari disk 20 ms
Exos X18 Data Sheet Seagate
Rata-rata latensi rotasi HDD 7.200 rpm 4,16 ms, baca acak 4K 170 IOPS
lsblk(8) — Linux manual page util-linux
-o memilih kolom output; kolom topologi perangkat mencakup ROTA (apakah perangkat berputar)
ABI stable symbols Linux kernel
/sys/block/(disk)/queue/rotational: menunjukkan apakah perangkat berputar atau tidak
iostat(1) — Linux manual page sysstat
-x: r/s dan w/s, r_await dan w_await (rata-rata waktu pemrosesan per permintaan, termasuk waktu menunggu di antrean)

L12 Database

Query tanpa indeks Missing index / full table scan

ID db-no-index · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Tanpa indeks, DB harus membaca seluruh tabel untuk menemukan baris yang memenuhi kondisi (full table scan).

Mengapa Deploy fitur baru menambahkan pencarian dengan kondisi yang tidak punya indeks → Akibatnya Jutaan baris dipindai semua, sehingga satu query butuh ratusan ms hingga beberapa detik → Di layar Loading mailbox dan riwayat trade tertunda, koneksi tertahan sehingga request lain ikut menunggu

Gejala: Input lag, Tidak bisa masuk / loading tanpa henti
Faktor: Latensi, Stall
Siapa yang mengalami: Fitur tertentu saja, Seluruh server
Kapan: Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Tinjau query plan setiap query baru sebelum deploy, tambahkan indeks, pastikan query yang mengubah data (UPDATE, DELETE) juga memakai indeks.
Tugas Tim Infrastruktur: Pantau slow query log, temukan query yang melakukan full table scan lalu bagikan ke Tim Pengembang Game, tambahkan indeks saat layanan berjalan dengan metode online yang lock-nya singkat.
Kisaran angka: Dengan indeks, beberapa ms. Tanpa indeks, query melambat sebanding dengan ukuran data, dan pada tabel besar bisa ratusan hingga puluhan ribu kali lebih lambat.
Di grafik: Naik seperti anak tangga · Latensi query DB, jumlah baris yang dibaca
Yang diperiksa: MySQL: periksa Rows_examined dan Rows_sent di slow query log (jika log_queries_not_using_indexes diaktifkan, query yang tidak memakai indeks juga dicatat) serta SUM_NO_INDEX_USED dan SUM_ROWS_EXAMINED di performance_schema events_statements_summary_by_digest, lalu jalankan EXPLAIN. PostgreSQL: periksa seq_scan dan seq_tup_read di pg_stat_user_tables, lalu jalankan EXPLAIN
Cocok jika: Query yang baru muncul setelah deploy membaca baris (Rows_examined) ribuan kali lebih banyak daripada baris yang dikembalikan (Rows_sent), dan EXPLAIN menunjukkan full table scan (MySQL type ALL, PostgreSQL Seq Scan). seq_tup_read pada tabel besar naik tajam sejak waktu deploy
Tidak cocok jika: Sudah memakai indeks tetapi tetap lambat: lebih mungkin menunggu lock (db-hot-row, db-ddl-lock) atau query plan berubah (db-plan-flip). Full table scan pada tabel kecil bisa saja normal
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Dampaknya tidak terbatas pada pembacaan. Tergantung DB-nya, query pengubah data (UPDATE, DELETE) tanpa indeks ikut mengunci baris yang dipindai, sehingga penyimpanan pemain yang tidak terkait pun bisa terhalang.

8 sumber

How MySQL Uses Indexes MySQL
Tanpa indeks, DB membaca seluruh tabel mulai dari baris pertama, dan makin besar tabel, makin besar biayanya
Locks Set by Different SQL Statements in InnoDB MySQL
Jika tidak ada indeks yang cocok dan seluruh tabel dipindai, semua baris terkunci sehingga pengguna lain bahkan tidak bisa menambah baris
The Slow Query Log MySQL
Mencatat query yang melebihi long_query_time (default 10 detik); query yang tidak memakai indeks juga bisa dicatat terpisah
CREATE INDEX (PostgreSQL Documentation) PostgreSQL
Dengan CONCURRENTLY, indeks dibuat tanpa memblokir penulisan; pembuatan biasa memblokir penulisan sampai selesai
Statement Summary Tables MySQL
events_statements_summary_by_digest: SUM_NO_INDEX_USED (jumlah eksekusi tanpa indeks) dan SUM_ROWS_EXAMINED per pola query yang sama
EXPLAIN Output Format MySQL
type ALL berarti full table scan; biasanya dihindari dengan menambahkan indeks
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
seq_scan (jumlah sequential scan) dan seq_tup_read (jumlah baris yang dibaca lewat sequential scan) di pg_stat_user_tables
Using EXPLAIN (PostgreSQL Documentation) PostgreSQL
Seq Scan: query plan yang membaca semua baris tabel secara berurutan

Perebutan lock pada hot row Hot row lock contention

ID db-hot-row · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Jika semua orang ingin mengubah baris yang sama (gudang guild, item populer di balai lelang, counter untuk seluruh server), lock hanya didapat satu per satu.

Mengapa Perubahan menumpuk pada baris yang sama karena event atau item populer → Akibatnya Request menunggu sampai mendapat lock → Di layar Trade gagal, “Coba lagi nanti”, timeout

Gejala: Aksi hilang / rollback, Input lag
Faktor: Stall, Latensi
Siapa yang mengalami: Fitur tertentu saja
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Pecah barisnya (sharded counter), persingkat transaksi, kumpulkan perubahan di memori lalu terapkan sekaligus.
Tugas Tim Infrastruktur: Pantau waktu tunggu row lock dan jumlah kejadiannya, temukan baris yang paling diperebutkan, lalu bagikan.
Kisaran angka: Jika satu request memegang lock selama 10 ms, baris itu hanya bisa diubah maksimal 100 kali per detik. Jika di dalam transaksi ada round-trip ke server lain, angka itu makin kecil sebanding dengan lamanya.
Di grafik: Naik mengikuti beban · Jumlah dan waktu tunggu row lock
Yang diperiksa: MySQL: periksa kenaikan Innodb_row_lock_waits dan Innodb_row_lock_time serta Innodb_row_lock_current_waits, lalu cari siapa menunggu siapa dengan sys.innodb_lock_waits. PostgreSQL: periksa sesi dengan wait_event_type Lock di pg_stat_activity dan request dengan granted bernilai false di pg_locks; jika log_lock_waits (default nonaktif) diaktifkan, lock yang ditunggu lama tercatat di log
Cocok jika: Jumlah request yang menunggu lock naik tajam mengikuti event dan jumlah pemain, dan sebagian besar request yang menunggu mengarah ke baris yang sama (key yang sama) di tabel yang sama
Tidak cocok jika: Request yang menunggu tersebar merata di banyak tabel dan baris: lebih mungkin disk atau CPU jenuh. Satu sesi memegang lock lama dan tidak melepasnya: lebih mungkin transaksi yang terbuka lama (db-long-tx)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

7 sumber

InnoDB Locking MySQL
Jika satu transaksi mengunci sebuah baris (index record), transaksi lain tidak bisa mengubah baris itu dan harus menunggu
How to Minimize and Handle Deadlocks MySQL
Anjuran untuk menjaga transaksi tetap kecil dan singkat serta segera commit setelah perubahan terkait agar konflik berkurang
Server Status Variables MySQL
Innodb_row_lock_waits dan Innodb_row_lock_time menunjukkan jumlah dan waktu tunggu row lock; Innodb_row_lock_current_waits menunjukkan jumlah yang sedang menunggu
The innodb_lock_waits and x$innodb_lock_waits Views MySQL
Query yang menunggu (waiting_query), sesi yang memblokir (blocking_pid), dan lama menunggu (wait_age)
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
wait_event_type di pg_stat_activity: Lock berarti sedang menunggu heavyweight lock
pg_locks (PostgreSQL Documentation) PostgreSQL
granted bernilai false berarti proses itu sedang menunggu untuk mendapatkan lock
Error Reporting and Logging (PostgreSQL Documentation) PostgreSQL
log_lock_waits: mencatat log jika menunggu lock lebih lama dari deadlock_timeout; default nonaktif

Deadlock DB Database deadlock

ID db-deadlock · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Jika dua transaksi (sekumpulan operasi DB yang diproses sebagai satu kesatuan) saling menunggu baris yang dikunci pihak lain, DB membatalkan salah satunya secara paksa.

Mengapa Trade A mengunci dengan urutan item→mata uang game, trade B dengan urutan mata uang game→item → Akibatnya DB mendeteksi deadlock dan melakukan rollback pada salah satunya → Di layar Trade dan crafting sesekali gagal, item kembali seperti semula

Gejala: Aksi hilang / rollback, Input lag
Faktor: Packet loss, Stall
Siapa yang mengalami: Fitur tertentu saja
Kapan: Saat banyak pemain berkumpul, Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Samakan urutan penguncian, persingkat transaksi, coba ulang otomatis saat gagal.
Tugas Tim Infrastruktur: Biarkan deteksi deadlock aktif, kumpulkan catatan deadlock lalu bagikan, perpendek batas waktu tunggu lock (default 50 detik) di server MySQL yang deteksinya dimatikan.
Kisaran angka: Waktu sampai terdeteksi: MySQL (InnoDB) hampir seketika, PostgreSQL default 1 detik, SQL Server hingga sekitar 5 detik. Selama itu kedua request tertahan. Pada server MySQL yang deteksinya dimatikan karena request bersamaan sangat banyak, request menunggu sampai batas waktu tunggu lock (default 50 detik).
Di grafik: Melonjak acak sesekali · Jumlah deadlock, jumlah trade gagal
Yang diperiksa: MySQL: periksa LATEST DETECTED DEADLOCK di SHOW ENGINE INNODB STATUS (hanya 1 yang terbaru), semua deadlock yang tercatat di error log jika innodb_print_all_deadlocks diaktifkan, dan lock_deadlocks di INFORMATION_SCHEMA.INNODB_METRICS. PostgreSQL: deadlocks di pg_stat_database. SQL Server: xml_deadlock_report di sesi system_health yang aktif secara default. Kode error di sisi server game: MySQL 1213, PostgreSQL 40P01, SQL Server 1205
Cocok jika: Saat trade dan crafting gagal, jumlah deadlock naik, dan dua transaksi yang tercatat mengunci tabel yang sama dengan urutan saling berlawanan
Tidak cocok jika: Jumlah deadlock tidak berubah tetapi tetap gagal: lebih mungkin batas waktu tunggu lock terlampaui (error MySQL 1205) atau hot row (db-hot-row)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

10 sumber

InnoDB Startup Options and System Variables MySQL
Jika deteksi aktif (default), InnoDB langsung mendeteksi deadlock dan melakukan rollback; innodb_lock_wait_timeout default 50 detik
Deadlock Detection MySQL
Pada konkurensi sangat tinggi, deteksi itu sendiri bisa menjadi lambat, sehingga kadang dimatikan dan diserahkan ke batas waktu tunggu lock
Lock Management (PostgreSQL Documentation) PostgreSQL
deadlock_timeout default 1 detik: pemeriksaan deadlock baru dilakukan setelah menunggu lock selama itu
Deadlocks guide Microsoft SQL Server
Interval default pemeriksaan deadlock 5 detik, dipersingkat hingga 100 ms jika deadlock sering terjadi; sesi system_health yang aktif secara default mengumpulkan xml_deadlock_report; pihak yang dikorbankan menerima error 1205
How to Minimize and Handle Deadlocks MySQL
Selalu ubah banyak baris dan tabel dengan urutan yang sama, coba lagi jika gagal, catat semua deadlock dengan innodb_print_all_deadlocks
InnoDB Standard Monitor and Lock Monitor Output MySQL
LATEST DETECTED DEADLOCK: dua transaksi pada deadlock terbaru, lock yang dipegang dan ditunggu, serta transaksi yang dibatalkan (rollback)
InnoDB INFORMATION_SCHEMA Metrics Table MySQL
Counter lock_deadlocks di INNODB_METRICS (aktif secara default)
Server Error Message Reference MySQL
1213 ER_LOCK_DEADLOCK (deadlock), 1205 ER_LOCK_WAIT_TIMEOUT (batas waktu tunggu lock terlampaui)
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
deadlocks di pg_stat_database: jumlah deadlock yang terdeteksi di DB ini
PostgreSQL Error Codes (PostgreSQL Documentation) PostgreSQL
40P01 deadlock_detected

Connection pool habis Connection pool exhaustion

ID db-pool · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Jumlah koneksi yang dibuka ke DB terbatas, jadi jika query lambat menahan koneksi, request lainnya harus menunggu.

Mengapa Semua koneksi terpakai karena query lambat atau lonjakan request → Akibatnya Request baru menunggu sampai ada koneksi yang kosong → Di layar Loading tanpa henti saat login, penyimpanan tertunda, timeout

Gejala: Tidak bisa masuk / loading tanpa henti, Input lag
Faktor: Stall, Latensi
Siapa yang mengalami: Seluruh server, Fitur tertentu saja
Kapan: Tepat setelah login atau maintenance, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Hilangkan query lambat, sesuaikan ukuran pool dan timeout tunggu (jangan asal memperbesar pool), pisahkan pool per fitur.
Tugas Tim Infrastruktur: Periksa batas koneksi maksimum DB serta sisa kapasitas CPU dan IOPS, pastikan jumlah server × ukuran pool masih di bawah batas koneksi maksimum sebelum menambah server atau autoscaling, tambahkan metrik waktu tunggu koneksi dan waktu tunggu lock ke monitoring.
Kisaran angka: Jumlah koneksi yang dibutuhkan diperkirakan dengan “request per detik × waktu satu request menahan koneksi”. Dengan 2.000 request per detik dan 5 ms per request, rata-rata 10 koneksi selalu sibuk. Untuk mengantisipasi lonjakan, biasanya disiapkan dua hingga tiga kali lipatnya. Jika query melambat menjadi 150 ms, request yang sama membutuhkan 300 koneksi.
Di grafik: Mendatar di batas · Jumlah koneksi DB yang terpakai, waktu tunggu koneksi
Yang diperiksa: Hitung status koneksi per server game dari sisi DB. MySQL: periksa Host, Command (koneksi idle tampil sebagai Sleep), dan Time di SHOW PROCESSLIST, serta Threads_connected, Threads_running, dan jumlah koneksi yang ditolak Connection_errors_max_connections. PostgreSQL: kelompokkan pg_stat_activity per client_addr dan state lalu hitung. Jika library connection pool di server game mengekspor jumlah dan waktu tunggu, periksa juga
Cocok jika: Semua koneksi satu server game, sebanyak ukuran pool, sedang menjalankan query dan koneksi idle 0, dan selama itu login dan penyimpanan menunggu. Atau jumlah koneksi seluruh DB mencapai max_connections sehingga koneksi baru ditolak
Tidak cocok jika: Koneksi idle masih banyak tetapi tetap lambat: lebih mungkin latensi query itu sendiri (db-no-index, db-hot-row) atau resource DB jenuh
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Jika pool diperbesar tanpa perhitungan, yang bertambah hanya beban CPU DB dan perebutan lock, sehingga semuanya ikut melambat. Selain itu, jika jumlah server × ukuran pool melebihi batas koneksi maksimum DB, server yang baru ditambahkan atau baru dimulai ulang bahkan tidak bisa membuka koneksi. Ini sering terjadi saat autoscaling atau tepat setelah maintenance.

6 sumber

Number Of Database Connections PostgreSQL
Setelah resource DB habis terpakai, menambah koneksi justru menurunkan throughput; menyesuaikan jumlah koneksi aktif dengan resource dan menaruh sisanya di antrean memberi latensi dan throughput yang lebih baik
Too many connections MySQL
Jika max_connections sudah terpakai semua, koneksi baru ditolak dengan error Too many connections
Connections and Authentication (PostgreSQL Documentation) PostgreSQL
max_connections: batas atas jumlah koneksi bersamaan, dengan nilai default biasanya 100
SHOW PROCESSLIST Statement MySQL
Host (alamat klien), Command (sesi idle tampil sebagai Sleep), Time, State
Server Status Variables MySQL
Threads_connected dan Threads_running, Connection_errors_max_connections (jumlah koneksi yang ditolak karena mencapai max_connections)
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_activity: client_addr dan state (active, idle, idle in transaction, dan lainnya) untuk setiap koneksi

Replication lag Replication lag

ID db-replica-lag · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Penulisan dilakukan ke DB primer dan pembacaan dari replika. Jika replika tertinggal, data yang baru ditulis belum terlihat.

Mengapa Penulisan menumpuk di DB primer sehingga replika tertinggal beberapa detik → Akibatnya Data yang baru disimpan belum ada saat dibaca dari replika → Di layar Item yang baru dibeli tidak terlihat, harga di market masih nilai lama, bug pemberian ganda

Gejala: Aksi hilang / rollback
Faktor: Latensi
Siapa yang mengalami: Fitur tertentu saja
Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Baca data yang baru ditulis dari DB primer, periksa status pemberian dan berikan item dalam satu transaksi di DB primer (cegah duplikasi dengan unique key atau UPDATE bersyarat).
Tugas Tim Infrastruktur: Pasang alert replication lag, beri replika spesifikasi minimal setara DB primer dan terapkan replikasi paralel, jalankan penghapusan massal dalam potongan kecil, kelola query agregasi yang berjalan lama di replika.
Di grafik: Naik mengikuti beban · Replication lag (detik)
Yang diperiksa: MySQL: periksa Seconds_Behind_Source di SHOW REPLICA STATUS pada replika (versi sebelum 8.0.22: SHOW SLAVE STATUS). PostgreSQL: periksa write_lag, flush_lag, dan replay_lag di pg_stat_replication pada server primer. RDS: periksa ReplicaLag
Cocok jika: Pada waktu laporan “tidak terlihat”, replication lag mencapai beberapa detik atau lebih, dan setelah lag itu hilang, data terlihat normal. Lag membesar saat lonjakan penulisan, penghapusan massal, atau query agregasi panjang di replika
Tidak cocok jika: Replication lag mendekati 0 tetapi data tetap tidak terlihat: lebih mungkin cache atau sinkronisasi di server game
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Replika bisa tertinggal walaupun penulisan tidak banyak. Satu penghapusan massal yang memakan 10 menit di DB primer dijalankan ulang di replika, sehingga replika tertinggal selama itu. Query agregasi yang berjalan lama di replika juga memperlambat replika mengejar ketertinggalan.

6 sumber

SHOW REPLICA STATUS Statement MySQL
Seconds_Behind_Source: selisih antara waktu event yang sedang diterapkan replika dan waktu event itu dicatat di DB primer (replication lag)
Replica Server Options and Variables MySQL
Dengan replica_parallel_workers, beberapa thread menerapkan transaksi secara paralel (default 4; jika 0, satu thread menerapkannya berurutan)
Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
Streaming replication secara default asinkron, sehingga ada jeda antara commit dan penerapannya di replika (biasanya kurang dari 1 detik jika replika mampu mengikuti)
MySQL 8.0 Reference Manual: SHOW REPLICA STATUS Statement MySQL
Mulai 8.0.22, SHOW REPLICA STATUS menggantikan SHOW SLAVE STATUS; versi sebelumnya memakai SHOW SLAVE STATUS
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
write_lag, flush_lag, dan replay_lag di pg_stat_replication: waktu sejak server primer menulis WAL sampai replika melaporkan bahwa WAL telah ditulis, disimpan ke disk (flush), dan diterapkan
Amazon CloudWatch metrics for Amazon RDS AWS
ReplicaLag: seberapa lama (detik) read replica tertinggal dari instance sumber

Checkpoint dan log flush Checkpoint / log flush stalls

ID db-checkpoint · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur)

Query melambat saat DB secara berkala menulis sekaligus perubahan yang tersimpan di memori ke disk.

Mengapa Perubahan menumpuk lalu ditulis ke disk secara berkala → Akibatnya Saat itu disk sibuk sehingga query melambat → Di layar Penyimpanan dan loading melambat secara berkala

Gejala: Input lag, Patah-patah
Faktor: Latensi
Siapa yang mengalami: Seluruh server, Fitur tertentu saja
Kapan: Secara berkala
Penanggung jawab: Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Infrastruktur: Pecah checkpoint menjadi bagian kecil agar penulisannya merata, beri ukuran log transaksi (redo log, WAL) yang lega, gunakan disk yang cepat.
Di grafik: Melonjak secara berkala · Latensi query DB, volume tulis disk
Yang diperiksa: PostgreSQL: periksa waktu checkpoint dan jumlah buffer yang ditulis di log log_checkpoints (aktif secara default di versi terbaru), jumlah checkpoint (versi 17 ke atas: num_timed dan num_requested di pg_stat_checkpointer; versi 16 ke bawah: checkpoints_timed dan checkpoints_req di pg_stat_bgwriter), serta peringatan checkpoint_warning. MySQL: periksa selisih Log sequence number dan Last checkpoint at di bagian LOG pada SHOW ENGINE INNODB STATUS. Tumpangkan juga volume tulis dan latensi tulis disk di server
Cocok jika: Waktu lonjakan latensi query bertepatan dengan waktu checkpoint, dan saat itu volume tulis serta latensi tulis disk melonjak. Di PostgreSQL, jika checkpoint atas permintaan (num_requested) jauh lebih banyak daripada checkpoint terjadwal (num_timed), artinya WAL sering mencapai max_wal_size sehingga checkpoint terjadi lebih awal
Tidak cocok jika: Melonjak dengan periode yang tidak terkait waktu checkpoint: lebih mungkin backup atau batch job (dk-backup, db-batch)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Jika log transaksi yang menyimpan catatan perubahan (redo log di MySQL, WAL di PostgreSQL) diatur terlalu kecil, DB terpaksa menjalankan checkpoint sekaligus secara terburu-buru setiap kali log penuh, sehingga throughput penulisan berulang kali anjlok tajam untuk sesaat.

7 sumber

WAL Configuration (PostgreSQL Documentation) PostgreSQL
Secara default checkpoint terjadi setiap 5 menit atau setiap 1 GB WAL (max_wal_size) dan mahal karena menulis semua dirty page. checkpoint_completion_target menyebar penulisan untuk menghindari lonjakan I/O. Jika interval checkpoint lebih pendek dari checkpoint_warning, log mencatat peringatan agar max_wal_size dinaikkan
Configuring Buffer Pool Flushing MySQL
Saat redo log penuh, sharp checkpoint (checkpoint mendadak) membuat throughput turun sesaat; adaptive flushing menyebar penulisan secara merata
Error Reporting and Logging (PostgreSQL Documentation) PostgreSQL
log_checkpoints: mencatat jumlah buffer yang ditulis dan lama setiap checkpoint di log; default aktif
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
num_timed (checkpoint yang dijalankan karena waktunya tiba) dan num_requested (checkpoint yang diminta) di pg_stat_checkpointer
PostgreSQL 17 Release Notes PostgreSQL
pg_stat_checkpointer ditambahkan, kolom terkait checkpoint dipindahkan dari pg_stat_bgwriter
The Cumulative Statistics System (PostgreSQL 16 Documentation) PostgreSQL
Sampai versi 16: checkpoints_timed dan checkpoints_req di pg_stat_bgwriter
InnoDB Standard Monitor and Lock Monitor Output MySQL
Bagian LOG: log sequence number saat ini dan posisi checkpoint terakhir

Cold cache (tepat setelah restart) Cold buffer pool after restart

ID db-cold-cache · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Setelah DB dimulai ulang, cache di memori kosong, sehingga untuk sementara semua pembacaan data diambil dari disk.

Mengapa DB dimulai ulang karena maintenance → Akibatnya Data yang sering dipakai tidak ada di memori sehingga dibaca dari disk → Di layar Login dan loading lambat untuk sementara tepat setelah maintenance

Gejala: Tidak bisa masuk / loading tanpa henti, Input lag
Faktor: Latensi
Siapa yang mengalami: Seluruh server
Kapan: Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Buka server secara bertahap (gunakan antrean login untuk menambah jumlah pemain yang login sedikit demi sedikit).
Tugas Tim Infrastruktur: Lakukan warm-up cache setelah restart (periksa pengaturan simpan dan pulihkan buffer pool), untuk DB yang dipulihkan dari snapshot baca juga disknya lebih dulu.
Di grafik: Melonjak tepat setelah server dibuka · Pembacaan disk, hit rate buffer cache
Yang diperiksa: MySQL: periksa rasio Innodb_buffer_pool_reads (jumlah pembacaan dari disk karena data tidak ada di buffer pool) terhadap Innodb_buffer_pool_read_requests, serta progres warm-up di Innodb_buffer_pool_load_status. PostgreSQL: periksa blks_read dan blks_hit di pg_stat_database. Periksa juga jumlah pembacaan disk di server DB
Cocok jika: Tepat setelah restart, pembacaan disk melonjak dan hit rate rendah, lalu pulih seiring waktu, dan selama rentang itu login dan loading lambat
Tidak cocok jika: Hit rate sama seperti biasa tetapi lambat tepat setelah maintenance: lebih mungkin lonjakan login dan N+1 (db-login-storm) atau connection pool (db-pool)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: MySQL menyimpan daftar page di buffer pool saat dimatikan, lalu membacanya kembali di latar belakang saat dinyalakan, tetapi butuh waktu sampai buffer pool terisi penuh. Jika DB di cloud dipulihkan dari snapshot (salinan disk), disk itu sendiri juga lambat pada setiap blok yang pertama kali dibaca, sehingga masa lambat ini berlangsung lebih lama.
Kasus nyata: Roblox 2021: Gangguan 73 jam di Roblox: perebutan sumber daya di cluster service discovery (Consul)

5 sumber

Saving and Restoring the Buffer Pool State MySQL
Untuk mempersingkat waktu warm-up setelah restart, daftar page yang baru dipakai (default 25%) disimpan saat dimatikan dan dibaca kembali saat dinyalakan; keduanya aktif secara default
pg_prewarm — preload relation data into buffer caches PostgreSQL
Isi shared buffer dicatat secara berkala lalu dimuat kembali setelah restart (autoprewarm)
Initialize Amazon EBS volumes AWS
Volume yang dibuat dari snapshot mengalami latensi lebih tinggi dan performa lebih rendah sampai semua bloknya selesai diambil
Server Status Variables MySQL
Innodb_buffer_pool_reads (jumlah logical read yang harus dibaca langsung dari disk karena tidak ada di buffer pool), Innodb_buffer_pool_read_requests, Innodb_buffer_pool_load_status (progres warm-up)
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
blks_read (jumlah blok yang dibaca dari disk) dan blks_hit (jumlah blok yang ditemukan di buffer cache) di pg_stat_database

Batch job berskala besar Batch jobs during service

ID db-batch · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Agregasi ranking, pengiriman mail massal, dan pembersihan data lama yang dijalankan saat layanan berjalan menahan lock dan menyita kapasitas disk.

Mengapa Pekerjaan berskala besar dijalankan pada jam layanan → Akibatnya Lock dengan cakupan luas, disk dan CPU tersita → Di layar Trade dan penyimpanan gagal pada jam tertentu, loading tertunda

Gejala: Input lag, Aksi hilang / rollback
Faktor: Latensi, Stall
Siapa yang mengalami: Fitur tertentu saja, Seluruh server
Kapan: Secara berkala
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Pecah pekerjaan menjadi potongan kecil dan jalankan sedikit demi sedikit, jalankan agregasi di replika.
Tugas Tim Infrastruktur: Sediakan replika khusus agregasi, jadwalkan batch job di jam sepi, pantau lock escalation dan waktu tunggu gap lock.
Di grafik: Melonjak secara berkala · Latensi query DB, waktu tunggu lock
Yang diperiksa: Cari query panjang yang berjalan pada waktu lag. Periksa slow query log (MySQL) atau query_start dan query di pg_stat_activity (PostgreSQL), lalu cocokkan dengan metrik waktu tunggu lock pada waktu yang sama dan jadwal batch (cron, event scheduler DB). Di SQL Server, catat lock escalation dengan extended event lock_escalation
Cocok jika: UPDATE, DELETE, atau query agregasi berskala besar berjalan pada jam yang sama setiap kali, dan selama itu waktu tunggu lock serta utilisasi disk naik bersamaan
Tidak cocok jika: Tidak ada query panjang pada waktu itu: lebih mungkin checkpoint (db-checkpoint) atau backup server (dk-backup)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Jika satu statement memegang lebih dari sekitar 5.000 row lock, SQL Server mengubahnya menjadi table lock (lock escalation). Saat itu semua request yang memakai tabel yang sama tertahan. Dengan pengaturan default, MySQL juga mengunci celah di antara baris (gap lock) saat data diubah dengan kondisi rentang, sehingga baris baru tidak bisa ditambahkan.

4 sumber

Transaction Locking and Row Versioning Guide Microsoft SQL Server
Jika satu statement memegang 5.000 lock atau lebih pada satu tabel (atau indeks), terjadi lock escalation; dicatat dengan extended event lock_escalation
InnoDB Locking MySQL
Pada isolation level default InnoDB, yaitu REPEATABLE READ, pencarian dan scan memakai next-key lock, sehingga gap lock mencegah penambahan baris baru di celah tersebut
The Slow Query Log MySQL
Mencatat query yang melebihi long_query_time beserta waktu eksekusi (Query_time), waktu lock (Lock_time), dan jumlah baris yang dibaca
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_activity: query yang sedang berjalan (query) dan waktu mulainya (query_start) untuk setiap sesi

Failover DB Database failover

ID db-failover · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Selama DB primer mati dan layanan dialihkan ke DB cadangan, penulisan tidak bisa dilakukan, dan data terakhir yang belum sempat direplikasi bisa hilang.

Mengapa DB primer mengalami gangguan sehingga DB cadangan dipromosikan → Akibatnya Selama peralihan, penulisan tidak bisa dilakukan selama beberapa detik hingga beberapa menit; dengan replikasi asinkron, data yang belum direplikasi bisa hilang → Di layar Semua penyimpanan gagal sesaat, item dan EXP kembali ke kondisi sebelumnya (rollback)

Gejala: Aksi hilang / rollback, Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti
Faktor: Stall, Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Buat penyimpanan yang bisa dicoba ulang, atur agar koneksi yang terputus cepat dibuang lalu dibuka ulang ke alamat baru (connection pool, cache DNS), pastikan koneksi ulang berjalan saat latihan failover.
Tugas Tim Infrastruktur: Gunakan replikasi sinkron atau semi-sinkron (dengan konsekuensi latensi tulis bertambah), lakukan latihan failover, pantau waktu failover dan replication lag.
Kisaran angka: Failover otomatis pada DB terkelola biasanya memakan puluhan detik hingga 2 menit. Dengan replikasi asinkron, penyimpanan terbaru bisa hilang sebanyak replication lag (kurang dari 1 detik hingga beberapa detik).
Di grafik: Koneksi putus serentak · Jumlah koneksi DB, jumlah error penulisan
Yang diperiksa: Letakkan catatan failover di sisi DB (RDS: event RDS-EVENT-0013 failover dimulai dan RDS-EVENT-0049 failover selesai; DB yang dikelola sendiri: log promosi) bersama jumlah koneksi DB dan jumlah error koneksi server game dalam satu grafik. Jika memakai replikasi asinkron, periksa juga replication lag sesaat sebelum gangguan (RDS ReplicaLag, replay_lag di pg_stat_replication PostgreSQL)
Cocok jika: Kegagalan penyimpanan terkumpul di satu rentang waktu yang bertepatan dengan periode antara mulai dan selesainya failover. Banyaknya data yang kembali ke kondisi lama kira-kira sama dengan replication lag sesaat sebelum gangguan. Server game yang masih error setelah failover selesai berarti terus memakai koneksi yang dibuka ke alamat lama
Tidak cocok jika: Koneksi terputus pada waktu tanpa catatan failover: lebih mungkin masalah jaringan atau DB kelebihan beban
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Kasus nyata: Riot Games 2021: Gangguan 5 jam di League of Legends EUW: satu DB pendukung menghentikan seluruh server

7 sumber

Failing over a Multi-AZ DB instance for Amazon RDS AWS
Failover Multi-AZ biasanya 60–120 detik; setelah failover koneksi harus dibuka ulang, dan TTL cache DNS JVM dianjurkan maksimal 60 detik
High availability for Amazon Aurora AWS
Selama gangguan, pembacaan dan penulisan gagal; biasanya pulih dalam 60 detik (sering dalam 30 detik)
Semisynchronous Replication MySQL
Dengan replikasi asinkron, transaksi yang sudah di-commit bisa tidak ada di replika jika DB primer mati; replikasi semi-sinkron menguranginya dengan menunggu konfirmasi terima dari satu replika, dengan konsekuensi latensi bertambah
Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
Log shipping berjalan asinkron, sehingga transaksi yang belum terkirim hilang jika server primer mati; lag streaming replication biasanya kurang dari 1 detik
Amazon RDS event categories and event messages AWS
RDS-EVENT-0013: failover Multi-AZ dimulai, RDS-EVENT-0049: failover Multi-AZ selesai
Amazon CloudWatch metrics for Amazon RDS AWS
ReplicaLag: seberapa lama (detik) read replica tertinggal dari instance sumber
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
replay_lag di pg_stat_replication: waktu sejak server primer menulis WAL sampai replika melaporkan bahwa WAL telah diterapkan

Progres hilang karena interval penyimpanan yang panjang Periodic save window

ID db-save-interval · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Jika data hanya disimpan beberapa menit sekali untuk mengurangi beban, progres akan hilang saat server mati di antara dua penyimpanan.

Mengapa State karakter disimpan sekali setiap beberapa menit → Akibatnya Di sela waktu itu server crash atau mengalami gangguan → Di layar Setelah login ulang, karakter kembali ke kondisi beberapa menit sebelumnya (rollback)

Gejala: Aksi hilang / rollback
Faktor: Packet loss
Siapa yang mengalami: Seluruh server, Lokasi/channel tertentu
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Simpan event penting (trade, perolehan item langka) saat itu juga, catat log perubahan.
Tugas Tim Infrastruktur: Pastikan DB punya sisa kapasitas IOPS dan CPU untuk menanggung penulisan yang bertambah saat interval penyimpanan diperpendek.
Di grafik: Koneksi putus serentak · Jumlah koneksi, jumlah laporan rollback
Yang diperiksa: Bandingkan waktu crash atau gangguan dengan waktu penyimpanan terakhir karakter yang melaporkan rollback (log penyimpanan di server game atau kolom waktu perubahan di DB)
Cocok jika: Titik kembalinya karakter sama dengan waktu penyimpanan terakhir sesaat sebelum crash, dan waktu yang hilang lebih pendek dari interval penyimpanan
Tidak cocok jika: Log server game mencatat penyimpanan sudah selesai tetapi data tetap kembali ke kondisi lama: lebih mungkin data hilang saat failover DB (db-failover) atau nilai lama dibaca dari replika (db-replica-lag)
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

Asynchronous Commit (PostgreSQL Documentation) PostgreSQL
Mengumpulkan catatan lalu menuliskannya ke disk belakangan menaikkan throughput, dengan konsekuensi transaksi terbaru bisa hilang saat terjadi gangguan (trade-off yang sama)
Redis persistence Redis
Jika snapshot RDB dibuat setiap beberapa menit, kehilangan data beberapa menit terakhir saat terminasi abnormal adalah risiko yang harus diterima

Cache stampede Cache stampede / thundering herd

ID db-cache-stampede · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Jika cache data populer kedaluwarsa bersamaan, ribuan request menyerbu DB sekaligus.

Mengapa Data populer yang disimpan di Redis dan sejenisnya kedaluwarsa bersamaan → Akibatnya Request yang ingin membuat ulang data yang sama menyerbu DB sekaligus → Di layar DB kelebihan beban sehingga banyak fitur satu per satu melambat atau berhenti merespons

Gejala: Input lag, Freeze, Tidak bisa masuk / loading tanpa henti
Faktor: Stall, Latensi
Siapa yang mengalami: Seluruh server
Kapan: Secara berkala, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Sebar waktu kedaluwarsa secara acak, biarkan hanya satu request yang memperbarui cache sementara sisanya memakai nilai lama.
Tugas Tim Infrastruktur: Siapkan replika dan failover otomatis agar cache tidak kosong total saat Redis dimulai ulang atau mengalami gangguan, pastikan DB punya sisa kapasitas untuk bertahan walaupun cache kosong.
Di grafik: Melonjak secara berkala · Hit rate cache, jumlah query DB per detik
Yang diperiksa: Tumpangkan keyspace_hits dan keyspace_misses (hit rate), expired_keys, dan tanda restart (uptime_in_seconds) dari INFO Redis dengan jumlah query DB per detik, lalu hitung berapa banyak query yang sama berjalan bersamaan di DB pada saat itu (MySQL SHOW PROCESSLIST, PostgreSQL pg_stat_activity)
Cocok jika: Saat cache miss tiba-tiba melonjak, jumlah query DB ikut melonjak, dan sebagian besar query yang berjalan bersamaan adalah query yang sama yang membaca data yang sama. Waktunya bertepatan dengan periode kedaluwarsa key populer atau waktu restart Redis
Tidak cocok jika: Cache miss sama seperti biasa tetapi hanya query DB yang bertambah: lebih mungkin lonjakan login (db-login-storm) atau batch job (db-batch)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Hal yang sama terjadi jika cache kosong total karena Redis dimulai ulang atau mengalami gangguan. Risikonya makin besar pada arsitektur yang mengandalkan cache sehingga DB-nya disiapkan dengan kapasitas kecil.

6 sumber

Scaling Memcache at Facebook (NSDI '13) USENIX
Thundering herd: saat key yang sering dipakai diinvalidasi, banyak pembacaan menyerbu DB; dicegah dengan lease (hanya satu klien yang memperbarui) dan mengembalikan nilai lama; warm-up untuk cluster yang cache-nya kosong dilakukan terpisah
Optimal Probabilistic Cache Stampede Prevention VLDB Endowment
Cache stampede: saat item populer kedaluwarsa, banyak request membuatnya ulang bersamaan; dicegah dengan memperbarui lebih awal secara probabilistik sebelum kedaluwarsa
High availability with Redis Sentinel Redis
Failover otomatis yang mempromosikan replika saat server primer mati
INFO Redis
keyspace_hits dan keyspace_misses (jumlah lookup key yang berhasil dan gagal), expired_keys (jumlah key yang kedaluwarsa), uptime_in_seconds (waktu sejak dijalankan)
SHOW PROCESSLIST Statement MySQL
Statement yang sedang dijalankan (Info) dan lama berada di status saat ini (Time, dalam detik) untuk setiap sesi
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_activity: query yang sedang berjalan (query) untuk setiap sesi

Transaksi yang terbuka lama Long-running transaction / MVCC purge lag

ID db-long-tx · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Transaksi yang terbuka lama terus memegang lock, dan DB tidak bisa membersihkan data versi lama (purge), sehingga seluruh DB makin lama makin lambat.

Mengapa Menunggu respons server lain sambil membiarkan transaksi terbuka, atau menjalankan query agregasi panjang di DB primer saat layanan berjalan → Akibatnya Lock yang dipegang tidak dilepas, dan data versi lama yang harus dibersihkan terus menumpuk → Di layar Fitur yang memakai baris itu timeout, penyimpanan dan pembacaan data melambat secara umum selama beberapa jam

Gejala: Input lag, Aksi hilang / rollback
Faktor: Latensi, Stall
Siapa yang mengalami: Fitur tertentu saja, Seluruh server
Kapan: Makin lama menyala, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Jangan menunggu pemanggilan jaringan atau input pengguna di dalam transaksi, jalankan query agregasi di replika.
Tugas Tim Infrastruktur: Pasang alert untuk transaksi yang terbuka lama dan hentikan paksa, sediakan replika khusus agregasi, pantau pertambahan undo log dan baris mati.
Di grafik: Naik perlahan · Panjang undo log (History list length), jumlah baris mati
Yang diperiksa: MySQL: cari transaksi tertua dengan trx_started di INFORMATION_SCHEMA.INNODB_TRX, lalu periksa History list length (jumlah undo log yang belum dibersihkan) di bagian TRANSACTIONS pada SHOW ENGINE INNODB STATUS. PostgreSQL: periksa xact_start dan sesi dengan state idle in transaction di pg_stat_activity, serta n_dead_tup di pg_stat_user_tables
Cocok jika: Ada transaksi yang sudah berumur beberapa menit hingga beberapa jam, dan selama itu History list length atau n_dead_tup terus naik, lalu turun setelah transaksi itu diakhiri dan pembersihan (purge, VACUUM) berjalan
Tidak cocok jika: Tidak ada transaksi lama tetapi DB lambat secara umum: lebih mungkin checkpoint (db-checkpoint) atau disk
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: DB menyimpan versi lama data agar pihak yang membaca bisa melihat kondisi sebelum diubah (MVCC). Catatan ini baru bisa dihapus setelah transaksi tertua selesai, sehingga jika satu transaksi terbuka selama beberapa jam, undo log menumpuk di MySQL, dan di PostgreSQL menumpuk baris mati (dead tuple) yang tidak bisa dibersihkan VACUUM. Di SQL Server, log transaksi tidak bisa menyusut dan kadang sampai memenuhi disk.

7 sumber

InnoDB Multi-Versioning MySQL
Selama masih ada transaksi yang bisa melihat versi lama, update undo log tidak bisa dibuang sehingga rollback segment membesar; transaksi yang hanya membaca pun dianjurkan sering di-commit
Routine Vacuuming (PostgreSQL Documentation) PostgreSQL
Versi baris lama tidak bisa dihapus selama transaksi lain masih bisa melihatnya; transaksi yang terbuka lama harus diakhiri atau sesinya dihentikan
Client Connection Defaults (PostgreSQL Documentation) PostgreSQL
idle_in_transaction_session_timeout: memutus sesi yang idle dengan transaksi masih terbuka agar lock tidak dipegang terlalu lama
Troubleshoot a full transaction log (SQL Server Error 9002) Microsoft SQL Server
Transaksi aktif yang berjalan lama menghalangi pembersihan log transaksi
The INFORMATION_SCHEMA INNODB_TRX Table MySQL
TRX_STARTED: waktu mulai transaksi
Purge Configuration MySQL
Purge membersihkan daftar undo log transaksi yang sudah di-commit (history list); jumlah yang tertunda ditampilkan sebagai History list length di bagian TRANSACTIONS pada SHOW ENGINE INNODB STATUS
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
xact_start (waktu mulai transaksi) dan state (idle in transaction) di pg_stat_activity, n_dead_tup (perkiraan jumlah baris mati) di pg_stat_user_tables

Perintah lambat di Redis Redis blocking commands (single-threaded)

ID db-redis-block · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Redis memproses perintah satu per satu, sehingga satu perintah lambat menahan semua request di belakangnya.

Mengapa Saat layanan berjalan, seluruh key dicari dengan KEYS, atau ranking dan list berisi jutaan elemen dibaca atau dihapus sekaligus → Akibatnya Semua request lain menunggu sampai perintah itu selesai (puluhan ms hingga beberapa detik) → Di layar Fitur yang memakai sesi, ranking, dan cache tersendat sesaat secara bersamaan, login tertunda

Gejala: Freeze, Input lag, Tidak bisa masuk / loading tanpa henti
Faktor: Stall, Latensi
Siapa yang mengalami: Seluruh server, Fitur tertentu saja
Kapan: Sesekali secara acak, Secara berkala
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Gunakan SCAN sebagai pengganti KEYS, pecah key besar, hapus dengan UNLINK (penghapusan di latar belakang), sebar waktu kedaluwarsa yang menumpuk di detik yang sama.
Tugas Tim Infrastruktur: Pantau log perintah lambat (SLOWLOG), blokir perintah berbahaya seperti KEYS di server produksi, periksa key besar secara rutin, matikan THP dan sisakan memori yang cukup untuk fork, jalankan penyimpanan RDB dan AOF di replika.
Kisaran angka: Perintah biasa butuh kurang dari 1 ms. Jika jutaan elemen ditangani sekaligus, waktunya bisa mencapai ratusan ms hingga beberapa detik.
Di grafik: Melonjak acak sesekali · Latensi respons Redis, jumlah perintah lambat
Yang diperiksa: Periksa perintah yang melebihi slowlog-log-slower-than dengan SLOWLOG GET, aktifkan latency monitor (default nonaktif) dengan CONFIG SET latency-monitor-threshold, lalu periksa latensi per event seperti fork dan expire-cycle dengan LATENCY LATEST dan LATENCY DOCTOR. Periksa juga waktu fork dan key besar dengan latest_fork_usec di INFO dan redis-cli --bigkeys
Cocok jika: Pada waktu Redis berhenti, SLOWLOG mencatat KEYS atau perintah yang menangani key besar sekaligus, atau LATENCY mencatat event fork atau expire-cycle pada waktu yang sama dengan durasi puluhan ms atau lebih
Tidak cocok jika: SLOWLOG dan LATENCY kosong tetapi lambat hanya di sisi server game: lebih mungkin jaringan atau waktu tunggu di dalam server game (SLOWLOG hanya mengukur waktu eksekusi perintah, tanpa waktu kirim-terima dengan klien)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Redis juga berhenti sesaat ketika menduplikasi prosesnya (fork) untuk membuat file simpanan (snapshot RDB) atau menulis ulang AOF. Di server modern, jedanya sekitar 10 ms per 1 GB memori, jadi sekitar 300 ms untuk 30 GB. Jika halaman besar (THP) diaktifkan, setiap penulisan setelah fork menyalin satu halaman besar secara utuh (copy-on-write), sehingga jeda dan pemakaian memori melonjak. Karena itu THP biasanya dimatikan dan memori disisakan dengan lega. Redis juga berhenti sesaat untuk menghapus key jika sangat banyak key kedaluwarsa pada detik yang sama.

7 sumber

Diagnosing latency issues Redis
Satu thread memproses request secara berurutan sehingga perintah lambat menahan semua yang di belakangnya; gunakan SCAN sebagai pengganti KEYS; hasil pengukuran fork di server fisik dan VM modern sekitar 9–13 ms per 1 GB; THP membuat latensi dan memori melonjak karena penyalinan setelah fork; Redis berhenti jika banyak key kedaluwarsa pada detik yang sama
KEYS Redis
Gunakan dengan sangat hati-hati di lingkungan produksi karena bisa merusak performa pada DB besar (40 ms untuk 1 juta key di laptop kelas entry-level)
UNLINK Redis
Penghapusan asinkron: key langsung dilepas, sedangkan pengambilan kembali memori dilakukan di thread lain
SLOWLOG Redis
Log perintah lambat yang mencatat perintah yang melebihi slowlog-log-slower-than; waktu eksekusinya tidak mencakup I/O kirim-terima dengan klien
Redis latency monitoring Redis
latency-monitor-threshold default 0 (nonaktif); LATENCY LATEST dan LATENCY DOCTOR; mencatat latensi per event seperti fork dan expire-cycle
INFO Redis
latest_fork_usec: waktu yang dibutuhkan fork terakhir (mikrodetik)
Redis CLI Redis
--bigkeys: memindai keyspace untuk menemukan key besar

Query melambat karena query plan berubah Query plan regression (stats, parameter sniffing)

ID db-plan-flip · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Walaupun kodenya tidak berubah, jika DB mengganti cara memproses query yang sama (query plan), query yang kemarin 2 ms bisa menjadi ratusan ms hari ini.

Mengapa Pembaruan statistik otomatis, restart DB, atau perubahan distribusi data membuat DB menyusun query plan baru → Akibatnya Plan yang tidak memakai indeks terpilih, sehingga query yang sama menjadi puluhan hingga ratusan kali lebih lambat dan koneksi tertahan → Di layar Tanpa ada deploy, loading fitur tertentu tiba-tiba melambat dan request lain ikut menunggu

Gejala: Input lag, Tidak bisa masuk / loading tanpa henti
Faktor: Latensi, Stall
Siapa yang mengalami: Fitur tertentu saja, Seluruh server
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pisahkan query yang jumlah hasilnya sangat berbeda tergantung nilainya atau pertimbangkan plan hint, rancang query yang pasti memakai indeks.
Tugas Tim Infrastruktur: Pantau query lambat dan riwayat query plan, kunci plan yang baik (Query Store SQL Server dan sejenisnya), atur waktu pembaruan statistik.
Di grafik: Naik seperti anak tangga · Rata-rata waktu eksekusi per query
Yang diperiksa: Kumpulkan rata-rata waktu query berpola sama secara berkala dan periksa trennya. MySQL: AVG_TIMER_WAIT di events_statements_summary_by_digest. PostgreSQL: mean_exec_time di pg_stat_statements (versi 12 ke bawah: mean_time). Bandingkan query plan sebelum dan sesudah melambat dengan EXPLAIN atau auto_explain PostgreSQL; di SQL Server, gunakan tampilan Regressed Queries di Query Store
Cocok jika: Pada waktu tanpa deploy, rata-rata waktu satu query naik seperti anak tangga hingga puluhan kali lipat, waktunya bertepatan dengan pembaruan statistik atau restart DB, dan query plan-nya sudah berubah
Tidak cocok jika: Query plan tidak berubah tetapi query melambat: lebih mungkin pertambahan data, menunggu lock (db-hot-row), atau disk
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: SQL Server memakai ulang plan yang disusun berdasarkan nilai yang pertama kali masuk (parameter sniffing). Jika plan yang disusun untuk karakter baru dengan beberapa item saja dipakai untuk karakter lama dengan puluhan ribu item, query menjadi sangat lambat, dan kasus sebaliknya juga sering terjadi. Saat plan terhapus karena restart, query kembali normal, lalu bisa memburuk lagi.

7 sumber

Query Processing Architecture Guide Microsoft SQL Server
Parameter sniffing: query plan disusun berdasarkan nilai parameter yang masuk saat kompilasi atau rekompilasi
Parameter Sensitive Plan Optimization Microsoft SQL Server
Jika distribusi data tidak merata, satu plan yang disimpan di cache tidak cocok untuk semua nilai parameter
Monitor performance by using the Query Store Microsoft SQL Server
Plan berubah karena perubahan statistik, skema, atau indeks, dan plan cache hanya menyimpan plan terbaru; plan forcing di Query Store mengunci plan yang baik; tampilan Regressed Queries membandingkan query yang melambat beserta plan-nya
Statement Summary Tables MySQL
events_statements_summary_by_digest: COUNT_STAR dan AVG_TIMER_WAIT (waktu rata-rata) per pola query yang sama
pg_stat_statements — track statistics of SQL planning and execution PostgreSQL
calls, total_exec_time, dan mean_exec_time (rata-rata waktu eksekusi) per statement
pg_stat_statements (PostgreSQL 12 Documentation) PostgreSQL
Sampai versi 12, nama kolomnya total_time dan mean_time
auto_explain — log execution plans of slow queries PostgreSQL
Mencatat query plan dari query yang berjalan lebih lama dari auto_explain.log_min_duration ke log

Lock akibat perubahan skema (DDL) saat layanan berjalan Schema change lock (DDL / metadata lock)

ID db-ddl-lock · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika kolom atau indeks ditambahkan ke tabel saat layanan berjalan, satu lock yang dibutuhkan sesaat bisa membuat semua request yang memakai tabel itu menunggu.

Mengapa Hotfix menambahkan kolom atau indeks ke tabel yang sedang dipakai layanan → Akibatnya Perubahan skema menunggu transaksi panjang yang sudah terbuka lebih dulu, dan semua request yang datang sesudahnya menunggu perubahan skema itu → Di layar Fitur yang memakai tabel itu (inventory, mail, dan sebagainya) berhenti total lalu timeout

Gejala: Input lag, Aksi hilang / rollback, Tidak bisa masuk / loading tanpa henti
Faktor: Stall
Siapa yang mengalami: Fitur tertentu saja, Seluruh server
Kapan: Sesekali secara acak, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Untuk hotfix yang berisi perubahan skema, sepakati jadwalnya dengan Infrastruktur DB, deploy lebih dulu kode yang tetap berjalan walaupun kolom baru belum ada.
Tugas Tim Infrastruktur: Pasang batas waktu tunggu lock yang pendek dan coba lagi jika gagal, jalankan saat tidak ada transaksi panjang, gunakan tools perubahan skema online, ubah tabel besar saat maintenance.
Di grafik: Naik seperti anak tangga · Jumlah sesi yang menunggu lock, latensi query pada tabel itu
Yang diperiksa: MySQL: hitung sesi dengan State Waiting for table metadata lock di SHOW PROCESSLIST, lalu cari sesi yang memblokir (blocking_pid) dengan sys.schema_table_lock_waits. PostgreSQL: periksa request dengan granted bernilai false dan AccessExclusiveLock di pg_locks, lalu cari sesi yang memblokir dengan pg_blocking_pids()
Cocok jika: Sejak perubahan skema dimulai, semua query yang memakai tabel itu menumpuk menunggu lock, dan di posisi paling depan ada transaksi yang belum selesai atau statement perubahan skema
Tidak cocok jika: Request yang menunggu hanya terpusat di baris tertentu, sedangkan baris lain di tabel yang sama diproses dengan lancar: lebih mungkin hot row (db-hot-row)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Saat skema diubah, MySQL memegang metadata lock sesaat, sedangkan PostgreSQL memegang table lock terkuat sesaat. Walaupun perubahannya sendiri selesai dalam sekejap, jika di depannya ada satu transaksi yang belum selesai, semua request di belakangnya menunggu.

8 sumber

Online DDL Performance and Concurrency MySQL
Online DDL pun membutuhkan exclusive metadata lock sesaat di tahap akhir; jika ada transaksi panjang, DDL menunggu, dan permintaan lock yang menunggu itu menahan semua transaksi di belakangnya
Server System Variables MySQL
lock_wait_timeout: batas waktu tunggu metadata lock, default 31.536.000 detik (1 tahun)
ALTER TABLE (PostgreSQL Documentation) PostgreSQL
ALTER TABLE tanpa keterangan khusus memegang lock ACCESS EXCLUSIVE yang paling kuat
Client Connection Defaults (PostgreSQL Documentation) PostgreSQL
lock_timeout: statement dibatalkan jika menunggu lock lebih lama dari waktu ini
General Thread States MySQL
Waiting for table metadata lock: status thread yang sedang menunggu metadata lock
The schema_table_lock_waits and x$schema_table_lock_waits Views MySQL
Sesi yang menunggu metadata lock (waiting_query) dan sesi yang memblokir (blocking_pid)
pg_locks (PostgreSQL Documentation) PostgreSQL
granted bernilai false berarti sedang menunggu lock; mode berisi jenis lock seperti AccessExclusiveLock
System Information Functions and Operators (PostgreSQL Documentation) PostgreSQL
pg_blocking_pids(): daftar sesi yang menghalangi sesi tertentu mendapatkan lock

L13 Arsitektur dan operasional server

Rute lewat gateway atau proxy Gateway / proxy hop

ID in-gateway · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)

Jika ada server perantara di antara klien dan server game, setiap kali paket melewatinya ada tambahan waktu pemrosesan, dan server itu menjadi single point of failure.

Mengapa Arsitektur klien ↔ gateway ↔ server game → Akibatnya Ada tambahan pemrosesan dan antrean di server perantara; saat kelebihan beban, semua pemain terdampak → Di layar Ping semua pemain naik; saat gateway mengalami gangguan, semua pemain yang melewatinya disconnect

Gejala: Input lag, Disconnect
Faktor: Latensi, Stall
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul, Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: rancang agar gateway bisa ditambah menjadi beberapa unit, dan agar karakter tetap berlanjut saat tersambung ulang ke gateway lain ketika satu gateway mati (penyambungan ulang sesi). Klien: reconnect otomatis saat koneksi ke gateway terputus.
Tugas Tim Infrastruktur: Scale out gateway secara horizontal (tambah unit), pantau CPU, jumlah koneksi, dan latensi pemrosesan per gateway.
Kisaran angka: Karena masih di dalam data center yang sama, biasanya kurang dari 1 ms setiap kali lewat. Jika gateway kelebihan beban, waktunya naik menjadi puluhan hingga ratusan ms.
Di grafik: Naik mengikuti beban · Latensi pemrosesan gateway, CPU dan jumlah koneksi gateway
Yang diperiksa: Periksa CPU dan jumlah koneksi gateway, Recv-Q socket gateway (ss, netstat), serta selisih latensi sebelum dan sesudah melewati gateway. Untuk pemanggilan HTTP atau gRPC yang lewat service mesh, bandingkan metrik standar Istio istio_request_duration_milliseconds yang dipisah antara sisi pengirim (reporter=source) dan sisi penerima (reporter=destination)
Cocok jika: Waktu pemrosesan server game tetap, tetapi hanya latensi di segmen gateway yang naik, dan pada saat itu CPU gateway jenuh atau Recv-Q menumpuk
Tidak cocok jika: Rute yang tidak lewat gateway (koneksi langsung, gateway lain) juga sama lambatnya: lebih mungkin koneksi atau server game
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Jika memakai service mesh (misalnya Istio), sidecar proxy (Envoy) yang menempel di samping setiap server juga menambah satu langkah. Permintaan antarlayanan melewati sidecar di sisi pengirim lalu sidecar di sisi penerima, dan makin banyak fitur yang ditambahkan ke proxy, seperti pengumpulan log dan metrik, makin panjang waktu pemrosesan dan waktu tunggunya.
Kasus nyata: Riot Games 2020: Host edge kelebihan beban di server League of Legends Eropa dan Brasil

7 sumber

The Unique Architecture behind Amazon Games’ Seamless MMO New World AWS
Di New World, klien terhubung ke salah satu dari 4 server pintu masuk (REP) yang memiliki alamat publik, lalu berkomunikasi dengan server simulasi (hub) di belakangnya
Designs, Lessons and Advice from Building Large Distributed Systems Google
Keynote LADIS 2009 (Jeff Dean). Round trip di dalam data center yang sama sekitar 0,5 ms
Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
Jika antrean memanjang akibat kelebihan beban, waktu tunggu naik menjadi beberapa kali waktu pemrosesan (pemrosesan 100 ms dan antrean 10 kali jumlah thread berarti 1,1 detik)
Performance and Scalability Istio
Dalam mode sidecar, permintaan melewati proxy sidecar di sisi pengirim lalu di sisi penerima; makin banyak fitur ditambahkan, makin panjang jalur pemrosesan di dalam proxy, dan pengumpulan telemetri menambah waktu tunggu permintaan berikutnya
What is Envoy Envoy
Envoy adalah proses terpisah yang berjalan di samping setiap server aplikasi, dan aplikasi berkomunikasi lewat Envoy di localhost
Istio Standard Metrics Istio
istio_request_duration_milliseconds (distribusi waktu pemrosesan permintaan HTTP dan gRPC); label reporter membedakan proxy sisi pengirim (source) dan sisi penerima (destination)
netstat(8) — Linux manual page net-tools
Recv-Q: jumlah byte di socket yang terhubung yang belum diambil oleh program pengguna

Pindah zona (handoff antarserver) Zone / server handoff

ID in-zone-transfer · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Saat masuk ke area atau dungeon lain, keterlambatan dan kegagalan bisa terjadi dalam proses memindahkan data karakter ke server lain.

Mengapa Server yang menangani karakter berganti saat masuk dungeon atau pindah benua → Akibatnya Simpan → kirim → muat; jika server tujuan padat atau tidak ada instance dungeon yang kosong, harus menunggu → Di layar Loading lama, gagal masuk, disconnect saat berpindah

Gejala: Tidak bisa masuk / loading tanpa henti, Freeze, Disconnect, Rubber banding
Faktor: Latensi, Stall
Siapa yang mengalami: Hanya saya, Lokasi/channel tertentu
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: Kurangi data yang dipindahkan, pesan server tujuan lebih dulu, kembalikan karakter ke posisi semula jika gagal.
Tugas Tim Infrastruktur: Pantau sisa instance kosong di server dungeon dan zona, siapkan jumlah server yang cukup sebelum jam sibuk.
Di grafik: Naik mengikuti beban · Waktu pindah zona dan jumlah kegagalan
Yang diperiksa: Periksa waktu per tahap pemindahan yang dicatat server (simpan, kirim, muat) dan alasan kegagalannya, serta jumlah pemain dan jumlah instance kosong di server tujuan
Cocok jika: Pada waktu laporan loading lama atau gagal masuk, waktu pemindahan naik atau kegagalan menumpuk, dan server tujuan padat atau instance kosongnya habis
Tidak cocok jika: Pemindahan selesai cepat, tetapi game berhenti setelah karakter tiba: lebih mungkin lonjakan spawn saat masuk area padat atau loading di klien
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Seamless world yang tersambung tanpa loading pun mengganti server yang menangani karakter saat karakter melewati batas server. Di dekat batas itu bisa terjadi tersendat sesaat atau rubber banding yang menarik karakter ke belakang.

1 sumber

The Unique Architecture behind Amazon Games’ Seamless MMO New World AWS
World tanpa loading dibagi menjadi grid yang ditangani beberapa server (hub), dan saat pemain bergerak state-nya dipindahkan dari hub ke hub; mode berbasis sesi mengambil server yang menganggur dari pool bersama

Kegagalan berantai Cascading failure

ID in-cascade · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)

Jika satu layanan melambat, server yang memanggilnya ikut tertahan menunggu respons, dan fitur yang tidak berhubungan pun ikut berhenti.

Mengapa Satu layanan, seperti DB atau autentikasi, melambat → Akibatnya Thread dan koneksi server pemanggil tertahan menunggu respons, dan retry dari permintaan yang gagal menambah beban → Di layar Fitur yang tampak tidak berhubungan pun ikut melambat atau berhenti

Gejala: Freeze, Input lag, Tidak bisa masuk / loading tanpa henti
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Pengembang Game: Pasang timeout di setiap pemanggilan, circuit breaker, isolasi per fitur (bulkhead), retry dengan interval yang makin panjang dan jumlah yang dibatasi, pisahkan respons health check dari pekerjaan yang berat.
Tugas Tim Infrastruktur: Beri kelonggaran pada jumlah kegagalan dan interval health check load balancer agar server yang lambat sesaat tidak langsung dikeluarkan, batasi jumlah server yang dikeluarkan sekaligus.
Di grafik: Mendatar di batas · Waktu respons dan tingkat error per layanan, jumlah thread dan koneksi yang terpakai
Yang diperiksa: Tampilkan waktu respons, tingkat error, dan jumlah retry per layanan dalam satu layar dengan sumbu waktu yang disamakan, lalu cari bagian yang paling dulu melambat. Jika di belakang load balancer, periksa waktu respons target (di AWS ALB: TargetResponseTime), jumlah 5xx dari target (HTTPCode_Target_5XX_Count), dan jumlah target yang dikeluarkan karena tidak sehat (UnHealthyHostCount)
Cocok jika: Latensi satu layanan naik lebih dulu, lalu jumlah thread dan koneksi yang terpakai di pihak pemanggil layanan itu menempel di batas, error merambat ke layanan lain, dan jumlah retry serta jumlah target yang dikeluarkan ikut naik
Tidak cocok jika: Beberapa layanan melambat bersamaan pada saat yang sama: periksa dulu gangguan pada sumber daya bersama (DB, jaringan, host)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Health check (pemeriksaan apakah server masih hidup) juga memperbesar efek berantai. Jika server yang sibuk terlambat menjawab pemeriksaan, load balancer mengeluarkan server yang sebenarnya normal, trafiknya membanjiri server yang tersisa, dan server berikutnya pun ikut terlambat.
Kasus nyata: Riot Games 2020: Host edge kelebihan beban di server League of Legends Eropa dan Brasil
Riot Games 2021: Gangguan 5 jam di League of Legends EUW: satu DB pendukung menghentikan seluruh server
Roblox 2021: Gangguan 73 jam di Roblox: perebutan sumber daya di cluster service discovery (Consul)
AWS 2021: Kongesti jaringan internal AWS us-east-1
AWS 2025: Gangguan DNS DynamoDB di AWS us-east-1 dan pemulihan yang lama

4 sumber

Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
Jika server yang kelebihan beban gagal health check dan dikeluarkan, beban menumpuk di server yang tersisa dan retry memperbesar beban; disarankan membatasi jumlah retry, exponential backoff acak, dan deadline
Circuit Breaker Pattern Microsoft Azure
Permintaan yang tertahan sampai timeout menahan thread dan koneksi DB sehingga fitur yang tidak berhubungan pun gagal; jika kegagalan menumpuk dalam waktu tertentu, pemanggilan langsung ditolak
Timeouts, retries, and backoff with jitter AWS
Amazon Builders' Library. Pada rantai pemanggilan 5 tingkat, jika setiap tingkat melakukan retry 3 kali, beban DB menjadi 243 kali lipat; lakukan retry di satu tempat saja dan batasi dengan token bucket
CloudWatch metrics for your Application Load Balancer AWS
TargetResponseTime (waktu sejak permintaan meninggalkan load balancer sampai target mulai merespons), HTTPCode_Target_5XX_Count (jumlah 5xx yang dihasilkan target), UnHealthyHostCount (jumlah target yang tidak sehat)

Gangguan server pendukung Auxiliary service outage

ID in-subservice · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika server yang berjalan terpisah dari server game, seperti server chat, party, atau balai lelang, mengalami gangguan, hanya fitur itu yang tidak berfungsi.

Mengapa Server khusus fitur melambat atau mati → Akibatnya Hanya permintaan untuk fitur itu yang tidak mendapat respons → Di layar Chat tidak jalan, undangan party tidak direspons, market loading tanpa henti (pertempuran tetap normal)

Gejala: Aksi hilang / rollback, Tidak bisa masuk / loading tanpa henti
Faktor: Stall, Packet loss
Siapa yang mengalami: Fitur tertentu saja
Kapan: Sesekali secara acak, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Rancang agar game tetap berjalan meskipun fitur itu gagal, tampilkan status per fitur, jangan memusatkan banyak fitur di satu server pusat.
Tugas Tim Infrastruktur: Pasang health check dan alert per server pendukung, siapkan redundansi dan restart otomatis.
Di grafik: Koneksi putus serentak · Tingkat keberhasilan permintaan per fitur, jumlah koneksi dan health check server pendukung
Yang diperiksa: Periksa health check, status proses, dan jumlah koneksi per server pendukung seperti chat, party, dan balai lelang, serta tingkat keberhasilan dan waktu respons permintaan per fitur. Jika di belakang load balancer, periksa UnHealthyHostCount pada target group
Cocok jika: Hanya server yang menangani fitur yang dilaporkan yang menunjukkan health check gagal atau koneksi anjlok, sedangkan tick dan pertempuran di server game normal
Tidak cocok jika: Banyak fitur berhenti bersamaan: lebih mungkin server pusat yang menjadi perantara fitur-fitur itu, atau kegagalan berantai
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Jika satu server pusat (server world atau server manager) menjadi perantara untuk party, guild, whisper, dan perpindahan antarserver sekaligus, banyak fitur berhenti bersamaan saat server itu saja melambat.

3 sumber

Bulkhead Pattern Microsoft Azure
Jika komponen diisolasi ke dalam pool masing-masing, saat satu komponen gagal sisanya tetap berjalan dan gangguan tidak merambat
REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies AWS
AWS Well-Architected. Rancang agar fungsi inti tetap berjalan dengan data yang agak lama atau data pengganti meskipun layanan yang diandalkan sedang mengalami gangguan
CloudWatch metrics for your Network Load Balancer AWS
UnHealthyHostCount: jumlah target yang dinilai tidak sehat oleh health check

Deploy dan restart Deploy / rolling restart

ID in-deploy · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika koneksi tidak dipindahkan saat server dimulai ulang untuk update, pemain di server itu disconnect, lalu penyimpanan data menjelang shutdown dan reconnect membanjir sekaligus.

Mengapa Server dimulai ulang satu per satu untuk deploy hotfix → Akibatnya Server dimatikan tanpa memindahkan koneksi ke server lain, penyimpanan data semua pemain di server itu membanjiri DB → Di layar Disconnect tanpa pengumuman, lonjakan reconnect

Gejala: Disconnect, Tidak bisa masuk / loading tanpa henti, Input lag
Faktor: Stall
Siapa yang mengalami: Seluruh server, Lokasi/channel tertentu
Kapan: Sesekali secara acak, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Sediakan fitur drain (blokir koneksi baru saja dan tunggu sampai pemain yang ada keluar), pindahkan karakter ke server lain, cicil penyimpanan sebelum shutdown, umumkan status siap setelah pemuatan cache dan JIT warm-up selesai sesudah restart, untuk hot reload baca data lebih dulu di thread terpisah lalu ganti sekaligus di antara tick.
Tugas Tim Infrastruktur: Buat tools deploy menunggu drain selesai per server sebelum restart, biarkan server yang baru dimulai ulang menerima trafik setelah status siap (pemanasan selesai) dipastikan, umumkan jadwal deploy.
Kisaran angka: Jika satu server menampung 5.000 pemain, 5.000 penyimpanan membanjiri DB dalam beberapa detik menjelang shutdown.
Di grafik: Koneksi putus serentak · Jumlah koneksi per server, jumlah penulisan DB
Yang diperiksa: Tumpangkan catatan kerja tools deploy (waktu restart per server) sebagai garis vertikal (anotasi) di grafik jumlah koneksi, jumlah disconnect, penulisan DB, dan permintaan login
Cocok jika: Jumlah koneksi per server anjlok satu per satu secara berurutan pada waktu restart, dengan penulisan DB melonjak tepat sebelumnya dan permintaan login melonjak tepat sesudahnya
Tidak cocok jika: Waktu putusnya koneksi tidak bertepatan dengan catatan deploy atau restart: lebih mungkin crash server atau perangkat jaringan
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Beberapa menit setelah dinyalakan ulang pun server masih lambat. Cache kosong sehingga query DB membanjir, dan server Java atau C# belum selesai mengoptimalkan kode selama berjalan (JIT warm-up), sehingga pekerjaan yang sama butuh waktu lebih lama. Cara membaca ulang script dan tabel data tanpa mematikan server (hot reload) juga membuat tick berhenti selama pembacaan sehingga terjadi jeda singkat.

3 sumber

Site Reliability Engineering, Chapter 20: Load Balancing in the Datacenter Google
Server yang menerima SIGTERM masuk status lame duck, mengalihkan permintaan baru ke server lain, dan hanya menyelesaikan permintaan yang sedang berjalan; beberapa menit setelah restart kode belum dioptimalkan JIT sehingga butuh lebih banyak sumber daya, jadi server baru menerima trafik setelah pemanasan
Liveness, Readiness, and Startup Probes Kubernetes
Readiness probe menahan trafik sampai pembuatan koneksi, pemuatan file, dan pemanasan cache selesai
Edit target group attributes for your Network Load Balancer AWS
Jika pendaftaran target dicabut, koneksi baru tidak lagi dikirim ke target itu dan koneksi yang ada dibiarkan selesai (drain, default 300 detik)

Keterlambatan autoscaling Autoscaling lag

ID in-autoscale · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Saat pemain membanjir, server ditambah secara otomatis, tetapi persiapannya butuh beberapa menit, dan selama itu server yang ada kelebihan beban.

Mengapa Koneksi melonjak saat event dimulai → Akibatnya Butuh beberapa menit sampai server baru menyala dan siap → Di layar Slow motion dan tidak bisa masuk selama beberapa menit tepat setelah event dimulai

Gejala: Slow motion, Tidak bisa masuk / loading tanpa henti
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Sebar pemain ke beberapa channel (pemain yang sudah ada di channel padat tidak bisa dipindahkan ke server baru), percepat waktu startup dan pemuatan data server baru.
Tugas Tim Infrastruktur: Lakukan scaling lebih dulu sebelum event, siapkan server cadangan yang sudah dipanaskan, saat mengurangi server matikan setelah pemain yang tersisa keluar.
Kisaran angka: Mendeteksi beban butuh 1 hingga beberapa menit (karena metrik dilihat sebagai rata-rata beberapa menit), lalu menyalakan server baru, membaca data game, dan mengisi cache butuh beberapa menit lagi.
Di grafik: Melonjak tepat setelah server dibuka · Jumlah instance, utilisasi CPU, antrean masuk
Yang diperiksa: Tumpangkan catatan aktivitas autoscaling (waktu keputusan scale out, waktu instance baru mulai melayani) di grafik utilisasi CPU dan jumlah koneksi. Di AWS, gunakan metrik grup Auto Scaling (baru terlihat jika diaktifkan) GroupDesiredCapacity (jumlah target), GroupPendingInstances (sedang disiapkan), dan GroupInServiceInstances (sedang melayani)
Cocok jika: Selama beberapa menit setelah koneksi melonjak, hanya jumlah target dan instance yang sedang disiapkan yang naik, sementara CPU server yang ada menempel di batas, lalu beban mereda sejak instance yang melayani bertambah
Tidak cocok jika: Masih lambat setelah instance baru masuk: lebih mungkin penyebab di luar jumlah server (sumber daya bersama seperti DB, kegagalan berantai)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Autoscaling umumnya dipakai di bagian yang cukup menerima pemain baru di server baru, seperti login, gateway, dan dungeon. Mengurangi server juga bisa menimbulkan masalah. Jika server dikurangi pada dini hari saat pemain sepi dan dimatikan tanpa menunggu pemain yang tersisa keluar, pemain itu disconnect.
Kasus nyata: AWS 2021: Kongesti jaringan internal AWS us-east-1
AWS 2025: Gangguan DNS DynamoDB di AWS us-east-1 dan pemulihan yang lama

4 sumber

Target tracking scaling policies for Amazon EC2 Auto Scaling AWS
Metrik dasar EC2 berinterval 5 menit (1 menit jika detailed monitoring diaktifkan), jadi untuk bereaksi cepat disarankan metrik berinterval 1 menit atau kurang
Amazon CloudWatch metrics for Amazon EC2 Auto Scaling AWS
Metrik grup baru dipublikasikan per 1 menit jika diaktifkan: GroupDesiredCapacity (jumlah yang ingin dipertahankan), GroupPendingInstances (jumlah instance yang belum melayani), GroupInServiceInstances (jumlah instance yang sedang melayani)
Scheduled scaling for Amazon EC2 Auto Scaling AWS
Menambah dan mengurangi kapasitas lebih dulu pada waktu yang ditentukan, sesuai perubahan beban yang bisa diprediksi
Decrease latency for applications with long boot times using warm pools AWS
Untuk aplikasi yang lama booting, keterlambatan scaling dikurangi dengan pool instance yang sudah diinisialisasi lebih dulu (warm pool)

Beban berlebih akibat log dan monitoring Logging / monitoring overhead

ID in-monitoring · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Saat terjadi gangguan, log melonjak, dan server yang mengirim log secara sinkron menjadi makin lambat karena log itu sendiri.

Mengapa Error terjadi, volume kirim log dan metrik melonjak → Akibatnya Pengumpul log tertinggal, dan server yang mengirim secara sinkron ikut menunggu → Di layar Saat gangguan, patah-patah dan freeze menjadi lebih parah karena log

Gejala: Patah-patah, Freeze
Faktor: Stall
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Kirim secara asinkron, lakukan sampling, buang log jika buffer penuh, kirim log error yang sama secara digabung.
Tugas Tim Infrastruktur: Siapkan kapasitas pengumpul log berdasarkan lonjakan volume saat gangguan, pasang alert untuk penumpukan di pengumpul.
Di grafik: Melonjak acak sesekali · Volume kirim log, antrean pengumpul log
Yang diperiksa: Periksa jumlah baris dan byte log per detik di server serta antrean dan jumlah log yang dibuang oleh agen pengumpul log, bersama waktu tick. Jika ada thread yang berhenti, periksa dengan bcc offcputime -p apakah thread itu menunggu di penulisan atau pengiriman log
Cocok jika: Saat tick melonjak, volume log melonjak menjadi puluhan kali lipat dari biasanya, dan waktu tunggu thread game terpusat pada call stack penulisan atau pengiriman log
Tidak cocok jika: Volume log sama seperti biasa, atau thread game tidak menunggu di bagian log: lonjakan log hanya akibat dari gangguan, jadi cari terpisah penyebab yang pertama kali memicu error
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Logging in C# Microsoft
Metode logging .NET bersifat sinkron, jadi jika storage lambat disarankan menulis dulu ke storage yang cepat lalu memindahkannya kemudian
Asynchronous loggers Apache Software Foundation
Logging asinkron menyerap lonjakan singkat dengan antrean, tetapi jika output terus lambat, antrean penuh dan kecepatannya turun ke kecepatan output yang paling lambat, atau log dibuang sesuai kebijakan (Discard)
Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
Menjumlahkan waktu thread berhenti dan meninggalkan CPU (off-CPU) per call stack, -p untuk menentukan proses

Selisih jam antarserver Clock skew between servers

ID in-clock-skew · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika jam di setiap server sedikit berbeda, keputusan cooldown, buff, dan waktu mulai event tidak sama antarserver.

Mengapa Jam server yang sinkronisasi waktunya berhenti selisih ratusan ms hingga beberapa detik dengan server lain → Akibatnya Jika waktu absolut, seperti waktu berakhirnya buff, dikirim antarserver, keputusannya meleset → Di layar Setelah berpindah, buff hilang atau cooldown mulai lagi dari awal

Gejala: Aksi hilang / rollback
Faktor: Latensi
Siapa yang mengalami: Hanya saya
Kapan: Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Untuk komunikasi antarserver, kirim sisa waktu sebagai pengganti waktu absolut.
Tugas Tim Infrastruktur: Pantau sinkronisasi waktu (NTP, chrony), pasang alert untuk selisih jam antarserver.
Kisaran angka: Jika sinkronisasi waktu (NTP, chrony) normal, selisih antarserver di data center yang sama biasanya hanya beberapa ms. Jika sinkronisasi berhenti, atau server virtual lama berhenti lalu berjalan lagi, selisihnya melebar menjadi ratusan ms hingga beberapa detik.
Di grafik: Naik perlahan · Offset jam per server
Yang diperiksa: Kumpulkan dan bandingkan System time (selisih jam sistem dengan jam NTP), Last offset, dan Ref time (waktu terakhir nilai ukur dari sumber waktu diterapkan) dari chronyc tracking di setiap server
Cocok jika: Offset server bermasalah selisih ratusan ms atau lebih dibandingkan server lain, atau Ref time-nya sudah lama berhenti, dan keputusan yang meleset hanya terjadi saat berpindah dari atau ke server itu
Tidak cocok jika: Offset semua server masih dalam beberapa ms: lebih mungkin perhitungan waktu di sisi game atau kesalahan sinkronisasi jam di klien
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Jam satu server yang melompat maju atau mundur sekaligus dibahas di “Lompatan jam sistem (NTP step)” pada lapisan OS server.

4 sumber

RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification IETF
Klien NTP di LAN yang cepat biasanya akurat hingga beberapa ratus µs
chrony – Frequently Asked Questions chrony
Drift jam komputer biasa umumnya kurang dari 100 ppm, tetapi pada virtual machine bisa lebih besar; virtual machine yang dijeda lalu dilanjutkan bisa mengalami jam yang meleset sehingga perlu koreksi step
clock_gettime(2) — Linux manual page Linux man-pages
CLOCK_REALTIME bisa melompat tidak kontinu akibat perubahan manual atau koreksi NTP, sedangkan CLOCK_MONOTONIC tidak terpengaruh lompatan seperti itu
chronyc(1) chrony
System time di chronyc tracking (selisih jam NTP dengan jam sistem), Last offset (offset yang diperkirakan saat koreksi terakhir), Ref time (waktu nilai ukur terakhir dari sumber waktu diterapkan)

Terlalu banyak macro dan bot Bots and macros

ID in-bots · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)

Bot mengirim permintaan jauh lebih sering daripada manusia sehingga menggerogoti throughput server.

Mengapa Banyak bot terhubung dan mengulang berburu, berpindah, dan trade tanpa henti → Akibatnya Throughput server dan beban DB naik → Di layar Area berburu tertentu atau seluruh server melambat (slow motion, input lag)

Gejala: Slow motion, Input lag
Faktor: Stall
Siapa yang mengalami: Seluruh server, Lokasi/channel tertentu
Kapan: Selalu, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Pengembang Game: Deteksi bot, batasi frekuensi permintaan per akun dan karakter.
Tugas Tim Infrastruktur: Batasi frekuensi koneksi dan permintaan per IP (beri kelonggaran untuk warnet dan jaringan seluler karena banyak orang memakai satu IP), blokir rentang IP bot dengan firewall atau WAF.
Di grafik: Hanya sebagian yang tinggi · Permintaan per detik per akun dan IP
Yang diperiksa: Periksa distribusi dan daftar teratas jumlah permintaan per detik per akun dan karakter dari log server game. Jika tidak ada metrik di kode, periksa jumlah permintaan per IP di firewall atau WAF
Cocok jika: Segelintir akun atau IP mengirim permintaan tanpa henti dengan frekuensi yang mustahil dicapai manusia, dan setelah dibatasi beban server turun dengan jelas
Tidak cocok jika: Permintaan tersebar merata di semua akun: lebih mungkin kenaikan jumlah pemain yang wajar (tick melewati budget, keterlambatan autoscaling)
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

Using rate-based rule statements in AWS WAF AWS
Menghitung jumlah permintaan per kriteria seperti IP, lalu membatasi kecepatan jika terlalu banyak dalam jendela waktu yang ditentukan
RFC 6269: Issues with IP Address Sharing IETF
Jika banyak pelanggan berbagi satu IP, pemblokiran atau pembatasan berbasis IP ikut menghalangi pengguna lain

Ketergantungan pada layanan eksternal External dependencies (auth, billing, platform)

ID in-external · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika layanan eksternal seperti login platform, pembayaran, atau verifikasi identitas lambat atau berhenti, proses tertahan di tahap itu.

Mengapa Gangguan atau keterlambatan di layanan autentikasi atau pembayaran eksternal → Akibatnya Tahap itu menunggu respons → Di layar Tidak bisa login, pembayaran gagal. Pemain yang sudah di dalam game baik-baik saja

Gejala: Tidak bisa masuk / loading tanpa henti, Aksi hilang / rollback
Faktor: Stall
Siapa yang mengalami: Seluruh server, Fitur tertentu saja
Kapan: Tepat setelah login atau maintenance, Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pasang timeout dan pesan yang ramah untuk pemanggilan eksternal, simpan hasil autentikasi di cache, siapkan prosedur retry dan kompensasi pembayaran.
Tugas Pihak Eksternal: Minta penyedia autentikasi, pembayaran, dan platform untuk memastikan gangguan dan memulihkannya, beri tahu pemain bahwa gangguan ada di layanan eksternal.
Di grafik: Naik seperti anak tangga · Waktu respons dan tingkat error pemanggilan eksternal, jumlah login berhasil
Yang diperiksa: Periksa waktu respons, tingkat error, dan jumlah timeout per pemanggilan eksternal seperti login platform, pembayaran, dan verifikasi identitas, serta halaman status penyedia
Cocok jika: Sejak kegagalan login atau pembayaran menumpuk, hanya error dan timeout pemanggilan eksternal tertentu yang naik satu tingkat lalu bertahan, dan halaman status penyedia mencatat gangguan pada waktu yang sama
Tidak cocok jika: Pemanggilan eksternal normal tetapi login tertahan: lebih mungkin server login itu sendiri (thread pool habis, DB) atau antrean koneksi (backlog) di sistem operasi
Sarana pemeriksaan: Log dan metrik server atau klien game
Kasus nyata: Fastly 2021: Error global pada CDN Fastly
AWS 2021: Kongesti jaringan internal AWS us-east-1
AWS 2025: Gangguan DNS DynamoDB di AWS us-east-1 dan pemulihan yang lama

3 sumber

Timeouts, retries, and backoff with jitter AWS
Amazon Builders' Library. Selama menunggu respons, sumber daya seperti thread dan koneksi tertahan, jadi pasang timeout, dan lakukan retry pada API yang punya efek samping hanya jika idempotensinya terjamin
Circuit Breaker Pattern Microsoft Azure
Pemanggilan yang kemungkinan besar gagal langsung ditolak tanpa menunggu timeout agar waktu respons tetap terjaga
REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies AWS
AWS Well-Architected. Pertahankan fungsi inti saat layanan yang diandalkan mengalami gangguan, meskipun dengan data yang agak lama (dasar untuk menyimpan hasil autentikasi di cache)

Kesalahan matchmaking dan penempatan region Wrong region assignment (matchmaking / GeoDNS)

ID in-region-match · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur), Pihak Eksternal (Pihak Eksternal)

Jika pemain ditempatkan di server region yang jauh padahal ada region yang dekat, ping pemain itu selalu tinggi walaupun koneksinya baik-baik saja.

Mengapa Data GeoIP salah, VPN, seluruh party ditempatkan berdasarkan rata-rata ping anggotanya, aturan yang memperluas pencarian ke region jauh saat pemain kurang, penempatan berdasarkan lokasi DNS resolver → Akibatnya Terhubung ke server region di seberang laut padahal ada region yang dekat → Di layar Di game yang punya server di beberapa region, hanya Anda (atau hanya party Anda) yang ping-nya selalu tinggi, disertai input lag, rubber banding, dan skill tidak keluar

Gejala: Input lag, Rubber banding, Aksi hilang / rollback
Faktor: Latensi
Siapa yang mengalami: Hanya saya, Wilayah/ISP tertentu
Kapan: Selalu, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur), Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Server: tempatkan pemain berdasarkan ping per region yang diukur klien sebagai pengganti GeoIP, pasang batas ping pada aturan perluasan ke region jauh, untuk party lihat juga ping anggota tertinggi selain rata-ratanya, catat region yang dipilih dan ping saat itu di log. Klien: ukur ping per region lewat UDP dan sertakan dalam permintaan matchmaking, tampilkan region yang tersambung dan ping-nya di layar, sediakan pilihan untuk memilih region sendiri.
Tugas Tim Infrastruktur: Jika region dipilih lewat DNS, pastikan DNS otoritatif mendukung EDNS Client Subnet (jika resolver yang dipakai pemain tidak mengirimkannya, penempatan mengikuti lokasi resolver), perbarui database GeoIP secara berkala, tambahkan negara dan ASN GeoIP ke log koneksi server per region untuk menemukan negara dan ISP yang diarahkan ke region jauh.
Tugas Pihak Eksternal: Imbau pemain untuk mematikan VPN atau game booster lalu terhubung kembali, imbau pemain yang memakai DNS kantor atau DNS luar negeri untuk beralih ke DNS ISP, minta penyedia GeoIP mengoreksi lokasi yang salah.
Kisaran angka: Jika pemain di Seoul ditempatkan di region US West padahal seharusnya di Tokyo, ping naik dari sekitar 30 ms menjadi sekitar 130 ms. GeoIP akurat sekitar 99,8% pada tingkat negara, tetapi pada tingkat kota, bahkan di Amerika Serikat, hanya sekitar 66% yang jatuh dalam radius 50 km, dan jika memakai VPN, yang terdeteksi adalah lokasi server VPN.
Di grafik: Hanya sebagian yang tinggi · RTT (ping) per pemain, distribusi region yang dipilih
Yang diperiksa: Tambahkan negara dan ASN GeoIP ke IP klien yang tercatat di log koneksi server per region (log akses load balancer, VPC Flow Logs), lalu hitung region yang dituju per negara dan ISP. Untuk satu pemain, bandingkan region yang benar-benar dituju pemain itu dengan ping ke region terdekat (diukur oleh pemain, atau dengan mtr dari server region itu ke IP pemain)
Cocok jika: Pemain atau negara dengan RTT tinggi terhubung ke region jauh padahal ada region dekat, dan ping yang diukur ke region dekat rendah
Tidak cocok jika: Sudah ditempatkan dengan benar di region dekat tetapi ping tetap tinggi: lebih mungkin routing memutar, atau koneksi atau Wi-Fi pemain itu
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Cara memilih region lewat DNS (DNS berbasis geolokasi atau latensi) menebak lokasi pemain dari alamat DNS resolver yang dipakainya. Jika resolver tidak mendukung EDNS Client Subnet, yang meneruskan sebagian alamat pemain, pemain yang memakai DNS kantor atau DNS yang jauh ditempatkan berdasarkan lokasi resolver. Sistem matchmaking juga bisa menilai party dari rata-rata ping anggotanya, atau memperlonggar batas ping saat antrean lama sehingga menempatkan party di region jauh. AWS GameLift Servers pun memakai rata-rata sebagai kriteria default ping party, dan mencontohkan pengaturan yang memperlebar batas ping dari 50 ms ke 100 ms lalu 200 ms. Pada pemain yang menyalakan VPN, latensi tambahan karena lewat server relay (“Rute lewat VPN atau game booster”) bisa bertumpuk dengan penempatan di region jauh, jadi bedakan keduanya dengan melihat apakah region yang dipilih berubah saat VPN dimatikan lalu pemain terhubung kembali. Kasus terhubung ke region jauh karena memang tidak ada region yang dekat dibahas di “Latensi propagasi (jarak fisik)”.

8 sumber

RFC 7871: Client Subnet in DNS Queries IETF
DNS yang menjawab berbeda menurut lokasi menebak lokasi dari alamat resolver yang mengirim query, dan jika pengguna memakai resolver pusat yang jauh dari dirinya, jawabannya tidak tepat. EDNS Client Subnet (fitur opsional) meneruskan sebagian alamat pengguna
How Amazon Route 53 uses EDNS0 to estimate the location of a user AWS
Jika resolver tidak mendukung edns-client-subnet, lokasi pengguna ditebak dari alamat resolver dan jawabannya mengikuti lokasi resolver (berlaku untuk routing berbasis geolokasi maupun latensi)
Geolocation accuracy MaxMind
Tingkat negara sekitar 99,8%, tingkat kota di AS (dalam 50 km) sekitar 66%; dengan VPN yang terlihat adalah lokasi server VPN; IP jaringan seluler dipakai di wilayah luas sehingga lokasi rinci tidak bisa diketahui; database harus terus diperbarui; koreksi bisa diminta
FlexMatch rule types AWS
Aturan latensi (maxLatency) melihat latensi pemain per lokasi, party secara default memakai rata-rata anggota (partyAggregation avg), dan queue bisa menempatkan game di region yang tidak memenuhi aturan latensi
Create a player latency policy AWS
Menempatkan game di lokasi dengan rata-rata latensi semua pemain paling rendah, tetapi pemain dengan latensi ekstrem pun ikut ditempatkan; contoh kebijakan yang memperlebar batas ping dari 50 ms ke 100 ms lalu 200 ms
Amazon GameLift Servers UDP ping beacons AWS
Klien game mengukur latensi ke endpoint UDP di setiap lokasi hosting dan memakainya untuk penempatan dan matchmaking; hasilnya lebih mendekati trafik game sebenarnya dibandingkan ping ICMP
Azure network round-trip latency statistics Microsoft Azure
Median round trip terukur dari Seoul (Korea Central): Tokyo (Japan East) 29 ms, US West 124–136 ms
Flow log records AWS
srcaddr pada record VPC Flow Logs: untuk trafik masuk, alamat IP pengirim

Sertifikat TLS kedaluwarsa atau salah konfigurasi TLS certificate expiry / misconfiguration

ID in-cert · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)

Jika sertifikat server login, API, atau patch kedaluwarsa atau sertifikat perantaranya tidak disertakan, koneksi TLS dari klien yang baru tersambung gagal sejak saat itu.

Mengapa Masa berlaku sertifikat sudah lewat, server mengirim tanpa sertifikat perantara, atau tanggal dan jam di perangkat pemain salah → Akibatnya Klien gagal memverifikasi sertifikat dan memutus koneksi TLS → Di layar Tidak bisa masuk atau loading tanpa henti di tahap login atau patch, atau hanya fitur HTTPS seperti toko yang gagal. Pemain yang sudah terhubung biasanya baik-baik saja

Gejala: Tidak bisa masuk / loading tanpa henti, Aksi hilang / rollback
Faktor: Stall
Siapa yang mengalami: Seluruh server, Fitur tertentu saja, Hanya saya
Kapan: Tepat setelah login atau maintenance, Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Catat error sertifikat dengan kode error yang dibedakan dari kegagalan koneksi lain dan tampilkan panduannya, jika masalahnya tanggal minta pemain menyetel tanggal dan jam perangkat secara otomatis, jika memakai certificate pinning sertakan kunci cadangan dan samakan jadwal penggantian sertifikat dengan Tim Infrastruktur.
Tugas Tim Infrastruktur: Jaringan: jika TLS diterminasi di load balancer atau CDN, pasang alert untuk status pembaruan otomatis dan sisa hari sertifikat terkelola (di ACM: DaysToExpiry), pertahankan record DNS untuk validasi. Server/OS: jika TLS diterminasi di server, otomatiskan pembaruan dan muat ulang konfigurasi setelah pembaruan, konfigurasikan chain yang menyertakan sertifikat perantara, periksa sisa masa berlaku setiap alamat login, API, dan patch secara berkala dari luar dan pasang alert.
Kisaran angka: Sertifikat Let’s Encrypt berlaku 90 hari dan disarankan diperbarui setiap 60 hari, sedangkan AWS Certificate Manager memeriksa sertifikat yang divalidasi lewat DNS 45 hari sebelum kedaluwarsa lalu memperbaruinya otomatis. Jika pembaruan otomatis gagal diam-diam, koneksi baru tertahan serentak tepat pada saat kedaluwarsa.
Di grafik: Koneksi putus serentak · Jumlah login berhasil, jumlah error TLS handshake
Yang diperiksa: Lihat daftar sertifikat yang benar-benar dikirim server dengan openssl s_client -connect HOST:443 -showcerts, lalu periksa tanggal kedaluwarsa (notAfter) tiap sertifikat dengan openssl x509 -noout -enddate. Jika TLS diterminasi di load balancer, periksa jumlah error negosiasi TLS (di AWS ALB dan NLB: ClientTLSNegotiationErrorCount) dan jumlah login berhasil
Cocok jika: Tanggal kedaluwarsa sudah lewat atau sertifikat perantara tidak ada di daftar yang dikirim server, dan waktu error mulai naik bertepatan dengan waktu kedaluwarsa atau waktu sertifikat diganti
Tidak cocok jika: Daftar sertifikat dan tanggal kedaluwarsa normal tetapi hanya sebagian pemain yang gagal: periksa tanggal dan jam perangkat pemain itu, atau daftar root certificate di OS lama
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Konfigurasi tanpa sertifikat perantara bisa terlihat normal saat dibuka di browser PC. Browser mengingat sertifikat perantara yang pernah diterima dari situs lain dan memakainya untuk mengisi kekosongan, tetapi klien yang tidak punya ingatan seperti itu, misalnya aplikasi Android, akan gagal. Masa berlaku juga makin pendek. Let’s Encrypt berencana memangkas masa berlaku default menjadi 64 hari pada 2027 dan 45 hari pada 2028, sehingga konfigurasi yang dipatok memperbarui setiap 60 hari hanya punya sisa empat hari untuk sertifikat 64 hari, dan sudah melewati masa kedaluwarsa untuk sertifikat 45 hari. AWS Certificate Manager juga tidak memperbarui otomatis sertifikat yang diimpor (import), dan pembaruan gagal jika record DNS untuk validasi dihapus. Gejala login tertahan mirip dengan “Gangguan dan latensi DNS”, tetapi masalah sertifikat gagal di TLS handshake setelah alamat server ditemukan, dan waktu mulainya bertepatan dengan waktu kedaluwarsa atau waktu sertifikat diganti.

12 sumber

RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile IETF
Masa berlaku sertifikat dari notBefore sampai notAfter; validasi jalur memeriksa apakah waktu saat ini masih dalam masa berlaku untuk setiap sertifikat di chain (gagal jika jam pihak yang memvalidasi salah)
FAQ Let's Encrypt
Masa berlaku default sertifikat 90 hari, disarankan diperbarui setiap 60 hari
Decreasing Certificate Lifetimes to 45 Days Let's Encrypt
Memangkas masa berlaku default menjadi 64 hari mulai Februari 2027 dan 45 hari mulai Februari 2028; pembaruan dengan interval tetap 60 hari tidak lagi cukup, jadi disarankan memperbarui pada sekitar dua pertiga masa berlaku
Renewal for domains validated by DNS AWS
45 hari sebelum kedaluwarsa, memeriksa apakah sertifikat dipakai di layanan AWS dan apakah record CNAME untuk validasi ada, lalu memperbaruinya otomatis; jika tidak bisa divalidasi, notifikasi dikirim 30, 15, 7, 3, dan 1 hari sebelum kedaluwarsa
Managed certificate renewal in AWS Certificate Manager AWS
Sertifikat yang diimpor (import) dan sertifikat yang sudah kedaluwarsa tidak diperbarui otomatis
Supported CloudWatch metrics AWS
DaysToExpiry: sisa hari sampai sertifikat kedaluwarsa, dipublikasikan dua kali sehari sampai kedaluwarsa
Security with network protocols Android (Google)
Jika server mengirim tanpa sertifikat perantara, aplikasi Android gagal dengan SSLHandshakeException, tetapi browser PC bisa tidak menampilkan error karena mengisinya dengan sertifikat perantara yang pernah diterima; periksa chain yang dikirim server dengan openssl s_client
Network security configuration Android (Google)
Jika memakai certificate pinning, kunci cadangan harus disertakan untuk berjaga-jaga saat kunci diganti atau CA berubah; jika tidak, koneksi terputus sampai aplikasi diperbarui
openssl-s_client OpenSSL
-showcerts: menampilkan daftar sertifikat yang dikirim server sesuai urutan pengirimannya (daftar ini belum tentu chain yang terverifikasi)
openssl-x509 OpenSSL
-enddate: menampilkan tanggal kedaluwarsa sertifikat (notAfter); -checkend: memeriksa apakah sertifikat kedaluwarsa dalam jumlah detik yang ditentukan
CloudWatch metrics for your Application Load Balancer AWS
ClientTLSNegotiationErrorCount: jumlah koneksi yang gagal membentuk sesi TLS, misalnya saat klien memutus koneksi karena gagal memverifikasi sertifikat server
CloudWatch metrics for your Network Load Balancer AWS
ClientTLSNegotiationErrorCount: jumlah TLS handshake yang gagal bernegosiasi antara klien dan TLS listener

Desain sinkronisasi

Feedback baru tampil setelah server merespons (model request-response) Request-response (no client-side feedback)

ID sy-request-response · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Saat tombol ditekan, tidak ada animasi maupun suara sampai jawaban server datang. Ping langsung menjadi kecepatan respons.

Mengapa Skill, gerakan, dan pengambilan item baru diputar setelah konfirmasi server datang → Akibatnya Sejak tombol ditekan, tidak ada respons apa pun selama waktu pulang-pergi + waktu tunggu tick → Di layar Dengan ping 150 ms, setiap aksi terasa lamban 0,2 detik

Gejala: Input lag
Faktor: Latensi
Siapa yang mengalami: Hanya saya
Kapan: Selalu, Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: mulai animasi, suara, dan efek begitu tombol ditekan (feedback sisi klien), tampilkan hanya hasilnya (damage, hadiah) setelah server mengonfirmasi, terapkan gerakan dan serangan dasar langsung dengan prediksi, dan saat menerima koreksi posisi dari server, terapkan ulang input yang belum dikonfirmasi mulai dari posisi itu. Server: hitung sendiri gerakan dari input yang diterima, kirim nilai koreksi hanya jika selisihnya dengan posisi prediksi klien melewati batas.
Kisaran angka: Waktu respons ≈ ping + setengah interval tick + satu frame. Pada server 20 tick dengan ping 150 ms, sekitar 190 ms.
Di grafik: Selalu tinggi sejak awal · Waktu dari input sampai animasi dimulai, RTT (ping)
Yang diperiksa: Catat waktu tombol ditekan, waktu animasi atau suara pertama dimulai, dan waktu respons server tiba di log klien pada build development, lalu bandingkan berdampingan dengan RTT di dalam game. Ukur sambil mengubah ping dengan menambahkan latensi lewat emulasi jaringan engine (Unreal NetEmulation.PktLag) atau tc netem Linux di server uji
Cocok jika: Animasi selalu dimulai tepat saat respons server tiba, waktu dari input sampai animasi sebesar RTT + waktu tunggu tick, dan bertambah persis sebesar latensi yang ditambahkan
Tidak cocok jika: Animasi dimulai begitu tombol ditekan dan hanya hasil seperti angka damage yang terlambat: desainnya normal. Tetap terlambat lebih dari satu interval tick walaupun ping rendah: lebih mungkin menunggu tick dua kali atau masalah frame di klien
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Untuk game yang tidak butuh respons cepat, seperti game turn-based, kartu, atau idle, cara ini paling sederhana dan aman. Masalah muncul saat game dengan kontrol real-time juga membuat gerakan atau serangan dasar dengan cara ini.

5 sumber

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
Klien yang hanya menunggu hasil dari server baru menampilkan setiap aksi 500 ms kemudian jika latensinya 500 ms. Diatasi dengan prediksi sisi klien dan rekonsiliasi server
Using Gameplay Abilities in Unreal Engine Epic Games
Local Predicted langsung dijalankan begitu tombol ditekan dan keputusan akhirnya di server, sedangkan Server Initiated tidak punya prediksi sehingga latensi terlihat oleh pemakainya
Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
Klien memprediksi dan menyimpan gerakan, server hanya mengoreksi jika selisihnya melewati batas toleransi (MAXPOSITIONERRORSQUARED), dan setelah koreksi gerakan yang disimpan diterapkan ulang
Using Network Emulation in Unreal Engine Epic Games
Pengujian dengan memasukkan latensi minimum dan maksimum serta rasio packet loss ke server dan klien; di konsol diatur seperti NetEmulation.PktLag
tc-netem(8) — Linux manual page iproute2
Tools pengujian yang meniru jaringan nyata dengan menambahkan latensi dan jitter (delay TIME JITTER) serta packet loss (loss random PERCENT) ke paket keluar

Protokol dengan banyak round trip berurutan (chatty) Chatty protocol / sequential round trips

ID sy-chatty · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika satu aksi butuh beberapa kali pulang-pergi ke server secara berurutan, ping dikalikan sebanyak jumlah itu.

Mengapa Buka toko → minta daftar → cek harga → beli → perbarui inventory, masing-masing diminta terpisah → Akibatnya Permintaan berikutnya baru dikirim setelah jawaban permintaan sebelumnya diterima → Di layar Dengan ping 150 ms, satu kali beli butuh hampir 1 detik. Loading terasa sangat lama

Gejala: Input lag, Tidak bisa masuk / loading tanpa henti
Faktor: Latensi
Siapa yang mengalami: Fitur tertentu saja, Hanya saya
Kapan: Saat melakukan aksi tertentu, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: ubah protokol agar beberapa tahap digabung dalam satu permintaan dan respons (misalnya, sertakan inventory yang sudah diperbarui di respons pembelian). Klien: ambil data yang dibutuhkan lebih dulu, buat UI yang tidak menunggu hasil.
Kisaran angka: Waktu yang dibutuhkan ≈ jumlah round trip × (ping + pemrosesan server + waktu tunggu tick). Untuk 5 kali dengan ping 150 ms, sekitar 0,85–1 detik.
Di grafik: Selalu tinggi sejak awal · Waktu selesai per fitur, jumlah round trip per aksi
Yang diperiksa: Dari packet capture di sisi server (Wireshark), hitung berapa kali permintaan dan respons bergantian dan berapa jeda di antaranya selama akun uji melakukan satu aksi, seperti membeli di toko atau login. Jika ada log permintaan server, kelompokkan berdasarkan ID sesi lalu periksa jumlah permintaan serta waktu tiba dan waktu respons setiap permintaan
Cocok jika: Dalam satu aksi, permintaan bolak-balik beberapa kali secara berurutan sambil menunggu respons sebelumnya, waktu selesai kira-kira jumlah round trip × RTT, dan makin tinggi ping wilayah pemain, makin lambat fitur yang sama secara proporsional
Tidak cocok jika: Round trip hanya satu atau dua kali tetapi satu respons lama: penyebabnya di pemrosesan server atau DB. Semua pemain sama lambatnya tanpa peduli ping: periksa beban server
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

1 sumber

Chatty I/O antipattern Microsoft Azure
Banyak permintaan I/O kecil membuat latensi kumulatif sangat menurunkan responsivitas. Disarankan menggabungkan permintaan menjadi lebih besar dan lebih sedikit

Tidak ada input buffering untuk skill No input/spell queue

ID sy-no-queue · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika skill berikutnya baru bisa ditekan setelah ada konfirmasi bahwa skill sebelumnya selesai di server, waktu pulang-pergi menyela setiap kombo.

Mengapa Input skill berikutnya hanya diterima “setelah skill sebelumnya dikonfirmasi” → Akibatnya Di antara setiap skill muncul waktu kosong sebesar ping → Di layar Ada celah di antara setiap kombo, dan makin tinggi ping makin rendah DPS

Gejala: Input lag, Aksi hilang / rollback
Faktor: Latensi
Siapa yang mengalami: Hanya saya, Fitur tertentu saja
Kapan: Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: sediakan batas waktu input buffering, yaitu input dalam waktu tertentu sebelum cooldown selesai (misalnya 0,3–0,4 detik) tetap diterima dan langsung dikirim ke server. Server: jangan tolak input yang tiba sedikit lebih awal, jalankan tepat saat cooldown selesai.
Kisaran angka: Pada kombo dengan cooldown 1 detik dan ping 150 ms, ada jeda kosong 0,15 detik atau lebih di antara setiap skill, sehingga jumlah skill yang dipakai dalam waktu yang sama berkurang lebih dari 13%.
Di grafik: Selalu tinggi sejak awal · Waktu kosong di antara skill, RTT (ping)
Yang diperiksa: Catat di log server, per karakter, waktu cooldown skill selesai, waktu permintaan skill berikutnya tiba, dan waktu skill dijalankan, lalu bandingkan waktu kosong di antaranya dengan RTT pemain
Cocok jika: Antara cooldown selesai dan skill berikutnya dijalankan selalu ada jeda sekitar RTT, makin tinggi ping pemain makin panjang jedanya, dan makin sedikit skill yang dipakai dalam waktu yang sama
Tidak cocok jika: Waktu kosong tetap tanpa peduli ping: lebih mungkin desain global cooldown atau panjang animasi. Waktu kosong hanya sesekali melonjak besar: periksa jitter, packet loss, atau tick melewati budget
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Misalnya, World of Warcraft punya batas waktu input buffering yang bisa diatur pemain di pengaturan. Jika batas waktu itu lebih panjang dari waktu pulang-pergi, ping hampir tidak menyela kombo.

1 sumber

Latency and Player Actions in Online Games (Communications of the ACM, 2006) ACM
Di EverQuest 2, makin besar latensi makin kecil damage yang diberikan karakter sehingga pertempuran makin lama (dari 0 ke 500 ms, pertempuran sekitar 2 menit bertambah 5 detik)

Timing window pendek yang termakan ping Timing window too short for latency + reaction

ID sy-short-window · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)

Jika waktu untuk bereaksi pendek, seperti pada dodge, parry, atau guard, ping memakan waktu itu sehingga muncul serangan yang mustahil dihindari.

Mengapa Timing window pendek, seperti telegraph serangan boss 0,5 detik atau parry window 0,2 detik → Akibatnya Telegraph terlihat terlambat (latensi dari server ke klien + interpolasi), dan input Anda juga tiba terlambat (latensi dari klien ke server + waktu tunggu tick) → Di layar Jelas sudah menghindar tetapi tetap kena, parry tidak terhitung

Gejala: Aksi hilang / rollback, Input lag
Faktor: Latensi
Siapa yang mengalami: Hanya saya, Fitur tertentu saja
Kapan: Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Server: jadwalkan telegraph serangan dengan waktu server lalu kirim lebih dulu, perpanjang timing window sebesar ping (lag compensation). Klien: putar telegraph yang diterima sesuai waktu server yang dijadwalkan.
Tugas Tim Infrastruktur: Tempatkan server dekat wilayah yang banyak pemainnya (server regional) untuk mengurangi ping itu sendiri.
Kisaran angka: Dengan ping 150 ms dan interpolasi 100 ms, telegraph butuh sekitar 0,18 detik untuk muncul di layar Anda, dan input Anda butuh sekitar 0,1 detik untuk sampai di server. Ditambah reaksi manusia 0,25 detik, telegraph 0,5 detik hampir mustahil dihindari.
Di grafik: Hanya sebagian yang tinggi · Tingkat gagal dodge dan parry (per rentang ping)
Yang diperiksa: Catat di log server waktu mulai dan akhir timing window, waktu input pemain tiba di server, dan RTT pemain itu, lalu lihat tingkat kegagalan per rentang ping (misalnya per 50 ms)
Cocok jika: Makin tinggi rentang ping, makin jelas tingkat kegagalannya naik, dan input yang gagal tiba sedikit setelah timing window berakhir (dalam batas RTT ditambah waktu interpolasi)
Tidak cocok jika: Tingkat kegagalan mirip di semua rentang ping: masalah tingkat kesulitan pola. Input tiba di dalam timing window tetapi tetap dianggap gagal: periksa kode penilaian atau validasi server
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015) Frontiers
Rata-rata waktu reaksi sederhana sekitar 231 ms (213 ms setelah dikoreksi latensi perangkat); studi skala besar terbaru menunjukkan 233–400 ms
Latency and Player Actions in Online Games (Communications of the ACM, 2006) ACM
Makin presisi dan makin pendek tenggat suatu aksi, makin sensitif terhadap latensi (batasnya sekitar 100 ms untuk sudut pandang orang pertama, sekitar 500 ms untuk orang ketiga, dan sekitar 1.000 ms untuk sudut pandang omnipresent)
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
Cara menjadwalkan event sesuai waktu server (ServerTime) agar semua klien memutarnya pada saat yang sama

Hit registration tanpa lag compensation Server-now hit validation

ID sy-no-lagcomp · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika server menilai serangan kena hanya dengan “posisi sekarang di server”, hasilnya tidak cocok dengan layar yang Anda lihat.

Mengapa Lawan di layar Anda ada di posisi sekitar 0,2 detik di masa lalu (dengan ping 150 ms dan interpolasi 100 ms) → Akibatnya Server menilai dengan posisi sekarang, jadi lawan sudah tidak ada di tempat yang Anda bidik → Di layar Jelas kena tetapi meleset. Harus menembak mendahului target yang bergerak

Gejala: Aksi hilang / rollback
Faktor: Latensi
Siapa yang mengalami: Hanya saya
Kapan: Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: putar mundur waktu ke momen yang dilihat penyerang saat menilai serangan (lag compensation), atau ganti ke sistem target lock. Klien: saat menyerang, kirim juga momen yang dilihatnya (waktu server yang sedang diinterpolasi).
Di grafik: Hanya sebagian yang tinggi · Akurasi terhadap target bergerak (per rentang ping)
Yang diperiksa: Catat di log keputusan server waktu serangan, posisi target di layar penyerang (nilai yang dikirim klien), posisi target di server yang dipakai untuk menilai, dan RTT penyerang. Di build development, jika posisi yang dipakai server digambar di atas layar klien, perbedaannya langsung terlihat
Cocok jika: Pada penilaian yang meleset, selisih kedua posisi kira-kira kecepatan target × (RTT penyerang + waktu interpolasi), dan makin tinggi ping, hanya akurasi terhadap target bergerak yang turun
Tidak cocok jika: Target yang diam pun meleset: masalah hitbox atau collision check. Sudah memakai rewind tetapi tetap meleset: periksa apakah klien salah memberi tahu waktu interpolasi ke server
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
Tanpa lag compensation, pemain harus menembak mendahului sebesar latensi. Lag compensation: server memutar mundur waktu sebesar latensi dan waktu interpolasi lalu menilai
Peeking into VALORANT's Netcode Riot Games
Server memutar mundur ke state game yang dilihat pemain saat menembak untuk menilai apakah kena; klien mengirim juga waktu simulasi yang sedang dilihatnya
Source SDK 2013: player_lagcompensation.cpp Valve
Waktu rewind di Source engine = latensi jaringan + waktu interpolasi

Lag compensation berlebihan Excessive lag compensation

ID sy-lagcomp-overreach · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika server memutar mundur waktu terlalu jauh demi penyerang, pihak yang diserang tetap kena walaupun sudah bersembunyi.

Mengapa Server memutar mundur waktu jauh demi penyerang yang ping-nya tinggi → Akibatnya Di layar pihak yang diserang, ia sudah berlindung → Di layar “Kena dari balik tembok”, pemain dengan ping tinggi diuntungkan

Gejala: Aksi hilang / rollback
Faktor: Latensi
Siapa yang mengalami: Hanya saya, Wilayah/ISP tertentu
Kapan: Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pasang batas rewind (misalnya 200–250 ms), untuk penyerang dengan ping lebih tinggi dari itu putar mundur hanya sampai batas dan biarkan sisanya ditutup dengan menembak mendahului sendiri.
Di grafik: Hanya sebagian yang tinggi · Waktu rewind per serangan yang kena (per ping penyerang)
Yang diperiksa: Catat di log keputusan server waktu rewind setiap serangan yang kena, RTT penyerang, dan waktu server saat pihak yang diserang masuk ke perlindungan. Di build development, gambar hitbox hasil rewind di layar (di Source engine: sv_showlagcompensation)
Cocok jika: Serangan kena dari laporan “kena dari balik tembok” terpusat pada penyerang dengan waktu rewind panjang, dan waktu rewind bertambah mengikuti ping penyerang tanpa batas
Tidak cocok jika: Kena dari balik tembok juga terjadi pada serangan dengan waktu rewind pendek: masalah hitbox atau collision check. Ping pihak yang diserang tinggi: gerakannya terlambat sampai di server
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Penilaian dengan rewind menganut prinsip “penembak didahulukan”. Ada juga usulan pengecualian “pihak yang diserang didahulukan”: jika pihak yang diserang sudah masuk ke tempat aman di layarnya sendiri, waktu tidak diputar mundur.

3 sumber

Peeking into VALORANT's Netcode Riot Games
Jika rewind tidak dibatasi, pemain dengan latensi 500 ms bisa mengenai lawan bahkan 0,5 detik setelah lawan berlindung, jadi diberi batas
A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022) ACM
Fenomena “kena dari balik sudut (shot around the corner)”, batas rewind di game FPS komersial, dan usulan teknik tanpa rewind jika pihak yang diserang sudah aman
Source SDK 2013: player_lagcompensation.cpp Valve
Batas rewind Source engine sv_maxunlag default 1 detik (maksimum 1 detik); sv_showlagcompensation menampilkan hitbox hasil rewind di layar

Otoritas klien Client-authoritative results

ID sy-client-auth · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika setiap klien memutuskan hasilnya sendiri, layar Anda terasa responsif, tetapi hasilnya tidak cocok dengan layar pemain lain dan rentan terhadap cheat.

Mengapa Klien menentukan posisi dan hit, server hanya meneruskan → Akibatnya Dua pemain sama-sama mengklaim mengenai lebih dulu, server tidak bisa memverifikasi → Di layar Lawan teleport atau menembus tembok, “saya sudah mengenai, tetapi tidak terhitung”

Gejala: Teleport, Aksi hilang / rollback
Faktor: Latensi
Siapa yang mengalami: Seluruh server
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: verifikasi sendiri hasil penting (seperti hit), periksa kecepatan dan jarak gerakan. Klien: jika menerima hasil yang ditolak atau dikoreksi server, kembalikan ke nilai itu.
Di grafik: Selalu tinggi sejak awal · Jumlah laporan kecepatan gerak mustahil dan laporan hit yang saling bertentangan
Yang diperiksa: Catat apa adanya di server posisi dan hit yang dilaporkan klien, hitung kecepatan gerak dari laporan posisi yang berurutan, lalu hitung laporan yang melewati kecepatan maksimum dan laporan dua pemain yang sama-sama mengklaim mengenai lebih dulu
Cocok jika: Server meneruskan laporan ke klien lain tanpa verifikasi, dan laporan kecepatan mustahil atau hit yang saling bertentangan muncul terus-menerus tanpa terkait patch atau wilayah
Tidak cocok jika: Server menghitung atau memverifikasi hasil sendiri: bukan penyebab ini. Teleport dalam kasus itu: periksa packet loss atau buffer interpolasi
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
Cara klien melaporkan hasil hanya mungkin jika klien bisa dipercaya. Karena khawatir cheat, dipakai server otoritatif
Peeking into VALORANT's Netcode Riot Games
Model otoritas server: server sama sekali tidak memercayai state game yang dilihat klien
Distributed authority topologies (Netcode for GameObjects 2.5) Unity
Jika otoritas dibagi ke klien, cheating menjadi mudah dan tidak ada lagi satu simulasi tunggal yang mengatur semua objek

Lockstep menunggu pemain paling lambat Lockstep waits for the slowest peer

ID sy-lockstep · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Dalam arsitektur tempat semua pemain menghitung giliran yang sama bersama-sama, jika input satu orang terlambat, semua orang menunggu.

Mengapa Setiap giliran baru bisa dihitung setelah input semua pemain terkumpul → Akibatnya Input satu orang tiba terlambat karena jitter atau packet loss → Di layar Semua orang tersendat sesaat bersamaan; jika parah, muncul jendela “Menunggu pemain”

Gejala: Freeze, Patah-patah, Input lag
Faktor: Jitter, Packet loss, Stall
Siapa yang mengalami: Lokasi/channel tertentu
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: atur input delay otomatis sesuai ping, keluarkan sementara hanya pemain yang terlambat agar pemain lain tetap berjalan tanpa menunggu. Klien: terapkan input delay yang ditentukan; jika P2P tanpa server relay, klien host juga menangani pengaturan input delay dan penanganan pemain yang terlambat.
Kisaran angka: Jika input delay diatur lebih pendek dari “waktu input sampai ke lawan + jitter”, game makin sering freeze. Waktu sampai itu kira-kira setengah ping jika saling kirim langsung, atau sekitar setengah dari jumlah ping kedua pemain jika lewat server relay.
Di grafik: Melonjak acak sesekali · Waktu tunggu giliran, latensi kedatangan input per pemain
Yang diperiksa: Catat untuk setiap giliran waktu kedatangan input per pemain dan lama giliran berhenti menunggu, lalu lihat input siapa yang ditunggu pada giliran yang berhenti. Jika ada server relay, interval kedatangan paket input per pemain juga bisa dilihat dari packet capture di sisi server
Cocok jika: Pada setiap giliran yang berhenti, input dari satu orang yang sama tiba lebih lambat dari input delay, dan pada saat itu jitter atau packet loss orang tersebut melonjak
Tidak cocok jika: Semua input tiba tepat waktu tetapi game tetap berhenti: masalah waktu komputasi PC paling lambat atau pemrosesan server. Tidak berhenti, tetapi hasil di dua layar berbeda: hasil komputasi menyimpang (desync), jadi periksa kemungkinan perhitungan jalur tidak sama pada sinkronisasi perintah
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Deterministic Lockstep Gaffer On Games
Frame n baru bisa dihitung setelah semua inputnya tiba, jadi jika ada yang terlambat game menunggu. Jika buffer playout delay yang menyerap jitter terlalu kecil, game tersendat sesaat
1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond Game Developer
Perintah dijadwalkan untuk dijalankan dua giliran kemudian, dan panjang giliran diatur sesuai komputer paling lambat dan ping (Speed Control)
A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022) ACM
Input delay (incoming delay) dibuat sebesar latensi “A→server + server→B” agar semua pemain menerapkannya pada saat yang sama

Prediksi rollback netcode meleset Rollback misprediction

ID sy-rollback · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Input lawan diprediksi dan ditampilkan lebih dulu; jika prediksinya salah, game diputar mundur lalu dihitung ulang. Makin tinggi ping, makin lebar rentang rewind.

Mengapa Lawan mengubah input (berbeda dari prediksi) → Akibatnya Input sebenarnya tiba terlambat sebesar setengah ping, jadi game diputar mundur sebesar itu lalu dihitung ulang → Di layar Gerakan lawan melompati beberapa frame atau tiba-tiba berubah

Gejala: Teleport
Faktor: Latensi, Jitter
Siapa yang mengalami: Hanya saya
Kapan: Saat melakukan aksi tertentu, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Campurkan input delay 1–3 frame untuk mempersempit rentang rewind, pasang batas rewind.
Kisaran angka: Dengan ping 100 ms (satu arah 50 ms), pada 60 fps sekitar 3 frame diputar mundur. Jika input delay 2 frame diterapkan, berkurang menjadi 1 frame.
Di grafik: Melonjak acak sesekali · Jumlah frame yang diputar mundur, RTT (ping)
Yang diperiksa: Catat di klien setiap rewind: jumlah frame yang diputar mundur, RTT saat itu, pengaturan input delay, dan waktu yang dipakai untuk rewind dan menghitung ulang
Cocok jika: Pada saat gerakan lawan dilaporkan melompat, jumlah frame yang diputar mundur besar, rata-rata rentang rewind kira-kira (latensi satu arah − input delay) ÷ waktu per frame, dan makin tinggi ping makin besar
Tidak cocok jika: Rentang rewind kecil tetapi tetap terjadi patah-patah: masalah performa, yaitu perhitungan ulang melebihi waktu satu frame. Hasil di dua layar tetap berbeda setelah rewind: hasil komputasi menyimpang (desync)
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

GGPO Rollback Networking SDK GGPO
Input lawan diprediksi dan game berjalan lebih dulu; jika input sebenarnya berbeda, game dihitung ulang dari titik penyimpangan sampai sekarang
8 Frames in 16ms: Rollback Networking in 'Mortal Kombat' and 'Injustice 2' GDC
Rollback menghilangkan input delay lokal pada lockstep, dan memutar mundur serta menghitung ulang hingga 8 frame dalam 16 ms

Event diputar begitu tiba tanpa timestamp Events played on arrival (no timestamps)

ID sy-no-timestamp · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika event dari server diputar begitu diterima tanpa diberi waktu kejadian, jitter jaringan langsung membuat timing animasi tidak beraturan.

Mengapa Event “mulai serang” atau “putar efek” dijalankan begitu tiba → Akibatnya Waktu tiba setiap paket berbeda sehingga intervalnya tidak beraturan → Di layar Gerakan serangan beruntun kadang cepat kadang lambat, timing pola boss berbeda setiap kali

Gejala: Patah-patah, Fast forward
Faktor: Jitter
Siapa yang mengalami: Hanya saya
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: putar event sesuai waktu yang menyertainya (event terjadwal, buffer interpolasi). Server: sertakan waktu kejadian (waktu server) saat mengirim event.
Di grafik: Melonjak acak sesekali · Interval pemutaran event, interval kedatangan paket
Yang diperiksa: Cocokkan waktu kejadian event di log server dengan waktu tiba dan waktu putar di log klien berdasarkan nomor event, lalu bandingkan intervalnya. Di build development, coba reproduksi dengan menambahkan jitter (nilai jitter di tc netem, latensi minimum dan maksimum di emulasi jaringan Unreal)
Cocok jika: Interval kejadian di server tetap, tetapi interval pemutaran persis mengikuti interval kedatangan yang tidak beraturan
Tidak cocok jika: Interval kedatangan rata tetapi pemutaran tidak beraturan: masalah frame di klien (lonjakan frame time). Interval kejadian di server sudah goyah sejak awal: tick melewati budget
Sarana pemeriksaan: Log dan metrik server atau klien game

5 sumber

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
Setiap update diberi waktu server, dan objek digambar di posisi pada waktu target, yaitu waktu sekarang dikurangi waktu interpolasi (100 ms)
Snapshot Interpolation Gaffer On Games
Jika snapshot yang diterima langsung digambar, gerakan tersendat karena jitter; jika dikumpulkan sebentar di buffer interpolasi lalu digambar, gerakan mulus
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
Contoh RPC yang membawa waktu pengiriman agar pihak penerima memutar efek sesuai waktu server
tc-netem(8) — Linux manual page iproute2
Tools pengujian yang meniru jaringan nyata dengan menambahkan latensi dan jitter (delay TIME JITTER) serta packet loss (loss random PERCENT) ke paket keluar
Using Network Emulation in Unreal Engine Epic Games
Pengujian dengan memasukkan latensi minimum dan maksimum serta rasio packet loss ke server dan klien; di konsol diatur seperti NetEmulation.PktLag

Menunggu tick dua kali Double tick quantization

ID sy-double-tick · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika permintaan dikumpulkan sampai tick berikutnya untuk diproses, lalu hasilnya juga dikirim pada tick sesudahnya, interval tick bertambah dua kali.

Mengapa Permintaan yang diterima diproses pada tick berikutnya → Akibatnya Hasil pemrosesan juga dikumpulkan dan dikirim pada tick pengiriman berikutnya → Di layar Ping koneksi rendah, tetapi respons selalu terlambat sekitar 1,5 kali interval tick. Pada server 10 tick, rata-rata 0,15 detik, terburuk 0,2 detik

Gejala: Input lag
Faktor: Latensi
Siapa yang mengalami: Seluruh server
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Kirim respons langsung pada tick yang memprosesnya, naikkan tick rate, kirim respons penting secepatnya.
Kisaran angka: Pada server 10 tick, satu tick 100 ms, jadi waktu tunggu tick saja menambah rata-rata 150 ms dan paling buruk 200 ms. Jika hanya menunggu sekali, rata-ratanya 50 ms.
Di grafik: Selalu tinggi sejak awal · Waktu dari permintaan tiba sampai respons dikirim
Yang diperiksa: Dari packet capture di sisi server, ukur jeda antara waktu paket permintaan tiba dan waktu paket responsnya keluar saat akun uji melakukan aksi yang sama berkali-kali (misalnya memakai item). Jika ada log server, periksa waktu permintaan tiba, nomor tick yang memprosesnya, dan waktu respons dikirim
Cocok jika: Waktu di dalam server rata-rata sekitar 1,5 kali interval tick, maksimum sekitar 2 kali, dan tetap tanpa terpengaruh RTT
Tidak cocok jika: Waktu di dalam server rata-rata sekitar setengah interval tick: menunggu tick hanya sekali. Lebih panjang dari interval tick dan tidak beraturan: periksa tick melewati budget
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Peeking into VALORANT's Netcode Riot Games
Input yang tiba menunggu paling lama satu tick sampai batas tick, lalu butuh satu frame lagi untuk diterapkan dan dikirim. Makin tinggi tick rate, makin kecil waktunya
VALORANT's 128-Tick Servers Riot Games
Sebagian latensi berasal dari jaringan, sebagian dari tick rate server
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
Perubahan NetworkVariable tidak langsung dikirim. Perubahan dikumpulkan lalu dikirim setiap network tick

Validasi server yang terlalu ketat Over-strict server validation

ID sy-strict-check · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika server memeriksa kecepatan gerak, cooldown, dan jangkauan terlalu ketat, input normal yang datang bertumpuk akibat jitter pun ikut ditolak.

Mengapa Kriteria ketat seperti “jarak yang boleh ditempuh dalam satu tick” atau “toleransi cooldown 0 ms” → Akibatnya Jika dua perintah tiba bertumpuk dalam satu tick akibat jitter, server menganggapnya melanggar aturan → Di layar Rubber banding, skill ditolak padahal cooldown sudah selesai

Gejala: Rubber banding, Aksi hilang / rollback
Faktor: Jitter
Siapa yang mengalami: Hanya saya
Kapan: Sesekali secara acak, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Periksa dengan cara kuota kumulatif (token bucket), beri kelonggaran sebesar ping dan jitter.
Di grafik: Melonjak acak sesekali · Jumlah penolakan validasi dan koreksi posisi oleh server
Yang diperiksa: Catat di log server alasan setiap penolakan validasi dan koreksi posisi, jumlah perintah pemain itu yang tiba pada tick tersebut, dan jeda kedatangan dari perintah sebelumnya
Cocok jika: Penolakan dan koreksi terpusat pada saat 2 perintah atau lebih tiba bertumpuk dalam satu tick, sedangkan jumlah gerakan dan pemakaian yang dijumlahkan per beberapa detik masih di dalam aturan
Tidak cocok jika: Dijumlahkan per beberapa detik pun tetap melanggar aturan: kemungkinan memang bergerak terlalu cepat atau cheat. Penolakan terpusat pada ISP tertentu dan malam hari: lebih mungkin false positive validasi yang terpusat pada pemain ISP tertentu
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

Source SDK 2013: player.cpp Valve
Perintah yang datang bertumpuk diizinkan dengan budget pemrosesan perintah yang terakumulasi setiap tick (maksimum sv_maxusrcmdprocessticks 24 tick). Ada komentar pengembang bahwa pembatasan yang lebih ketat membuat pemain normal pun mengalami patah-patah
RFC 2697: A Single Rate Three Color Marker IETF
Token bucket: dinilai dengan kecepatan rata-rata (CIR) dan ukuran burst yang diizinkan sekaligus (CBS)

Arsitektur host (pembuat room) Listen server / host advantage

ID sy-host · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)

Jika PC salah satu pemain berperan sebagai server, koneksi dan performa PC orang itu menentukan rasa bermain semua pemain.

Mengapa PC host berperan sebagai server (P2P, listen server) → Akibatnya Jika koneksi atau PC host lambat, dampaknya menyebar ke semua pemain, sementara ping host sendiri 0 → Di layar Hanya host yang diuntungkan; jika host keluar, semua pemain freeze atau disconnect

Gejala: Patah-patah, Freeze, Disconnect
Faktor: Latensi, Stall
Siapa yang mengalami: Lokasi/channel tertentu
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Server: beralih ke server dedicated yang menangani keputusan; sampai saat itu, pilih pemain dengan koneksi dan PC yang bagus sebagai host saat matchmaking. Klien: dukung perpindahan host (migration), ukur ping ke peserta lain, kecepatan upload, dan performa PC saat matchmaking lalu kirimkan hasilnya.
Tugas Tim Infrastruktur: Siapkan server fisik atau instance untuk server dedicated, tempatkan dekat wilayah yang banyak pemainnya.
Di grafik: Hanya sebagian yang tinggi · Jumlah laporan lag dan disconnect per host
Yang diperiksa: Catat di log match kecepatan upload host, RTT tiap peserta ke host, frame time PC host, dan waktu host keluar, lalu kelompokkan laporan lag dan disconnect per host. Pemain juga bisa memastikannya dengan bermain lagi bersama orang yang sama sambil hanya mengganti host
Cocok jika: Lag dan disconnect terpusat di room host tertentu, semua peserta memburuk bersamaan saat kecepatan upload host rendah atau frame time-nya panjang, dan tanpa perpindahan host semua pemain disconnect begitu host keluar
Tidak cocok jika: Hanya peserta dari wilayah yang sama yang buruk tanpa peduli siapa host-nya: masalah koneksi atau rute. Arsitekturnya server dedicated: bukan penyebab ini
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Networking Overview for Unreal Engine Epic Games
Host listen server lebih diuntungkan dibanding klien lain, dan bebannya besar karena menangani server sekaligus rendering
Distributed authority topologies (Netcode for GameObjects 2.5) Unity
Jika session owner keluar, owner baru dipilih otomatis dari klien yang tersisa
A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022) ACM
Game P2P pun bisa dipandang sebagai arsitektur client-server tempat host merangkap peran server

Server menolak setelah feedback sisi klien Client-side feedback rejected by server

ID sy-optimistic-reject · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika server kemudian tidak mengakui hit atau skill yang sudah lebih dulu ditampilkan di layar Anda, hasil yang jelas-jelas Anda lihat menjadi tidak pernah terjadi.

Mengapa Efek hit dan animasi skill diputar lebih dulu sebelum konfirmasi server (feedback sisi klien) → Akibatnya Server menimbang ulang jangkauan, posisi target, cooldown, dan resource, lalu menolak → Di layar Darah muncrat tetapi tidak ada damage, hanya animasi skill yang keluar tanpa efek, hanya cooldown yang berjalan

Gejala: Aksi hilang / rollback, Rubber banding
Faktor: Latensi
Siapa yang mengalami: Hanya saya, Fitur tertentu saja
Kapan: Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: tampilkan dari hasil server hanya bagian yang perlu dikonfirmasi, seperti angka damage, kematian, dan hadiah, periksa lebih dulu alasan penolakan yang umum, jika ditolak kembalikan cooldown dan resource lalu tampilkan alasannya. Server: beri kelonggaran sebesar ping pada pemeriksaan jangkauan dan posisi target, sertakan alasan di respons penolakan, kumpulkan rasio penolakan per skill sebagai metrik.
Kisaran angka: Respons penolakan datang terlambat sebesar ping + waktu tunggu tick setelah tombol ditekan. Dengan ping 150 ms, selama sekitar 0,2 detik pemain mengira serangannya kena.
Di grafik: Hanya sebagian yang tinggi · Rasio penolakan server per skill (per rentang ping)
Yang diperiksa: Kumpulkan di server rasio penolakan per skill dan alasannya (jangkauan, posisi target, cooldown, resource), lalu bagi per rentang RTT pemain. Di klien, catat jumlah aksi dengan feedback sisi klien yang ditolak
Cocok jika: Penolakan terpusat pada skill tertentu dengan alasan jangkauan atau posisi target, dan makin tinggi ping makin tinggi rasio penolakan
Tidak cocok jika: Alasan penolakan adalah cooldown atau resource dan tidak terkait ping: periksa apakah nilai data (cooldown, biaya) di klien dan server berbeda. Tidak ada penolakan, tetapi animasi baru dimulai setelah respons server: lebih mungkin feedback baru tampil setelah server merespons (model request-response)
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Feedback sisi klien adalah cara terbaik untuk menutupi ping. Namun, makin berbeda informasi yang dipakai klien dan server untuk memutuskan (posisi lawan, sisa resource), makin sering penolakan terjadi. Jika rasio penolakan per skill dikumpulkan sebagai metrik, tempat keputusan yang tidak cocok lebih mudah ditemukan.

2 sumber

Using Gameplay Abilities in Unreal Engine Epic Games
Ability Local Predicted langsung dijalankan di klien, tetapi keputusan akhirnya di server dan server bisa membatalkan hasilnya
Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
Tembakan senjata diprediksi di klien dan efeknya diputar lebih dulu, lalu kesalahan prediksi dikoreksi dengan hasil server

Perhitungan jalur tidak sama pada sinkronisasi perintah Command sync with divergent pathing

ID sy-path-mismatch · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika yang dipertukarkan hanya “pergi ke sini” dan jalurnya dihitung masing-masing oleh kedua pihak, perbedaan perhitungan sekecil apa pun membuat karakter atau monster berjalan lewat jalur lain lalu ditarik kembali ke posisinya.

Mengapa Pada click-to-move dan monster yang mengejar, hanya tujuan yang dikirim dan jalurnya dihitung terpisah oleh klien → Akibatnya Bergerak lewat jalur yang berbeda dari server karena perbedaan data terrain, tabrakan dengan karakter lain, atau perbedaan urutan perhitungan → Di layar Monster berjalan menembus tembok lalu tiba-tiba berpindah tempat, karakter yang diklik berbelok seperti meluncur

Gejala: Teleport, Rubber banding
Faktor: Latensi
Siapa yang mengalami: Lokasi/channel tertentu, Hanya saya
Kapan: Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: kirim juga titik-titik antara pada jalur (waypoint), samakan posisi secara berkala. Klien: konvergensikan penyimpangan secara halus, pakai data terrain yang sama dengan server.
Di grafik: Melonjak acak sesekali · Jumlah dan jarak koreksi posisi per objek
Yang diperiksa: Catat per objek selisih antara posisi yang dikirim server dan posisi yang dihitung klien, lalu tandai koordinat tempat koreksi terjadi di peta. Jika hasil jalur atau posisi di kedua pihak diringkas menjadi checksum dan dibandingkan secara berkala, waktu mulai penyimpangan bisa ditemukan
Cocok jika: Koreksi terpusat pada terrain tertentu (ambang, lorong sempit, lereng) atau tempat ramai, dan berulang di tempat yang sama bahkan pada pemain yang metrik jaringannya normal
Tidak cocok jika: Koreksi hanya terjadi saat packet loss atau jitter melonjak, tanpa terkait tempat: masalah koneksi. Satu monster melompat di layar banyak orang sekaligus: periksa apakah otoritas kontrol monster ada di klien yang lambat
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Cara inilah salah satu alasan game click-to-move dan tab-target tidak terlalu sensitif terhadap ping. Sebagai gantinya, tidak ada jaminan hasil di kedua pihak sama, jadi mekanisme yang sesekali menyamakan posisi wajib ada. Perhitungan floating point bisa sedikit berbeda hasilnya tergantung jenis CPU, compiler, dan pengaturan optimasinya (termasuk perbedaan build debug dan release). Pada arsitektur yang hanya bertukar input dan mengasumsikan hasil perhitungan di kedua pihak sama persis, seperti lockstep atau rollback, perbedaan kecil ini bisa menumpuk sampai state game di dua layar terbelah (desync).

6 sumber

Deterministic Lockstep Gaffer On Games
Meski deterministik di mesin yang sama, hasil floating point bisa berbeda jika compiler, OS, atau CPU berbeda
State Synchronization Gaffer On Games
Jika state dikirim bersama input, kedua pihak bisa disamakan tanpa determinisme yang sempurna
Peeking into VALORANT's Netcode Riot Games
Saat ada packet loss atau dua karakter mencoba menuju posisi yang sama, simulasi server dan klien menyimpang sehingga perlu koreksi
1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond Game Developer
Perbedaan yang sangat kecil membesar seiring waktu sehingga jalur worker sedikit demi sedikit menyimpang. World, objek, dan pathfinding dibandingkan dengan checksum untuk menemukan penyimpangan (out-of-sync)
Floating Point Determinism Gaffer On Games
Kode floating point yang sama pun bisa memberi hasil berbeda tergantung compiler, arsitektur CPU, serta build debug atau release. Ada kasus CPU AMD dan Intel memberi nilai yang sedikit berbeda pada fungsi transendental
/fp (Specify floating-point behavior) Microsoft
/fp:fast bisa mengubah urutan atau menggabungkan operasi floating point sehingga hasilnya berbeda dari pengaturan /fp lain, dan operasi yang digabung dengan FMA juga bisa berbeda dari hasil perkalian dan penjumlahan terpisah

Laju pengiriman snapshot rendah Low snapshot / update rate

ID sy-low-send-rate · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika server mengirim update posisi (snapshot) hanya beberapa kali per detik, buffer interpolasi harus dibuat lebih panjang sebanding, sehingga karakter lain terlihat di masa lalu yang lebih jauh.

Mengapa Untuk menghemat volume kirim, update posisi hanya dikirim 5–10 kali per detik → Akibatnya Agar gerakan tergambar mulus, buffer harus 2 kali interval paket (200–400 ms); jika lebih pendek, kehilangan satu paket saja sudah membuat gerakan terhenti → Di layar Perubahan arah lawan terlihat terlambat dan tidak cocok dengan keputusan server. Jika buffer pendek, gerakan patah-patah dan teleport saat terjadi packet loss

Gejala: Patah-patah, Teleport, Aksi hilang / rollback
Faktor: Latensi, Packet loss
Siapa yang mengalami: Seluruh server
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: kirim lebih sering untuk target yang dekat atau sedang bertarung dan lebih jarang untuk target yang jauh, kirim hanya bagian yang berubah (kompresi delta) agar ukuran per kirim kecil lalu naikkan frekuensinya. Klien: sesuaikan panjang buffer interpolasi otomatis dengan interval paket.
Kisaran angka: Pada 10 kali per detik, interval paket 100 ms dan buffer 200 ms. Ditambah latensi satu arah 75 ms dari ping 150 ms, lawan terlihat sekitar 0,3 detik di masa lalu.
Di grafik: Selalu tinggi sejak awal · Interval kedatangan paket per klien, panjang buffer interpolasi
Yang diperiksa: Dari packet capture di sisi server, saring hanya aliran ke satu pemain lalu periksa jumlah paket per detik dan interval antarpaket dengan I/O Graphs di Wireshark. Jika ada log di sisi game, periksa juga interval update per objek dan sisa buffer interpolasi klien (waktu tersisa sampai snapshot berikutnya datang)
Cocok jika: Update posisi selalu jarang, 5–10 kali per detik (interval 100–200 ms), dan buffer interpolasi diatur lebih dari 200 ms atau sisa buffer sering mencapai 0
Tidak cocok jika: Update dikirim rapat tetapi hanya interval kedatangannya yang goyah: lebih mungkin jitter atau packet loss. Hanya objek jauh yang jarang diterima saat ramai: lebih mungkin budget pengiriman dan prioritas per koneksi
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

4 sumber

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
Dengan update 10 kali per detik, interpolasi 200 ms tahan terhadap satu kali kehilangan. Default Half-Life 20 kali per detik dengan interpolasi 100 ms
Snapshot Interpolation Gaffer On Games
Pada 10 snapshot per detik, butuh latensi 350 ms agar tahan sampai dua kehilangan berturut-turut; pada 30 per detik cukup 150 ms
State Synchronization Gaffer On Games
Dengan akumulasi prioritas, objek penting dikirim lebih sering, dan sisanya dikirim bergiliran dalam batas bandwidth
8.8. The “I/O Graphs” Window Wireshark
Menggambar jumlah paket dan byte yang cocok dengan filter tampilan sebagai grafik per interval waktu

Masalah yang hanya dialami sebagian pemain

Pemain yang lag terlihat fast forward di layar pemain lain Laggy player seen by others (bursty inputs)

ID pt-slow-burst · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Input dari pemain yang koneksinya buruk tiba di server secara tidak beraturan dan bertumpuk. Jika server menerapkan input sebanyak yang diterima di setiap tick, pemain lain melihat karakter itu tersendat sesaat, lalu maju beberapa langkah sekaligus.

Mengapa Perintah gerak dari pemain yang lambat tiba dalam jumlah berubah-ubah: 0 di satu tick, 2–3 di tick lain → Akibatnya Server menerapkan semuanya sekaligus di tick saat perintah diterima, sehingga posisi karakter itu berubah seperti anak tangga → Di layar Di layar pemain lain, hanya karakter itu yang tersendat lalu bergerak sekaligus. Yang lain normal

Gejala: Fast forward, Teleport
Faktor: Jitter, Packet loss
Siapa yang mengalami: Hanya satu karakter yang terlihat aneh, Wilayah/ISP tertentu
Kapan: Selalu, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Terapkan perintah secara merata lewat buffer input per pemain, terapkan dengan interval aslinya berdasarkan nomor urut input, memperbesar buffer interpolasi di layar pemain lain saja tidak cukup (karena riwayat posisi di server sendiri sudah berbentuk anak tangga).
Tugas Pihak Eksternal: Imbau pemain yang lambat untuk memakai koneksi kabel (LAN) serta memeriksa Wi-Fi dan router.
Kisaran angka: Dengan jitter 80 ms, jumlah perintah per tick di server 20 tick (50 ms) berubah-ubah antara 0 dan 3.
Di grafik: Hanya sebagian yang tinggi · Jumlah perintah yang diterapkan per tick per pemain, jitter per pemain
Yang diperiksa: Di packet capture sisi server, saring hanya paket dari pemain yang dilaporkan, hitung berapa paket yang tiba di setiap interval tick (misalnya 50 ms), lalu bandingkan dengan pemain lain. Jika ada log server, periksa jumlah perintah gerak yang diterapkan per tick dan nomor urut input per pemain
Cocok jika: Hanya paket pemain yang dilaporkan yang tiba bertumpuk, berganti-ganti antara 0 dan 2–3 per tick, jitter dan packet loss pemain itu tinggi, sedangkan paket pemain lain tiba merata. Berkurang jika pemain itu beralih ke koneksi kabel
Tidak cocok jika: Banyak karakter mengalami fast forward bersamaan: lebih mungkin tick server terlambat atau koneksi di sisi pemain yang melihat. Kedatangan dan penerapan merata, tetapi hanya karakter itu yang terlihat melompat: masalah interpolasi atau tampilan di sisi pemain yang melihat
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Dalam struktur otoritas server, ini perilaku normal. Lag satu pemain yang lambat hanya terlihat oleh orang lain sebagai “pemain itu bergerak aneh”, dan tidak memengaruhi kontrol pemain lain maupun gerakan monster. Namun, interaksi langsung dengan pemain itu (trade, mekanik party, hit registration di PvP) ikut terlambat.

3 sumber

Peeking into VALORANT's Netcode Riot Games
Server memasukkan input yang tiba ke antrean gerak per pemain sesuai urutan tick, dan mengisinya dengan prediksi jika kosong. Koreksi hanya terlihat oleh pemain itu, sedangkan pemain lain melihat gerakan yang mulus
State Synchronization Gaffer On Games
Paket yang dikirim 60 kali per detik pun tiba bertumpuk, misalnya 2 paket di satu frame dan 0 di frame berikutnya
Source SDK 2013: player.cpp Valve
Perintah yang datang bertumpuk dibagi ke beberapa tick server untuk diproses (meter out)

Fast forward pada server yang memproses input begitu tiba Event-driven processing of bursty inputs

ID pt-event-server · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Pada server yang langsung memproses paket begitu tiba dan segera mengabarkan hasilnya, aksi pemain lambat yang datang bertumpuk langsung dijalankan berturut-turut.

Mengapa Permintaan skill dan gerak dari pemain yang lambat tiba bertumpuk → Akibatnya Server langsung menjalankannya sesuai urutan begitu diterima, lalu segera memberi tahu semua pemain → Di layar Di mata pemain lain, pemain itu memakai beberapa skill dalam sekejap atau bergerak seperti dipercepat

Gejala: Fast forward
Faktor: Jitter
Siapa yang mengalami: Hanya satu karakter yang terlihat aneh
Kapan: Saat melakukan aksi tertentu, Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: jalankan aksi sesuai interval waktu input yang tercantum pada aksi (waktu itu hanya diterima dalam batas toleransi), atau jangan tolak aksi yang datang bertumpuk dan jalankan satu per satu dengan jarak minimum (global cooldown), jangan memeriksa cooldown hanya dari waktu kedatangan (input normal jadi hilang). Klien: kirim aksi beserta waktu input-nya.
Di grafik: Hanya sebagian yang tinggi · Interval eksekusi aksi per pemain
Yang diperiksa: Catat di log server waktu tiba, waktu eksekusi, dan waktu input yang dicantumkan klien (jika ada) untuk setiap aksi per pemain, lalu bandingkan interval eksekusi dengan interval input. Periksa juga interval kedatangan paket pemain itu di packet capture sisi server
Cocok jika: Interval input normal, tetapi interval tiba dan eksekusi di server menumpuk dalam beberapa ms, dan waktu terjadinya penumpukan itu bertepatan dengan waktu laporan fast forward dari pemain lain
Tidak cocok jika: Interval waktu input sudah menumpuk sejak awal: lebih mungkin klien atau macro. Interval eksekusi di server merata, tetapi hanya terlihat menumpuk di layar pemain lain: koneksi pemain yang melihat
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
Server menghitung gerakan setiap kali menerima ServerMove dan menentukan selang waktu dari selisih timestamp dengan gerakan sebelumnya. Jika selisihnya dengan waktu server terlalu besar, gerakan itu dibuang
Deterministic Lockstep Gaffer On Games
Jika input diterapkan begitu tiba, intervalnya tidak merata meskipun dikirim pada 60 Hz, sehingga hasilnya tidak konsisten

Ukuran buffer input per pemain Per-player server input buffer (jitter buffer)

ID pt-input-buffer · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika server menampung sedikit input untuk setiap pemain lalu mengambilnya satu per tick, gerakan terlihat mulus di mata pemain lain, tetapi aksi pemain itu sendiri dikonfirmasi server lebih lambat sebesar itu.

Mengapa Server menampung input pemain yang lambat di buffer, lalu menerapkannya satu per tick → Akibatnya Buffer kecil sering kosong, sehingga karakter itu berhenti di tempat atau server menggerakkannya dengan menebak dari input terakhir. Buffer besar membuat input pemain itu sendiri lambat dikonfirmasi → Di layar Buffer kecil: tersendat sesaat di mata pemain lain. Buffer besar: hasil skill pemain itu sendiri keluar terlambat (input lag)

Gejala: Patah-patah, Input lag
Faktor: Jitter
Siapa yang mengalami: Hanya satu karakter yang terlihat aneh, Hanya saya
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: atur ukuran buffer secara otomatis sesuai kondisi koneksi tiap pemain, ambil dua input sekaligus untuk mengejar jika tertinggal, perintahkan klien pemain yang buffer-nya sering kosong untuk mengirim input lebih awal. Klien: kirim input sedikit lebih awal sesuai perintah server (penyesuaian waktu klien).
Kisaran angka: Berbeda di setiap game, tetapi umumnya sepanjang 1–3 tick. VALORANT, dengan server 128 tick, menjaga buffer server lebih pendek lagi, rata-rata setengah frame (sekitar 4 ms). Cara adaptif yang hanya memperbesar buffer untuk pemain dengan jitter besar cukup umum.
Di grafik: Hanya sebagian yang tinggi · Panjang buffer input dan jumlah buffer kosong per pemain
Yang diperiksa: Catat di server, per pemain dan per tick, jumlah input yang tersisa di buffer input, berapa kali buffer kosong lalu diisi tebakan dari input terakhir, dan waktu dari input tiba sampai diterapkan
Cocok jika: Pemain dengan buffer kecil sering mengalami buffer kosong, dan pada saat itu karakternya berhenti sebentar di layar pemain lain. Pada pemain dengan buffer besar, waktu dari input sampai diterapkan bertambah sebesar panjang buffer
Tidak cocok jika: Buffer hampir tidak pernah kosong, tetapi patah-patah terlihat di layar pemain lain: masalah interpolasi di sisi pemain yang melihat. Buffer pendek, tetapi input lag tetap besar: lebih mungkin RTT itu sendiri atau menunggu tick dua kali
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Peeking into VALORANT's Netcode Riot Games
Server menyesuaikan acuan waktu klien agar antrean input tetap sependek mungkin, tetapi cukup untuk meredam kedatangan yang tidak merata. Target buffering server rata-rata setengah frame
NetworkTimeSystem class (Netcode for GameObjects 2.5) Unity
LocalBufferSec: lama server menampung pesan klien di buffer. Waktu klien dimajukan agar pesan tiba lebih awal di server
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
Nilai buffer bisa diperbesar untuk pemain dengan koneksi buruk

False positive validasi yang terpusat pada pemain ISP tertentu Anti-cheat / movement validation false positives on bad ISPs

ID pt-isp-validation · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)

Input dari pemain yang koneksinya punya jitter besar tiba bertumpuk, sehingga sering terjaring pemeriksaan kecepatan dan cooldown di server.

Mengapa Jitter koneksi di ISP atau wilayah tertentu membesar pada malam hari → Akibatnya Server menganggap input normal yang tiba bertumpuk sebagai pelanggaran kecepatan atau cooldown → Di layar Hanya pemain dari ISP itu yang mengalami rubber banding dan skill ditolak. Dalam kasus parah, server mengeluarkan mereka sehingga terjadi disconnect

Gejala: Rubber banding, Aksi hilang / rollback, Disconnect
Faktor: Jitter
Siapa yang mengalami: Wilayah/ISP tertentu, Hanya saya
Kapan: Jam sibuk malam hari, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Pengembang Game: Lakukan pemeriksaan dengan kuota kumulatif selama beberapa detik, longgarkan kriteria dengan mempertimbangkan kondisi koneksi (ping, jitter), sisipkan tahap peringatan sebelum pemain dikeluarkan paksa, kurangi false positive dari akarnya dengan membagi input yang datang bertumpuk secara merata per tick lewat buffer input per pemain.
Tugas Tim Infrastruktur: Periksa sebaran packet loss dan jitter per ISP menurut jam lalu bagikan ke Tim Pengembang Game, periksa rute di jalur ISP tersebut (mtr dua arah), ubah rute atau lakukan eskalasi ke ISP jika perlu.
Di grafik: Tinggi hanya di jam tertentu · Jumlah penolakan validasi dan kick per ISP (ASN), jitter per ISP
Yang diperiksa: Tambahkan ISP (ASN) dari IP koneksi dan waktunya ke log penolakan validasi, koreksi, dan kick di server, lalu hitung per ISP dan per jam. Tim Infrastruktur menjalankan mtr dua arah ke ISP itu pada jam yang sama untuk memeriksa jitter dan packet loss
Cocok jika: Penolakan dan kick terpusat di ISP tertentu dan bertambah pada malam hari, jitter ISP itu ikut tinggi pada jam yang sama, dan total gerakan yang dijumlahkan per beberapa detik masih dalam aturan
Tidak cocok jika: Hanya akun tertentu yang berulang tanpa peduli ISP: kemungkinan memang cheat. Bertambah bersamaan di semua ISP: penyebab di sisi server berupa tick melewati budget (tick overrun), yang membuat tick tertunda dan perintah diterapkan bertumpuk
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Source SDK 2013: player.cpp Valve
Komentar pengembang: gerak terlalu cepat dicegah dengan budget perintah yang bertambah setiap tick, tetapi batasan yang lebih ketat membuat pemain normal pun mengalami patah-patah
RFC 2697: A Single Rate Three Color Marker IETF
Token bucket: penilaian berdasarkan laju rata-rata dan ukuran burst yang diizinkan
Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
Jika selisih timestamp klien dan server besar, gerakan dibuang atau ditangani dengan prosedur penyelesaian selisih waktu. Perhitungan memakai waktu server untuk mencegah speed hack

Satu anggota party yang lambat dan mekanik boss One laggy member in a synchronized mechanic

ID pt-raid-member · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Pada mekanik raid yang menuntut semua pemain bereaksi bersamaan di saat yang ditentukan, reaksi terlambat dari satu pemain yang lambat membuat seluruh party gagal.

Mengapa Mekanik bersama seperti “semua menyebar bersamaan” atau “satu orang menekan tombol” → Akibatnya Pemain yang lambat melihat telegraph terlambat, dan input-nya juga tiba terlambat → Di layar Seluruh party tewas (wipe) gara-gara satu orang itu, dan anggota party lain merasa “ini gara-gara orang yang lag”

Gejala: Aksi hilang / rollback, Input lag
Faktor: Latensi
Siapa yang mengalami: Lokasi/channel tertentu, Hanya satu karakter yang terlihat aneh
Kapan: Saat banyak pemain berkumpul, Saat melakukan aksi tertentu
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: beri kelonggaran timing window mekanik sebesar ping, kirim telegraph lebih dulu dengan waktu server, desain agar kegagalan satu orang tidak berujung wipe. Klien: putar telegraph yang diterima sesuai waktu server.
Di grafik: Hanya sebagian yang tinggi · RTT per pemain yang memicu kegagalan mekanik
Yang diperiksa: Catat di log mekanik server pemain yang memicu kegagalan, waktu tiba input-nya, timing window, serta RTT dan packet loss pemain itu
Cocok jika: Sebagian besar input yang memicu wipe berasal dari satu orang yang sama, RTT orang itu jelas lebih tinggi dari rata-rata party, dan input-nya tiba sesaat setelah timing window berakhir
Tidak cocok jika: Kegagalan terbagi merata di antara anggota party: lebih mungkin timing window pendek yang termakan ping. Input pemain yang lambat tiba di dalam timing window, tetapi tetap gagal: kode penilaian di server
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
Cara menjadwalkan event sesuai waktu server agar semua pemain memutarnya di saat yang sama
Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015) Frontiers
Rata-rata waktu reaksi sederhana sekitar 231 ms

Otoritas kontrol monster ada di klien yang lambat Monster movement delegated to a player client

ID pt-mob-control · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Ada game yang menyerahkan perhitungan gerakan monster ke klien salah satu pemain di dekatnya untuk mengurangi beban server. Jika koneksi pemain itu buruk, monster itu bergerak aneh di layar semua pemain.

Mengapa Server menyerahkan perhitungan gerakan monster ke klien pemain yang paling dekat (atau yang datang lebih dulu) → Akibatnya Laporan hasil dari pemain yang memegangnya tiba di server terlambat atau bertumpuk → Di layar Hanya monster itu yang tersendat lalu teleport di layar semua pemain di sekitarnya. Di layar pemain yang memegangnya, monster itu normal

Gejala: Teleport, Patah-patah, Fast forward
Faktor: Jitter, Packet loss
Siapa yang mengalami: Hanya satu karakter yang terlihat aneh, Lokasi/channel tertentu
Kapan: Selalu, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Alihkan otoritas kontrol ke pemain dengan koneksi baik (berdasarkan ping dan packet loss), biarkan server segera mengambilnya kembali jika laporan terhenti, hitung langsung di server untuk monster penting seperti boss.
Di grafik: Hanya sebagian yang tinggi · Interval laporan posisi per monster (per klien yang memegang otoritas kontrol)
Yang diperiksa: Catat di server, untuk setiap monster, klien yang memegang otoritas kontrol beserta interval laporan, RTT, dan packet loss klien itu. Interval kedatangan paket dari klien itu juga bisa diperiksa di packet capture sisi server
Cocok jika: Otoritas kontrol semua monster yang bergerak aneh dipegang satu orang yang sama, interval laporannya tidak beraturan atau terputus, dan langsung normal begitu otoritas dialihkan ke orang lain
Tidak cocok jika: Monster yang dihitung langsung oleh server juga melompat dengan cara yang sama: lebih mungkin tick server terlambat atau koneksi di sisi pemain yang melihat. Tetap melompat walaupun otoritas sudah dialihkan: lebih mungkin perhitungan jalur tidak sama pada sinkronisasi perintah
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Pemain yang memegang kontrol merasa semuanya normal, sehingga laporan yang masuk hanya berbunyi “monsternya aneh”. Jika semua pemain kecuali satu orang melihat monster yang sama bergerak aneh, periksa dulu siapa yang memegang otoritas kontrol monster itu.

2 sumber

Authority (Netcode for GameObjects 2.5) Unity
Pada model otoritas terdistribusi, setiap instance game (klien) memegang otoritas atas sebagian objek jaringan dan menghitung objek itu
Distributed authority topologies (Netcode for GameObjects 2.5) Unity
Jika otoritas dibagi ke klien, tidak ada satu simulasi tunggal dan game rentan terhadap cheating

Data karakter tertentu terlalu besar One character with oversized data (inventory, mail, buffs)

ID pt-heavy-char · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)

Karakter yang menumpuk ribuan item atau mail, atau punya daftar teman, daftar blokir, dan buff yang sangat banyak, harus memuat, menyimpan, dan mengabarkan ke sekitarnya data yang berkali-kali lipat lebih besar dari karakter lain. Lambatnya hanya terjadi pada karakter itu, tanpa peduli koneksinya.

Mengapa Pada karakter yang sudah lama dimainkan, atau akibat hadiah event, ribuan item menumpuk di inventory dan mailbox → Akibatnya Setiap kali login, pindah area, atau menyimpan, data sebanyak itu dibaca dari dan ditulis ke DB, dan data equipment serta buff yang dikirim ke pemain di sekitar juga besar → Di layar Hanya karakter itu yang loading masuknya lama dan tersendat sesaat saat membuka inventory atau mail. Pada server yang menunggu penyimpanan di thread game, pemain di sekitarnya pun ikut terhenti sebentar

Gejala: Tidak bisa masuk / loading tanpa henti, Input lag, Freeze
Faktor: Stall
Siapa yang mengalami: Hanya saya, Fitur tertentu saja
Kapan: Tepat setelah login atau maintenance, Saat melakukan aksi tertentu, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game: Tetapkan batas penyimpanan inventory dan mail serta pembersihan otomatis mail lama, muat hanya bagian yang dibutuhkan secara bertahap, simpan hanya bagian yang berubah di luar thread game.
Tugas Tim Infrastruktur: Cari query baca lambat yang berulang untuk karakter yang sama di slow query log lalu teruskan ke Tim Pengembang Game, sediakan daftar teratas karakter dengan jumlah baris item dan mail terbanyak.
Kisaran angka: Jika satu item adalah satu baris di DB, karakter dengan 5.000 item membaca 5.000 baris setiap kali login. Itu puluhan kali lipat karakter biasa.
Di grafik: Hanya sebagian yang tinggi · Waktu login dan penyimpanan per karakter, jumlah baris yang dibaca dari DB per karakter
Yang diperiksa: Cari pembacaan dan penyimpanan lambat yang berulang dengan ID karakter yang sama di slow query log DB (MySQL slow query log, PostgreSQL log_min_duration_statement), lalu ambil daftar teratas jumlah baris per karakter di tabel item dan mail
Cocok jika: Query lambat terpusat pada beberapa ID karakter, jumlah baris item dan mail karakter itu puluhan kali rata-rata, dan tetap lambat walaupun login dari PC atau koneksi lain
Tidak cocok jika: Karakter lain di akun yang sama atau pemain lain ikut lambat: lebih mungkin server DB atau lock. Karakter itu normal di PC lain: lingkungan pemain
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Jika karakter yang sama tetap lambat walaupun login dari PC atau koneksi lain, sementara karakter lain di akun yang sama normal, curigai data karakternya. Karena itulah nama karakter wajib dicantumkan dalam laporan.

3 sumber

Extraneous Fetching antipattern Microsoft Azure
Mengambil data lebih dari yang dibutuhkan menambah beban I/O dan memperlambat respons
PostgreSQL Documentation: Error Reporting and Logging PostgreSQL
log_min_duration_statement: mencatat SQL yang berjalan melebihi durasi tertentu untuk melacak query lambat
The Slow Query Log MySQL
Slow query log yang mencatat query yang melewati long_query_time

Perbedaan channel, instance, atau phasing Different channel / instance / phase

ID pt-phase · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika dua karakter berada di channel atau instance yang berbeda, atau di “phasing” berbeda yang menentukan NPC yang terlihat sesuai progres quest, keduanya melihat dunia yang berbeda.

Mengapa Karakter kedua ditempatkan di channel lain, atau tahap quest-nya berbeda → Akibatnya Server tidak mengirim NPC tersebut ke karakter itu (normal) → Di layar NPC tidak ada hanya di salah satu sisi. Terlihat seperti bug, tetapi memang sesuai desain

Gejala: Tidak terlihat / objek hantu
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama, Hanya saya
Kapan: Selalu, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: kirim informasi channel dan phasing ke klien, tambahkan “periksa channel dan tahap quest kedua karakter” ke checklist QA. Klien: tampilkan channel dan phasing di layar.
Di grafik: Hanya sebagian yang tinggi · Jumlah objek di sekitar per klien, channel dan phasing
Yang diperiksa: Bandingkan nomor channel dan tahap progres quest terkait pada kedua karakter di layar game, lalu samakan channel dan tahapnya dan lihat lagi. Jika ada log pengiriman objek di server, periksa alasan NPC itu tidak dikirim ke karakter tersebut (channel atau phasing)
Cocok jika: Channel atau tahap quest kedua karakter berbeda, dan NPC terlihat setelah disamakan
Tidak cocok jika: Channel dan tahapnya sama, tetapi NPC tetap tidak ada di salah satu sisi: lebih mungkin pesan spawn yang tiba saat loading dibuang, data spawn hilang saat membanjir tepat setelah masuk zona, atau urutan pendaftaran jarak pandang kacau
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Periksa juga apakah progres quest disimpan per akun atau per karakter. Pada dua karakter di akun yang sama, progres salah satunya bisa mengubah phasing karakter yang lain.

2 sumber

Actor Relevancy in Unreal Engine Epic Games
Server hanya mereplikasi actor yang relevan untuk setiap koneksi, dan tidak mengirim actor yang tidak relevan
Object visibility (Netcode for GameObjects 2.5) Unity
CheckObjectVisibility menentukan objek yang terlihat untuk setiap klien, dan objek yang disembunyikan tidak dikirim ke klien itu

Pesan spawn yang tiba saat loading dibuang Spawn messages dropped before the client is ready

ID pt-loading-drop · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Begitu karakter masuk zona, server mengirim pesan spawn NPC di sekitarnya, tetapi klien masih memuat map sehingga pesan itu dibuang.

Mengapa Server mengirim pesan spawn objek di sekitar tepat setelah proses masuk selesai → Akibatnya Klien masih loading dan belum punya message handler, sehingga pesan itu dibuang → Di layar Server menganggap pesan sudah terkirim dan tidak mengirim ulang. NPC tidak terlihat sampai karakter keluar dari jarak pandang lalu kembali

Gejala: Tidak terlihat / objek hantu
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama, Hanya saya
Kapan: Tepat setelah login atau maintenance, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: kirim “siap” setelah loading selesai, atau simpan paket yang diterima selama loading lalu proses belakangan. Server: kirim informasi sekitar setelah menerima “siap”.
Kisaran angka: Jika dua klien di PC yang sama loading bersamaan, atau klien yang sedang loading berada di jendela latar belakang, CPU dan disk dipakai bersama dan pemrosesannya juga dibatasi, sehingga loading klien itu bisa beberapa kali lebih lama. Bug yang sama juga muncul jika proses masuk di server menjadi lebih cepat.
Di grafik: Hanya sebagian yang tinggi · Waktu loading per klien, jumlah pesan yang dibuang selama loading
Yang diperiksa: Bandingkan jumlah dan jenis pesan yang diterima lalu dibuang klien selama loading serta waktu loading selesai dengan waktu server mengirim pesan spawn. Gejala mudah direproduksi dengan menjalankan loading dua klien bersamaan di PC yang sama, atau membiarkan klien yang sedang loading di jendela latar belakang
Cocok jika: Server sudah mengirim pesan spawn NPC yang tidak terlihat, pesan itu tiba sebelum loading selesai, dan jumlah pesan yang dibuang pada saat itu bertambah. Hanya terjadi di klien yang loading-nya lebih lama
Tidak cocok jika: Pesan spawn tiba setelah loading selesai, tetapi NPC tetap tidak terlihat: lebih mungkin snapshot baseline hilang atau kekeliruan akibat ID objek dipakai ulang. Server sama sekali tidak mengirim pesan untuk NPC itu: lebih mungkin urutan pendaftaran jarak pandang kacau atau perbedaan channel atau phasing
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

NetworkConfig class (Netcode for GameObjects 2.5) Unity
SpawnTimeout: pesan untuk objek yang belum dibuat ditahan dulu, lalu dibuang jika objek itu tidak juga dibuat dalam batas waktu
Actor Relevancy in Unreal Engine Epic Games
Actor yang tidak lagi relevan dihapus di klien, lalu direplikasi ulang dari awal saat kembali relevan

Urutan pendaftaran jarak pandang kacau Interest-management race on enter/leave

ID pt-aoi-race · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Jika saat karakter didaftarkan ke grid jarak pandang bertepatan dengan saat NPC berpindah sel grid, pesan spawn NPC itu bisa terlewat.

Mengapa Proses masuk, pindah channel, atau teleportasi karakter bertepatan dengan gerakan NPC → Akibatnya NPC itu terlewat dari perhitungan “objek yang baru terlihat” → Di layar Hanya beberapa NPC tertentu yang tidak terlihat, atau NPC yang sudah pergi masih tertinggal

Gejala: Tidak terlihat / objek hantu
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama, Hanya saya
Kapan: Saat bergerak atau pindah area, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Proses update jarak pandang di satu thread dengan satu urutan, sinkronkan ulang seluruh “daftar objek terlihat” secara berkala.
Di grafik: Melonjak acak sesekali · Jumlah selisih antara daftar objek terlihat di server dan daftar objek di klien
Yang diperiksa: Catat di server pendaftaran ke grid jarak pandang, perpindahan sel objek, dan pengiriman pesan spawn/despawn beserta nomor tick-nya, lalu bandingkan secara berkala “daftar objek terlihat” di server dengan daftar yang dimiliki klien
Cocok jika: NPC yang terlewat berpindah sel di tick yang sama dengan proses masuk atau teleportasi karakter itu, dan tidak ada catatan pengiriman pesan spawn untuk NPC itu
Tidak cocok jika: Pesan spawn sudah dikirim, tetapi klien tidak menerimanya atau membuangnya: masalah pengiriman (data spawn hilang saat membanjir tepat setelah masuk zona, pesan spawn yang tiba saat loading dibuang). Selalu NPC yang sama yang terlewat: lebih mungkin perbedaan phasing atau opsi tampilan
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

Replication Graph in Unreal Engine Epic Games
MMORPG dan game sejenis membagi dunia game menjadi grid, menyimpan daftar actor per sel, dan mengirim data berdasarkan sel tempat klien berada
Actor Relevancy in Unreal Engine Epic Games
Relevansi dinilai per koneksi, dan actor yang tidak lagi relevan dihapus di klien

Snapshot baseline hilang Lost baseline for delta compression

ID pt-baseline · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Pada server yang hanya mengirim “yang berubah sejak terakhir kali”, jika data lengkap yang dikirim sekali di awal (baseline) hilang, perubahan setelahnya tidak bisa diterapkan.

Mengapa Paket data lengkap objek (baseline) hilang atau dibuang sebelum diproses → Akibatnya Klien tidak punya dasar untuk menerapkan perubahan berikutnya, sehingga mengabaikannya → Di layar Objek itu tidak terlihat, atau tiba-tiba muncul jauh kemudian

Gejala: Tidak terlihat / objek hantu, Teleport
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama, Hanya saya
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: kirim ulang baseline sampai ACK (konfirmasi terima) diterima, buat data perubahan hanya terhadap baseline yang sudah dikonfirmasi diterima klien. Klien: kirim ACK untuk baseline setelah benar-benar diterapkan, minta ulang ke server jika menerima data perubahan untuk objek yang tidak dikenal.
Di grafik: Melonjak acak sesekali · Jumlah data perubahan yang diterima untuk objek yang tidak dikenal
Yang diperiksa: Cocokkan jumlah dan ID objek dari data perubahan yang dibuang klien karena tidak ada baseline dengan waktu server mengirim baseline objek itu dan waktu ACK diterima. Reproduksi di lingkungan development dengan menambahkan packet loss (loss di tc netem, rasio packet loss di emulasi jaringan Unreal)
Cocok jika: Untuk objek yang tidak terlihat, server sudah mengirim baseline tetapi tidak menerima ACK, namun tetap terus mengirim data perubahan saja, dan klien membuang data perubahan itu
Tidak cocok jika: Baseline sudah mendapat ACK dan diterapkan di klien, tetapi objek tetap tidak terlihat: lebih mungkin pesan despawn hilang atau kekeliruan akibat ID objek dipakai ulang
Sarana pemeriksaan: Log dan metrik server atau klien game

4 sumber

Snapshot Compression Gaffer On Games
Data perubahan hanya boleh dibuat terhadap baseline yang sudah dikonfirmasi (ack) diterima pihak lain, dan state awal dikirim terpisah
Quake III Arena source: code/server/sv_snapshot.c id Software
Kompresi delta dilakukan terhadap snapshot yang sudah dikonfirmasi klien, dan jika baseline-nya terlalu lama, snapshot lengkap dikirim
tc-netem(8) — Linux manual page iproute2
Tools pengujian yang meniru jaringan nyata dengan menambahkan latensi dan jitter (delay TIME JITTER) serta packet loss (loss random PERCENT) ke paket keluar
Using Network Emulation in Unreal Engine Epic Games
Pengujian dengan memasukkan latensi minimum dan maksimum serta rasio packet loss ke server dan klien; di konsol diatur seperti NetEmulation.PktLag

Pesan despawn hilang (objek hantu) Missed despawn (ghost entity)

ID pt-ghost · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Sebaliknya, jika pesan “sudah hilang” terlewat, NPC atau pemain yang sudah mati atau pergi tetap tertinggal hanya di layar Anda.

Mengapa Pesan bahwa objek mati, pergi, atau keluar dari jarak pandang hilang atau urutannya kacau → Akibatnya Klien menganggap objek itu masih ada → Di layar Monster yang tidak bereaksi saat diserang atau pemain yang sudah keluar masih berdiri

Gejala: Tidak terlihat / objek hantu
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama, Hanya saya
Kapan: Sesekali secara acak, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: kirim “daftar objek yang sedang terlihat” secara berkala. Klien: hapus objek yang tidak ada di daftar, sembunyikan objek yang seharusnya bergerak jika lama tidak mendapat update.
Di grafik: Melonjak acak sesekali · Jumlah objek yang hanya tersisa di klien
Yang diperiksa: Bandingkan “daftar objek yang sedang terlihat” dari server dengan daftar objek di klien, hitung objek yang hanya ada di klien, lalu cocokkan log pengiriman dan penerimaan pesan despawn berdasarkan ID objek
Cocok jika: Server sudah mengirim pesan despawn untuk objek hantu itu, tetapi tidak ada catatan penerimaan di klien, atau pesan despawn tiba lebih dulu dari pesan spawn sehingga urutannya terbalik
Tidak cocok jika: Objek itu juga masih ada di daftar objek terlihat di server: server tidak membersihkan objek itu. Terjadi tepat setelah objek baru muncul dengan ID yang sama: lebih mungkin kekeliruan akibat ID objek dipakai ulang
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

Actor Relevancy in Unreal Engine Epic Games
Actor dinamis yang tidak lagi relevan dihapus di klien
Object visibility (Netcode for GameObjects 2.5) Unity
Jika objek disembunyikan, klien itu melakukan despawn dan menghapus objek tersebut

Data spawn hilang saat membanjir tepat setelah masuk zona Initial spawn burst lost (unreliable channel, receive buffer, fragmentation)

ID pt-spawn-burst · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Begitu karakter masuk zona, server mengirim data spawn puluhan hingga ratusan objek di sekitarnya sekaligus. Jika data ini dikirim lewat channel unreliable, atau buffer terima meluap selama klien tidak bisa membaca socket karena sedang loading, sebagian data hilang dan tidak dikirim lagi.

Mengapa Tepat setelah masuk, data spawn tiba bertumpuk dalam waktu singkat → Akibatnya Klien yang sedang loading terlambat membaca socket sehingga buffer terima OS meluap, atau paket UDP besar terfragmentasi sehingga satu fragmen saja yang hilang membuat seluruh paket hilang. Jika lewat channel unreliable, data itu juga tidak dikirim ulang → Di layar Beberapa NPC hilang hanya di klien yang loading-nya lambat. NPC terlihat setelah karakter keluar dari jarak pandang lalu kembali

Gejala: Tidak terlihat / objek hantu
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama, Hanya saya
Kapan: Tepat setelah login atau maintenance, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: kirim pesan spawn/despawn lewat channel reliable yang menjamin retransmisi, kirim data awal secara bertahap. Klien: terima paket di thread yang terpisah dari loading, perbesar ukuran buffer terima.
Kisaran angka: Nilai default buffer terima UDP di PC berbeda di setiap OS, tetapi biasanya puluhan hingga ratusan KB. Jika data masuk di kota yang ramai pemain lebih besar dari itu, buffer meluap meskipun socket hanya sebentar tidak terbaca karena loading.
Di grafik: Melonjak tepat setelah server dibuka · Volume data yang diterima tepat setelah masuk, jumlah pesan spawn yang terlewat
Yang diperiksa: Bandingkan jumlah pesan spawn yang dikirim server tepat setelah masuk dengan jumlah yang diterima klien, lalu periksa channel yang dipakai (reliable atau unreliable). Di packet capture sisi server, periksa volume data yang dikirim ke pemain itu tepat setelah masuk dan paket yang terfragmentasi (filter Wireshark ip.flags.mf == 1 || ip.frag_offset > 0)
Cocok jika: Jumlah yang diterima lebih sedikit dari yang dikirim, yang terlewat berkumpul di rentang padat tepat setelah masuk, dan pesan dikirim lewat channel unreliable atau paket besar terfragmentasi. Lebih sering terjadi di klien yang loading-nya lambat
Tidak cocok jika: Jumlah yang dikirim dan diterima sama, tetapi objek tetap tidak terlihat: pesan dibuang setelah diterima (pesan spawn yang tiba saat loading dibuang) atau masalah perhitungan jarak pandang. Sering terlewat kapan saja, tidak hanya tepat setelah masuk: packet loss di koneksi
Sarana pemeriksaan: Log dan metrik server atau klien game

4 sumber

RFC 8085: UDP Usage Guidelines IETF
Paket yang terfragmentasi hilang seluruhnya meskipun hanya satu fragmen yang hilang
UDP vs. TCP Gaffer On Games
UDP tidak menjamin pengiriman maupun urutan, sehingga paket yang hilang harus dideteksi dan dikirim ulang sendiri
Socket.ReceiveBufferSize Property Microsoft
Ukuran default buffer terima socket berbeda di setiap OS
Display Filter Reference: Internet Protocol Version 4 Wireshark
Paket IP yang terfragmentasi disaring dengan ip.flags.mf (More fragments) dan ip.frag_offset (Fragment Offset)

Kekeliruan akibat ID objek dipakai ulang Entity ID reused without a generation counter

ID pt-id-reuse · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika server memakai ulang ID objek yang sama saat NPC yang mati muncul kembali, klien yang melewatkan pesan despawn di antaranya salah mengira NPC baru sebagai NPC lama.

Mengapa NPC mati, lalu muncul lagi dengan ID objek yang sama → Akibatnya Klien yang melewatkan pesan despawn mengabaikan pesan spawn karena menganggapnya “objek yang sudah dikenal”, atau membiarkan objek itu tetap dalam keadaan mati → Di layar NPC tidak ada atau terlihat tergeletak hanya di salah satu layar, kadang juga terlihat dengan wujud NPC lain

Gejala: Tidak terlihat / objek hantu
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama, Hanya saya
Kapan: Sesekali secara acak, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: tambahkan nomor generasi ke ID objek untuk membedakan ID yang dipakai ulang. Klien: jika menerima pesan spawn untuk ID yang sudah dikenal, hapus objek lama lalu buat yang baru.
Di grafik: Melonjak acak sesekali · Jumlah pesan spawn untuk ID yang sudah dikenal
Yang diperiksa: Catat di server waktu pembuatan dan penghapusan per ID objek (beserta nomor generasi jika ada), lalu hitung berapa kali klien menerima pesan spawn dengan ID yang sudah dikenal dan berapa penghapusan dan pembuatan ulang yang diproses sebagai “tidak berubah” saat update jarak pandang
Cocok jika: ID NPC yang tidak terlihat atau terlihat tergeletak sama dengan NPC yang baru saja mati, dan di antaranya klien itu tidak menerima pesan despawn, atau server tidak mengirim pesan despawn maupun pesan spawn
Tidak cocok jika: ID punya nomor generasi dan nomor itu juga dipakai saat membandingkan: bukan penyebab ini. Tidak terlihat walaupun ID-nya tidak dipakai ulang: lebih mungkin pesan spawn hilang
Sarana pemeriksaan: Log dan metrik server atau klien game
Pelajari lebih lanjut: Masalah ini juga bisa terjadi di sisi server. Jika daftar objek dalam jarak pandang dibandingkan hanya berdasarkan ID, NPC yang mati lalu spawn lagi dengan ID yang sama di antara dua update jarak pandang dianggap “tidak berubah”, sehingga pesan despawn maupun pesan spawn sama-sama tidak dikirim. Jika waktu update jarak pandang berbeda untuk setiap pemain, hanya klien yang update-nya jatuh di saat itu yang mengalaminya.

2 sumber

Entity struct (Entities 1.3) Unity
Entity terdiri dari Index dan nomor generasi (Version), sehingga bisa dibedakan apakah Index yang dipakai ulang masih valid
NetworkConfig class (Netcode for GameObjects 2.5) Unity
RecycleNetworkIds dan NetworkIdRecycleDelay: ID jaringan dipakai ulang setelah dibiarkan kosong selama waktu tertentu

Bentrok port UDP tetap Two clients bound to the same local UDP port

ID pt-port-collision · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika klien dibuat untuk memakai port lokal yang tetap, klien kedua di PC yang sama tidak bisa memakai port itu atau harus berbagi paket dengan klien pertama.

Mengapa Dua klien mencoba membuka port UDP lokal yang sama (dipaksa berbagi dengan opsi reuse) → Akibatnya OS hanya meneruskan paket masuk ke salah satu socket, atau tidak menjamin socket mana yang menerimanya. Router dan server juga melihat kedua klien sebagai alamat yang sama → Di layar Salah satu klien tidak menerima paket dunia game, sehingga NPC dan pemain lain tidak terlihat atau terjadi disconnect

Gejala: Tidak terlihat / objek hantu, Disconnect, Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama
Kapan: Tepat setelah login atau maintenance, Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: biarkan OS memilih port lokal secara otomatis (bind ke port 0). Server: bedakan koneksi dengan token sesi yang diterbitkan untuk setiap koneksi.
Di grafik: Hanya sebagian yang tinggi · Jumlah paket yang diterima per klien
Yang diperiksa: Di PC pemain, dengan kedua klien menyala, jalankan netstat -ano -p udp di Command Prompt untuk melihat port UDP lokal yang dibuka setiap proses game (PID). Di sisi server, periksa apakah kedua sesi masuk dari IP publik dan port yang sama
Cocok jika: Kedua proses game terikat ke port lokal yang sama, atau di server kedua sesi terlihat dari IP dan port yang sama. Normal jika hanya satu klien yang dinyalakan
Tidak cocok jika: Kedua klien memakai port lokal yang berbeda, tetapi salah satunya tetap bermasalah: lebih mungkin bug pembedaan sesi berdasarkan IP atau perangkat, atau pembatasan multi-klien
Sarana pemeriksaan: Lingkungan pemain sendiri

3 sumber

Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE Microsoft
Bind kedua ke port yang sama dengan SO_REUSEADDR merebut port itu, dan tidak bisa dipastikan socket mana yang menerima paket
bind function (winsock.h) Microsoft
Jika bind dilakukan ke port 0, port unik dialokasikan dari rentang port dinamis (49152–65535)
netstat Microsoft
-a menampilkan port TCP dan UDP, -n alamat dalam bentuk angka, -o ID proses (PID), dan -p udp hanya UDP

Bug pembedaan sesi berdasarkan IP atau perangkat Session keyed by IP or machine ID

ID pt-session-key · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika server atau server perantara membedakan koneksi berdasarkan IP atau ID perangkat, dua klien di PC yang sama (IP publik yang sama) dikenali sebagai satu orang.

Mengapa Tabel sesi dibuat dengan kunci IP atau IP + ID perangkat → Akibatnya Data klien kedua menimpa sesi pertama atau tercampur dengannya → Di layar Di satu klien NPC tidak terlihat, sementara klien lainnya disconnect atau menerima data orang lain

Gejala: Tidak terlihat / objek hantu, Disconnect
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama, Satu rumah, Wilayah/ISP tertentu
Kapan: Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: bedakan setiap koneksi dengan token sesi yang unik, baik di server maupun server perantara, dan pastikan ini diperbaiki karena beberapa orang di rumah yang sama (di balik NAT router) serta pengguna jaringan seluler yang satu IP-nya dibagi ISP ke banyak pelanggan (CGNAT) juga mengalami masalah yang sama. Klien: pakai token sesi yang diterima terpisah untuk setiap klien yang dijalankan.
Di grafik: Hanya sebagian yang tinggi · Jumlah sesi bersamaan dari IP publik yang sama, jumlah sesi yang tertimpa
Yang diperiksa: Catat di log server dan server perantara kunci yang dipakai untuk mencari sesi, token sesi, serta IP dan port klien, lalu periksa apakah sesi yang ada berubah saat koneksi kedua dari IP yang sama masuk. Gejala bisa direproduksi dengan menyalakan dua klien berturut-turut di PC yang sama
Cocok jika: Begitu klien kedua terhubung, alamat atau data karakter sesi pertama berubah, dan disconnect yang sama juga terlihat pada pemain lain di balik router yang sama atau jaringan seluler (CGNAT)
Tidak cocok jika: Dua sesi dari IP yang sama tetap terpisah dengan token yang berbeda: bukan penyebab ini. Kedua proses memakai port lokal yang sama: bentrok port UDP tetap
Sarana pemeriksaan: Log dan metrik server atau klien game

1 sumber

RFC 6269: Issues with IP Address Sharing IETF
Jika banyak pelanggan berbagi satu alamat IPv4 lewat NAT atau CGN, pengguna tidak bisa dibedakan hanya dari IP

Pembatasan multi-klien Multi-client restriction policy

ID pt-multiclient · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika modul keamanan atau kebijakan server membatasi beberapa klien di satu PC, klien kedua tidak bisa dijalankan atau masuk, atau klien yang dinyalakan lebih dulu terputus. Sebagian game hanya memblokir fitur pada klien tambahan.

Mengapa Modul keamanan mendeteksi klien yang dijalankan ganda, atau server membatasi koneksi tambahan dari perangkat yang sama → Akibatnya Menolak eksekusi atau koneksi kedua, atau memutus salah satunya. Dalam kasus yang jarang, hanya sebagian fitur klien tambahan yang diblokir → Di layar Tidak bisa masuk, atau salah satu klien disconnect. Pada game yang hanya memblokir fitur, NPC atau toko tidak terlihat di salah satu klien saja

Gejala: Tidak bisa masuk / loading tanpa henti, Tidak terlihat / objek hantu, Disconnect
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama
Kapan: Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: jika memang dibatasi, tampilkan pesan pemberitahuan yang jelas, atur pengecualian untuk QA di modul keamanan. Server: atur juga pengecualian untuk QA pada pembatasan koneksi dari perangkat yang sama.
Di grafik: Hanya sebagian yang tinggi · Jumlah penolakan koneksi dan pemutusan per alasan (koneksi ganda)
Yang diperiksa: Periksa pesan yang muncul saat klien kedua dinyalakan dan pesan pemutusan di klien yang dinyalakan lebih dulu. Periksa apakah log penolakan koneksi dan kick di server mencatat kode alasan seperti koneksi ganda atau perangkat yang sama
Cocok jika: Saat klien kedua dijalankan atau masuk, muncul pesan penolakan atau klien pertama terputus dengan alasan koneksi ganda, dan tidak ada masalah jika hanya satu klien yang dinyalakan
Tidak cocok jika: Kedua klien bisa masuk tanpa alasan penolakan atau pemutusan, tetapi NPC tidak terlihat di salah satunya: lebih mungkin bentrok port UDP tetap, bug pembedaan sesi berdasarkan IP atau perangkat, atau penyebab di sisi loading dan tampilan
Sarana pemeriksaan: Lingkungan pemain sendiri

1 sumber

CreateMutexW function (synchapi.h) Microsoft
Jika named mutex sudah ada, ERROR_ALREADY_EXISTS dikembalikan, sehingga dipakai untuk mendeteksi eksekusi ganda dan membatasi agar hanya satu instance yang berjalan

Pemrosesan dibatasi di jendela latar belakang Background window throttling

ID pt-background · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Untuk klien di jendela latar belakang, game, engine, dan OS mengurangi frame dan pemrosesan. Paket yang diterima tidak sempat diproses tepat waktu, sehingga menumpuk atau meluap.

Mengapa Batas frame latar belakang di opsi game atau driver grafis (misalnya, di driver NVIDIA bisa diatur 20–200 frame per detik), mode hemat daya, pengaturan engine yang menghentikan game di latar belakang. OS juga memprioritaskan CPU dan GPU untuk jendela di depan (foreground) → Akibatnya Jumlah paket yang diproses per frame berkurang sehingga antrean menumpuk, dan paket dibuang jika buffer terima meluap → Di layar Saat jendela dibawa ke depan, semuanya muncul sekaligus, atau sebagian NPC tetap tidak terlihat

Gejala: Tidak terlihat / objek hantu, Fast forward, Disconnect
Faktor: Stall, Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama
Kapan: Setelah lama diam, Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Terus terima data jaringan di thread terpisah dari game loop, jamin throughput minimum di latar belakang, aktifkan pengaturan engine untuk berjalan di latar belakang (runInBackground di Unity).
Tugas Pihak Eksternal: Imbau pemain untuk mematikan batas frame latar belakang di driver grafis dan mode hemat daya PC.
Kisaran angka: Di Unity, jika runInBackground dimatikan, game loop berhenti begitu jendela kehilangan fokus. Jika paket hanya diterima di loop itu, tidak ada paket yang diproses sama sekali selama itu.
Di grafik: Kosong lalu datang sekaligus · Interval frame klien, jumlah paket yang diproses per frame
Yang diperiksa: Di PC yang sama, letakkan satu jendela di depan dan yang lain di belakang, lalu tukar posisinya dan bandingkan. Ukur interval frame kedua proses dengan PresentMon, dan jika ada log dari game, periksa status fokus jendela dan jumlah paket yang diproses per frame
Cocok jika: Interval frame melebar jauh hanya saat jendela di latar belakang (jika karena batas driver, intervalnya mendatar di nilai yang sesuai dengan frame rate yang diatur) atau pemrosesan berhenti, dan saat jendela ditukar, masalahnya ikut pindah ke klien lain
Tidak cocok jika: Terjadi sama persis di jendela depan: bukan karena pembatasan latar belakang. Selalu klien yang sama yang bermasalah tanpa peduli posisi jendela: lebih mungkin perbedaan opsi tampilan atau versi
Sarana pemeriksaan: Lingkungan pemain sendiri

4 sumber

Application.runInBackground Unity
Nilai default runInBackground adalah false, dan dengan nilai itu aplikasi dijeda di latar belakang
Manage 3D Settings (reference) — NVIDIA Control Panel Help NVIDIA
Background Application Max Frame Rate: membatasi frame maksimum game di latar belakang pada 20–200 frame per detik
Priority Boosts Microsoft
Windows menaikkan prioritas proses milik jendela foreground hingga setara atau lebih tinggi dari proses di latar belakang
PresentMon README Intel
Tool yang mengumpulkan frame time CPU, GPU, dan display per aplikasi untuk aplikasi grafis Windows

Bentrok akses bersamaan ke file cache dan aset Shared cache / asset file lock conflicts

ID pt-asset-lock · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Jika dua klien menulis ke folder cache yang sama secara bersamaan atau mengunci file, salah satu klien gagal memuat model dan tekstur NPC.

Mengapa Dua klien menulis file cache atau patch di folder instalasi yang sama secara bersamaan → Akibatnya Pemuatan gagal karena file tidak bisa dikunci atau file yang baru setengah tertulis ikut terbaca → Di layar NPC yang punya name tag tetapi tanpa model karakter, atau NPC yang transparan

Gejala: Tidak terlihat / objek hantu
Faktor: Stall
Siapa yang mengalami: Hanya satu klien di PC yang sama
Kapan: Tepat setelah login atau maintenance, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Pisahkan folder cache per klien, coba lagi jika penguncian file gagal, tampilkan setidaknya model default jika pemuatan gagal.
Di grafik: Hanya sebagian yang tinggi · Jumlah kegagalan pemuatan aset per klien
Yang diperiksa: Di PC pemain, saring hanya path folder instalasi dan cache game di Process Monitor, lalu periksa hasil operasi buka dan tulis file oleh kedua proses game. Jika ada log klien, cari kegagalan pemuatan aset dan kode error saat membuka file (ERROR_SHARING_VIOLATION)
Cocok jika: Pembukaan file untuk model yang tidak terlihat berakhir dengan sharing violation atau gagal kunci, dan pada saat yang sama klien lain sedang menulis file itu. Hilang jika hanya satu klien yang dinyalakan atau folder instalasi dan cache dipisah
Tidak cocok jika: Model yang sama tetap tidak terlihat walaupun hanya satu klien yang dinyalakan: lebih mungkin file rusak, atau versi klien atau data tidak cocok. File terbuka dengan baik tetapi tidak tergambar: lebih mungkin kekurangan memori atau VRAM
Sarana pemeriksaan: Lingkungan pemain sendiri

2 sumber

Creating and Opening Files Microsoft
File yang dibuka tanpa share mode tidak bisa dibuka proses lain, dan muncul ERROR_SHARING_VIOLATION
Process Monitor Microsoft
Mencatat aktivitas file system, registry, dan proses secara real-time, dan bisa disaring berdasarkan path maupun semua kolom lainnya

Streaming gagal akibat kekurangan memori atau VRAM Memory / VRAM exhaustion

ID pt-vram · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)

Jika dua klien berbagi memori grafis, tidak ada ruang untuk memuat model dan tekstur yang baru dibutuhkan, sehingga sebagian tidak tergambar.

Mengapa Dua klien berbagi VRAM dan RAM. OS juga bisa lebih dulu mengurangi jatah memori grafis untuk jendela di latar belakang → Akibatnya Engine tidak bisa memuat model dan tekstur baru, atau terus melepas lalu memuatnya lagi → Di layar NPC muncul terlambat, tampak buram, atau tidak terlihat, disertai patah-patah

Gejala: Tidak terlihat / objek hantu, Patah-patah
Faktor: Stall
Siapa yang mengalami: Hanya satu klien di PC yang sama
Kapan: Saat bergerak atau pindah area, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Atur kualitas otomatis sesuai budget memori, tampilkan model pengganti jika pemuatan gagal.
Tugas Pihak Eksternal: Imbau pemain yang menyalakan dua klien sekaligus untuk menurunkan kualitas grafis atau memakai mode grafis rendah, informasikan spesifikasi VRAM dan RAM yang direkomendasikan.
Di grafik: Mendatar di batas · Pemakaian memori GPU khusus (dedicated) per proses
Yang diperiksa: Di Task Manager PC pemain, tambahkan kolom Dedicated GPU memory di tab “Details”, lalu bandingkan total pemakaian kedua klien dengan kapasitas VRAM kartu grafis. Di sisi game, catat budget (Budget) dan pemakaian saat ini (CurrentUsage) yang dilaporkan QueryVideoMemoryInfo dari DXGI
Cocok jika: Total pemakaian kedua klien mendatar di dekat kapasitas VRAM, dan kegagalan pemuatan model dan tekstur terpusat pada saat pemakaian saat ini melewati budget. Hilang jika kualitas diturunkan atau hanya satu klien yang dinyalakan
Tidak cocok jika: VRAM masih longgar tetapi objek tetap tidak terlihat: lebih mungkin bentrok akses bersamaan ke file cache dan aset, atau perbedaan opsi tampilan
Sarana pemeriksaan: Lingkungan pemain sendiri

3 sumber

Residency (Direct3D 12) Microsoft
Budget memori video bisa turun drastis saat beralih ke aplikasi lain, dan jika budget terlampaui, aplikasi bisa terhenti atau pembuatan resource gagal. Jika bukan foreground, jatah yang sudah dipesan pun tidak dijamin
GPUs in the task manager Microsoft
Dengan menambahkan kolom di tab Details pada Task Manager, pemakaian memori GPU khusus (dedicated) dan bersama (shared) per proses bisa dilihat. Memori GPU khusus adalah VRAM kartu grafis
DXGI_QUERY_VIDEO_MEMORY_INFO structure (dxgi1_4.h) Microsoft
Budget (budget memori video yang ditetapkan OS) dan CurrentUsage (pemakaian aplikasi saat ini). Jika pemakaian melewati budget, bisa terjadi patah-patah

Perbedaan opsi tampilan Different display settings

ID pt-display-option · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Jika opsi seperti batas jumlah karakter yang ditampilkan, penyembunyian name tag atau model NPC, dan mode grafis rendah berbeda di kedua klien, yang terlihat pun berbeda.

Mengapa Hanya satu klien yang memakai “batas jumlah karakter di sekitar yang ditampilkan” atau mode grafis rendah → Akibatnya NPC yang jauh atau berprioritas rendah tidak digambar (normal) → Di layar NPC tidak ada hanya di salah satu sisi

Gejala: Tidak terlihat / objek hantu
Faktor: Stall
Siapa yang mengalami: Hanya satu klien di PC yang sama, Hanya saya
Kapan: Saat banyak pemain berkumpul, Selalu
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Beri tanda bahwa objek disembunyikan oleh opsi, pisahkan file pengaturan per klien agar tidak tercampur.
Di grafik: Hanya sebagian yang tinggi · Jumlah objek yang digambar di layar per klien
Yang diperiksa: Bandingkan berdampingan pengaturan batas jumlah karakter yang ditampilkan, penyembunyian name tag dan model, serta mode grafis rendah di kedua klien, lalu samakan salah satunya dengan yang lain. Periksa juga apakah kedua klien memakai satu file pengaturan bersama dan saling menimpa
Cocok jika: Setelah pengaturannya disamakan, kedua layar menjadi sama, dan NPC yang tadinya tidak terlihat ternyata objek jauh di luar batas jumlah tampilan atau objek berprioritas rendah
Tidak cocok jika: Pengaturan sudah disamakan, tetapi NPC tetap tidak ada di salah satu sisi: lebih mungkin perbedaan channel atau phasing, atau pesan spawn hilang
Sarana pemeriksaan: Lingkungan pemain sendiri

1 sumber

Changing the Quantity of Characters Displayed On-screen (FINAL FANTASY XIV UI Guide) Square Enix
Pengaturan batas tampilan (Character and Object Quantity) mengatur jumlah karakter dan objek yang digambar di layar

Versi klien atau data tidak cocok Client version / data table mismatch

ID pt-version · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika klien kedua berasal dari instalasi lain atau patch-nya belum selesai, klien itu tidak mengenal ID NPC baru yang dikirim server dan diam-diam mengabaikannya.

Mengapa Instalasi di folder lain, atau klien yang dijalankan saat patch masih berlangsung → Akibatnya ID NPC atau ID model yang tidak dikenal dilewati → Di layar Hanya NPC yang baru ditambahkan yang tidak terlihat di salah satu sisi

Gejala: Tidak terlihat / objek hantu
Faktor: Packet loss
Siapa yang mengalami: Hanya satu klien di PC yang sama
Kapan: Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Klien: kirim versi data saat masuk, catat ke log dan tampilkan pengganti jika menerima ID yang tidak dikenal. Server: periksa versi data saat masuk, tolak koneksi dan arahkan pemain untuk patch jika berbeda.
Di grafik: Hanya sebagian yang tinggi · Jumlah ID tidak dikenal yang diterima per versi klien
Yang diperiksa: Bandingkan path file executable kedua klien serta versi klien dan versi data yang tampil di layar atau log. Di sisi game, catat versi data yang dikirim saat masuk dan berapa kali ID NPC atau model yang tidak dikenal diterima lalu dilewati
Cocok jika: Versi atau folder instalasi kedua klien berbeda, NPC yang tidak terlihat adalah NPC yang ditambahkan lewat patch terbaru, dan NPC itu terlihat di instalasi yang patch-nya sudah selesai
Tidak cocok jika: Versi dan folder instalasi sama, tetapi NPC tidak ada di salah satu sisi: lebih mungkin perbedaan channel atau phasing, atau penyebab di sisi loading atau pengiriman
Sarana pemeriksaan: Lingkungan pemain sendiri

1 sumber

NetworkConfig class (Netcode for GameObjects 2.5) Unity
Jika ProtocolVersion berbeda, keduanya tidak saling berkomunikasi, dan ForceSamePrefabs memeriksa perbedaan daftar prefab saat koneksi dibuat

Budget pengiriman dan prioritas per koneksi Per-connection bandwidth budget and priority

ID pt-priority · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Jika server membatasi volume kirim per koneksi dan mengirim objek yang dekat lebih dulu, koneksi dengan batas rendah menerima NPC yang jauh dengan terlambat atau tidak menerimanya sama sekali.

Mengapa Di tempat ramai, server mengirim data sesuai urutan kepentingan dalam batas volume kirim per koneksi → Akibatnya Koneksi dengan estimasi bandwidth rendah (misalnya, klien di jendela latar belakang yang lambat mengirim ACK) terus menunda objek di urutan belakang → Di layar NPC yang jauh terlihat terlambat atau tidak terlihat hanya di salah satu sisi

Gejala: Tidak terlihat / objek hantu, Input lag
Faktor: Latensi
Siapa yang mengalami: Hanya satu klien di PC yang sama, Lokasi/channel tertentu
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: naikkan prioritas objek yang tertunda seiring waktu (mencegah starvation), jamin interval update minimum. Klien: tetap kirim ACK tepat waktu di latar belakang agar estimasi bandwidth tidak turun.
Di grafik: Naik mengikuti beban · Jumlah objek yang ditunda per koneksi, volume kirim per koneksi
Yang diperiksa: Catat di server, per koneksi, byte yang dikirim per tick, batas kirim (estimasi bandwidth), jumlah objek yang tertunda karena tidak sempat dikirim, dan waktu sejak pengiriman terakhir per objek. Di Unreal, ukuran paket per koneksi dan objek replikasi di dalamnya bisa dilihat di Networking Insights
Cocok jika: NPC yang tidak terlihat adalah objek yang lama tertunda di koneksi itu, batas koneksi itu lebih rendah dari koneksi lain, dan makin ramai pemain, makin banyak objek yang tertunda
Tidak cocok jika: Tidak ada objek yang tertunda dan NPC itu juga dikirim tepat waktu: masalahnya di tahap setelah pengiriman (buffer terima, loading, opsi tampilan). Semua koneksi menempel di batas: masalah volume kirim seluruh server atau desain jarak pandang
Sarana pemeriksaan: Log dan metrik server atau klien game

3 sumber

Actor Priority in Unreal Engine Epic Games
Saat bandwidth jenuh, actor yang direplikasi dipilih berdasarkan prioritas (jarak, arah pandang, waktu sejak replikasi terakhir). Tidak semua actor direplikasi setiap kali
State Synchronization Gaffer On Games
Akumulasi prioritas: objek yang tidak masuk ke paket kali ini masuk lebih dulu ke paket berikutnya, dan batas bandwidth disesuaikan secara real-time
Networking Insights in Unreal Engine Epic Games
Menampilkan ukuran paket yang dikirim dan diterima per koneksi serta objek dan properti replikasi di dalamnya

Objek ditahan akibat kesalahan estimasi jam Clock estimate error holds or discards entities

ID pt-clock-hold · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)

Jika waktu server yang diperkirakan klien salah, data objek yang baru tiba ditahan karena dianggap “masih di masa depan”, atau dibuang karena dianggap “sudah terlalu lama”.

Mengapa Perkiraan waktu server di salah satu klien meleset jauh (diukur saat loading, atau setelah bangun dari mode hemat daya) → Akibatnya Waktu acuan interpolasi tidak cocok dengan waktu data objek → Di layar Objek muncul terlambat atau terlihat diam di tempat

Gejala: Tidak terlihat / objek hantu, Patah-patah
Faktor: Latensi
Siapa yang mengalami: Hanya satu klien di PC yang sama
Kapan: Setelah lama diam, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Ulangi sinkronisasi waktu secara berkala dan reset segera jika selisihnya besar, jangan pakai nilai yang diukur saat loading atau tepat setelah bangun dari mode hemat daya.
Di grafik: Hanya sebagian yang tinggi · Error perkiraan waktu server per klien
Yang diperiksa: Catat di klien perkiraan waktu server, RTT, saat sinkronisasi waktu diulang, dan berapa kali data objek ditahan atau dibuang. Coba reproduksi tepat setelah loading atau tepat setelah bangun dari mode hemat daya
Cocok jika: Hanya di klien yang bermasalah error perkiraannya melewati ambang reset (di Unity hardResetThresholdSec, default 0,2 detik), ada catatan data objek ditahan karena dianggap masa depan atau dibuang karena dianggap masa lalu, dan langsung normal setelah sinkronisasi waktu diulang
Tidak cocok jika: Error perkiraannya kecil, tetapi objek tetap muncul terlambat: lebih mungkin budget pengiriman dan prioritas per koneksi, atau penyebab di sisi loading
Sarana pemeriksaan: Log dan metrik server atau klien game

2 sumber

NetworkTimeSystem class (Netcode for GameObjects 2.5) Unity
Jika selisih waktu melewati hardResetThresholdSec (default 0,2 detik), waktu langsung dipaksa disamakan. Di luar itu, waktu disesuaikan sedikit demi sedikit lebih cepat atau lebih lambat dengan adjustmentRatio
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
LocalTime berjalan lebih dulu dari server, sedangkan ServerTime tertinggal. Pesan yang tiba terlambat bisa punya waktu tunggu negatif

Akar penyebab retransmisi TCP

Packet loss di jalur nirkabel Wi-Fi / cellular link loss

ID rt-wireless · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)

Wi-Fi dan jaringan seluler mengirim ulang paket beberapa kali di jalur nirkabel, dan jika tetap gagal, paket dibuang. Paket yang dibuang itu baru dikirim ulang oleh TCP jauh kemudian.

Mengapa Sinyal lemah atau interferensi berat membuat pengiriman di jalur nirkabel gagal berturut-turut → Akibatnya Paket dibuang setelah melewati batas percobaan ulang perangkat nirkabel (biasanya beberapa hingga belasan kali) → Di layar Freeze selama menunggu retransmisi TCP, lalu fast forward karena paket berikutnya yang tertahan di buffer terima diteruskan sekaligus

Gejala: Freeze, Fast forward, Teleport
Faktor: Packet loss, Jitter
Siapa yang mengalami: Hanya saya, Satu rumah
Kapan: Sesekali secara acak, Saat bergerak atau pindah area
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: aktifkan TCP_NODELAY (jika Nagle aktif, RACK tidak punya paket susulan untuk mendeteksi packet loss), kirim hanya update state terbaru selama koneksi tertahan oleh retransmisi (batasi jumlah yang menumpuk di kernel dengan TCP_NOTSENT_LOWAT). Klien: aktifkan TCP_NODELAY (packet loss di arah input pemain dipulihkan oleh OS klien), tampilkan status jaringan di layar saat packet loss menumpuk atau ping melonjak.
Tugas Tim Infrastruktur: Percepat pemulihan packet loss dengan RACK-TLP (server tidak bisa mencegah packet loss nirkabel dan paling jauh hanya bisa mempercepat pemulihan), pastikan nilai default Linux terbaru net.ipv4.tcp_recovery=1 (RACK) dan net.ipv4.tcp_early_retrans=3 (TLP) tidak diubah.
Tugas Pihak Eksternal: Imbau pemain untuk memakai koneksi kabel atau Wi-Fi 5 GHz/6 GHz, serta memindahkan router atau mengganti channel-nya.
Kisaran angka: Dengan packet loss nirkabel 1%, 1 dari 100 paket game hilang. Jika menerima 10 paket per detik, game tersendat sesaat kira-kira sekali setiap 10 detik. Tanpa RACK-TLP, setiap kejadian membuat game berhenti selama RTO (ping + 200 ms atau lebih).
Di grafik: Hanya sebagian yang tinggi · Tingkat retransmisi per koneksi, RTT (ping) per koneksi
Yang diperiksa: Dari PC pemain, kirim ping ratusan kali ke alamat router (gateway) dan ke server game, bandingkan packet loss dan rentang latensinya, lalu ukur lagi setelah beralih ke kabel atau data seluler. Di server, periksa retrans dan rtt (rata-rata/deviasi) pada koneksi pemain itu dengan ss -ti
Cocok jika: Ping ke router saja sudah menunjukkan packet loss atau latensi yang naik turun, dan masalah hilang setelah beralih ke kabel. Dari sisi server, hanya koneksi pemain itu yang retrans dan deviasi RTT-nya besar
Tidak cocok jika: Bersih sampai router, packet loss baru mulai setelahnya: mengarah ke ISP atau rute (“Antrean bottleneck meluap”, “Perubahan rute dan jalur ECMP bermasalah”). Beberapa pemain di ISP yang sama memburuk bersamaan: periksa jalur ISP lebih dulu
Sarana pemeriksaan: Lingkungan pemain sendiri
Pelajari lebih lanjut: Percobaan ulang di perangkat nirkabel menimbulkan jitter (beberapa ms setiap percobaan), dan hanya paket yang melewati batas percobaan ulang yang menjadi packet loss. Karena itu, makin buruk kualitas nirkabel, gejalanya makin berat dengan urutan “jitter → sesekali freeze → sering freeze”. Saat roaming, yaitu berpindah dari satu router (AP) ke AP lain, paket bisa hilang berturut-turut selama puluhan ms hingga beberapa detik. Jaringan seluler banyak melakukan retransmisi di jalur ke BTS, sehingga masalahnya lebih sering muncul sebagai lonjakan latensi ratusan ms daripada sebagai packet loss.
Kasus nyata: Square Enix 2021: Kepadatan server saat rilis ekspansi FINAL FANTASY XIV dan error antrean login

8 sumber

net/wireless/core.c Linux kernel
Batas percobaan ulang default di stack nirkabel Linux: 7 kali untuk frame pendek, 4 kali untuk frame panjang (dot11ShortRetryLimit, dot11LongRetryLimit)
RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks IETF
Berkat retransmisi di lapisan link, packet loss IP di jaringan seluler kecil, tetapi pemulihan itu muncul sebagai jitter dan lonjakan latensi
Wi-Fi roaming support in Apple devices Apple
Saat berpindah AP, data tidak bisa dikirim sampai autentikasi ke AP baru selesai, dan di lingkungan 802.1X prosesnya bisa memakan beberapa detik
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
Definisi RACK (deteksi packet loss berbasis waktu) dan TLP (retransmisi paket terakhir)
IP Sysctl Linux kernel
Default tcp_recovery 0x1 (RACK), default tcp_early_retrans 3 (TLP aktif), TCP_NOTSENT_LOWAT dan tcp_notsent_lowat membatasi jumlah data yang belum dikirim
tcp(7) — Linux manual page Linux man-pages
TCP_NODELAY mematikan algoritma Nagle sehingga data kecil pun langsung dikirim
include/net/tcp.h Linux kernel
Nilai minimum RTO: TCP_RTO_MIN = 200 ms
misc/ss.c iproute2
ss -ti menampilkan retrans:jumlah yang sedang dikirim ulang/jumlah retransmisi kumulatif dan rtt:RTT/deviasi RTT (rttvar)

Antrean bottleneck meluap (packet loss akibat kongesti) Tail drop at a congested bottleneck

ID rt-queue-drop · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal), Pengembangan klien (Tim Pengembang Game)

Saat antrean di titik tersempit penuh, misalnya router rumah, jalur penghubung antar-ISP, atau jalur data center, paket yang baru datang dibuang.

Mengapa Bottleneck penuh oleh trafik video, unduhan, dan pengguna lain → Akibatnya Selama antrean penuh, paket yang baru datang dibuang berturut-turut (tail drop). Paket yang lolos pun menunggu di ujung antrean yang penuh → Di layar Banyak paket hilang sekaligus sehingga terjadi freeze panjang lalu fast forward, sering pada malam hari

Gejala: Freeze, Fast forward, Rubber banding
Faktor: Packet loss, Latensi
Siapa yang mengalami: Satu rumah, Wilayah/ISP tertentu, Seluruh server
Kapan: Jam sibuk malam hari, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Tampilkan status jaringan di layar saat packet loss menumpuk atau ping melonjak (sertakan petunjuk bahwa mungkin ada transfer besar di koneksi yang sama).
Tugas Tim Infrastruktur: Sediakan kapasitas cadangan di jalur data center, periksa counter drop antrean (output drops) di jalur dan port switch kami, alihkan trafik lewat jalur lain atau peering jika jalur ISP padat.
Tugas Pihak Eksternal: Imbau pemain untuk memakai SQM (fq_codel, CAKE) dan ECN di router (agar pengirim menurunkan laju sebelum antrean meluap), minta ISP menambah kapasitas di bottleneck.
Kisaran angka: Saat antrean meluap, sebagian besar paket yang masuk selama puluhan ms bisa hilang sekaligus. Paket mudah hilang berturut-turut, bahkan paket retransmisinya pun ikut hilang, sehingga pemulihan sering harus menunggu RTO.
Di grafik: Tinggi hanya di jam tertentu · Tingkat retransmisi, RTT (ping)
Yang diperiksa: Pilah tingkat retransmisi server (kenaikan TcpRetransSegs ÷ TcpOutSegs dari nstat yang dijalankan setiap 1 menit) dan RTT per koneksi menurut wilayah, ISP, dan jam, lalu periksa juga drop output (ifOutDiscards) di jalur dan port switch kami. Jalankan mtr ke wilayah bermasalah pada jam sibuk dan jam sepi, lalu bandingkan
Cocok jika: Tingkat retransmisi naik hanya pada jam sibuk malam, dan RTT naik lebih dulu tepat sebelum packet loss (tanda antrean terisi). Di mtr, hanya pada jam sibuk packet loss dan latensi bertambah bersamaan mulai dari satu hop sampai ujung
Tidak cocok jika: RTT tidak naik sebelum packet loss: lebih mungkin “Policer membuang trafik berlebih”. Packet loss selalu mirip di jam berapa pun: lebih mungkin “Error fisik” atau “Perubahan rute dan jalur ECMP bermasalah”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Kasus nyata: Riot Games 2015: Trafik League of Legends yang memutar jauh dan Riot Direct

9 sumber

RFC 7567: IETF Recommendations Regarding Active Queue Management IETF
Penjelasan bahwa tail drop membuat antrean penuh dalam waktu lama sehingga latensi bertambah dan packet loss terjadi beruntun, serta rekomendasi AQM
RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm IETF
fq_codel: antrean per flow dan AQM menjaga antrean tetap pendek sehingga bufferbloat berkurang
RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP IETF
ECN: memberi tahu adanya kongesti dengan tanda di header IP tanpa membuang paket
Smart Queue Management Bufferbloat.net
SQM: cara yang menggabungkan penjadwalan per flow, pengelolaan panjang antrean (AQM), dan shaping
Cake Bufferbloat.net
CAKE: SQM untuk router yang menggabungkan shaper dan pengelolaan antrean ala fq_codel
net/ipv4/proc.c Linux kernel
TcpRetransSegs dan TcpOutSegs yang ditampilkan nstat (RetransSegs dan OutSegs pada bagian Tcp)
nstat(8) — Linux manual page iproute2
Secara default, nstat menampilkan kenaikan sejak eksekusi sebelumnya
RFC 2863: The Interfaces Group MIB IETF
ifOutDiscards: jumlah paket keluar yang dibuang tanpa dikirim walaupun tidak ada error, misalnya untuk mengosongkan ruang buffer
An Internet-Wide Analysis of Traffic Policing Google
Pembedaan: pada antrean yang meluap, waktu antre dan RTT naik lebih dulu sebelum packet loss, sedangkan policing membuang kelebihan trafik tanpa kenaikan RTT (SIGCOMM 2016)

Buffer dangkal meluap akibat burst pengiriman Sender bursts overflow shallow buffers

ID rt-burst · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur)

Jika setiap tick server mengirim update untuk ribuan pemain sekaligus dalam sekejap, buffer kecil di switch atau batas sesaat di cloud meluap dalam waktu kurang dari 1 ms dan sebagian paket dibuang.

Mengapa Paket untuk semua pemain dikirim sekaligus tepat saat tick dimulai → Akibatnya Buffer port switch tempat trafik banyak server berkumpul (ratusan KB hingga beberapa MB per port) atau batas instance cloud meluap sesaat (utilisasi rata-rata tetap rendah) → Di layar Banyak pemain teleport atau tersendat sesaat secara bersamaan, penyebabnya tidak terlihat dari metrik rata-rata

Gejala: Teleport, Freeze, Fast forward
Faktor: Packet loss
Siapa yang mengalami: Lokasi/channel tertentu, Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur)
Tugas Tim Pengembang Game: Sebar pengiriman satu tick di sepanjang durasi tick (lonjakan ribuan koneksi di awal tick sulit diatasi dengan pacing per koneksi), sebar waktu mulai tick antarserver, batasi kecepatan koneksi yang mengirim data besar dengan SO_MAX_PACING_RATE.
Tugas Tim Infrastruktur: Server/OS: batasi laju kirim total server (shaper di OS server, tc di Linux), ratakan burst dari satu koneksi dengan pacing (qdisc fq di Linux, BBR). Jaringan: pakai switch dengan buffer besar, periksa counter drop output port switch dengan interval pendek (tidak terlihat dari utilisasi rata-rata).
Kisaran angka: Port 10 Gbps bisa mengirim sekitar 1,25 MB dalam 1 ms. Jika tick dari beberapa server bertepatan dan trafiknya terkumpul di satu port, buffer penuh dalam sekejap.
Di grafik: Naik mengikuti beban · Jumlah drop output port switch, tingkat retransmisi
Yang diperiksa: Kumpulkan drop output (ifOutDiscards) di port switch tempat server terhubung dan port di atasnya setiap beberapa detik; di cloud, periksa bw_out_allowance_exceeded dan pps_allowance_exceeded di ethtool -S. Kumpulkan retransmisi pada saat yang sama dengan bcc tcpretrans, lalu cocokkan
Cocok jika: Utilisasi rata-rata per menit rendah, tetapi drop output atau allowance yang terlampaui bertambah, dan jumlahnya membesar mengikuti CCU dan jumlah pemain yang berkumpul di satu tempat. Retransmisi tidak terpusat pada rentang IP pemain tertentu (ISP atau wilayah) dan muncul di banyak koneksi server itu pada saat yang sama
Tidak cocok jika: Error CRC dan error input di port yang sama ikut naik: lebih mungkin “Error fisik”. Counter drop NIC atau softnet dropped di server penerima naik: lebih mungkin “Paket dibuang di host server penerima”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Pacing bekerja per koneksi. Lonjakan saat ribuan koneksi masing-masing mengirim satu atau dua paket di awal tick sulit diatasi dengan pacing per koneksi, sehingga server game sendiri harus menyebar waktu pengirimannya. Sebaliknya, saat satu koneksi mengirim data besar, NIC memotong data puluhan KB menjadi seukuran paket lalu mengirimnya beruntun (TSO), dan burst seperti ini bisa diratakan dengan baik oleh pacing.

7 sumber

High-Resolution Measurement of Data Center Microbursts Meta
Lebih dari 70% burst di switch rak data center selesai dalam puluhan µs, dan hubungan antara utilisasi rata-rata per menit dan drop lemah (IMC 2017)
tc-fq(8) — Linux manual page iproute2
Qdisc fq melakukan pacing per socket (koneksi), dan SO_MAX_PACING_RATE menentukan kecepatan maksimum per koneksi
net/ipv4/tcp_bbr.c Linux kernel
BBR menentukan pacing_rate dari estimasi bandwidth bottleneck
IP Sysctl Linux kernel
TCP menentukan ukuran frame TSO sesuai laju flow (maksimal 64 KB, tcp_min_tso_segs)
Monitor network performance for ENA settings on your EC2 instance AWS
bw_out_allowance_exceeded, pps_allowance_exceeded: jumlah paket yang dimasukkan ke antrean atau dibuang karena instance melewati batas bandwidth atau batas paket per detik
RFC 2863: The Interfaces Group MIB IETF
ifOutDiscards: jumlah paket keluar yang dibuang tanpa dikirim walaupun tidak ada error, misalnya untuk mengosongkan ruang buffer
Demonstrations of tcpretrans, the Linux eBPF/bcc version IO Visor
Menampilkan satu baris untuk setiap retransmisi, berisi alamat dan port lawan serta status koneksi

Policer membuang trafik berlebih Traffic policing

ID rt-policer · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)

Batas kecepatan langganan ISP, batas instance cloud, dan perangkat proteksi DDoS kadang langsung membuang paket yang melewati kecepatan yang ditetapkan tanpa memasukkannya ke antrean.

Mengapa Volume kirim sesaat melewati kecepatan atau burst yang diizinkan → Akibatnya Paket yang melewati batas langsung dibuang tanpa antrean (policing) → Di layar Setiap ada burst besar, beberapa paket hilang sehingga terjadi freeze lalu fast forward, padahal kecepatan rata-rata terlihat di bawah batas

Gejala: Freeze, Fast forward, Teleport
Faktor: Packet loss
Siapa yang mengalami: Seluruh server, Wilayah/ISP tertentu, Hanya saya
Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Sebar volume yang dikirim sekaligus setiap tick di sepanjang durasi tick agar volume kirim sesaat berada di bawah burst yang diizinkan, gabungkan pesan satu tick ke dalam satu paket jika terbentur batas paket per detik.
Tugas Tim Infrastruktur: Jaringan: periksa counter pelampauan policer di perangkat, ganti policer dengan shaper, perbesar burst yang diizinkan. Server/OS: periksa metrik batas cloud yang terlampaui (di AWS, bw_out_allowance_exceeded dan pps_allowance_exceeded di ethtool -S), naikkan tipe instance, lakukan pacing di server (qdisc fq di Linux).
Kisaran angka: Shaper (memasukkan paket ke antrean dan menundanya) menambah latensi, sedangkan policer (langsung membuang) menambah packet loss. Koneksi game TCP bisa berhenti ratusan ms karena satu kali packet loss, jadi jika trafik hanya sesaat melewati batas, biasanya dampak policer lebih besar.
Di grafik: Mendatar di batas · Volume kirim pada interval pendek, counter pelampauan policer dan allowance
Yang diperiksa: Periksa counter pelampauan (exceed) dan drop di perangkat yang menjalankan policer; di cloud, periksa bw_out_allowance_exceeded dan pps_allowance_exceeded di ethtool -S. Untuk koneksi yang mengalami packet loss, periksa RTT tepat sebelum packet loss lewat rtt di ss -ti atau packet capture
Cocok jika: Counter pelampauan naik, dan volume kirim pada interval pendek mendatar seperti terpotong di nilai tertentu. RTT tidak naik sebelum packet loss, dan beberapa paket hilang sekaligus hanya saat burst besar
Tidak cocok jika: RTT naik lebih dulu sebelum packet loss: lebih mungkin antrean meluap (“Antrean bottleneck meluap”, “Buffer dangkal meluap akibat burst pengiriman”). Counter pelampauan tidak berubah: penyebab lain
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

5 sumber

RFC 2475: An Architecture for Differentiated Services IETF
Definisi: shaping menunda paket agar sesuai profil trafik, sedangkan policing membuang paket yang melewati profil
An Internet-Wide Analysis of Traffic Policing Google
Transfer yang terkena policing rata-rata mengalami packet loss 6 kali lebih tinggi, dan tujuan yang sama bisa dicapai dengan pacing atau shaping. Pembedaan: policing membuang kelebihan trafik tanpa kenaikan RTT, sedangkan pada antrean yang meluap RTT naik sebelum packet loss (SIGCOMM 2016)
Monitor network performance for ENA settings on your EC2 instance AWS
bw_out_allowance_exceeded, pps_allowance_exceeded di ethtool -S: jumlah paket yang dimasukkan ke antrean atau dibuang karena melewati batas instance
tc-fq(8) — Linux manual page iproute2
Pacing per koneksi pada qdisc fq di Linux
ss(8) — Linux manual page iproute2
rtt (rata-rata round-trip time) di ss -i

Error fisik (kabel, modul optik, atau konektor rusak) Bit errors: bad cable, optics, dirty fiber

ID rt-physical · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pihak Eksternal (Pihak Eksternal)

Kabel yang rusak, konektor serat optik yang kotor, dan modul optik yang sudah habis umur pakainya menimbulkan bit error, dan paket yang rusak dibuang diam-diam oleh perangkat.

Mengapa Bit terbalik akibat kabel, modul optik, atau konektor yang rusak → Akibatnya Perangkat membuang paket yang checksum (CRC)-nya tidak cocok → Di layar Hanya pemain yang melewati jalur itu yang terus-menerus tersendat sesaat lalu mengalami fast forward, di jam berapa pun

Gejala: Freeze, Fast forward, Teleport
Faktor: Packet loss
Siapa yang mengalami: Lokasi/channel tertentu, Satu rumah
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pihak Eksternal (Pihak Eksternal)
Tugas Tim Infrastruktur: Error CRC menumpuk di sisi penerima pada arah yang rusak, jadi periksa kedua ujung. Jaringan: periksa counter error CRC dan error input di port perangkat, periksa kekuatan sinyal optik (informasi modul optik di switch), bersihkan konektor serat optik, ganti kabel dan modul optik. Server/OS: periksa rx_crc_errors di ethtool -S server (namanya sedikit berbeda tiap driver), periksa kekuatan sinyal optik (ethtool -m), ganti kabel atau NIC di sisi server.
Tugas Pihak Eksternal: Jika masalahnya di rumah pemain, imbau pemain untuk mengganti kabel LAN atau router; jika di jalur ISP, minta ISP memeriksa jalurnya.
Kisaran angka: Packet loss 0,1% pun berarti satu dari 1.000 paket game. Jika puluhan pemain melewati jalur itu, setiap beberapa detik ada saja yang tersendat sesaat. Makin besar paketnya, makin mudah terkena bit error.
Di grafik: Hanya sebagian yang tinggi · Jumlah error CRC per port, tingkat retransmisi per server dan per port
Yang diperiksa: Periksa counter CRC di kedua ujung link: di server, rx_crc_errors di ethtool -S atau crc di ip -s -s link; di switch, error FCS (dot3StatsFCSErrors) dan error input (ifInErrors) pada port. Untuk link optik, periksa kekuatan sinyal optik yang diterima dengan ethtool -m dan informasi modul optik di switch
Cocok jika: Error CRC pada satu port terus naik di jam berapa pun, dan hanya server dan koneksi yang melewati port itu yang tingkat retransmisinya tinggi. Kekuatan sinyal optik yang diterima lebih rendah daripada link lain yang sejenis
Tidak cocok jika: CRC tidak berubah, hanya drop output yang naik: lebih mungkin antrean meluap (“Buffer dangkal meluap akibat burst pengiriman”, “Antrean bottleneck meluap”). Late collision di satu sisi dan error CRC di sisi lain naik bersamaan: lebih mungkin “Duplex mismatch”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

3 sumber

Interface statistics Linux kernel
rx_crc_errors adalah jumlah paket yang dihitung interface penerima sebagai error CRC; periksa dengan ip -s -s link dan ethtool -S
ethtool(8) — Linux manual page ethtool
-S untuk statistik per NIC dan driver, -m untuk EEPROM modul optik (SFP+, QSFP) dan informasi diagnostik optik
RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
Error FCS pada port switch (dot3StatsFCSErrors); error ini ikut dijumlahkan ke error input (ifInErrors)

Duplex mismatch Duplex mismatch

ID rt-duplex · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika satu sisi memakai autonegotiation sedangkan sisi lain mengunci kecepatan dan duplex, salah satu sisi berjalan dalam mode half duplex, dan paket hilang akibat collision setiap kali beban naik.

Mengapa Kecepatan dan duplex dikunci hanya di salah satu perangkat → Akibatnya Satu sisi berjalan full duplex, sisi lain half duplex, sehingga terjadi collision dan late collision → Di layar Biasanya normal, tetapi saat trafik naik, semua pemain yang melewati perangkat itu mengalami freeze lalu fast forward

Gejala: Freeze, Fast forward
Faktor: Packet loss
Siapa yang mengalami: Seluruh server, Lokasi/channel tertentu
Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Atur kedua sisi ke autonegotiation, atau kunci kedua sisi ke nilai yang sama. Jaringan: periksa kecepatan dan duplex di status port switch, lalu periksa di counter port apakah late collision bertambah di sisi half duplex, serta error CRC dan frame yang terlalu pendek (runt) bertambah di sisi full duplex. Server/OS: periksa kecepatan dan duplex dengan ethtool.
Kisaran angka: Kabel tembaga 1 Gbps wajib memakai autonegotiation, dan pada 10 Gbps ke atas half duplex sama sekali tidak ada. Karena itu, sekarang masalah ini terutama muncul di perangkat lama 100 Mbps ke bawah, di port manajemen, dan di sebagian titik sambungan sirkuit.
Di grafik: Naik mengikuti beban · Jumlah late collision dan error CRC per port, tingkat retransmisi
Yang diperiksa: Periksa kecepatan dan duplex yang sebenarnya di kedua ujung link: di server, jalankan ethtool hanya dengan nama interface; di switch, lihat status port atau dot3StatsDuplexStatus lewat SNMP. Periksa juga late collision (tx_window_errors di server, dot3StatsLateCollisions di switch) dan error CRC
Cocok jika: Satu sisi menunjukkan half duplex, sisi lain full duplex. Setiap kali trafik naik, late collision di sisi half duplex dan error CRC di sisi full duplex naik bersamaan
Tidak cocok jika: Kecepatan dan duplex di kedua sisi sama, hanya CRC yang naik: lebih mungkin “Error fisik”. Link 10 Gbps ke atas tidak punya half duplex, jadi coret penyebab ini untuk link tersebut
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

6 sumber

Linux Base Driver for Intel(R) Ethernet Network Connection Linux kernel
Standar 1000BASE-T mewajibkan autonegotiation
IEEE 802.3ae 10 Gigabit Ethernet: HSSG Objectives IEEE
10 Gigabit Ethernet hanya mendukung full duplex
IEEE P802.3ba Objectives IEEE
40 dan 100 Gigabit Ethernet juga hanya mendukung full duplex
Interface statistics Linux kernel
tx_window_errors adalah jumlah pengiriman yang gagal akibat late collision, rx_crc_errors adalah jumlah paket yang diterima dengan error CRC
ethtool(8) — Linux manual page ethtool
ethtool -s mengatur kecepatan, duplex, dan autonegotiation lewat speed, duplex, dan autoneg; jika hanya diberi nama interface, ethtool menampilkan pengaturan saat ini
RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
dot3StatsDuplexStatus (menampilkan duplex saat ini sebagai halfDuplex atau fullDuplex), dot3StatsLateCollisions (jumlah late collision)

Paket dibuang di host server penerima Receiver host drops (ring, softirq, CPU)

ID rt-host-drop · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Paket sudah sampai di server, tetapi dibuang karena ring buffer NIC (buffer yang menampung sementara paket yang tiba) meluap atau core yang menangani pemrosesan terima di kernel jenuh.

Mengapa Lonjakan jumlah pemain, interrupt yang terpusat di satu core, CPU steal di virtual machine, atau virtual switch yang kelebihan beban → Akibatnya Paket dibuang di ring buffer (rx_missed_errors dan sejenisnya, namanya berbeda tiap driver) atau di antrean terima kernel (softnet dropped) → Di layar Saat pemain berkumpul, input terlambat diproses dan game tersendat sesaat di seluruh server secara bersamaan

Gejala: Input lag, Freeze, Fast forward, Teleport
Faktor: Packet loss, Stall
Siapa yang mengalami: Seluruh server
Kapan: Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Tambahkan counter drop seperti rx_missed_errors di ethtool -S dan dropped di /proc/net/softnet_stat ke monitoring, perbesar ring buffer (ethtool -G), sebar RSS dan interrupt ke beberapa core, pisahkan core thread game dari core pemrosesan terima, sisakan kapasitas CPU, dan di virtual machine periksa CPU steal serta beban virtual switch.
Kisaran angka: Paket yang dibuang server saat diterima akan dikirim ulang oleh klien. Karena itu, kejadian ini jarang tertangkap di metrik retransmisi server dan lebih dulu muncul di counter drop seperti rx_missed_errors di ethtool -S (namanya berbeda tiap driver) dan di dropped pada /proc/net/softnet_stat.
Di grafik: Mendatar di batas · Utilisasi softirq per core, counter drop NIC
Yang diperiksa: Periksa counter drop di ethtool -S (rx_missed_errors dan sejenisnya; di mlx5, rx_out_of_buffer dan rx_discards_phy), missed di ip -s -s link, serta kolom ke-2 (dropped) dan kolom ke-3 (time_squeeze) di /proc/net/softnet_stat, lalu periksa %soft (pemrosesan software interrupt) per core dengan mpstat -P ALL. Di virtual machine, periksa juga %steal
Cocok jika: Saat pemain berkumpul, counter drop atau softnet dropped naik, dan %soft pada core yang menangani pemrosesan terima tertahan di dekat 100% dan tidak bisa naik lagi. Input melambat di semua koneksi server itu pada saat yang sama
Tidak cocok jika: Counter drop server tidak berubah dan retransmisi terpusat pada koneksi dari wilayah atau ISP tertentu: packet loss di rute. Jika paket yang dikirim server hilang di rute, TcpRetransSegs di nstat server naik, sedangkan counter di atas tidak berubah
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

10 sumber

Interface statistics Linux kernel
rx_missed_errors adalah jumlah paket yang tidak bisa diterima host karena tidak ada buffer (di /proc/net/dev dijumlahkan ke drop); periksa dengan ip -s -s link
drivers/net/ethernet/intel/igb/igb_ethtool.c Linux kernel
Nama counter di ethtool -S ditentukan oleh driver (misalnya rx_missed_errors dan rx_no_buffer_count pada igb)
Ethtool counters Linux kernel
rx_out_of_buffer (tidak ada buffer di antrean terima) dan rx_discards_phy (dibuang karena buffer port kurang) pada driver mlx5
net/core/net-procfs.c Linux kernel
/proc/net/softnet_stat berisi satu baris per CPU dalam heksadesimal; kolom ke-2 adalah dropped, kolom ke-3 adalah time_squeeze
Documentation for /proc/sys/net/ Linux kernel
netdev_max_backlog: batas antrean terima yang menampung paket saat paket datang lebih cepat daripada kemampuan kernel memprosesnya
Scaling in the Linux Networking Stack Linux kernel
RSS: NIC membagi trafik ke beberapa antrean terima yang diproses oleh beberapa CPU
ethtool(8) — Linux manual page ethtool
-G (--set-ring) mengubah ukuran ring buffer
proc_stat(5) — Linux manual page Linux man-pages
steal di /proc/stat: waktu CPU dipakai OS lain di lingkungan virtualisasi
mpstat(1) — Linux manual page sysstat
mpstat -P ALL menampilkan utilisasi per core; %soft adalah waktu pemrosesan software interrupt, %steal adalah waktu menunggu selama hypervisor melayani CPU virtual lain
net/ipv4/proc.c Linux kernel
TcpRetransSegs yang ditampilkan nstat (RetransSegs pada bagian Tcp)

Paket dibuang oleh firewall atau connection tracking Stateful firewall / conntrack drops

ID rt-stateful-fw · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)

Firewall dan connection tracking Linux (conntrack, fitur yang mencatat koneksi yang lewat ke dalam tabel) membuang paket jika tabelnya penuh atau jika paket dianggap tidak sesuai dengan status koneksi.

Mengapa Tabel connection tracking penuh (table full), atau rute pergi dan pulang berbeda sehingga hanya satu arah yang melewati firewall (rute asimetris) → Akibatnya Firewall menganggap paket itu milik “koneksi yang tidak dikenal” atau membawa “nomor urut di luar rentang window”, lalu membuangnya → Di layar Jika tabel penuh, koneksi baru terblokir; jika rutenya asimetris, hanya pemain di rute itu yang disconnect setelah retransmisi berulang

Gejala: Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss
Siapa yang mengalami: Seluruh server, Wilayah/ISP tertentu
Kapan: Saat banyak pemain berkumpul, Tepat setelah login atau maintenance, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: antisipasi tabel penuh dengan mengatur lonjakan koneksi lewat sistem antrean login, pakai ulang koneksi agar tidak terus membuka koneksi singkat (termasuk pemanggilan antarserver), tutup lebih dulu koneksi yang heartbeat-nya berhenti. Klien: jika koneksi gagal atau terputus, coba lagi dengan interval yang makin panjang dan disebar secara acak (agar pemain tidak menyerbu kembali bersamaan saat tabel penuh).
Tugas Tim Infrastruktur: Jaringan: perbesar tabel connection tracking di firewall, keluarkan port game dari connection tracking, samakan routing agar rute pergi dan pulang melewati firewall yang sama, periksa pengaturan pemeriksaan window TCP di firewall. Server/OS: perbesar tabel di Linux (nf_conntrack_max), keluarkan port game dari connection tracking (NOTRACK), periksa pengaturan pemeriksaan window TCP (nf_conntrack_tcp_be_liberal), di AWS periksa juga conntrack_allowance_exceeded.
Kisaran angka: Batas default conntrack Linux (nf_conntrack_max) berkisar puluhan ribu hingga ratusan ribu entri tergantung memori. Jika jumlah saat ini (nf_conntrack_count) mencapai batas, log mencatat “nf_conntrack: table full, dropping packet”.
Di grafik: Mendatar di batas · Jumlah entri conntrack (nf_conntrack_count), jumlah koneksi baru yang gagal
Yang diperiksa: Di server Linux, periksa nf_conntrack_count dan nf_conntrack_max, “nf_conntrack: table full, dropping packet” di dmesg, serta drop dan invalid di /proc/net/stat/nf_conntrack (satu baris per core, heksadesimal). Di firewall, periksa pemakaian tabel sesi dan log drop; di AWS, periksa conntrack_allowance_exceeded di ethtool -S
Cocok jika: Jumlah entri mendatar di batas, dan pada saat yang sama log table full dan drop, atau conntrack_allowance_exceeded, naik. Pada rute asimetris, tabel masih punya ruang, tetapi invalid dan log drop firewall naik pada koneksi di rute tertentu
Tidak cocok jika: Jumlah entri jauh dari batas, invalid dan log drop juga tidak berubah: penyebab lain. Tabel masih punya ruang, tetapi CPU atau paket per detik firewall sudah penuh: lebih mungkin “Batas pemrosesan perangkat perantara terlampaui”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

5 sumber

Netfilter Conntrack Sysfs variables Linux kernel
Nilai default nf_conntrack_max adalah jumlah hash bucket (memori ÷ 16384, 1.024–262.144), jumlah saat ini ada di nf_conntrack_count, dan nf_conntrack_tcp_be_liberal hanya menandai RST di luar window sebagai INVALID
net/netfilter/nf_conntrack_core.c Linux kernel
Jika tabel penuh, kernel mencatat log “nf_conntrack: table full, dropping packet” dan membuang paket (statistik drop naik); paket yang tidak sesuai dengan status koneksi menaikkan statistik invalid
iptables-extensions(8) — Linux manual page netfilter
CT --notrack di tabel raw mengecualikan trafik dari connection tracking
Amazon EC2 security group connection tracking AWS
Jika jumlah koneksi yang dilacak melewati batas per instance, paket dibuang dan kejadiannya terlihat di conntrack_allowance_exceeded; disertai rekomendasi untuk menghindari rute asimetris
net/netfilter/nf_conntrack_standalone.c Linux kernel
/proc/net/stat/nf_conntrack berisi satu baris per core dalam heksadesimal, dengan kolom seperti entries, invalid, insert_failed, drop, dan early_drop

Batas pemrosesan perangkat perantara terlampaui (firewall, IPS, proteksi DDoS) Inline appliance PPS / CPU overload

ID rt-appliance-pps · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Firewall, perangkat pencegah intrusi (IPS), dan perangkat proteksi DDoS memeriksa setiap paket yang lewat. Begitu trafik melampaui kapasitas pemeriksaannya, paket yang tidak sempat diproses dibuang.

Mengapa Lebih dari ratusan ribu paket game kecil per detik datang bersamaan pada jam sibuk atau saat event, atau aturan pemeriksaannya berat → Akibatnya Batas CPU atau paket per detik perangkat penuh sehingga paket dibuang di perangkat. Jika terjadi false positive, paket normal pun diblokir → Di layar Seluruh server di belakang perangkat itu mengalami freeze dan teleport bersamaan, makin parah hanya saat pemain berkumpul

Gejala: Freeze, Fast forward, Teleport, Disconnect
Faktor: Packet loss, Latensi
Siapa yang mengalami: Seluruh server, Wilayah/ISP tertentu
Kapan: Jam sibuk malam hari, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Bagikan pola trafik game (port, ukuran paket, paket per detik) ke Tim Infrastruktur, kumpulkan pesan kecil dalam satu tick lalu kirim sekaligus untuk mengurangi jumlah paket.
Tugas Tim Infrastruktur: Pantau CPU, paket per detik, dan counter drop perangkat bersama metrik game, hitung kapasitas perangkat berdasarkan paket kecil, keluarkan port game dari pemeriksaan berat, sesuaikan aturan proteksi DDoS dengan pola trafik game.
Kisaran angka: Angka “10 Gbps” di spesifikasi perangkat sering ditulis berdasarkan paket besar 1.500 byte. Paket game berukuran sekitar 100 byte, sehingga pada bandwidth yang sama jumlah paketnya lebih dari 10 kali lipat, dan batas paket per detik tercapai lebih dulu walaupun jalurnya terlihat sepi.
Di grafik: Mendatar di batas · Paket per detik dan utilisasi CPU perangkat, jumlah drop perangkat
Yang diperiksa: Periksa CPU, paket per detik, dan counter drop perangkat, lalu bandingkan jumlah paket di port switch sebelum dan sesudah perangkat dengan interval yang sama. Tumpangkan dengan CCU dan tingkat retransmisi server di satu layar
Cocok jika: Saat jam sibuk atau event, paket per detik atau CPU perangkat tertahan di satu nilai dan tidak bisa naik lagi, paket yang keluar dari perangkat lebih sedikit daripada yang masuk, dan pada saat yang sama tingkat retransmisi seluruh server di belakangnya ikut naik
Tidak cocok jika: Jumlah paket sebelum dan sesudah perangkat sama dan tidak ada drop di perangkat: penyebab lain. Counter drop NIC atau softnet dropped di server naik: lebih mungkin “Paket dibuang di host server penerima”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

1 sumber

RFC 2544: Benchmarking Methodology for Network Interconnect Devices IETF
Performa perangkat harus diuji dengan berbagai ukuran frame, termasuk ukuran minimum dan maksimum (performa pemrosesan berubah sesuai ukuran paket)

MTU black hole (hanya paket besar yang berulang kali hilang) PMTU black hole

ID rt-mtu · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)

Jika ukuran maksimum yang bisa dilewati suatu jalur di tengah rute mengecil dan notifikasi “terlalu besar” (ICMP) diblokir, paket besar terus hilang berapa kali pun dikirim ulang.

Mengapa Ukuran maksimum mengecil di segmen VPN atau tunnel, dan notifikasi ukuran terlampaui diblokir firewall → Akibatnya Pengirim terus mengirim ulang paket besar yang sama tanpa tahu sebabnya, dan RTO berlipat dua setiap kali → Di layar Biasanya normal, tetapi saat data besar lewat (inventory, tempat ramai, loading saat masuk), paket kecil di belakangnya pun ikut berhenti, lalu berakhir dengan disconnect atau loading tanpa henti

Gejala: Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss
Siapa yang mengalami: Wilayah/ISP tertentu, Hanya saya
Kapan: Saat melakukan aksi tertentu, Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Untuk menurunkannya langsung dari sisi server, atur ukuran segmen maksimum socket (TCP_MAXSEG); memecah pesan menjadi kecil-kecil di kode game saja tidak mencegah masalah ini (TCP menggabungkan lagi data yang akan dikirim seukuran MSS).
Tugas Tim Infrastruktur: Jaringan: lakukan penyesuaian MSS (clamping) di perangkat tepi jaringan, izinkan ICMP ukuran terlampaui (tipe 3 kode 4, fragmentation needed) di firewall dan network ACL cloud. Server/OS: atur path MTU, pastikan ICMP ukuran terlampaui juga tidak diblokir di firewall server dan security group cloud, aktifkan tcp_mtu_probing=1 di Linux sebagai jaring pengaman terakhir.
Kisaran angka: Biasanya 1.500 byte, dan sekitar 1.400 jika melewati tunnel. Jika paket yang sama dikirim ulang 5–6 kali, jedanya lebih dari 10 detik.
Di grafik: Hanya sebagian yang tinggi · RTO dan backoff per koneksi, jumlah disconnect per wilayah dan ISP
Yang diperiksa: Periksa retransmisi pada koneksi bermasalah dengan packet capture di sisi server atau bcc tcpretrans -s (menampilkan nomor urut), lalu periksa mss, pmtu, dan backoff koneksi itu dengan ss -ti. Dari server, kirim ping kecil dan ping 1.500 byte dengan DF aktif (ping -M do -s 1472) ke alamat pemain itu, lalu bandingkan
Cocok jika: Paket seukuran MSS penuh terus dikirim ulang dengan nomor urut yang sama dan interval yang berlipat dua, sedangkan paket yang lebih kecil lolos. ICMP ukuran terlampaui (filter Wireshark icmp.type == 3 and icmp.code == 4) tidak datang, dan ping kecil dibalas, tetapi ping DF besar hilang tanpa balasan
Tidak cocok jika: Paket kecil juga ikut hilang: packet loss yang tidak terkait ukuran (“Antrean bottleneck meluap”, “Perubahan rute dan jalur ECMP bermasalah”). ICMP ukuran terlampaui datang dan pmtu di ss -ti mengecil: path MTU discovery berjalan dengan benar
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: tcp_mtu_probing=1 baru menganggap ada black hole dan menurunkan MSS ke 1.024 byte setelah timeout retransmisi berlangsung beberapa detik (setara dengan tcp_retries1=3). Selama itu koneksi berhenti, jadi jadikan opsi ini jaring pengaman terakhir dan dahulukan penyesuaian MSS yang mencegah masalah sejak awal.

15 sumber

RFC 1191: Path MTU discovery IETF
Path MTU discovery: paket yang terlalu besar diberitahukan lewat ICMP “fragmentation needed and DF set” (tipe 3 kode 4)
RFC 2923: TCP Problems with Path MTU Discovery IETF
Masalah PMTU black hole, yaitu ICMP diblokir sehingga hanya paket besar yang terus hilang
RFC 4821: Packetization Layer Path MTU Discovery IETF
Cara lapisan transport menemukan ukuran paket tanpa ICMP (dasar tcp_mtu_probing di Linux)
IP Sysctl Linux kernel
tcp_mtu_probing: 0 nonaktif, 1 hanya saat black hole terdeteksi, 2 selalu (MSS awal adalah tcp_base_mss). Default tcp_retries1 adalah 3
net/ipv4/tcp_timer.c Linux kernel
Jika retransmisi RTO berlangsung sebanyak tcp_retries1, kernel menganggapnya sebagai black hole, mengaktifkan MTU probing, dan menurunkan MSS
include/net/tcp.h Linux kernel
TCP_BASE_MSS = 1.024 byte
RFC 6298: Computing TCP's Retransmission Timer IETF
Menggandakan RTO setiap kali timer retransmisi habis
iptables-extensions(8) — Linux manual page netfilter
TCPMSS --clamp-mss-to-pmtu: mengatasi paket besar yang tertahan di segmen yang memblokir ICMP dengan menyesuaikan MSS di SYN
tcp(7) — Linux manual page Linux man-pages
TCP_MAXSEG: ukuran segmen maksimum paket keluar; jika diatur sebelum koneksi dibuat, MSS yang diberitahukan ke pihak lawan juga berubah
Network maximum transmission unit (MTU) for your EC2 instance AWS
Internet gateway dan VPN memakai MTU 1.500; PMTUD membutuhkan ICMP tipe 3 kode 4, yang tidak akan diterima jika diblokir security group atau network ACL
MTU considerations | Cloud VPN Google Cloud
MTU gateway Cloud VPN 1.460 byte, MTU payload tunnel IPv4 1.406 byte (sekitar 1.400 jika melewati tunnel)
Demonstrations of tcpretrans, the Linux eBPF/bcc version IO Visor
Menampilkan satu baris untuk setiap retransmisi, dan -s juga menampilkan nomor urut paket yang dikirim ulang
ss(8) — Linux manual page iproute2
mss, pmtu (path MTU), dan backoff (berapa kali RTO digandakan) di ss -i
ping(8) — Linux manual page iputils
-M do mengaktifkan DF dan tidak mengirim paket yang lebih besar daripada path MTU yang diketahui kernel; -s adalah ukuran data (belum termasuk header ICMP 8 byte)
Display Filter Reference: Internet Control Message Protocol Wireshark
Filter tampilan icmp.type dan icmp.code

Mapping NAT atau load balancer kedaluwarsa di tengah koneksi NAT / load balancer mapping expired mid-connection

ID rt-mapping · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur), Infrastruktur server (Tim Infrastruktur)

Jika perangkat di tengah rute menghapus mapping koneksi idle (entri yang mencatat ke mana koneksi itu diteruskan), paket berikutnya tidak bisa diteruskan. Retransmisi terus berulang sampai pemain disconnect, atau perangkat membalas dengan penolakan koneksi (RST) sehingga pemain langsung disconnect.

Mengapa Koneksi yang tidak dilewati paket selama beberapa waktu (AFK, di lobi) → Akibatnya NAT di router, CGNAT ISP, firewall, load balancer, atau security group cloud menghapus mapping yang idle → Di layar Begitu pemain bergerak lagi, retransmisi berlanjut hingga disconnect, atau langsung disconnect

Gejala: Disconnect, Freeze
Faktor: Packet loss
Siapa yang mengalami: Hanya saya, Wilayah/ISP tertentu
Kapan: Setelah lama diam
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur), Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek (mapping di router pemain dan CGNAT ISP hanya diperbarui dengan pasti oleh paket keluar, dan timeout-nya tidak bisa kami ubah, jadi klien yang mengirim), reconnect otomatis jika terputus. Server: balas heartbeat dan putuskan koneksi lebih dulu jika tidak ada heartbeat dalam waktu tertentu (perpendek interval keepalive TCP dengan opsi socket seperti TCP_KEEPIDLE, deteksi cepat dengan TCP_USER_TIMEOUT), lanjutkan sesi dengan token sesi.
Tugas Tim Infrastruktur: Jaringan: kumpulkan idle timeout firewall dan load balancer di sepanjang rute lalu bagikan ke Tim Pengembang Game, perpanjang idle timeout di firewall dan load balancer kami jika perlu. Server/OS: periksa waktu connection tracking di security group cloud lalu bagikan ke Tim Pengembang Game.
Kisaran angka: Lama mapping TCP dipertahankan berbeda-beda tiap perangkat, dari beberapa menit hingga beberapa jam. Jika security group cloud diatur untuk melacak koneksi, tipe instance AWS Nitro v6 secara default menghapus entri pelacakannya setelah 350 detik (tipe lain setelah 5 hari, lihat entri “Connection tracking di security group cloud kedaluwarsa”). Nilai default keepalive TCP di Linux adalah “periksa setelah idle 2 jam”, lebih lambat daripada kebanyakan perangkat.
Di grafik: Koneksi putus serentak · Jumlah disconnect, waktu idle sebelum terputus
Yang diperiksa: Periksa beberapa menit terakhir koneksi yang terputus lewat packet capture di sisi server; untuk koneksi yang masih hidup, periksa waktu idle dari lastsnd dan lastrcv di ss -ti (ms sejak terakhir mengirim dan menerima). Periksa juga TcpExtTCPAbortOnTimeout di nstat (jumlah koneksi yang dilepas karena timer habis)
Cocok jika: Setiap koneksi yang terputus sebelumnya idle melewati nilai yang mirip (idle timeout perangkat di rute, misalnya 350 detik untuk security group instance AWS Nitro v6), dan sejak paket pertama setelah idle hanya ada retransmisi tanpa ACK sampai koneksi menyerah, atau RST langsung datang
Tidak cocok jika: Terputus juga di tengah permainan tanpa terkait waktu idle: penyebab lain (“Perubahan rute dan jalur ECMP bermasalah”, “Paket dibuang oleh firewall atau connection tracking”). Koneksi yang bertukar heartbeat dengan interval maksimal setengah dari idle timeout terpendek: coret penyebab ini
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

8 sumber

RFC 5382: NAT Behavioral Requirements for TCP IETF
Rekomendasi bahwa idle timeout koneksi TCP di NAT minimal 2 jam 4 menit (dengan asumsi perangkat bisa menghapus sesi idle lebih awal)
RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP IETF
Mapping NAT harus diperbarui oleh paket keluar (REQ-6), sedangkan pembaruan oleh paket masuk bersifat opsional (untuk UDP)
Amazon EC2 security group connection tracking AWS
Nilai default timeout pelacakan TCP idle adalah 350 detik untuk tipe instance Nitro v6 dan 432.000 detik (5 hari) untuk tipe lain; disarankan keepalive dengan interval kurang dari 5 menit
IP Sysctl Linux kernel
Default tcp_keepalive_time 2 jam
tcp(7) — Linux manual page Linux man-pages
TCP_KEEPIDLE (waktu idle sebelum keepalive dimulai), TCP_USER_TIMEOUT (lama menunggu data yang belum dikonfirmasi sebelum koneksi ditutup)
RFC 5482: TCP User Timeout Option IETF
TCP user timeout: berapa lama data yang dikirim boleh belum dikonfirmasi sebelum koneksi ditutup
ss(8) — Linux manual page iproute2
lastsnd dan lastrcv di ss -i: waktu sejak terakhir mengirim dan menerima (ms)
SNMP counter Linux kernel
TcpExtTCPAbortOnTimeout: jumlah koneksi yang dilepas tanpa RST karena timer TCP habis

Perubahan rute dan jalur ECMP bermasalah Route change / bad ECMP member

ID rt-path · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)

Paket hilang selama beberapa detik saat rute internet berubah, atau terus-menerus pada koneksi yang ditempatkan di jalur bermasalah di antara beberapa jalur ECMP.

Mengapa Perhitungan ulang rute BGP, atau perangkat atau jalur yang rusak di salah satu dari beberapa jalur (ECMP, LAG) → Akibatnya Packet loss sementara selama rute beralih, atau packet loss terus-menerus hanya pada koneksi yang melewati jalur itu → Di layar Tiba-tiba freeze beberapa detik lalu fast forward, atau “membaik setelah reconnect” (ditempatkan di jalur lain)

Gejala: Freeze, Fast forward, Teleport
Faktor: Packet loss
Siapa yang mengalami: Wilayah/ISP tertentu
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)
Tugas Tim Pengembang Game: Catat statistik retransmisi per koneksi (TCP_INFO) agar IP, port, dan waktu pemain yang terdampak bisa diambil, jangan langsung memutus koneksi yang berhenti beberapa detik.
Tugas Tim Infrastruktur: Pantau tingkat retransmisi per wilayah dan ISP, periksa apakah rute berubah setelah reconnect, sediakan jalur dari beberapa ISP, periksa link yang rusak di jalur ECMP dan LAG perangkat kami, ukur rute dengan port TCP yang sama dengan game (mtr --tcp --port. Rute ditentukan oleh alamat dan port, jadi ping biasa bisa lewat jalur lain dan hasilnya terlihat normal).
Tugas Pihak Eksternal: Laporkan jalur bermasalah ke ISP dengan melampirkan hasil pengukuran rute pada port TCP yang sama serta perbandingan sebelum dan sesudah reconnect.
Di grafik: Naik seperti anak tangga · RTT (ping), tingkat retransmisi per wilayah dan ISP
Yang diperiksa: Kumpulkan retransmisi per koneksi dengan bcc tcpretrans -c untuk mengambil alamat dan port pemain yang terdampak, lalu jalankan mtr dengan port TCP yang sama dengan game (mtr -T -P PORT) dari server ke arah pemain dan dari pemain ke arah server, lalu bandingkan. Bandingkan juga hasil sebelum dan sesudah reconnect
Cocok jika: Sejak waktu tertentu, RTT satu wilayah atau ISP berubah seperti anak tangga dan packet loss menumpuk selama beberapa detik, atau di dalam ISP yang sama hanya sebagian koneksi (kombinasi alamat dan port) yang terus mengirim ulang dan membaik setelah reconnect. Kadang ping biasa terlihat normal, tetapi packet loss hanya terlihat di mtr TCP
Tidak cocok jika: Semua koneksi di ISP itu memburuk bersamaan pada jam sibuk malam: lebih mungkin “Antrean bottleneck meluap”. Hanya satu pemain yang terdampak dan packet loss sudah muncul sejak ping ke router: lebih mungkin “Packet loss di jalur nirkabel”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Kasus nyata: Cloudflare 2020: Trafik hilang di sebagian kota akibat kesalahan konfigurasi backbone Cloudflare

5 sumber

RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
Hasil tools diagnosis seperti ping dan traceroute sulit dipercaya di jaringan multipath; menjelaskan cara mengunci rute setiap flow dengan hash
RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
ECMP memilih jalur berikutnya dari hash field header yang mengidentifikasi flow (flow yang sama melewati jalur yang sama)
tcp(7) — Linux manual page Linux man-pages
TCP_INFO: membaca status per socket (struct tcp_info)
mtr(8) manual page source mtr
-T (--tcp) memakai TCP SYN sebagai pengganti ICMP, -P (--port) menentukan port tujuan
Demonstrations of tcpretrans, the Linux eBPF/bcc version IO Visor
Menampilkan satu baris untuk setiap retransmisi berisi alamat dan port lawan; -c menghitung jumlah retransmisi per flow

Retransmisi yang tidak perlu akibat lonjakan latensi Spurious RTO from delay spikes

ID rt-spurious-delay · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)

Paket sebenarnya tidak hilang dan hanya sesaat datang sangat terlambat, tetapi jika keterlambatan itu lebih lama dari RTO, pengirim menganggap paket hilang lalu mengirimnya ulang.

Mengapa Bufferbloat, mode hemat daya Wi-Fi, transisi state radio seluler, atau virtual machine yang dijeda sesaat menimbulkan keterlambatan sesaat ratusan ms → Akibatnya RTO habis lebih dulu sehingga paket dikirim ulang, lalu paket aslinya pun segera tiba (penerima menerima duplikat) → Di layar Freeze dan fast forward disebabkan oleh lonjakan latensi itu sendiri. Retransmisi yang tidak perlu hampir tidak menambah lama freeze, tetapi menaikkan metrik retransmisi sehingga disangka packet loss

Gejala: Freeze, Fast forward, Input lag
Faktor: Latensi, Jitter
Siapa yang mengalami: Hanya saya, Seluruh server
Kapan: Sesekali secara acak, Setelah lama diam
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Di klien Android 10 ke atas, minta mode Wi-Fi latensi rendah selama bermain (Wi-Fi lock WIFI_MODE_FULL_LOW_LATENCY, hanya berlaku saat layar menyala dan game berada di latar depan) untuk mengurangi lonjakan latensi akibat mode hemat daya.
Tugas Tim Infrastruktur: Hindari instance tipe burstable, jangan menurunkan nilai minimum RTO terlalu rendah, pertahankan F-RTO dan timestamp (tcp_frto, tcp_timestamps), baca metrik retransmisi bersama TCPSpuriousRTOs dan TCPDSACKRecv di nstat agar tidak disangka packet loss.
Tugas Pihak Eksternal: Imbau pemain untuk memakai SQM di router dan mematikan mode hemat daya Wi-Fi agar lonjakan latensinya sendiri berkurang.
Kisaran angka: Linux bisa mendeteksi RTO yang tidak perlu dengan F-RTO dan membatalkan penurunan laju kirim. Periksa dengan TCPSpuriousRTOs di nstat (berapa kali RTO dinilai tidak perlu) dan TCPDSACKRecv (berapa kali penerima memberi tahu “sudah pernah diterima”).
Di grafik: Melonjak acak sesekali · RTT (ping), jumlah RTO yang tidak perlu
Yang diperiksa: Jalankan nstat setiap 1 menit dan periksa kenaikan TcpExtTCPTimeouts (RTO habis), TcpExtTCPSpuriousRTOs, TcpExtTCPDSACKRecv, dan TcpExtTCPLostRetransmit secara bersamaan. Jika ada packet capture, pakai filter Wireshark tcp.analysis.spurious_retransmission
Cocok jika: Saat RTO bertambah, TcpExtTCPSpuriousRTOs atau TcpExtTCPDSACKRecv ikut naik, dan pada saat yang sama RTT melonjak ke ratusan ms. Di capture sisi penerima, paket asli dan paket retransmisi sama-sama tiba
Tidak cocok jika: TcpExtTCPSpuriousRTOs dan DSACK tidak berubah, tetapi TcpExtTCPLostRetransmit (paket yang dikirim ulang pun hilang lagi) naik: packet loss sungguhan. RTT tidak melonjak, tetapi DSACK terus banyak: lebih mungkin “Fast retransmit yang tidak perlu akibat urutan paket tertukar”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

11 sumber

RFC 5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP IETF
F-RTO: memakai ACK yang datang setelah RTO untuk menentukan apakah RTO itu tidak perlu
RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks IETF
Lonjakan latensi di jaringan seluler (handover, pemulihan di lapisan link, dan lainnya) menimbulkan timeout dan retransmisi TCP yang tidak perlu serta mengecilkan congestion window
RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP IETF
DSACK: penerima memberi tahu adanya duplikat sehingga pengirim tahu retransmisinya tidak perlu
SNMP counter Linux kernel
TcpExtTCPSpuriousRTOs (RTO tidak perlu yang dideteksi F-RTO), TcpExtTCPDSACKRecv (jumlah DSACK yang diterima), TcpExtTCPLostRetransmit (jumlah laporan SACK bahwa paket yang dikirim ulang hilang lagi)
IP Sysctl Linux kernel
tcp_frto aktif secara default (menguntungkan di jaringan nirkabel yang RTT-nya naik turun), default tcp_timestamps 1
RFC 6298: Computing TCP's Retransmission Timer IETF
Dasar bahwa RTO minimum yang besar diperlukan untuk mencegah retransmisi yang tidak perlu (rekomendasi minimal 1 detik)
WifiManager Android (Google)
WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): Wi-Fi lock latensi rendah yang hanya berlaku saat terhubung ke AP, layar menyala, dan aplikasi berada di latar depan
net/ipv4/proc.c Linux kernel
Nama counter yang ditampilkan nstat: TCPTimeouts, TCPSpuriousRTOs, TCPDSACKRecv, TCPLostRetransmit
net/ipv4/tcp_timer.c Linux kernel
TCPTimeouts naik saat timer retransmisi (RTO) habis
nstat(8) — Linux manual page iproute2
Secara default, nstat menampilkan kenaikan sejak eksekusi sebelumnya
Display Filter Reference: Transmission Control Protocol Wireshark
Filter tampilan tcp.analysis.spurious_retransmission

Fast retransmit yang tidak perlu akibat urutan paket tertukar Reordering triggers spurious fast retransmit

ID rt-reorder · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika urutan paket berubah saat melewati beberapa jalur atau link yang digabung, penerima memberi tahu “ada paket yang hilang” lewat duplicate ACK, dan pengirim mengirim ulang paket yang sebenarnya sudah sampai dengan baik.

Mengapa Perangkat yang membagi rute per paket, LAG (gabungan link) yang membagi muatan per paket, dan momen saat rute berubah membuat urutan paket teracak → Akibatnya Paket belakang tiba lebih dulu sehingga 3 duplicate ACK menumpuk → fast retransmit → Di layar Paket game yang dikirim jarang-jarang hampir tidak terpengaruh. Update besar di tempat ramai dan unduhan patch melambat, sesekali patah-patah

Gejala: Patah-patah, Input lag
Faktor: Jitter
Siapa yang mengalami: Wilayah/ISP tertentu, Seluruh server
Kapan: Selalu, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Jaringan: ganti pembagian beban per paket dengan pembagian per koneksi (ECMP dan LAG dengan hash alamat dan port). Server/OS: pakai RACK (deteksi packet loss berbasis waktu yang tahan terhadap urutan paket tertukar; jika DSACK menunjukkan retransmisi yang tidak perlu, toleransi urutan tertukar diperlebar otomatis), periksa tingkat reordering yang diestimasi Linux secara otomatis untuk tiap koneksi (nilai reordering di ss -ti, nilai awalnya tcp_reordering=3).
Di grafik: Selalu tinggi sejak awal · Jumlah deteksi urutan paket tertukar, jumlah DSACK yang diterima
Yang diperiksa: Periksa TcpExtTCPSACKReorder dan TcpExtTCPTSReorder (jumlah deteksi urutan paket tertukar) serta TcpExtTCPDSACKRecv di nstat; per koneksi, periksa reordering (ditampilkan jika nilainya selain 3) dan reord_seen di ss -ti. Di packet capture, pakai filter Wireshark tcp.analysis.out_of_order
Cocok jika: Counter urutan tertukar dan DSACK terus naik di jam berapa pun, dan nilai reordering pada koneksi yang melewati rute atau perangkat tertentu lebih besar dari 3. Di capture sisi penerima, paket belakang datang lebih dulu dan paket depan pun segera menyusul
Tidak cocok jika: Counter urutan tertukar tidak berubah, tetapi TcpExtTCPLostRetransmit naik: packet loss sungguhan. DSACK hanya naik saat RTT melonjak: lebih mungkin “Retransmisi yang tidak perlu akibat lonjakan latensi”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

9 sumber

RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
Jika rute dibagi per paket, urutan paket berubah, dan jika 3 paket belakang atau lebih datang lebih dulu, TCP melakukan fast retransmit yang tidak perlu
RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
ECMP yang memilih rute dari hash field header yang mengidentifikasi flow (pembagian beban per flow)
RFC 5681: TCP Congestion Control IETF
Fast retransmit pada duplicate ACK ketiga
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
RACK mendeteksi packet loss berbasis waktu sehingga tahan terhadap urutan paket tertukar, dan memperlebar batas waktu toleransi urutan tertukar (reo_wnd) jika menerima DSACK
IP Sysctl Linux kernel
Nilai awal tcp_reordering 3 (disesuaikan otomatis per koneksi hingga tcp_max_reordering), pengaturan RACK di tcp_recovery
misc/ss.c iproute2
ss -ti menampilkan reordering:nilai jika nilai reordering koneksi berbeda dari default 3, dan reord_seen:jumlah jika koneksi pernah mengalami urutan paket tertukar
SNMP counter Linux kernel
TcpExtTCPSACKReorder, TcpExtTCPTSReorder (urutan paket tertukar terdeteksi), TcpExtTCPDSACKRecv (jumlah DSACK yang diterima), TcpExtTCPLostRetransmit (paket yang dikirim ulang hilang lagi)
include/uapi/linux/tcp.h Linux kernel
tcpi_reord_seen di tcp_info: berapa kali koneksi mengalami urutan paket tertukar
Display Filter Reference: Transmission Control Protocol Wireshark
Filter tampilan tcp.analysis.out_of_order

ACK terlambat atau hilang (upload penuh) ACK path congestion on asymmetric links

ID rt-ack-path · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Data sudah tiba dengan baik, tetapi jika ACK “sudah diterima” tertunda atau hilang di antrean upload yang penuh, pengirim menganggap data hilang lalu mengirimnya ulang.

Mengapa Upload di rumah penuh oleh upload video atau backup cloud → Akibatnya ACK tertunda ratusan ms di antrean router, atau dibuang saat antrean meluap → Di layar Paket game dari server umumnya datang tepat waktu. Input Anda yang menumpuk di antrean upload yang sama terlambat terkirim sehingga terjadi input lag dan rubber banding, sesekali disertai retransmisi yang tidak perlu

Gejala: Input lag, Rubber banding
Faktor: Latensi, Packet loss
Siapa yang mengalami: Satu rumah
Kapan: Sesekali secara acak, Jam sibuk malam hari
Penanggung jawab: Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Tampilkan status jaringan di layar saat ping melonjak, dan tampilkan petunjuk “periksa program yang sedang melakukan upload”.
Tugas Pihak Eksternal: Imbau pemain untuk memperpendek antrean upload dengan SQM di router, memprioritaskan paket kecil (ACK), dan membatasi kecepatan upload (upload video, backup cloud).
Kisaran angka: ACK yang datang belakangan ikut mengonfirmasi data yang sudah dikonfirmasi ACK sebelumnya, jadi beberapa ACK yang hilang biasanya tidak masalah. Masalahnya ada pada ACK yang tertunda di antrean.
Di grafik: Hanya sebagian yang tinggi · RTT (ping) per koneksi
Yang diperiksa: Dari PC pemain, bandingkan ping ke server game saat upload (upload video, backup cloud) berjalan dan saat dihentikan. Di server, periksa rtt koneksi pemain itu dengan ss -ti
Cocok jika: Ping naik ke ratusan ms hanya selama upload, disertai input lag dan rubber banding, lalu segera pulih setelah upload dihentikan. Dari sisi server, rtt koneksi itu juga naik pada saat yang sama
Tidak cocok jika: Packet loss dan latensi muncul tanpa terkait upload: lebih mungkin “Packet loss di jalur nirkabel” atau penyebab di sisi rute. Hanya arah server ke pemain yang lambat dan tidak terkait upload: lebih mungkin “Antrean bottleneck meluap”
Sarana pemeriksaan: Lingkungan pemain sendiri

4 sumber

RFC 3449: TCP Performance Implications of Network Path Asymmetry IETF
Di jalur asimetris dengan upload sempit, ACK yang tertunda atau hilang menurunkan performa TCP; ACK bersifat kumulatif sehingga ACK berikutnya menggantikan yang hilang; solusi seperti penjadwalan yang memprioritaskan ACK
Smart Queue Management Bufferbloat.net
Menjaga antrean router tetap pendek dengan pengelolaan antrean dan shaping
tc-cake(8) — Linux manual page iproute2
CAKE memisahkan flow dan meminimalkan latensi untuk flow yang jarang mengirim (sparse flow)
ss(8) — Linux manual page iproute2
rtt (rata-rata round-trip time) dan rttvar (deviasi) di ss -i

Pengaturan RTO tidak sesuai dengan lingkungan RTO min too low or too high

ID rt-rto-setting · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)

Jika nilai minimum RTO diturunkan terlalu rendah, keterlambatan kecil saja sudah memicu retransmisi yang tidak perlu. Sebaliknya, nilai default (200 ms) terlalu panjang untuk game sehingga setiap kali paket hilang, game berhenti lama.

Mengapa Nilai minimum RTO diturunkan drastis untuk keperluan data center, atau nilai default dipakai apa adanya di jalur internet → Akibatnya Terlalu rendah: retransmisi membanjir bahkan saat latensi naik sesaat. Terlalu tinggi: setiap packet loss harus ditunggu lama → Di layar Dengan nilai default, satu kali packet loss membuat freeze ratusan ms lalu fast forward; jika diturunkan terlalu rendah, freeze memendek, tetapi retransmisi yang tidak perlu melonjak dan memboroskan bandwidth

Gejala: Freeze, Fast forward, Input lag
Faktor: Latensi
Siapa yang mengalami: Seluruh server
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Di Linux 6.15 ke atas, pertimbangkan menurunkan batas atas RTO untuk koneksi game dengan TCP_RTO_MAX_MS (waktu sampai koneksi menyerah juga ikut memendek, jadi tentukan sekalian waktu deteksi terputus dengan TCP_USER_TIMEOUT), turunkan nilai minimum RTO hanya untuk koneksi internal antarserver dengan opsi socket TCP_RTO_MIN_US (6.15 ke atas), pertimbangkan opsi socket TCP_THIN_LINEAR_TIMEOUTS agar RTO berturut-turut tidak berlipat dua khusus pada koneksi game.
Tugas Tim Infrastruktur: Turunkan rto_min per rute hanya untuk koneksi internal antarserver, pertahankan nilai default di jalur internet dan lengkapi dengan RACK-TLP serta pengaturan thin stream (tcp_thin_linear_timeouts).
Kisaran angka: RTO di Linux = round-trip time + max(200 ms, deviasi RTT × 4). Nilainya berlipat dua setiap kali gagal, maksimal 120 detik. Di Linux 6.15 ke atas, batas atas ini bisa diturunkan hingga 1 detik dengan TCP_RTO_MAX_MS.
Di grafik: Selalu tinggi sejak awal · RTO per koneksi, jumlah RTO yang tidak perlu
Yang diperiksa: Periksa pengaturan nilai minimum RTO di server (rto_min di ip route show; di Linux 6.11 ke atas, sysctl net.ipv4.tcp_rto_min_us) serta rto dan rtt di ss -ti, lalu periksa kenaikan TcpExtTCPSpuriousRTOs di nstat
Cocok jika: Di server yang nilai minimumnya diturunkan, rto koneksi internet menempel ketat pada rtt dan TcpExtTCPSpuriousRTOs naik banyak. Dengan nilai default, rto koneksi game 200 ms atau lebih di atas rtt, dan setiap packet loss membuat game berhenti selama itu
Tidak cocok jika: rto sesuai perhitungan default (sekitar rtt + 200 ms) dan RTO yang tidak perlu juga sedikit, tetapi jedanya sangat lama: lebih mungkin packet loss berturut-turut atau cara pemulihannya (“Pemulihan lambat pada thin stream”, “Opsi TCP dihapus oleh perangkat perantara”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

12 sumber

RFC 6298: Computing TCP's Retransmission Timer IETF
RTO = SRTT + max(G, 4·RTTVAR), minimum yang direkomendasikan 1 detik, berlipat dua setiap kali gagal, dan jika ada nilai maksimum, nilainya minimal 60 detik
include/net/tcp.h Linux kernel
TCP_RTO_MIN di Linux 200 ms, TCP_RTO_MAX 120 detik
net/ipv4/tcp_input.c Linux kernel
RTO di Linux adalah SRTT + rttvar, dan rttvar tidak pernah turun di bawah nilai minimum RTO (default 200 ms)
tcp: add the ability to control max RTO Linux kernel
Penambahan opsi socket TCP_RTO_MAX_MS (1–120 detik), mulai Linux 6.15
tcp: add sysctl_tcp_rto_min_us Linux kernel
Penambahan tcp_rto_min_us, nilai minimum RTO default untuk seluruh server, mulai Linux 6.11
tcp: support TCP_RTO_MIN_US for set/getsockopt use Linux kernel
Penambahan opsi socket TCP_RTO_MIN_US untuk menentukan nilai minimum RTO per socket, mulai Linux 6.15
IP Sysctl Linux kernel
Default tcp_rto_min_us 200000 (opsi rute rto_min dan opsi socket TCP_RTO_MIN_US lebih diutamakan), tcp_rto_max_ms 1.000–120.000 (default 120.000), tcp_thin_linear_timeouts
ip-route(8) — Linux manual page iproute2
Opsi rto_min per rute: nilai minimum RTO yang dipakai saat berkomunikasi dengan tujuan itu
Thin-streams and TCP Linux kernel
TCP_THIN_LINEAR_TIMEOUTS bisa mematikan exponential backoff khusus untuk koneksi thin stream
tcp(7) — Linux manual page Linux man-pages
TCP_USER_TIMEOUT: lama menunggu data yang belum dikonfirmasi sebelum koneksi ditutup
ss(8) — Linux manual page iproute2
rto (ms) dan rtt di ss -i
SNMP counter Linux kernel
TcpExtTCPSpuriousRTOs: RTO tidak perlu yang dideteksi F-RTO

Pemulihan lambat pada thin stream Thin streams fall back to RTO

ID rt-thin · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)

Jika game mengirim paket kecil secara jarang-jarang, RTO datang lebih dulu sebelum “3 paket susulan” terkumpul. Untuk packet loss yang sama, game berhenti jauh lebih lama daripada transfer data besar.

Mengapa Interval paket sekitar 100 ms sehingga hanya ada sedikit paket yang belum mendapat ACK (in-flight) → Akibatnya Butuh lebih dari 300 ms untuk mengumpulkan 3 duplicate ACK sehingga RTO (ping + 200 ms) terpicu lebih dulu, dan berlipat dua jika packet loss terjadi berturut-turut → Di layar Satu kali packet loss membuat freeze sekitar 0,3 detik; jika paket yang dikirim ulang juga hilang, freeze hampir 1 detik lalu fast forward

Gejala: Freeze, Fast forward
Faktor: Packet loss, Stall
Siapa yang mengalami: Hanya saya, Seluruh server
Kapan: Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: aktifkan TCP_NODELAY (jika Nagle aktif, RACK tidak punya paket susulan sebagai dasar penilaian), kirim paket real-time lewat UDP dengan retransmisi buatan sendiri. Klien: aktifkan TCP_NODELAY, kirim paket real-time dengan cara yang sama seperti server (UDP).
Tugas Tim Infrastruktur: Pakai RACK-TLP (default di Linux terbaru), aktifkan tcp_thin_linear_timeouts agar RTO berturut-turut tidak berlipat dua.
Kisaran angka: Dengan interval paket 100 ms dan ping 60 ms, fast retransmit butuh sekitar 360 ms (sampai 3 paket berikutnya tiba dan konfirmasinya kembali), sedangkan RTO sekitar 260 ms. Dengan RACK, paket langsung dikirim ulang di sekitar 160 ms, saat konfirmasi paket berikutnya kembali. Jika interval paket lebih dari 200 ms, RACK pun tidak lebih cepat daripada RTO.
Di grafik: Kosong lalu datang sekaligus · Volume terima per koneksi, jumlah RTO habis
Yang diperiksa: Bandingkan kenaikan TcpExtTCPTimeouts (RTO habis), TcpExtTCPFastRetrans (fast retransmit), serta TcpExtTCPLossProbes dan TcpExtTCPLossProbeRecovery (TLP) di nstat, lalu periksa rto dan backoff koneksi game dengan ss -ti. Periksa juga nilai net.ipv4.tcp_recovery, tcp_early_retrans, dan tcp_sack di server
Cocok jika: Di antara retransmisi, RTO habis lebih banyak daripada fast retransmit, dan koneksi game sering menunjukkan backoff lebih dari 0 (sedang mengalami RTO). Volume terima 0 selama koneksi berhenti, lalu datang sekaligus saat pulih
Tidak cocok jika: Transfer data besar di server yang sama juga berhenti sama lamanya: masalah packet loss yang tidak terkait pola trafik koneksi. Terpusat pada koneksi tanpa SACK atau timestamp: lebih mungkin “Opsi TCP dihapus oleh perangkat perantara”
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: Linux dulu juga punya opsi retransmisi pada 1 duplicate ACK untuk thin stream (tcp_thin_dupack), tetapi opsi ini dihapus pada 2017, dan sekarang perannya digantikan oleh RACK. Jika Nagle aktif (TCP_NODELAY nonaktif), pengirim tidak mengirim paket baru selama menunggu konfirmasi paket yang hilang, sehingga RACK tidak punya paket susulan sebagai dasar penilaian dan koneksi harus menunggu sampai RTO.

11 sumber

Thin-streams and TCP Linux kernel
Thin stream yang mengirim secara jarang-jarang seperti game tidak memicu fast retransmit dengan baik sehingga bergantung pada timeout yang panjang; batasnya adalah kurang dari 4 paket yang belum mendapat ACK (in-flight)
RFC 5681: TCP Congestion Control IETF
Fast retransmit pada duplicate ACK ketiga
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
RACK menilai packet loss dari terkirimnya paket yang dikirim belakangan; waktu tunggu TLP adalah 2·SRTT (ditambah kelonggaran delayed ACK jika hanya ada satu paket yang belum dikonfirmasi)
include/net/tcp.h Linux kernel
TCP_RTO_MIN 200 ms, penentuan thin stream (kurang dari 4 paket in-flight), dan 6 kali percobaan ulang linear
tcp: remove thin_dupack feature Linux kernel
thin_dupack dihapus pada Januari 2017 (Linux 4.11), disertai penjelasan bahwa perannya digantikan oleh RACK
IP Sysctl Linux kernel
tcp_thin_linear_timeouts: pada thin stream, RTO tidak digandakan hingga maksimal 6 kali percobaan (default nonaktif)
tcp(7) — Linux manual page Linux man-pages
TCP_NODELAY mematikan algoritma Nagle
net/ipv4/proc.c Linux kernel
Nama counter yang ditampilkan nstat: TCPTimeouts, TCPFastRetrans, TCPLossProbes, TCPLossProbeRecovery
net/ipv4/tcp_timer.c Linux kernel
TCPTimeouts naik saat timer retransmisi (RTO) habis
SNMP counter Linux kernel
TcpExtTCPFastRetrans (retransmisi di luar state Loss), TcpExtTCPLossProbes (TLP dikirim), TcpExtTCPLossProbeRecovery (packet loss dipulihkan oleh TLP)
ss(8) — Linux manual page iproute2
rto (ms) dan backoff (berapa kali RTO digandakan) di ss -i

Opsi TCP dihapus oleh perangkat perantara Middlebox strips TCP options

ID rt-sack-stripped · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)

Jika sebagian firewall atau perangkat akselerator menghapus atau mengubah opsi TCP, saat beberapa paket hilang, pemulihannya hanya satu paket per round trip, atau window (jumlah yang bisa dikirim sekaligus) mengecil sehingga koneksi melambat.

Mengapa “TCP normalization” di firewall atau perangkat akselerator lama menghapus opsi SACK, timestamp, dan window scaling → Akibatnya Jika beberapa paket hilang, pemulihannya satu paket per round trip, dan window dibatasi 64 KB → Di layar Freeze di setiap packet loss jauh lebih lama (tanpa SACK, RACK-TLP juga tidak bisa dipakai), lalu fast forward setelah pulih. Transfer data besar seperti patch juga lambat

Gejala: Freeze, Fast forward
Faktor: Stall, Latensi
Siapa yang mengalami: Wilayah/ISP tertentu, Seluruh server
Kapan: Selalu
Penanggung jawab: Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur: Jaringan: matikan pengaturan TCP normalization di perangkat terkait, periksa juga pengacakan nomor urut di firewall, bandingkan opsi di SYN lewat packet capture di kedua ujung. Server/OS: periksa di ss -ti apakah koneksi tanpa tanda sack atau wscale terpusat pada rute tertentu (PC Windows bisa tidak memakai ts tergantung pengaturannya, jadi jika hanya ts yang tidak ada, itu bisa normal), pastikan net.ipv4.tcp_sack di server bernilai 1.
Di grafik: Selalu tinggi sejak awal · Jumlah pemulihan yang dimulai tanpa SACK (TcpExtTCPRenoRecovery)
Yang diperiksa: Periksa di ss -ti apakah setiap koneksi menampilkan sack dan wscale, lalu periksa rasio TcpExtTCPRenoRecovery (pemulihan yang dimulai tanpa SACK) terhadap TcpExtTCPSackRecovery serta TcpExtTCPSACKDiscard (jumlah blok SACK yang dibuang karena tidak konsisten) di nstat. Untuk rute yang dicurigai, capture SYN di kedua ujung lalu bandingkan opsinya (tcp.options.sack_perm di Wireshark dan sejenisnya)
Cocok jika: Hanya koneksi yang melewati rute atau perangkat tertentu yang tidak memiliki sack dan wscale, dan porsi TcpExtTCPRenoRecovery tinggi. Opsi SACK-permitted yang ada di SYN saat dikirim tidak ada lagi di SYN saat diterima. Jika penyebabnya pengacakan nomor urut, opsinya masih ada, tetapi TcpExtTCPSACKDiscard naik
Tidak cocok jika: sack tidak ada di semua koneksi: periksa nilai net.ipv4.tcp_sack di server lebih dulu. Opsi utuh dan TcpExtTCPSACKDiscard juga tidak berubah: pemulihan lambat karena sebab lain (“Pemulihan lambat pada thin stream”)
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut: SACK bisa rusak walaupun opsinya masih ada. Jika pengacakan nomor urut (sequence randomization) di firewall hanya mengubah nomor urut di header dan membiarkan nomor di dalam SACK, pengirim membuang SACK yang tidak konsisten itu. Hasilnya sama jika tcp_sack=0 pernah diatur di server saat masalah keamanan SACK tahun 2019 lalu terlupakan.

10 sumber

RFC 2018: TCP Selective Acknowledgment Options IETF
Tanpa SACK, ACK kumulatif saja hanya bisa memberi tahu satu paket yang hilang per round trip
RFC 7323: TCP Extensions for High Performance IETF
Tanpa opsi window scaling, window maksimal 2^16 = 64 KiB
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
RACK-TLP wajib memakai SACK
net/ipv4/tcp_output.c Linux kernel
TLP di Linux hanya dijadwalkan pada koneksi yang memakai SACK
IP Sysctl Linux kernel
Default tcp_sack 1 (aktif)
misc/ss.c iproute2
ss -ti menampilkan ts, sack, dan wscale:kirim,terima sesuai opsi yang dipakai koneksi
tcp: limit payload size of sacked skbs Linux kernel
Commit perbaikan kerentanan penanganan SACK tahun 2019 (CVE-2019-11477)
Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service vulnerabilities (NFLX-2019-001) Netflix
Saat itu tcp_sack=0 (mematikan pemrosesan SACK) dianjurkan sebagai mitigasi sementara
SNMP counter Linux kernel
TcpExtTCPRenoRecovery (pemulihan dimulai tanpa SACK), TcpExtTCPSackRecovery (pemulihan dimulai dengan SACK), TcpExtTCPSACKDiscard (jumlah blok SACK yang tidak valid)
Display Filter Reference: Transmission Control Protocol Wireshark
Filter tampilan tcp.options.sack_perm (opsi SACK-permitted di SYN)

Zero window (jeda yang terlihat seperti retransmisi) Zero window, often mistaken for retransmission

ID rt-zero-window · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)

Jika program penerima tidak membaca socket tepat waktu sehingga buffer penuh, pengirim menghentikan pengiriman dan hanya mengirim zero window probe. Koneksinya sendiri baik-baik saja.

Mengapa Frame di klien berhenti atau thread server tertahan sehingga socket tidak terbaca → Akibatnya Receive window menjadi 0 sehingga pengirim berhenti mengirim dan hanya mengirim probe (intervalnya makin panjang) → Di layar Freeze lalu fast forward. Packet capture menunjukkan “ZeroWindow” dan tidak ada packet loss

Gejala: Freeze, Fast forward
Faktor: Stall
Siapa yang mengalami: Hanya saya, Seluruh server
Kapan: Saat banyak pemain berkumpul, Sesekali secara acak
Penanggung jawab: Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)
Tugas Tim Pengembang Game: Periksa dulu sisi yang mengirim ZeroWindow di packet capture (sisi yang tidak sempat membaca socket), terus baca data jaringan di thread terpisah, atur ukuran buffer terima yang sesuai. Klien: atasi penyebab frame berhenti seperti loading dan GC. Server: atasi penyebab thread pembaca socket tertahan.
Tugas Tim Infrastruktur: Tambahkan TcpExtTCPToZeroWindowAdv di nstat server (berapa kali server memberi tahu receive window 0) ke monitoring (jika naik, masalahnya di sisi server, jadi teruskan ke Pengembangan server), sediakan packet capture sisi server.
Di grafik: Kosong lalu datang sekaligus · Volume terima per koneksi, jumlah zero window
Yang diperiksa: Di packet capture, cari sisi yang memberi tahu window 0 dengan filter Wireshark tcp.analysis.zero_window. Di nstat server, periksa terpisah TcpExtTCPToZeroWindowAdv (server memberi tahu window 0) dan TcpExtTCPWinProbe (server mengirim probe karena window pihak lawan 0), lalu periksa Recv-Q socket server (byte di ss yang belum dibaca program)
Cocok jika: Selama koneksi berhenti, tidak ada retransmisi, hanya paket zero window dan probe yang lalu-lalang. TcpExtTCPToZeroWindowAdv di server atau Recv-Q socket server naik: server tidak membaca tepat waktu. TcpExtTCPWinProbe naik: klien tidak membaca tepat waktu
Tidak cocok jika: Tidak ada zero window di capture dan data yang sama dikirim ulang: lebih mungkin packet loss atau retransmisi yang tidak perlu
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)
Kasus nyata: Roblox 2021: Gangguan 73 jam di Roblox: perebutan sumber daya di cluster service discovery (Consul)

7 sumber

RFC 9293: Transmission Control Protocol (TCP) IETF
Jika receive window 0, pengirim mengirim zero window probe dan interval probe diperpanjang secara eksponensial
7.5. TCP Analysis Wireshark
TCP ZeroWindow: paket tempat penerima memberi tahu window 0 sehingga pengirim berhenti mengirim
Display Filter Reference: Transmission Control Protocol Wireshark
Filter tampilan tcp.analysis.zero_window, tcp.analysis.zero_window_probe
SNMP counter Linux kernel
TcpExtTCPToZeroWindowAdv: berapa kali receive window diberitahukan berubah dari nilai lebih dari 0 menjadi 0
net/ipv4/proc.c Linux kernel
Nama counter yang ditampilkan nstat: TCPToZeroWindowAdv, TCPWinProbe
net/ipv4/tcp_output.c Linux kernel
TCPWinProbe: naik setiap kali probe (tcp_send_probe0) dikirim saat receive window pihak lawan 0
net/ipv4/tcp_diag.c Linux kernel
Untuk socket yang terhubung, Recv-Q di ss adalah jumlah byte yang sudah diterima tetapi belum dibaca program

Retransmisi permintaan koneksi (SYN) SYN retransmission on connect

ID rt-syn · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)

Jika permintaan koneksi hilang karena antrean koneksi (backlog) meluap atau diblokir firewall, OS klien mengirimnya ulang mulai 1 detik kemudian dengan interval yang makin panjang.

Mengapa Lonjakan koneksi tepat setelah maintenance membuat antrean koneksi server meluap, atau firewall dan proteksi DDoS membuang SYN → Akibatnya OS klien mengirim ulang SYN mulai 1 detik kemudian dengan interval yang sudah ditentukan (Linux versi lama: 1 detik → 2 detik → 4 detik) → Di layar Setelah tombol masuk ditekan, keterlambatannya pas dalam hitungan detik seperti 1 atau 3 detik, dan jika terus gagal, pemain tidak bisa masuk atau mengalami loading tanpa henti

Gejala: Tidak bisa masuk / loading tanpa henti
Faktor: Packet loss
Siapa yang mengalami: Seluruh server, Wilayah/ISP tertentu
Kapan: Tepat setelah login atau maintenance
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game: Server: perbesar argumen backlog pada listen (bersama somaxconn), pastikan server game memanggil accept tepat waktu, gunakan sistem antrean login. Klien: perpanjang interval percobaan ulang koneksi (disebar secara acak).
Tugas Tim Infrastruktur: Server/OS: periksa apakah antrean koneksi server meluap lewat TcpExtListenOverflows dan TcpExtListenDrops di nstat serta peringatan “Possible SYN flooding” di log, perbesar somaxconn (bersama argumen listen), aktifkan SYN cookie. Jaringan: longgarkan batas SYN di firewall dan proteksi DDoS.
Kisaran angka: Di Linux (termasuk Android), retransmisi SYN pertama terjadi setelah 1 detik. Kernel lama kemudian menggandakan jedanya setiap kali dan mengirim ulang pada detik ke-1, 3, 7, 15 …, sedangkan kernel 6.5 ke atas mengirim ulang lima kali pada detik ke-1, 2, 3, 4, dan 5, lalu menggandakannya (7, 11, 19 detik …) (tcp_syn_linear_timeouts=4). Ponsel Android sering tetap memakai kernel bawaan saat rilis walaupun OS-nya diperbarui, sehingga perilakunya bisa berbeda antarperangkat walaupun versi Android-nya sama. Apa pun kernelnya, jika semua percobaan gagal, OS menyerah setelah sekitar 2 menit. Windows mulai dari 1 atau 3 detik tergantung versi dan pengaturan, dan mengirim ulang 2–4 kali, sehingga menyerah dalam 20–30 detik (nilai di PC tersebut bisa dilihat di Max SYN Retransmissions pada netsh int tcp show global).
Di grafik: Melonjak tepat setelah server dibuka · Jumlah percobaan koneksi, jumlah kejadian antrean koneksi meluap
Yang diperiksa: Di nstat server, periksa TcpExtListenOverflows dan TcpExtListenDrops serta peringatan “Possible SYN flooding on port” di dmesg, lalu periksa dengan ss -lnt apakah Recv-Q socket listen (jumlah koneksi yang menunggu accept) mencapai Send-Q (batas backlog). Pastikan lewat capture di sisi server apakah SYN tiba dan apakah SYN-ACK dikirim balik
Cocok jika: Saat lonjakan koneksi tepat setelah maintenance, TcpExtListenOverflows naik dan Recv-Q menempel di Send-Q. Di capture, SYN dari klien yang sama datang lagi dengan interval hitungan detik, tetapi server tidak merespons
Tidak cocok jika: SYN tidak sampai ke server dan counter server juga tidak berubah: firewall atau proteksi DDoS di depan yang membuangnya, jadi periksa batas SYN dan log drop di perangkat itu. Server sudah mengirim SYN-ACK, tetapi koneksi tetap lambat: packet loss di arah balik
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

11 sumber

include/net/tcp.h Linux kernel
RTO pertama TCP_TIMEOUT_INIT = 1 detik (nilai awal dari RFC 6298)
RFC 6298: Computing TCP's Retransmission Timer IETF
RTO awal 1 detik, berlipat dua setiap kali retransmisi
IP Sysctl Linux kernel
Default tcp_syn_retries 6, default tcp_syn_linear_timeouts 4 (RTO SYN 1, 1, 1, 1, 1, 2, 4 …), retransmisi terakhir pada detik ke-67 dan menyerah pada detik ke-131, default somaxconn 4.096, default tcp_syncookies 1
tcp: make the first N SYN RTO backoffs linear Linux kernel
Commit yang mengubah bagian awal retransmisi SYN menjadi interval tetap, mulai Linux 6.5 (default 4 mengikuti cara macOS dan iOS)
Android common kernels Android (Google)
Common kernel 5.10–6.18 didukung bersamaan, dan kernel untuk platform sebelumnya (misalnya android14-6.1) bisa dipakai untuk peluncuran atau upgrade perangkat Android baru
TcpMaxConnectRetransmissions Microsoft
Default Windows versi lama: 2 kali retransmisi SYN, dimulai dengan tunggu 3 detik lalu berlipat dua, dan setelah yang terakhir menunggu dua kali lipat lagi sebelum menyerah (3+6+12=21 detik)
TCP/IP connectivity issues troubleshooting Microsoft
Jumlah retransmisi SYN berbeda tiap OS dan bisa dilihat di Max SYN Retransmissions pada netsh int tcp show global
listen(2) — Linux manual page Linux man-pages
Argumen backlog pada listen dipotong ke somaxconn (default 4.096 sejak Linux 5.4, sebelumnya 128)
SNMP counter Linux kernel
Jika antrean accept penuh, SYN dibuang dan TcpExtListenOverflows serta TcpExtListenDrops naik bersamaan; TcpExtTCPSynRetrans
net/ipv4/tcp_input.c Linux kernel
Pesan log “Possible SYN flooding on port …”
net/ipv4/tcp_diag.c Linux kernel
Untuk socket listen, Recv-Q di ss adalah jumlah koneksi yang menunggu accept, dan Send-Q adalah batas backlog

Prosedur per situasi

Lag setelah patch

Saat laporan lag bertambah sejak patch atau deploy tertentu. Pakai prosedur ini saat laporan seperti “sejak update ini jadi aneh” mulai berdatangan, atau saat grafik naik seperti anak tangga pada suatu waktu lalu bertahan di level itu.

Membuka layanan di negara atau wilayah baru

Saat membuka layanan di negara baru atau menambah region atau data center baru. Pakai juga untuk pemeriksaan sebelum peluncuran dan untuk memilah laporan seperti “di Korea lancar, tetapi hanya pemain di negara baru yang lag”.

Kasus insiden nyata

Yang dipilih hanya postmortem yang dipublikasikan sendiri oleh perusahaan game dan perusahaan infrastruktur.

CCP Games 2014: Kelebihan beban server dalam pertempuran armada besar HED-GP di EVE Online

Apa yang terjadi: Dalam pertempuran armada besar di sistem bintang HED-GP yang dibahas tulisan retrospektif Januari 2014, server mengalami kelebihan beban yang parah. Bahkan setelah Time Dilation (fitur yang memperlambat waktu game saat kelebihan beban) mencapai batas bawahnya, yaitu 10%, dan seluruh medan pertempuran menjadi slow motion, beban terus menumpuk. Keterlambatan pekerjaan yang memproses penghentian dan siklus berulang modul (Dogma Lateness) mencapai puncak 193 detik waktu game, atau sekitar 32 menit waktu nyata. Pertempuran 6VDT pada Juli 2013, yang skalanya hampir sama, mencapai puncak 42 detik (sekitar 7 menit waktu nyata).
Penyebab: CCP menegaskan bahwa penyebabnya belum bisa dipastikan, karena tools analisis performa ikut menambah beban sehingga tidak dijalankan dalam situasi seperti ini. Dengan catatan itu, CCP menyebut dua penyebab yang paling mungkin. Pertama, beban yang tidak sempat diproses terus menumpuk selama pertempuran berlangsung lama. Kedua, penggunaan drone meningkat: jumlah drone unik yang dikerahkan selama pertempuran mencapai 21.123 di 6VDT dan 38.852 di HED-GP, atau 84% lebih banyak. Aksi seorang pemain harus diberitahukan kepada semua orang yang melihatnya, sehingga jumlah pengiriman tumbuh sebanding dengan kuadrat jumlah pemain (O(n²)), dan drone menghasilkan lebih banyak pesan untuk setiap serangan. Kode yang dipakai drone untuk memilih target juga sering memeriksa semua target yang bisa diserang di medan pertempuran yang sama, sehingga biayanya tumbuh mendekati n².
Pelajaran: Jika throughput satu area yang dipadati pemain melewati batasnya, seluruh area itu menjadi slow motion. Makin lama pertempuran berlangsung, makin banyak pemrosesan tertunda yang menumpuk, dan input lag makin besar. Sinyal yang perlu diperiksa adalah waktu tick dan jumlah pekerjaan tertunda di server (node) yang menangani area itu, serta jumlah pemain dan objek. Cirinya, area lain tetap normal. Penanggung jawab utama adalah Tim Pengembang Game (server), dan yang perlu diperbaiki adalah cakupan penerima pemberitahuan untuk satu aksi serta biaya pencarian target oleh AI. Desain yang memperlambat waktu game tidak menghilangkan kelebihan beban. Namun, desain ini membuat semua pemain melambat dengan kecepatan yang sama, sehingga tidak ada aksi tertentu yang tertunda tanpa batas.
Penyebab terkait: Lonjakan broadcast, Tick melewati budget (tick overrun), Penumpukan antrean pesan, Kelebihan beban di area single-thread (hotspot)
Sumber asli: CCP Games

Riot Games 2015: Trafik League of Legends yang memutar jauh dan Riot Direct

Apa yang terjadi: Tulisan teknis Riot Games yang menjelaskan mengapa internet tidak cocok untuk game real-time. Trafik nyata yang dilaporkan seorang pemain League of Legends seharusnya berjalan langsung dari San Francisco ke Portland, tetapi malah melewati Los Angeles, Denver, dan Seattle, sehingga perjalanan yang cukup 14 ms jika langsung menjadi 70 ms. Riot menjelaskan bahwa jika router meluap dan paket dibuang, champion lain terlihat melompat-lompat di layar dan proyektil terlihat teleport.
Penyebab: Riot menyebut rute dan router sebagai penyebabnya. Penyedia backbone dan ISP mengirim trafik lewat rute yang biayanya paling murah, yang belum tentu rute dengan latensi terendah, dan jika rute yang ditentukan BGP memutar jauh, jumlah router yang dilewati juga bertambah. Beban pemrosesan router bergantung pada jumlah paket, berapa pun ukurannya. Paket game berukuran sekitar 55 byte, sehingga untuk volume data yang sama jumlahnya 27 kali lipat paket 1.500 byte dan buffer input router pun lebih cepat penuh. Menurut penjelasan Riot, banyak router juga membuang paket UDP lebih dulu saat kelebihan beban. Sebagai solusinya, Riot membangun jaringan sendiri bernama Riot Direct dengan menempatkan router di 10 hub internet besar di Amerika Serikat dan terhubung langsung (peering) dengan sebanyak mungkin ISP. Menurut tulisan bagian kedua, porsi pemain yang bermain dengan ping di bawah 80 ms naik dari 31% menjadi 50% dalam sedikit lebih dari 9 bulan, lalu menjadi 80% dalam semalam setelah server game dipindahkan ke Chicago.
Pelajaran: Jika hanya pemain dari ISP tertentu yang ping-nya jauh lebih tinggi, bahkan di dalam satu negara, curigai rutenya. Sinyal yang perlu diperiksa adalah distribusi RTT per ISP (ASN) dan kota transit yang muncul di traceroute. Penanggung jawab utama adalah Tim Infrastruktur (jaringan), dan perbaikannya lewat peering langsung dengan ISP, koneksi ke IX, dan pemilihan lokasi server. Kebijakan rute di sisi ISP perlu dibicarakan dengan Pihak Eksternal (ISP). Kasus ini juga menunjukkan bahwa memindahkan server lebih dekat ke pusat sebaran pemain saja sudah memberi dampak besar.
Penyebab terkait: Routing memutar, Latensi propagasi (jarak fisik), Antrean bottleneck meluap (packet loss akibat kongesti)
Sumber asli: Riot Games

Riot Games 2020: Host edge kelebihan beban di server League of Legends Eropa dan Brasil

Apa yang terjadi: Pada akhir Februari 2020, server League of Legends EUW, EUNE, dan BR beberapa kali mengalami gangguan, dan jumlah game baru yang dimulai turun tajam. Semua layanan backend seperti matchmaking dan server game berstatus normal, tetapi hampir tidak ada trafik yang masuk. Riot menunda jadwal mode turnamen (Clash) selama satu minggu agar tidak membukanya di cluster yang mungkin tidak stabil. Tulisan retrospektifnya tidak mencantumkan berapa lama setiap gangguan berlangsung.
Penyebab: Tiga hal terjadi bersamaan. Request ke satu layanan dibuat dengan keliru sehingga dalam kasus tertentu terus gagal dan terus dicoba ulang, dan jumlah request melonjak. Masalah kompatibilitas yang sudah diketahui antara sistem container dan versi OS membuat memori di dalam OS bocor. Upgrade baru selesai di sekitar 60% seluruh lingkungan container Riot, sedangkan cluster Eropa dan Amerika Latin masih dalam proses. Container edge, yang menerima trafik internet, menyaringnya, lalu meneruskannya ke backend, ditempatkan terpisah di dalam shard (kelompok server) yang sama, tetapi tidak ada yang mencegah container dari shard yang berbeda berkumpul di satu host. Akibatnya, setiap kali gangguan terjadi, container edge dari minimal tiga shard menumpuk di satu host. Lonjakan retry menghantam host itu, lalu kebocoran memori membuat host itu berhenti.
Pelajaran: Jika semua layanan backend menjawab “normal, tetapi trafik tidak masuk”, periksa bagian di depannya (edge, gateway, load balancer). Sinyal yang perlu diperiksa adalah jumlah koneksi masuk yang menumpuk di host tertentu, serta rasio kegagalan dan retry untuk request tertentu. Penanggung jawab utama adalah Tim Pengembang Game (server: request yang keliru dan cara retry), sedangkan aturan penempatan container, upgrade OS, dan alert penumpukan ditangani Tim Infrastruktur (server/OS). Riot memperbaiki kode request-nya, mengubah retry agar tidak melonjak, dan memasang alert penumpukan sampai penyebaran ke shard yang berbeda selesai diimplementasikan.
Penyebab terkait: Rute lewat gateway atau proxy, Kegagalan berantai
Sumber asli: Riot Games

Riot Games 2021: Gangguan 5 jam di League of Legends EUW: satu DB pendukung menghentikan seluruh server

Apa yang terjadi: Pada 22 Januari 2021, server League of Legends EUW tidak berfungsi dengan benar selama sedikit lebih dari 5 jam. Metrik jumlah pemain yang login dan jumlah pemain yang sedang bermain terputus bersamaan, dan di antara dua kali restart, jumlah login bertambah tetapi hampir tidak ada game yang dimulai.
Penyebab: Server primer dari DB yang menangani fitur tidak penting mengalami kerusakan hardware, dan DB itu tidak dikonfigurasi untuk failover otomatis ke server cadangan. Setiap DB punya connection pool sendiri, tetapi semua pool memakai thread pool yang sama. Pekerjaan yang dikirim ke DB yang rusak tidak pernah selesai dan terus menahan thread, sampai seluruh sistem kehabisan thread. Di tengah banjir alert, tim lebih dulu mencurigai serangan jaringan berbahaya yang baru saja dialami dan pekerjaan hardware di region lain, sehingga alert dari DB yang rusak baru diperhatikan sekitar 1 jam kemudian. Semua sistem berjalan di satu JVM, jadi ketika GC berulang kali menghentikan proses selama beberapa detik di tengah beban reconnect setelah restart, pengumpulan metrik juga mengalami celah besar. Antrean login juga tidak mematuhi batas yang dikonfigurasi, sehingga arus pemain yang masuk naik turun tidak beraturan.
Pelajaran: Satu DB pendukung yang dianggap tidak penting pun bisa menghentikan semuanya lewat sumber daya bersama seperti thread pool. Sinyal yang perlu diperiksa adalah jumlah request yang menunggu per DB, utilisasi thread pool, serta rasio game yang dimulai terhadap jumlah login yang terlalu rendah. Penanggung jawabnya Tim Pengembang Game (server: isolasi thread pool dan timeout) dan Tim Infrastruktur (DB: failover otomatis). Saat alert membanjir, orang cenderung lebih dulu mencurigai masalah yang baru saja dialami (misalnya serangan), jadi singkirkan kemungkinan satu per satu sesuai urutan diagnosis (cakupan → waktu → lapisan). Setelah restart, periksa juga apakah antrean login benar-benar membatasi arus masuk sesuai konfigurasi.
Penyebab terkait: Thread pool habis, Failover DB, Kegagalan berantai, Jeda GC stop-the-world di server
Sumber asli: Riot Games

Roblox 2021: Gangguan 73 jam di Roblox: perebutan sumber daya di cluster service discovery (Consul)

Apa yang terjadi: Gangguan dimulai pada sore hari 28 Oktober 2021 (waktu Pasifik) dengan beban CPU tinggi di satu server Consul. Pada pukul 16.35, jumlah pemain yang sedang online turun menjadi setengah dari biasanya, lalu seluruh layanan berhenti. Baru pada 31 Oktober pukul 16.45 semua pemain bisa masuk kembali, 73 jam sejak gangguan dimulai. Roblox menyebut layanannya dipakai 50 juta orang setiap hari.
Penyebab: Roblox memakai HashiCorp Consul untuk service discovery (fungsi yang dipakai layanan untuk saling menemukan alamat), health check, dan penyimpanan KV, dan satu cluster Consul menangani beberapa workload sekaligus. Ada dua akar penyebab. Pertama, fitur streaming baru di Consul, yang cakupannya diperluas selama beberapa bulan, diaktifkan juga untuk layanan routing trafik sehari sebelum gangguan, dan jumlah node layanan itu ditambah 50%. Di bawah beban baca dan tulis yang sama-sama sangat tinggi, fitur ini menimbulkan perebutan pada satu sumber daya bersama (channel Go). Di server dual socket (NUMA) dengan jumlah core lebih banyak yang dipasang sebagai pengganti selama gangguan, perebutannya makin parah. Kedua, pengelolaan daftar halaman kosong (freelist) di BoltDB, yang dipakai Consul untuk menyimpan log Raft, melambat secara tidak wajar: setiap penambahan data 16 kB atau kurang menulis 7,8 MB ke disk. Median latensi tulis KV yang biasanya di bawah 300 ms menjadi 2 detik, dan zero window (buffer TCP penuh) juga terlihat di server leader yang lambat. Karena telemetri bergantung pada Consul, metrik yang dibutuhkan untuk mencari penyebab ikut hilang.
Pelajaran: Jika sistem dasar yang diandalkan banyak layanan sekaligus (service discovery, penyimpanan konfigurasi, autentikasi) melambat, semua fitur berhenti bersamaan. Sinyal yang perlu diperiksa adalah latensi tulis, pergantian leader, dan CPU sistem itu, serta perubahan konfigurasi tepat sebelum gangguan. Penanggung jawabnya kedua tim, yaitu Tim Pengembang Game (server) dan Tim Infrastruktur (server/OS). Monitoring perlu dipisahkan agar tidak bergantung pada sistem yang dipantaunya, supaya metrik tetap bisa dilihat saat gangguan. Saat pemulihan, cache masih kosong sehingga sistem bisa runtuh lagi jika semua pemain masuk sekaligus. Karena itu Roblox mengatur porsi pemain yang boleh masuk lewat DNS dan menaikkannya sekitar 10% setiap tahap.
Penyebab terkait: Kegagalan berantai, Perebutan lock, Zero window (jeda yang terlihat seperti retransmisi), Cold cache (tepat setelah restart)
Sumber asli: Roblox

Square Enix 2021: Kepadatan server saat rilis ekspansi FINAL FANTASY XIV dan error antrean login

Apa yang terjadi: Sejak early access ekspansi Endwalker pada Desember 2021, setiap World sangat padat. Antrean login memanjang, dan Error 2002 sering muncul saat login dari layar pemilihan karakter atau saat menunggu di antrean. Sebagian World dan zona juga down (Error 3001), dan antrean mengalami timeout (Error 4004). Saat pengumuman 11 Desember, pada hari ke-8 early access, kepadatan masih berlanjut.
Penyebab: Error 2002 muncul dalam dua kasus. Kasus pertama terjadi saat jumlah pemain yang menunggu di satu data center logis melebihi 17.000 orang. Ini adalah batas atas untuk mencegah server login down karena antrean terlalu panjang, dan saat batas ini tercapai, klien tertutup sepenuhnya. Pada 7 Desember, hardware cadangan untuk keperluan pengembangan dipasang ke server lobi untuk menaikkan batas itu. Error ini berkurang, tetapi antreannya justru makin panjang. Kasus kedua terjadi saat koneksi pemain yang sedang menunggu tidak stabil. Makin lama waktu tunggu, makin sering koneksi putus sesaat akibat packet loss di jalur internet atau Wi-Fi yang tidak stabil. Server lobi menunggu reconnect selama puluhan detik hingga sekitar 1 menit. Pemain yang tersambung kembali dalam waktu itu melanjutkan dari posisinya di antrean, sedangkan yang melewati batas itu harus mulai lagi dari paling belakang. Square Enix menyebut sebagian besar laporan termasuk kasus ini. Akibat kekurangan chip semikonduktor, World juga tidak bisa langsung ditambah.
Pelajaran: Makin panjang antrean, makin sering koneksi yang putus sesaat pada pemain yang sedang menunggu berubah menjadi error koneksi. Dalam kepadatan yang sama, error menumpuk pada pemain yang memakai Wi-Fi atau koneksi tidak stabil, sehingga masalahnya menjadi masalah yang “hanya dialami sebagian pemain”. Sinyal yang perlu diperiksa adalah panjang antrean dan waktu tunggu, serta porsi koneksi yang putus saat menunggu di antrean di antara semua alasan koneksi terputus. Penanggung jawab utama adalah Tim Pengembang Game (server: batas atas antrean dan masa tenggang reconnect), dan Tim Infrastruktur ikut menambah server lobi dan server World. Dengan masa tenggang reconnect yang longgar, koneksi pemain yang putus sesaat lebih jarang berujung pada hilangnya nomor antrean.
Penyebab terkait: Batas antrean login dan masa tenggang reconnect yang terlalu singkat, Interferensi Wi-Fi dan sinyal lemah, Packet loss di jalur nirkabel
Sumber asli: Square Enix

Cloudflare 2020: Trafik hilang di sebagian kota akibat kesalahan konfigurasi backbone Cloudflare

Apa yang terjadi: Banyak game menyerahkan web, API, dan proteksi DDoS kepada penyedia CDN, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Pada 17 Juli 2020 pukul 21.12–21.39 (UTC), selama 27 menit, trafik di seluruh jaringan Cloudflare turun sekitar 50%. Dampaknya terbatas pada sebagian lokasi di kota-kota Amerika Serikat, Eropa, Rusia, dan Brasil yang terhubung ke backbone. Lokasi lain normal.
Penyebab: Gangguan di segmen backbone Newark–Chicago membuat segmen Atlanta–Washington mengalami kongesti, sehingga seorang engineer mengubah konfigurasi router untuk mengurangi trafik backbone di Atlanta. Seharusnya seluruh entri kebijakan (term) dinonaktifkan, tetapi yang dinonaktifkan hanya kondisi di dalamnya (prefix-list). Akibatnya, router Atlanta menyebarkan semua rute BGP ke seluruh backbone dengan prioritas lebih tinggi (local-preference 200). Prioritas yang diberikan setiap lokasi untuk rute ke servernya sendiri adalah 100, sehingga semua trafik dari lokasi yang terhubung ke backbone tersedot ke Atlanta. Atlanta kelebihan beban, sedangkan lokasi yang terdampak hampir tidak punya trafik untuk diproses. Layanan pulih setelah router Atlanta dikeluarkan dari backbone. Cloudflare menyatakan gangguan ini tidak berkaitan dengan serangan atau pembobolan.
Pelajaran: Jika hanya pemain di kota atau wilayah tertentu yang serentak mengalami disconnect atau tidak bisa masuk / loading tanpa henti, sementara pemain lain normal, curigai dulu perubahan konfigurasi rute yang baru saja dilakukan. Di grafik, CPU dan trafik melonjak hanya di satu lokasi, sedangkan lokasi yang terdampak justru turun mendekati 0. Penanggung jawab utama adalah Tim Infrastruktur (jaringan), atau Pihak Eksternal jika gangguannya ada di sisi penyedia. Cloudflare memutuskan untuk memasang batas jumlah rute yang boleh diterima setiap sesi BGP backbone (maximum-prefix), dan menyesuaikan prioritas agar satu lokasi tidak bisa menarik trafik lokasi lain.
Penyebab terkait: Perubahan rute dan konvergensi BGP, Perubahan rute dan jalur ECMP bermasalah
Sumber asli: Cloudflare

Fastly 2021: Error global pada CDN Fastly

Apa yang terjadi: Banyak game mendistribusikan file patch, launcher, dan halaman web lewat CDN, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Mulai 8 Juni 2021 pukul 09.47 (UTC), 85% jaringan Fastly mengembalikan error. Dalam 49 menit, 95% jaringan kembali normal, dan gangguan selesai ditangani pada pukul 12.35.
Penyebab: Deploy software yang dimulai pada 12 Mei mengandung bug yang terpicu saat konfigurasi pelanggan tertentu bertemu kondisi tertentu. Pada 8 Juni, seorang pelanggan mengunggah perubahan konfigurasi yang valid, dan kondisi itu terpenuhi. Fastly mendeteksi anomali dalam 1 menit, dan pemulihan dimulai setelah konfigurasi pelanggan penyebabnya ditemukan dan dinonaktifkan. Deploy perbaikan bug dimulai pada hari yang sama pukul 17.25.
Pelajaran: Kode yang sudah di-deploy beberapa minggu sebelumnya pun bisa seketika menjadi gangguan global saat bertemu kondisi langka. Di sisi game, sinyal yang perlu diperiksa adalah tingkat error HTTP untuk request patch, launcher, dan web yang naik serentak di semua wilayah, serta halaman status penyedia CDN. Cirinya, koneksi game yang sudah tersambung tetap normal jika tidak lewat CDN, dan yang terblokir hanya koneksi baru, unduhan patch, dan login web. Penanggung jawab utama adalah Pihak Eksternal (penyedia CDN), sedangkan Tim Pengembang Game dan Tim Infrastruktur menyiapkan rute cadangan, misalnya memakai lebih dari satu CDN atau mengambil langsung dari server origin.
Penyebab terkait: Ketergantungan pada layanan eksternal
Sumber asli: Fastly

Meta 2021: Gangguan Facebook: satu perintah di backbone sampai menghilangkan DNS

Apa yang terjadi: Gangguan infrastruktur yang pelajarannya berlaku juga untuk jaringan dan DNS milik perusahaan game sendiri. Pada 4 Oktober 2021, layanan Facebook (kini Meta) tidak bisa diakses di seluruh dunia. Backbone yang menghubungkan data center-nya terputus seluruhnya, dan server DNS Facebook tidak bisa ditemukan dari internet. Tulisan retrospektifnya tidak mencantumkan berapa lama gangguan berlangsung.
Penyebab: Dalam pekerjaan maintenance rutin, sebuah perintah yang dijalankan untuk memeriksa kapasitas backbone global secara tidak sengaja memutus semua koneksi backbone, dan tools audit yang seharusnya memblokir perintah semacam itu gagal mencegahnya karena bug. Server DNS di lokasi kecil dirancang untuk menganggap dirinya tidak sehat dan menarik pengumuman rute BGP jika tidak bisa berkomunikasi dengan data center, sehingga server DNS tidak bisa dijangkau dari internet padahal masih berjalan. Jalur akses biasa dan akses out-of-band sama-sama terputus, dan tools internal juga kehilangan DNS, sehingga engineer harus dikirim langsung ke data center, dan prosedur keamanan membuat prosesnya makin lama. Saat pemulihan, konsumsi daya di setiap data center sudah turun puluhan MW, dan mengembalikan semuanya sekaligus dinilai berisiko bagi banyak hal, dari instalasi listrik sampai cache. Karena itu beban dinaikkan secara bertahap.
Pelajaran: Jika gejala tidak bisa masuk / loading tanpa henti muncul serentak di semua wilayah dan semua ISP, periksa DNS dan rute BGP sebelum memeriksa server game. Hal ini bisa dipastikan juga dari luar perusahaan, lewat lookup DNS eksternal dan informasi rute BGP yang terbuka untuk publik. Penanggung jawab utama adalah Tim Infrastruktur (jaringan). Periksa lebih dulu bahwa jalur akses out-of-band dan tools internal yang dipakai saat gangguan tidak bergantung pada DNS dan jaringan yang sama, dan saat pemulihan, naikkan beban secara bertahap agar reconnect tidak datang sekaligus.
Penyebab terkait: Perubahan rute dan konvergensi BGP, Gangguan dan latensi DNS
Sumber asli: Meta

AWS 2021: Kongesti jaringan internal AWS us-east-1

Apa yang terjadi: Banyak game menempatkan server, login, dan data di cloud publik, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Pada 7 Desember 2021 pukul 07.30 PST, jaringan internal region Virginia Utara (us-east-1) mengalami kongesti. Mulai pukul 07.33, error dan latensi API EC2 meningkat sehingga instance baru sulit dijalankan (peluncuran instance pulih pukul 14.40), lalu menyusul kegagalan login konsol, perubahan konfigurasi Route 53 yang tidak bisa dilakukan, serta metrik CloudWatch yang terlambat dan sebagian hilang. Perangkat jaringan pulih sepenuhnya pukul 14.22. Instance EC2 yang sudah berjalan dan respons DNS yang sudah ada tidak terdampak.
Penyebab: Proses otomatis untuk menambah kapasitas sebuah layanan di jaringan utama memicu perilaku tak terduga dari banyak sekali klien di jaringan internal, sehingga upaya koneksi melonjak. Perangkat yang menghubungkan jaringan internal dan jaringan utama meluap sehingga komunikasi melambat, dan keterlambatan itu kembali menambah upaya koneksi dan retry, sehingga kongesti terus berlanjut. Klien sebenarnya punya mekanisme backoff yang memperpanjang jarak waktu di antara request saat kongesti seperti ini, tetapi mekanisme itu tidak bekerja dengan benar karena cacat tersembunyi. Monitoring internal juga bergantung pada jaringan yang sama, sehingga tim operasional menangani gangguan tanpa metrik real-time dan hanya mengandalkan log.
Pelajaran: Jika retry tidak bisa memperpanjang jedanya, kongesti singkat bisa menjadi gangguan berjam-jam. Dari sisi game, server game yang sudah berjalan mungkin baik-baik saja, tetapi penambahan server baru (autoscaling), login, matchmaking, dan pembayaran yang memakai API cloud, serta monitoring bisa ikut terblokir. Sinyal yang perlu diperiksa adalah halaman status penyedia cloud, tingkat error API cloud, dan kegagalan peluncuran instance. Penanggung jawab utama adalah Pihak Eksternal (penyedia cloud). Tim Pengembang Game memasang exponential backoff dengan jeda acak dan batas jumlah percobaan pada semua retry, sedangkan Tim Infrastruktur menyiapkan kapasitas cadangan agar tetap bertahan saat penambahan server terblokir, serta alternatif di region lain.
Penyebab terkait: Kegagalan berantai, Keterlambatan autoscaling, Ketergantungan pada layanan eksternal
Sumber asli: AWS

Cloudflare 2025: Gangguan DNS publik Cloudflare 1.1.1.1

Apa yang terjadi: Gangguan pada resolver DNS publik yang diatur sendiri oleh pemain di perangkat atau router. Pada jenis gangguan ini, semua game dan layanan ikut terblokir, tetapi hanya bagi pemain yang memakai pengaturan itu. Pada 14 Juli 2025 pukul 21.52–22.54 (UTC), selama 62 menit, resolver 1.1.1.1 tidak merespons di seluruh dunia. Cloudflare menyatakan bahwa bagi banyak pengguna, ini praktis berarti tidak bisa memakai layanan internet apa pun. Query UDP, TCP, dan DNS over TLS terdampak, sedangkan DNS over HTTPS, yang tersambung lewat nama domain, relatif stabil.
Penyebab: Pada 6 Juni, saat menyiapkan topologi layanan (konfigurasi yang menentukan lokasi mana yang mengumumkan rentang IP tertentu) untuk layanan lain yang akan dipakai nanti, rentang IP resolver 1.1.1.1 tidak sengaja ikut dimasukkan ke konfigurasi itu. Pada 14 Juli, saat konfigurasi layanan tersebut diubah, lokasi yang mengumumkan rentang resolver menyusut dari semua lokasi menjadi satu lokasi yang sedang offline, dan rute BGP-nya ditarik di seluruh dunia. Perubahan ini langsung menyebar ke semua data center tanpa melalui canary deployment. Setelah konfigurasi dikembalikan pada pukul 22.20, trafik kembali hingga sekitar 77%, tetapi selama itu konfigurasi IP yang diperlukan sudah terhapus dari sekitar 23% server edge. Konfigurasi ulangnya membuat layanan baru normal pada pukul 22.54. Cloudflare menyatakan ini kesalahan konfigurasi internal yang tidak berkaitan dengan serangan atau pembajakan BGP (BGP hijacking).
Pelajaran: Jika server game dan pemain lain normal, tetapi hanya sebagian pemain yang mengalami tidak bisa masuk / loading tanpa henti ke server login atau server patch, curigai DNS yang dipakai pemain tersebut. Cirinya, sesi yang sudah tersambung tetap bertahan dan hanya koneksi baru yang gagal. Penyebabnya langsung terpilah jika pemain diminta mengganti pengaturan DNS atau melakukan lookup alamat server secara langsung. Penanggung jawab utama adalah Pihak Eksternal (operator DNS, ISP). Jika Tim Pengembang Game (klien) membedakan kegagalan resolusi nama dari error lain dalam pesan ke pemain, tim CS bisa langsung menentukan penyebabnya.
Penyebab terkait: Gangguan dan latensi DNS, Perubahan rute dan konvergensi BGP
Sumber asli: Cloudflare

AWS 2025: Gangguan DNS DynamoDB di AWS us-east-1 dan pemulihan yang lama

Apa yang terjadi: Banyak game menempatkan server, login, dan data di cloud publik, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Dari 19 Oktober 2025 pukul 23.48 sampai 20 Oktober pukul 14.20 (PDT), region Virginia Utara terdampak dalam tiga tahap. Error API DynamoDB meningkat sampai pukul 02.40 tanggal 20; peluncuran instance EC2 baru gagal dari pukul 02.25 sampai 10.36 (masalah koneksi pada sebagian instance baru teratasi pukul 13.50); dan error koneksi di sebagian Network Load Balancer (NLB) meningkat dari pukul 05.30 sampai 14.09.
Penyebab: Otomatisasi yang mengelola DNS DynamoDB mengandung race condition tersembunyi. Di antara eksekutor yang menerapkan rencana DNS di availability zone yang berbeda (DNS Enactor), satu eksekutor yang tertunda sangat lama menimpa rencana baru dengan rencana lama. Tepat setelah itu, proses pembersihan dari eksekutor lain menghapus rencana lama tersebut, sehingga record DNS untuk endpoint region (dynamodb.us-east-1.amazonaws.com) menjadi kosong. Otomatisasi tidak bisa memperbaikinya, sehingga pemulihan harus dilakukan manual. Sistem pengelola server fisik EC2 bergantung pada DynamoDB, sehingga selama itu lease yang dipegang untuk setiap server fisik kedaluwarsa. Setelah DynamoDB pulih, jumlah server fisik terlalu banyak sehingga proses membuat ulang lease mengalami timeout sebelum selesai, dan pekerjaan retry kembali menumpuk hingga sistem masuk ke kondisi “congestive collapse” (runtuh akibat kongesti). Konfigurasi jaringan untuk instance yang baru dijalankan menyebar dengan lambat, sehingga health check NLB bolak-balik antara berhasil dan gagal, dan node yang sehat pun berulang kali keluar dari DNS lalu masuk kembali.
Pelajaran: Kesalahan record DNS di satu tempat menjalar ke layanan lain yang bergantung pada layanan itu, dan setelah penyebabnya teratasi pun, pemulihan masih butuh beberapa jam lagi karena pekerjaan yang tertunda dan health check yang tidak stabil. Dari sisi game, server yang sudah berjalan mungkin bertahan, tetapi server baru tidak bisa dijalankan sehingga autoscaling berhenti, dan health check yang tidak stabil bisa membuat load balancer mengeluarkan server yang sebenarnya normal. Sinyal yang perlu diperiksa adalah halaman status cloud, tingkat error API layanan terkelola (managed service), kegagalan peluncuran instance, dan jumlah target sehat di load balancer. Penanggung jawab utama adalah Pihak Eksternal (penyedia cloud), sedangkan Tim Infrastruktur membatasi jumlah server yang boleh keluar sekaligus karena gagal health check dan menyiapkan alternatif di region lain.
Penyebab terkait: Ketergantungan pada layanan eksternal, Kegagalan berantai, Keterlambatan autoscaling, Distribusi load balancer timpang dan health check keliru, Gangguan dan latensi DNS
Sumber asli: AWS

Glosarium

Daftar pustaka

616 referensi dari 83 penerbit: dokumen standar, dokumentasi resmi kernel, OS, cloud, engine, dan DB, makalah ilmiah, serta artikel teknis dari pengembang aslinya.