Cara Mengatasi Lag Server Minecraft: Panduan Optimasi Paper

Lag adalah keluhan nomor satu di hampir setiap server Minecraft, dan juga hal yang paling sering disalahartikan. Reaksi pertama kebanyakan pemilik server selalu sama: tambah RAM. Padahal di mayoritas kasus, RAM bukan biang masalahnya, dan menambahnya tidak mengubah apa-apa selain tagihan bulanan.

Panduan ini adalah titik awal untuk membereskan lag di server berbasis Paper secara benar. Bukan dengan menyalin config ajaib dari internet, tapi dengan memahami apa yang sebenarnya membebani server, cara mengukurnya, lalu menyetel tuas yang paling berpengaruh. Anggap ini peta besarnya; panduan lain di MSID membahas tiap bagian lebih dalam.

Ukur dulu, jangan menebak: MSPT, bukan TPS

Sebelum mengubah satu baris config pun, kamu harus bisa mengukur. Tanpa angka, kamu cuma menebak, dan menebak biasanya berujung mengubah hal yang salah.

Minecraft berjalan pada laju tetap 20 tick per detik. Artinya server punya jatah 50 milidetik untuk menyelesaikan satu tick (1000 ms dibagi 20). Selama satu tick selesai di bawah 50 ms, server santai dan tetap di 20 TPS. Begitu sebuah tick butuh lebih dari 50 ms, tick itu telat, dan TPS mulai turun di bawah 20.

Di sinilah banyak orang tertipu. TPS adalah angka rata-rata, dan rata-rata menyembunyikan masalah. Server bisa menunjukkan "20 TPS" tapi tetap terasa patah-patah, karena di antara tick-tick yang mulus ada lonjakan berat yang langsung dirasakan pemain. Yang menangkap lonjakan itu adalah MSPT (milliseconds per tick), yaitu berapa lama tiap tick benar-benar berjalan.

Pegang ini sebagai patokan:

• MSPT konsisten di bawah 50 ms: sehat. Server punya napas.
• MSPT sering menyentuh atau melewati 50 ms: server kewalahan, dan pemain merasakannya, berapa pun TPS rata-ratanya.
• Sesekali sedikit lewat 50 ms saat jam ramai masih wajar. Yang berbahaya adalah pola yang terus-menerus tinggi.

Intinya: berhenti mengejar angka TPS, mulai pantau MSPT.

Temukan biang lag dengan Spark

Spark adalah alat diagnosa standar untuk server Minecraft, dan wajib dipasang sebelum kamu menyetel apa pun. Spark mengubah "rasanya lag" menjadi data yang bisa dibaca. Plugin ini juga sudah masuk daftar plugin wajib server.

Untuk pembacaan cepat:

• /spark tps menampilkan TPS dan penggunaan CPU.
• /spark health memberi laporan ringkas berisi TPS, MSPT, CPU, memori, dan disk. Inilah cara tercepat melihat MSPT aktualmu.

Untuk diagnosa mendalam saat server benar-benar lag, jalankan profiler:

/spark profiler start --only-ticks-over 300 --timeout 300

Perintah itu merekam hanya tick yang lebih berat dari 300 ms selama 300 detik, lalu menghasilkan laporan web yang bisa kamu buka di browser. Beberapa aturan agar laporannya berguna:

• Jangan merekam tepat setelah server restart. Data saat startup tidak mewakili kondisi normal dan hasilnya menyesatkan.
• Rekam saat jam ramai atau saat lag terjadi, minimal sekitar 3 menit, supaya pola yang sebenarnya tertangkap.
• Baca dalam konteks. Persentase besar pada satu kategori tidak otomatis berarti masalah. Yang kamu cari adalah bagian yang benar-benar tidak wajar.

Tersangka yang paling sering muncul di laporan Spark adalah pemrosesan entity (mob, item, projectile), pemuatan chunk, dan mob spawning. Tiga hal itu menentukan ke mana kamu mengarahkan optimasi berikutnya.

Tidak ada config ajaib

Sebelum masuk ke setelan, satu prinsip yang menyelamatkanmu dari banyak kesalahan: tidak ada satu config yang cocok untuk semua server. Setelan ideal bergantung pada hardware, jumlah pemain, dan jenis gameplay-mu. Config yang membuat server survival 40 pemain mulus bisa jadi buruk untuk server skyblock atau minigame.

Tiga kenyataan yang perlu kamu terima:

• Setiap perubahan punya tradeoff. Menurunkan beban server hampir selalu berarti mengubah sesuatu di sisi gameplay. Tidak ada optimasi yang benar-benar gratis; yang ada adalah kompromi yang kamu pilih secara sadar.
• Optimasi itu pekerjaan berkelanjutan, bukan sekali jadi. Seiring dunia menua dan pemain masuk ke late game, beban server naik sendiri. Server yang mulus bulan ini bisa berat tiga bulan lagi tanpa kamu mengubah apa pun.
• Pada titik tertentu, hardware-lah batasnya. Setelah semua config disetel, tetap ada plafon. Tidak ada config yang bisa membuat CPU lemah menampung 100 pemain aktif dengan gameplay mendekati vanilla.

Maka jangan menyalin file config orang lain bulat-bulat. Pahami tiap setelan, lalu sesuaikan dengan servermu sendiri.

Dua tuas terbesar: view-distance dan simulation-distance

