Folia

Fork of Paper yang menambahkan multithreading wilayah ke server khusus.

Ringkasan

Kelompok Folia di dekatnya memuat bongkahan untuk membentuk "wilayah mandiri". Lihat dokumentasi PaperMC untuk rincian lebih lanjut tentang bagaimana Folia mengelompokkan potongan-potongan di dekatnya. Setiap wilayah independen memiliki loop centangnya sendiri, yang dicentang pada tickrate Minecraft biasa (20TPS). Loop centang dieksekusi pada kumpulan thread secara paralel. Tidak ada lagi thread utama, karena setiap wilayah secara efektif memiliki "thread utama" sendiri yang mengeksekusi seluruh tick loop.

Untuk server dengan banyak pemain yang tersebar, Folia akan membuat banyak wilayah yang tersebar dan mencentang semuanya secara paralel pada threadpool berukuran yang dapat dikonfigurasi. Oleh karena itu, Folia harus berkembang dengan baik untuk server seperti ini.

Folia juga merupakan proyeknya sendiri, ini tidak akan digabungkan ke dalam Paper di masa mendatang.

Ikhtisar yang lebih rinci namun abstrak: Ikhtisar proyek.

Pertanyaan Umum

Jenis server apa yang bisa mendapatkan keuntungan dari Folia?

Jenis server yang menyebarkan pemain secara alami, seperti skyblock atau SMP, akan mendapatkan keuntungan paling banyak dari Folia. Server juga harus memiliki jumlah pemain yang cukup besar.

Perangkat keras apa yang paling baik digunakan pada Folia?

Idealnya, minimal 16 core (bukan thread).

Bagaimana cara terbaik mengkonfigurasi Folia?

Pertama, disarankan agar dunia dibuat terlebih dahulu sehingga jumlah thread pekerja sistem chunk yang diperlukan dapat dikurangi secara signifikan.

Berikut ini adalah perkiraan kasar berdasarkan pengujian yang dilakukan sebelum Folia dirilis pada server pengujian yang kami jalankan yang memiliki puncak ~330 pemain. Jadi, ini tidak tepat dan memerlukan penyetelan lebih lanjut - anggap saja sebagai titik awal.

Jumlah total inti pada mesin yang tersedia harus diperhitungkan. Kemudian, alokasikan thread untuk:

• netty IO :~4 per 200-300 pemain
• thread io sistem potongan: ~3 per 200-300 pemain
• pekerja sistem potongan jika dibuat sebelumnya, ~2 per 200-300 pemain
• Tidak ada tebakan terbaik untuk pekerja sistem chunk jika tidak dibuat sebelumnya, karena pada server pengujian yang kami jalankan, kami memberikan 16 thread tetapi pembuatan chunk masih lambat pada ~300 pemain.
• Pengaturan GC: ???? Namun, pengaturan GC memang mengalokasikan thread secara bersamaan, dan Anda perlu mengetahui secara pasti berapa jumlahnya. Ini biasanya melalui flag -XX:ConcGCThreads=n . Jangan bingung membedakan tanda ini dengan -XX:ParallelGCThreads=n , karena thread GC paralel hanya berjalan ketika aplikasi dijeda oleh GC dan oleh karena itu tidak boleh diperhitungkan.

Setelah semua alokasi tersebut, inti yang tersisa pada sistem hingga alokasi 80% (total thread yang dialokasikan <80% dari CPU yang tersedia) dapat dialokasikan ke tickthreads (di bawah konfigurasi global, threaded-regions.threads).

Alasan Anda tidak boleh mengalokasikan lebih dari 80% inti adalah karena plugin atau bahkan server mungkin menggunakan thread tambahan yang tidak dapat Anda konfigurasi atau bahkan prediksi.

Selain itu, semua hal di atas hanyalah perkiraan kasar berdasarkan jumlah pemain, namun kemungkinan besar alokasi thread tidak ideal, dan Anda perlu menyesuaikannya berdasarkan penggunaan thread yang akhirnya Anda lihat.

Kompatibilitas plugin

