Buku Putih Lag Game › L12 Database

Lock akibat perubahan skema (DDL) saat layanan berjalan Schema change lock (DDL / metadata lock)

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

Buka kartu interaktif dengan gambar dan simulasi →

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.

Sumber

1. 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
2. Server System Variables MySQL
   lock_wait_timeout: batas waktu tunggu metadata lock, default 31.536.000 detik (1 tahun)
3. ALTER TABLE (PostgreSQL Documentation) PostgreSQL
   ALTER TABLE tanpa keterangan khusus memegang lock ACCESS EXCLUSIVE yang paling kuat
4. Client Connection Defaults (PostgreSQL Documentation) PostgreSQL
   lock_timeout: statement dibatalkan jika menunggu lock lebih lama dari waktu ini
5. General Thread States MySQL
   Waiting for table metadata lock: status thread yang sedang menunggu metadata lock
6. 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)
7. pg_locks (PostgreSQL Documentation) PostgreSQL
   granted bernilai false berarti sedang menunggu lock; mode berisi jenis lock seperti AccessExclusiveLock
8. System Information Functions and Operators (PostgreSQL Documentation) PostgreSQL
   pg_blocking_pids(): daftar sesi yang menghalangi sesi tertentu mendapatkan lock

Lihat juga

Lapisan yang sama: L12 Database

• Query tanpa indeks
• Perebutan lock pada hot row
• Deadlock DB
• Connection pool habis
• Replication lag
• Checkpoint dan log flush
• Cold cache (tepat setelah restart)
• Lonjakan login dan N+1 query
• Batch job berskala besar
• Failover DB
• Progres hilang karena interval penyimpanan yang panjang
• Cache stampede
• Transaksi yang terbuka lama
• Perintah lambat di Redis
• Query melambat karena query plan berubah

Penyebab di lapisan lain dengan gejala yang sama (Input lag)

• Beban rendering kerumunan besar L1 Proses game di klien
• Bottleneck pemrosesan paket di main thread L1 Proses game di klien
• V-Sync dan antrean render L1 Proses game di klien
• Mode hemat daya dan thermal throttling L2 OS dan perangkat klien
• Pemakaian bandwidth oleh aplikasi lain di perangkat yang sama L2 OS dan perangkat klien
• Latensi layar, perangkat input, dan frame generation L2 OS dan perangkat klien
• Channel Wi-Fi padat L3 Jaringan rumah
• Bufferbloat (antrean router) L3 Jaringan rumah

Lihat kartu interaktif dengan gambar dan simulasi