Kalau hanya ada dua setelan yang kamu sentuh, jadikan keduanya ini. Inilah dua tuas dengan dampak performa terbesar, dan keduanya sering dibiarkan di nilai default 10.

Keduanya terdengar mirip tapi mengerjakan hal yang sangat berbeda:

• view-distance menentukan seberapa jauh terrain dikirim ke pemain, yaitu seberapa luas dunia yang terlihat. Setelan ini lebih ringan di CPU, tapi memakan lebih banyak RAM karena lebih banyak chunk yang dipegang.
• simulation-distance menentukan seberapa luas area di sekitar pemain yang benar-benar aktif (di-tick): mob bergerak, redstone jalan, tanaman tumbuh, air mengalir. Di luar radius ini, dunia praktis membeku sampai ada pemain mendekat. Setelan inilah yang paling berat membebani CPU.

Karena tiap pemain memuat sebuah area chunk di sekelilingnya, biayanya naik cepat. Paper memuat radius chunk sebesar view-distance ditambah dua chunk border, sehingga jumlah chunk per pemain mengikuti rumus [(view-distance + 2) x 2 + 1]^2:

• view-distance 10: sekitar 625 chunk per pemain.
• view-distance 8: sekitar 441 chunk per pemain.
• view-distance 5: sekitar 225 chunk per pemain.

Bayangkan angka itu dikalikan jumlah pemain online. Menurunkan distance adalah cara tercepat dan paling ampuh mengurangi beban.

Aturan praktisnya:

• simulation-distance harus selalu sama atau lebih kecil dari view-distance. Tidak ada gunanya men-tick area yang lebih luas dari yang terlihat.
• Jangan turunkan di bawah 5. Lebih rendah dari itu, gameplay mulai terasa rusak.
• Kombinasi yang umum dan aman untuk server ramai adalah view-distance 8 dengan simulation-distance 5: pemain tetap melihat cukup jauh, tapi area yang di-tick jauh lebih kecil.

Tradeoff-nya nyata: dengan simulation-distance rendah, mob dan redstone di luar radius berhenti jalan, sehingga sebagian desain farm yang dibuat untuk default vanilla tidak lagi berfungsi. Itu harga yang biasanya sepadan demi server yang mulus, tapi pemainmu perlu tahu.

Kesalahan dan mitos yang bikin server tetap lag

Banyak server tetap lag bukan karena kurang dioptimasi, tapi karena energinya habis untuk hal yang salah. Ini yang paling umum:

• "Tambah RAM pasti lebih kencang." Salah. Performa server hampir sepenuhnya ditentukan CPU, bukan RAM. Mayoritas server baik-baik saja dengan sekitar 10 GB RAM, berapa pun jumlah pemain atau plugin-nya. RAM hanya perlu cukup; menambahnya di atas kebutuhan tidak membuat tick lebih cepat. Hosting yang menjanjikan "RAM lebih besar = server lebih kencang" sedang menjual sesuatu yang tidak akan menolongmu.
• "Penggunaan RAM tinggi berarti ada memory leak." Tidak selalu. Pada JVM yang disetel benar, angka penggunaan RAM di panel atau htop nyaris tidak bermakna, karena JVM memang sengaja mengisi heap sebelum membersihkannya. Yang perlu dipantau adalah jeda dan durasi garbage collection (GC), bukan persentase RAM terpakai. RAM tinggi bukan berarti bocor.
• "CPU dengan GHz lebih besar pasti lebih cepat." Jangan membandingkan dua CPU lewat angka clock speed kecuali keduanya model dan generasi yang sama. Yang menentukan adalah arsitektur terbaru dan performa single-core tertinggi. Game loop utama Minecraft berjalan di satu thread, jadi kecepatan satu inti jauh lebih penting daripada jumlah inti.
• "Satu thread saja sudah cukup karena Minecraft single-threaded." Game loop memang satu thread, tapi banyak tugas lain (jaringan/Netty, plugin, database SQL, sistem chunk, GC) memanfaatkan thread tambahan. Minimal 4 thread/core adalah rekomendasi yang wajar.

Singkatnya: belanja CPU dengan single-core kencang dan generasi baru, beri RAM secukupnya, lalu habiskan waktumu menyetel config, bukan menambah hardware yang tidak menyelesaikan masalah.

Langkah selanjutnya

Urutan yang sehat untuk mengatasi lag selalu sama: ukur dulu, baru ubah.

1. Pasang Spark, pantau MSPT (bukan TPS), dan jalankan profiler saat lag untuk tahu biang sebenarnya.
2. Setel view-distance dan simulation-distance ke nilai yang masuk akal (misalnya 8 dan 5).
3. Kendalikan entity dan mob, yang biasanya menjadi beban terberat berikutnya setelah distance.
4. Pre-generate map supaya server tidak tersendat saat pemain menjelajah area baru.
5. Beri server hardware yang tepat: CPU single-core kencang, RAM secukupnya.

Tiap langkah di atas akan dibahas tuntas di panduan terpisah dalam seri optimasi ini. Untuk sekarang, mulai dari yang paling cepat berdampak: pasang plugin wajib seperti Spark lalu ukur MSPT-mu. Kalau servermu adalah sebuah network, baca juga cara setup Velocity.

Server yang mulus adalah fondasi dari server yang ramai. Setelah lag beres, lanjutkan ke cara menambah pemain server, dan daftarkan servermu di MSID supaya pemain Indonesia mulai menemukannya di daftar server Minecraft Indonesia.

Selamat mengoptimasi servermu!