Apa itu Spark Profiler?
Spark Profiler adalah salah satu tool administrator yang sudah dibundle ke dalam Paper.
Fungsi dari spark adalah mempermudah deteksi sumber lag yang ada di server.
Umumnya digunakan untuk mendeteksi lag spike atau lag konsisten
Catatan: Laman ini mungkin kurang ramah pemula. Penulis mencoba untuk menjelaskan secara detil dengan sesimpel mungkin, tetapi tidak bisa dibuat terlalu sederhana.
Lag Spike
Lag Spike adalah lag yang terjadi sekian detik, namun cukup parah.
Contoh kasus: Server yang berjalan 20 TPS di bawah 50 MSPT, tiba-tiba mengalami lonjakan MSPT hingga 800 dan TPS turun ke 1.2, namun lonjakan ini hanya berlangsung selama 2 detik. Namun hal ini cukup sering terjadi dalam waktu yang berdekatan, seperti "rasanya setiap beberapa menit ngelag banget deh ini."
Cara mengatasinya adalah dengan menjalankan command-command ini secara bertahap:
/spark tpsKemudian akan muncul tampilan seperti berikut:
[17:26:51 INFO]: [⚡] TPS from last 5s, 10s, 1m, 5m, 15m:
[17:26:51 INFO]: [⚡] *20.0, *20.0, 1.2, *20.0, *20.0
[17:26:51 INFO]: [⚡]
[17:26:51 INFO]: [⚡] Tick durations (min/med/95%ile/max ms) from last 10s, 1m:
[17:26:51 INFO]: [⚡] 4.2/5.8/7.6/12.5; 4.2/6.8/9.0/800.0
[17:26:51 INFO]: [⚡]
[17:26:51 INFO]: [⚡] CPU usage from last 10s, 1m, 15m:
[17:26:51 INFO]: [⚡] 7%, 8%, 9% (system)
[17:26:51 INFO]: [⚡] 7%, 8%, 9% (process)
Terlihat TPS dari last 1m berada di angka 1.2, sementara Tick durations max ms dari last 1m berada di angka 800.0.
Angka-angka lain terlihat normal (MSPT 95%ile di bawah 50ms, baik last 10s ataupun last 1m).
Maka dapat dipastikan jika ada lag spike yang telah terjadi dalam satu menit terakhir.
/spark tickmonitorSetelah dijalankan, server akan menghitung tick rata-rata server, dan akan memprint semua tick yang jauh di atas tick rata-rata server.

Tick#184 lasted 813.78ms.
Tick#318 lasted 337.26ms.
Maka lag spike terjadi di atas 300ms hingga 800ms.
/spark profiler start --timeout 300 --only-ticks-over 270Ini akan menyalakan spark profiler selama--timeout 3005 menit (300 detik) dan hanya akan melakukan profiling terhadap--only-ticks-over 270tick di atas 270ms.
Loh, kenapa 270ms tidak 800ms?
Idealnya, kita akan menurunkan angka yang diprofile, tetapi tidak terlalu jauh, supaya lag spike benar-benar terdeteksi.
Juga karena 813ms itu di atas 270ms, maka jika ada tick lain yang memakan waktu lebih lama dari 270ms bahkan hingga 10000ms sekalipun, itu akan ikut terprofile.
Setelah 5 menit, console atau chat akan menulis teks bahwa profiling sudah selesai, dan kemudian linknya akan muncul di chat. Tenang saja karena yang console dan orang yang memiliki permission spark yang bisa membaca notifikasi chat link tersebut.
- Buka hasil profiler spark
Buka dan scroll ke bawah. Jika Anda pemula, Anda tidak perlu menyetel apapun, cukup expand profile tree dengan mengklik tombol
[>] pada Server thread %.
Teruslah membuka thread dengan persentase tertinggi hingga paling task dalam.