Tidak ada lagi thread utama. Saya berharap setiap plugin yang ada memerlukan beberapa tingkat modifikasi agar berfungsi di Folia. Selain itu, multithreading dalam bentuk apa pun menimbulkan kemungkinan kondisi balapan dalam data yang disimpan plugin - jadi, pasti ada perubahan yang perlu dilakukan.

Jadi, perkirakan ekspektasi Anda untuk kompatibilitas pada 0.

rencana API

Saat ini banyak sekali API yang mengandalkan thread utama. Saya berharap pada dasarnya tidak ada plugin yang kompatibel dengan Paper yang kompatibel dengan Folia. Namun, ada rencana untuk menambahkan API yang memungkinkan plugin Folia kompatibel dengan Paper.

Misalnya, Penjadwal Bukkit. Penjadwal Bukkit secara inheren bergantung pada satu thread utama. RegionScheduler Folia dan EntityScheduler Folia memungkinkan penjadwalan tugas ke "centang berikutnya" di wilayah mana pun yang "memiliki" lokasi atau entitas. Ini dapat diimplementasikan pada Paper biasa, kecuali mereka menjadwalkannya ke thread utama - dalam kedua kasus tersebut, pelaksanaan tugas akan terjadi di thread yang "memiliki" lokasi atau entitas. Konsep ini berlaku secara umum, karena Paper saat ini (single threaded) dapat dipandang sebagai satu "wilayah" raksasa yang mencakup seluruh bongkahan di seluruh dunia.

Belum diputuskan apakah akan menambahkan API ini ke Paper itu sendiri secara langsung atau ke Paperlib.

Aturan baru

Pertama, Folia merusak banyak plugin. Untuk membantu pengguna dalam mengetahui plugin mana yang berfungsi, hanya plugin yang telah ditandai secara eksplisit oleh penulis untuk bekerja dengan Folia yang akan dimuat. Dengan menempatkan "didukung folia: true" ke dalam plugin.yml plugin, pembuat plugin dapat menandai plugin mereka sebagai kompatibel dengan multithreading regional.

Aturan penting lainnya adalah bahwa wilayah-wilayah tersebut dicentang secara paralel , dan tidak secara bersamaan . Mereka tidak berbagi data, mereka tidak berharap untuk berbagi data, dan berbagi data akan menyebabkan kerusakan data. Kode yang berjalan di satu wilayah dalam keadaan apa pun tidak boleh mengakses atau mengubah data yang ada di wilayah lain. Hanya karena namanya multithreading, bukan berarti semuanya sekarang aman untuk thread. Faktanya, hanya ada beberapa hal yang dibuat thread-safe untuk mewujudkan hal ini. Seiring berjalannya waktu, jumlah pemeriksaan konteks thread hanya akan bertambah, bahkan jika hal itu menyebabkan penalti kinerja - tidak ada yang akan menggunakan atau mengembangkan platform server yang sangat bermasalah, dan satu-satunya cara untuk mencegah dan menemukannya bug adalah membuat akses buruk gagal total pada sumber akses buruk.

Ini berarti plugin yang kompatibel dengan Folia perlu memanfaatkan API seperti RegionScheduler dan EntityScheduler untuk memastikan kodenya berjalan pada konteks thread yang benar.

Secara umum, dapat diasumsikan bahwa suatu wilayah memiliki data bongkahan dalam jumlah sekitar 8 bongkahan dari sumber suatu peristiwa (yaitu pemain memecahkan blok, mungkin dapat mengakses 8 bongkahan di sekitar blok tersebut). Namun, hal ini tidak dijamin - plugin harus memanfaatkan API pemeriksaan thread yang akan datang untuk memastikan perilaku yang benar.

Satu-satunya jaminan keamanan thread berasal dari fakta bahwa suatu wilayah memiliki data dalam bagian tertentu - dan jika wilayah tersebut berfungsi, maka wilayah tersebut memiliki akses penuh ke data tersebut. Data ini secara khusus adalah data entitas/potongan/poi, dan sepenuhnya tidak terkait dengan data plugin APAPUN .