Anda bisa melihat org.enginehub.piston.CommandManager.execute() 4.23% di dalam com.sk89q.bukkit.util.DynamicPluginCommand.execute() 5.30% 1362.65ms (WorldEdit) yang diikuti dengan com.sk89q.worldedit.bukkit.WorldEditPlugin.onCommand() 5.30%
org.enginehub.piston adalah Package Java, CommandManager adalah class, dan .execute() adalah method.
com.sk89q.bukkit.util package, DynamicPluginCommand class, .execute() method, (WorldEdit) adalah nama plugin.
com.sk89q.worldedit.bukkit package, WorldEditPlugin class, .onCommand() method.
Maka, terdapat command WorldEdit dari developer sk89q yang mengeksekusi sesuatu dan memakan tick 1362.65ms atau sebanyak 5.30% dari total server tick.
- Tindakan
Setelah ditemukan bahwa penyebabnya adalah command WorldEdit, maka langkah yang bisa dilakukan salah satunya adalah membatasi akses command WorldEdit dan membatasi jumlah block yang diperbolehkan pada setiap pemrosesan WorldEdit.
Jumlah block atau pembatasan lainnya dapat ditemukan di dalam config worldedit di /home/container/plugins/worldedit/config.yml.
Catatan: Ini hanyalah salah satu contoh kasus. Penyebab lag spike sangat beragam tergantung pada kondisi masing-masing server.
Lag Konstan
Berbeda dari lag spike, lag konstan terjadi secara terus-menerus.
Umumnya, CPU server tidak kuat menghandle task-task yang dijalankan oleh plugin ataupun Minecraft server itu sendiri.
Namun sering juga masalah ini disebabkan oleh plugin yang memang optimisasi event, task, dan loopingnya buruk.
/spark tpsKemudian akan muncul tampilan seperti berikut:
[17:26:51 INFO]: [⚡] TPS from last 5s, 10s, 1m, 5m, 15m:
[17:26:51 INFO]: [⚡] 11.6, 16.7, 13.5, 10.9, 12.1
[17:26:51 INFO]: [⚡]
[17:26:51 INFO]: [⚡] Tick durations (min/med/95%ile/max ms) from last 10s, 1m:
[17:26:51 INFO]: [⚡] 27.1/61.5/74.3/136.8; 39.2/65.8/73.0/101.0
[17:26:51 INFO]: [⚡]
[17:26:51 INFO]: [⚡] CPU usage from last 10s, 1m, 15m:
[17:26:51 INFO]: [⚡] 79%, 87%, 90% (system)
[17:26:51 INFO]: [⚡] 79%, 87%, 90% (process)
Terlihat bahwa CPU Usage dari last 1m adalah 87%, dan dari last 15m adalah 90%.
CPU bekerja terlalu keras.
Juga terlihat bahwa tick duration 95%ile dari last 10s adalah 74.3 disusul dengan last 1m sebesar 73.0.
Artinya rata-rata tick server memerlukan waktu 71ms-75ms untuk diproses.
Standarnya adalah tick server memerlukan waktu di bawah 50ms untuk diproses.
/spark profiler start --timeout 600 --only-ticks-over 51
Ini akan menyalakan spark profiler selama --timeout 600 10 menit (600 detik) dan hanya akan melakukan profiling terhadap --only-ticks-over 51 tick di atas 51ms.
Mengapa 51ms dan bukan 73ms? Dan kenapa bukan 50ms?
50ms akan menghasilkan hasil yang ngepas, sehingga kita beri buffer sebesar 1 ms tambahan.
Sama seperti lag spike, kita turunkan angkanya sedikit supaya ruang sampelnya menjadi lebih banyak.
- Buka hasil profiler spark.
Tahap ini mirip seperti pada pembacaan untuk lag spike.
Selain percentage, Anda juga bisa mengubah thread task tree menjadi Time per Tick dengan mengganti Label: Percentage ke Label: Time per Tick. Ini akan membuat Anda lebih mudah membayangkan suatu task membutuhkan waktu berapa milisecond.

Terlihat bahwa class NaturalSpawner melakukan spawnForChunk selama 27.65ms, sekitar setengah dari ServerChunkCache.tickChunks.
Maka penyebabnya adalah dua kemungkinan:
Kemungkinan pertama adalah CPU server tidak kuat menahan beban generate fresh chunk, dan kemungkinan ada banyak pemain yang sedang melakukan eksplor ke tempat-tempat yang belum pernah dijelajahi sebelumnya.
Kemungkinan kedua adalah simulation distance dan/atau view distance server terlalu jauh. Ini juga berkontribusi ke kemungkinan sebelumnya, namun hanya di world yang belum pernah dilakukan pregenerate. Karena task spawnForChunk biasanya hanya ditemukan untuk mempopulasikan chunk-chunk yang baru digenerate dengan beragam mob seperti animal ataupun hostile.
- Tindakan
Setelah mengetahui hasil profiling dan mempetakan beragam kemungkinan, saatnya melakukan tindakan.
Lakukan pregenerate chunk menggunakan plugin Chunky. Tidak perlu terlalu besar, secukupnya saja seperti radius 1000 hingga 2000 block dari center. Untuk menghitung perkiraan size world, gunakan World Size Calculator.
Turunkan simulation-distance= di server.properties ke 5. Juga turunkan view-distance= ke 8.
Lebih lengkap: Setelan Ajaib Lancar
Informasi Lainnya
Ada beberapa hal lainnya yang bisa Anda manfaatkan dari spark profiler.
Anda bisa membaca graphnya dengan tampilan Flame Graph dengan mengklik tombol api di bagian atas laman spark profiler Anda.
Anda bisa melihat beragam grafik sekaligus seperti CPU (process), CPU (system) TPS, MSPT, Players, Entities, Tile Entities, Chunks, dan melihat apakah ada korelasi antara satu grafik dengan lainnya.
Anda bisa melihat settingan konfigurasi server.
Anda bisa melihat plugin dan datapack yang digunakan di server.
Anda bisa melihat server implementation dan juga spesifikasi singkat mesin server.
Daftar Pustaka:
Lucko. finding the cause of lag spikes.
Suntingan Termutakhir: 13 Desember 2025.
Penulis: Jan Wafa Karsiena. Lisensi: CC BY-SA 4.0.