Aturan multithreading normal berlaku untuk data yang plugin menyimpan/mengakses datanya sendiri atau plugin lain - acara/perintah/dll. dipanggil secara paralel karena wilayah berjalan secara paralel (kami TIDAK BISA memanggilnya secara sinkron, karena hal ini akan membuka masalah kebuntuan dan akan menghambat kinerja). Tidak ada jalan keluar yang mudah, ini hanya bergantung pada data apa yang sedang diakses. Terkadang koleksi serentak (seperti ConcurrentHashMap) sudah cukup, dan sering kali koleksi serentak yang digunakan secara sembarangan hanya akan menyembunyikan masalah threading, yang kemudian menjadi hampir mustahil untuk di-debug.

Penambahan API saat ini

Untuk memahami penambahan API dengan benar, harap baca Ikhtisar proyek.

• RegionScheduler, AsyncScheduler, GlobalRegionScheduler, dan EntityScheduler bertindak sebagai pengganti BukkitScheduler. Penjadwal entitas diambil melalui Entity#getScheduler, dan penjadwal lainnya dapat diambil dari kelas Bukkit/Server.
• Bukkit#isOwnedByCurrentRegion untuk menguji apakah wilayah yang berdetak saat ini memiliki posisi/entitas

Konteks thread untuk API

Untuk memahami penambahan API dengan benar, harap baca Ikhtisar proyek.

Aturan umum:

1. Perintah untuk entitas/pemain dipanggil di wilayah pemilik entitas/pemain tersebut. Perintah konsol dijalankan di wilayah global.

2. Peristiwa yang melibatkan satu entitas (yaitu pemain istirahat/blok tempat) dipanggil pada entitas pemilik wilayah. Peristiwa yang melibatkan tindakan pada suatu entitas (seperti kerusakan entitas) dilakukan di wilayah yang memiliki entitas target.

3. Pengubah async untuk peristiwa tidak digunakan lagi - semua peristiwa yang dipicu dari wilayah atau wilayah global dianggap sinkron , meskipun tidak ada lagi thread utama.

API yang rusak saat ini

• Sebagian besar API yang berinteraksi dengan portal/pemain respawning/beberapa API login pemain rusak.
• SEMUA API papan skor dianggap rusak (ini adalah keadaan global yang saya belum tahu cara menerapkannya dengan benar)
• Bongkar/muat dunia
• Entitas#teleportasi. Ini TIDAK AKAN PERNAH DALAM KEADAAN APAPUN kembali, gunakan teleportAsync
• Bisa lebih

Penambahan API yang direncanakan

• Peristiwa asinkron yang tepat. Ini akan memungkinkan hasil suatu peristiwa diselesaikan nanti, pada konteks thread yang berbeda. Hal ini diperlukan untuk mengimplementasikan beberapa hal seperti pemilihan posisi spawn, karena pemuatan bongkahan asinkron diperlukan saat mengakses data bongkahan di luar wilayah.
• Bongkar/muat dunia
• Lebih banyak lagi yang akan datang ke sini

Perubahan API yang direncanakan

• Pemeriksaan thread super agresif secara menyeluruh. Hal ini mutlak diperlukan untuk mencegah pengembang plugin mengirimkan kode yang dapat secara acak merusak bagian server secara acak dengan cara yang sepenuhnya tidak dapat didiagnosis .
• Lebih banyak lagi yang akan datang ke sini

informasi pakar

• Maven Repo (untuk folia-api):

< repository >
    < id >papermc</ id >
    < url >https://repo.papermc.io/repository/maven-public/</ url >
</ repository >

• Informasi Artefak:

< dependency >
    < groupId >dev.folia</ groupId >
    < artifactId >folia-api</ artifactId >
    < version >1.20.1-R0.1-SNAPSHOT</ version >
    < scope >provided</ scope >
</ dependency >

Lisensi

File PATCHES-LICENSE menjelaskan lisensi untuk api & patch server, yang terdapat di ./patches dan subdirektorinya kecuali jika dinyatakan sebaliknya.

Fork ini didasarkan pada contoh fork PaperMC yang ditemukan di sini. Oleh karena itu, ini berisi modifikasi dalam proyek ini, silakan lihat repositori untuk informasi lisensi file yang dimodifikasi.