Tối Ưu Leaf Cho Server SMP - Hướng Dẫn Async, DAB, Chunk và Performance

Leaf không chỉ là Paper với một cái tên khác. Điểm đáng chú ý của Leaf nằm ở cách nó mở rộng server tick: một số công việc có thể chuyển sang worker thread (luồng phụ), một số AI được giảm tần suất khi ở xa người chơi, còn dữ liệu world có thể dùng định dạng region khác. Main thread là luồng xử lý tick chính; I/O là việc đọc và ghi dữ liệu world trên ổ đĩa. Mỗi lựa chọn đều có giá của nó: thêm worker có thể tranh CPU với main thread, DAB có thể làm farm ở xa hoạt động khác, còn Linear có thể ảnh hưởng khả năng khôi phục world.

Vì vậy, tối ưu Leaf cho máy chủ SMP không nên bắt đầu bằng việc dán một file config lớn. Cách thực tế hơn là trả lời lần lượt ba câu hỏi:

1. Server đang chậm ở main thread, chunk I/O, entity AI hay plugin?

2. Leaf có module nào xử lý đúng phần đó mà không phá gameplay server đang cam kết?

3. Sau khi đổi, số liệu và hành vi trong game có tốt hơn trong cùng một kịch bản không?

Bài viết này xây dựng một playbook riêng cho Leaf: từ lúc chuyển từ Paper, phân bổ module async, kiểm soát DAB và mob spawning, đến cách thử region format mà không đặt world chính vào rủi ro.

Mốc kiểm tra 04/10/2026: GitHub Releases của Leaf đang liệt kê Leaf 26.3 build 2 là bản mới nhất, phát hành ngày 03/10/2026, nhưng được ghi rõ là early dev build chỉ dành cho thử nghiệm và không nên dùng production. Nhánh Leaf 26.2 build 123 ngày 25/09/2026 cũng mang cảnh báo early-dev. README/API nhánh 26.2 dùng Java 25. Vì Leaf thay đổi nhanh, hãy kiểm tra đúng release, build, Java và config trước mỗi lần nâng cấp.

Quick Start — 30 phút

1. Backup server, world, plugin và thư mục config/.

2. Giữ config Leaf mặc định trong vòng benchmark đầu tiên.

3. Chạy Spark khoảng 10 phút trong workload thật: bay, farm hoặc giờ đông người.

4. Xác định hotspot: chunk, entity, pathfinding, plugin, GC hay I/O.

5. Chọn một module hoặc một setting khớp với hotspot đó.

6. Restart server nếu module yêu cầu restart.

7. Chạy lại đúng workload cũ, với cùng số người và cùng tuyến kiểm tra.

8. So sánh MSPT p95/max và các lag spike.

9. Kiểm tra farm, plugin và gameplay contract.

10. Giữ thay đổi nếu số liệu và gameplay cùng tốt hơn; rollback nếu không.

Nếu bạn chưa biết server lag ở đâu, đừng bắt đầu bằng config. Hãy bắt đầu bằng Spark.

Leaf có phải lựa chọn phù hợp cho server của bạn?

Leaf đáng thử khi server có một trong các đặc điểm sau:

• Nhiều người chơi bay, teleport hoặc khám phá cùng lúc và main thread bị dồn ở chunk send.

• Mob AI, pathfinding (tính đường đi cho mob) hoặc entity tracker (theo dõi entity nào được gửi tới người chơi) chiếm nhiều thời gian trong Spark.

• Bạn muốn giữ hệ sinh thái plugin Paper nhưng cần thêm các công tắc async và tối ưu sâu hơn.

• Bạn có quy trình backup, server test và người có thể kiểm tra farm/plugin sau mỗi thay đổi.

Leaf chưa phải lựa chọn hợp lý nếu bạn chỉ muốn “cài vào là nhanh hơn” nhưng không có bản sao để test, hoặc server phụ thuộc nặng vào plugin NMS/packet chưa có support cho Leaf. Trong trường hợp đó, Paper ổn định hơn thường đáng giá hơn một vài phần trăm benchmark.

Leaf công bố khả năng tương thích plugin Spigot/Paper trong README chính thức. Điều đó là mục tiêu API, không phải bảo đảm mọi plugin chạy giống hệt: NPC, ProtocolLib, plugin dùng NMS và plugin giả định entity tracker chạy đồng bộ vẫn cần test riêng.

Mô hình hiệu năng của Leaf: main thread và worker thread

Minecraft vẫn có một server thread phải hoàn thành tick. Leaf không làm giới hạn 50 ms biến mất; nó tìm cách đưa một phần công việc ra khỏi luồng đó. Điều này chỉ có lợi khi CPU còn dư và công việc có thể tách an toàn.

Hãy hình dung server có hai ngân sách:

• Ngân sách tick: thời gian main thread xử lý gameplay trong mỗi tick.

• Ngân sách phụ: CPU và bộ nhớ dành cho async task, I/O, packet, profiler và plugin.

Bật mọi module async có thể làm ngân sách phụ tranh CPU với ngân sách tick. Vì vậy, câu hỏi “bật được không?” kém hữu ích hơn “Spark đang cho thấy phần nào cần chuyển luồng, và CPU còn bao nhiêu khoảng trống?”.

Đo một baseline nhỏ nhưng có ý nghĩa

Không cần chạy profiler cả ngày. Chọn ba kịch bản đại diện cho server của bạn:

Trong từng kịch bản, ghi MSPT (milliseconds per tick, thời gian xử lý một tick) trung bình, p95, max, TPS thấp nhất, CPU main thread và lỗi log. Theo hướng dẫn TPS/MSPT của Spark, Minecraft cần khoảng 50 ms cho mỗi tick để duy trì 20 TPS; MSPT vượt 50 ms kéo dài có thể khiến TPS giảm. Có thể dùng:

/spark tps
/spark profiler start --timeout 600
/spark tickmonitor --threshold-tick 50
/spark profiler --only-ticks-over 100
/spark gcmonitor

Spark không phải phần “trang trí” của bài tối ưu. Nó là cách quyết định nên đụng vào async-chunk-send, async-pathfinding, DAB hay plugin. Nếu report không chỉ ra module liên quan, đừng bật module đó chỉ vì một bảng config trên mạng khuyên nên bật.

Bản đồ cấu hình Leaf 26.2

Leaf kế thừa nhiều lớp cấu hình. Hãy xem file do đúng build tạo ra là nguồn chính; các bài hướng dẫn cũ có thể dùng leaf.yml hoặc tên setting đã bị chuyển.

Trong Leaf 26.2, source LeafConfig xác định file riêng là config/leaf-global.yml và config-version: 3.0; tài liệu Leaf Global Config mô tả cấu trúc file này. Lệnh /leaf reload không reload được toàn bộ module async; sau khi đổi async, hãy restart server. Không tạo thủ công một file config “đủ mọi setting” từ bài khác rồi kỳ vọng Leaf tự hiểu.

Playbook 1: xử lý chunk trước khi đụng AI

Với SMP, chunk là nơi dễ nhìn thấy lợi ích của Leaf nhất: người chơi vào world, teleport, bay nhanh hoặc mở bản đồ mới. Nhưng cần phân biệt ba công đoạn:

• Generate: tính địa hình/structure cho chunk chưa có.

• Load: đọc chunk đã tồn tại từ ổ đĩa.

• Send: chuẩn bị và gửi packet tới client.

Spark hoặc log có thể cho thấy công đoạn nào nặng. async-chunk-send chỉ nhắm vào công đoạn chuẩn bị/gửi, không thay thế CPU tạo terrain và không làm ổ đĩa nhanh hơn.

Thử async chunk send có kiểm soát

Theo tài liệu Leaf Global Config hiện hành, async-chunk-send mặc định false. Nếu profile chỉ ra spike lúc join, teleport hoặc Elytra, có thể thử:

# config/leaf-global.yml
async:
  async-chunk-send:
    enabled: true

Sau khi restart, kiểm tra bốn điểm:

1. Người chơi có vào world nhanh hơn hay chỉ chuyển lag sang CPU phụ?

2. Client chậm có nhận chunk ổn định không?

3. Anti-cheat, plugin map, NPC và plugin packet có log lỗi không?

4. MSPT p95/max trong cùng tuyến bay có giảm không?

Nếu vấn đề là generate, hãy giới hạn vùng bằng world border và pregenerate có kế hoạch. Pregeneration chuyển chi phí sang giờ bảo trì; nó không làm entity ticking, packet send hay plugin nhẹ hơn. Đừng pregenerate toàn bộ thế giới vô hạn chỉ để che một lần mở map.

Setup View Distance theo như nào?

Thay vì coi View Distance là một con số tối ưu, hãy thống nhất với người chơi server cần nhìn xa bao nhiêu và farm cần hoạt động ở khoảng cách nào. Một mốc thử cho SMP vừa là:

view-distance=8
simulation-distance=6

Giảm view-distance chủ yếu giảm số chunk phải giữ/gửi. Giảm simulation-distance giảm số chunk thực sự tick, nên thường tác động tới MSPT rõ hơn nhưng có thể làm farm, crop, villager và redstone ngừng sớm. Đổi từng giá trị, rồi kiểm tra gameplay trước khi kết luận.

Playbook 2: bật async theo triệu chứng

Không có một “Leaf config tối ưu” dùng chung. Các giá trị trong cột Mặc định dưới đây là fact lấy từ source Leaf 26.2; cột Nên thử khi là khuyến nghị của bài, không phải cam kết hiệu năng chính thức của Leaf.

Mob spawning: lợi ích có điều kiện

Theo source AsyncMobSpawning, async-mob-spawning chuyển một số phép tính chuẩn bị sang worker; thao tác spawn thực tế không trở thành hoàn toàn async. Nó cần Paper per-player-mob-spawns: true theo tài liệu world configuration của Paper để phát huy đúng mục đích.

Vì source trên đặt setting này là true mặc định ở Leaf 26.2, việc cần làm thường không phải “bật nó”, mà là xác minh nó không làm sai farm:

• Đo cùng khu vực, cùng số người và cùng thời lượng.

• So sánh mob cap, tốc độ spawn và sản lượng farm.

• Kiểm tra Nether/End, nơi tải spawn có thể khác Overworld.

• Nếu Spark không có hotspot mob spawning, giữ nguyên và chuyển sang nguyên nhân khác.

Pathfinding: bắt đầu từ queue, không bắt đầu từ thread count

Nếu profiler chỉ ra mob pathfinding là nút thắt, có thể thử:

async:
  async-pathfinding:
    enabled: true
    reject-policy: CALLER_RUNS

CALLER_RUNS giới hạn việc đẩy task mới bị tràn queue về thread gọi. FLUSH_ALL có thể làm nhiều task chờ cùng chạy trên server thread, tạo lag spike lớn. Để max-threads: 0 ở vòng đầu để Leaf tự tính pool bảo thủ; chỉ tăng sau khi đo được pathfinding còn nặng và CPU phụ còn dư.

Sau khi bật, đi qua trading hall, khu breeder và mob farm. Mob đi đường khác, villager đứng lâu hơn hoặc farm giảm sản lượng là lý do hợp lệ để rollback, ngay cả khi MSPT đẹp hơn.

Entity tracker: module experimental, không phải quick win

async-entity-tracker được đánh dấu experimental trong source MultithreadedTracker. Nó có thể hữu ích khi rất nhiều entity tập trung trong một vùng, nhưng rủi ro nằm ở metadata, visibility và NPC. Chỉ thử khi Spark chứng minh đây là bottleneck, rồi kiểm tra NPC không biến mất, tab list/armor cập nhật, teleport và packet plugin.

Parallel world ticking: chỉ dành cho bài toán nhiều world

parallel-world-ticking nhắm tới các server có nhiều world có thể tick song song. Source của module đánh dấu đây là experimental. Với SMP một Overworld, nó thêm độ phức tạp nhưng không giải quyết nguyên nhân chính; chỉ thử khi bạn có benchmark và test concurrency riêng.

Playbook 3: giảm AI xa người chơi mà không phá farm

performance.dab (Dynamic Activation of Brain, cơ chế giảm tần suất AI của entity ở xa người chơi) làm entity ở xa người chơi tick AI thưa hơn. Đây là tối ưu rất “đặc trưng Leaf”: hiệu quả thường đến từ việc bỏ bớt công việc không cần thiết, nhưng nó cũng tác động trực tiếp tới cảm giác sống động của world.

DAB mặc định false theo source DynamicActivationofBrain. Nếu Spark cho thấy AI của entity xa người chơi là hotspot, hãy thử:

performance:
  dab:
    enabled: true
    start-distance: 12
    max-tick-freq: 20
    activation-dist-mod: 8

Source DynamicActivationofBrain mặc định blacklist villager, axolotl, hoglin, zombified_piglin và goat. Đừng xóa villager khỏi blacklist để lấy thêm hiệu năng nếu server có trading hall hoặc iron farm. Hãy kiểm tra:

• Villager có restock và nhận workstation không.

• Golem farm có còn đúng sản lượng không.

• Mob trong Nether có thay đổi hành vi không.

• Entity ở dưới nước có bị xử lý khác không.

• Người chơi có thấy mob “đứng hình” khi đứng xa farm không.

Leaf cũng có các lựa chọn như skip-ai-for-non-aware-mob và optimize-block-entities; không nên thay đổi chúng chỉ vì tên nghe có vẻ tối ưu. Hãy để Spark cho biết còn phần nào đáng động vào.

Playbook 4: gameplay contract cho hopper, redstone và item

Một server SMP không chỉ được đánh giá bằng MSPT. Người chơi còn quan tâm sorter có chạy, hopper có hút đúng, redstone có giữ timing và item có mất hay không. Với Leaf, hãy coi các cơ chế này là gameplay contract: mỗi thay đổi phải ghi rõ điều gì được phép khác Vanilla.

Leaf 26.2 có gameplay.use-vanilla-hopper, tối ưu powered rail, item merging và các tùy chọn block state. Không bật use-vanilla-hopper chỉ vì từ “vanilla” nghe an toàn; hãy đọc comment được Leaf sinh trong file đúng build và test:

• Hopper clock chạy 15 phút.

• Sorter xử lý item liên tục và khi container đầy.

• Minecart hopper đi qua nhiều đoạn rail.

• Farm redstone có timing ngắn.

• Plugin shop nhận event inventory bình thường.

Nếu Spark chỉ ra hopper/block entity, sửa thiết kế trước: bỏ chuỗi hopper thừa, tránh clock chạy 24/7, chia khu farm và xử lý container đầy. Tối ưu config chỉ là bước sau.

Không dùng plugin “clear lag” quét xóa entity toàn server theo lịch. Một lệnh xóa hàng loạt có thể làm mất item và chính nó tạo spike. Với item rơi, hãy xử lý nguồn sinh item và khu vực thu gom trước.

Random generator, slime chunk và seed parity

performance.faster-random-generator là ví dụ rõ nhất cho việc tối ưu không đồng nghĩa “miễn phí”. Leaf có thể dùng Xoroshiro128PlusPlus trên JVM hỗ trợ, nhưng source cảnh báo vị trí slime chunk có thể bị lệch.

Với world đang có slime farm, nếu bạn chủ động bật faster RNG thì giữ random legacy cho slime chunk:

performance:
  faster-random-generator:
    enabled: true
    enable-for-worldgen: false
    use-legacy-random-for-slime-chunk: true

Không bật enable-for-worldgen trên world hiện tại nếu cần seed parity với Vanilla. Nó có thể thay đổi terrain, ore và structure. Tùy chọn misc.secure-seed.enabled cũng là quyết định về seed cracking/world generation, không phải giải pháp giảm MSPT.

Region format: tối ưu dung lượng không phải tối ưu tick

Theo source RegionFormatConfig, Leaf hỗ trợ MCA, B_LINEAR và LINEAR_V2, trong đó MCA là mặc định. Đây cũng là lựa chọn thận trọng cho world production:

misc:
  region-format:
    format-name: MCA

Linear dùng Zstandard và có thể tiết kiệm dung lượng, nhưng source trên cảnh báo LINEAR_V2 không ổn định và có nguy cơ mất dữ liệu. Đừng đổi format để chữa lag tick; đó là bài toán lưu trữ/I/O riêng.

Nếu thật sự cần thử Linear:

1. Dừng server hoàn toàn và tạo backup offline của world.

2. Thử trên bản sao có cùng plugin và cùng workload.

3. Kiểm tra restart, rollback, chunk save, player data và POI.

4. Chuẩn bị đường quay lại MCA trước khi ghi world mới.

Network và compatibility budget

network.OptimizeNonFlushPacketSending mặc định false và source module ghi rõ không tương thích với ProtocolLib, có thể ảnh hưởng plugin can thiệp packet. Giữ false nếu server dùng ProtocolLib, anti-cheat, NPC packet hoặc plugin map:

network:
  OptimizeNonFlushPacketSending: false

Các mục network.protocol-support như Jade, AppleSkin, Xaero Map và Syncmatica là cầu nối protocol cho client mod, không phải công tắc tăng TPS. Chỉ bật khi server thật sự cần chúng. chat-message-signature liên quan secure chat và report, không nên thay đổi chỉ vì đang tìm cách giảm lag.

Chuyển từ Paper sang Leaf mà không biến production thành phòng thí nghiệm

Đừng thay file JAR trên world duy nhất rồi quan sát bằng cảm giác. Staging ở đây là bản sao của server dùng để thử; một lần migration có thể tách thành bốn vòng:

Vòng A: tương thích cơ bản

• Sao chép world và plugin sang staging.

• Chạy Leaf với config mặc định.

• Kiểm tra startup, console, login, teleport, plugin load và save.

Vòng B: tải thực tế

• Tái hiện bay/teleport, farm và giờ đông người.

• Lưu Spark report và log.

• So sánh MSPT p95/max với Paper bằng cùng seed, plugin và số người.

Vòng C: một module Leaf

• Chỉ bật module khớp hotspot, ví dụ async-chunk-send.

• Restart, chạy lại đúng kịch bản.

• Ghi hiệu năng và lỗi gameplay.

Vòng D: quyết định rollout

• Giữ Leaf nếu hiệu năng tốt hơn mà contract gameplay không đổi.

• Rollback nếu lợi ích nhỏ hơn rủi ro plugin/farm.

• Chỉ đưa config đã kiểm thử lên production, kèm backup và kế hoạch quay lại Paper.

Checklist riêng cho Leaf

Trước migration

1. Kiểm tra release có được hỗ trợ hay đang ghi early-dev/unsupported.

2. Dùng Java đúng nhánh và test restore backup.

3. Lập danh sách plugin NMS, ProtocolLib, NPC, anti-cheat và map.

4. Chụp baseline Paper bằng cùng ba kịch bản tải.

5. Giữ MCA, DAB, entity tracker và parallel ticking ở trạng thái an toàn ban đầu.

Khi tuning

1. Đổi một module Leaf mỗi vòng.

2. Để max-threads: 0 trong vòng thử đầu tiên.

3. Kiểm tra CPU phụ không tranh với main thread.

4. Dùng CALLER_RUNS khi thử async pathfinding để hạn chế flush task vào main thread.

5. Kiểm tra villager, mob farm, hopper, redstone, NPC và packet plugin sau mỗi restart.

6. Không đổi worldgen random hoặc region format trên world chính chỉ để benchmark.

Trước rollout

1. MSPT p95/max và lag spike tốt hơn trong cùng workload.

2. Không có lỗi mới trong log và Spark.

3. Sản lượng farm/timing redstone nằm trong mức đã thống nhất.

4. Có backup offline, config cũ và hướng dẫn rollback.

5. Ghi build Leaf, Java và checksum JAR trong nhật ký vận hành.

Khi nào nên nâng cấp phần cứng?

Sau khi đã profile và thử đúng module, nếu main thread vẫn chạm 50 ms trong giờ cao điểm, hãy nhìn vào giới hạn thực tế:

• CPU đơn nhân: tick, AI và nhiều plugin vẫn phụ thuộc mạnh vào tốc độ một core.

• CPU tổng: worker pool async, GC, map renderer và plugin phụ cần core riêng.

• I/O: world lớn, backup và chunk load cần ổ đĩa có độ trễ ổn định.

• RAM: chỉ nâng khi heap/GC chứng minh đang thiếu; RAM không sửa được hotspot CPU.

Mốc RAM để bắt đầu benchmark

Các mốc dưới đây chỉ là điểm bắt đầu để benchmark, không phải requirement cố định và không phải cam kết số slot:

• SMP nhỏ: khoảng 4-5 GB RAM Java.

• SMP 15-40 người: có thể benchmark từ 6-8 GB.

• Server đông hơn: có thể benchmark từ 8-12 GB rồi điều chỉnh theo số liệu.

Kết quả thực tế còn phụ thuộc vào world size, plugin, entity, loaded chunks, view-distance, simulation-distance, JVM heap, hoạt động của người chơi, map renderer và workload nói chung. Không có công thức đáng tin cậy kiểu X người chơi = Y GB RAM nếu chưa có benchmark cùng workload. RAM chỉ giúp chứa dữ liệu và tạo khoảng trống cho GC; nó không tự sửa được CPU hoặc main-thread bottleneck.

Nếu cần console, quản lý file/SFTP, backup và theo dõi CPU/RAM/TPS, bạn có thể tham khảo Minecraft Hosting của LumineCloud. Hãy chọn gói sau khi có baseline Leaf, thay vì mua RAM theo số slot quảng cáo.

Câu hỏi thường gặp

Leaf có tự động nhanh hơn Paper không?

Không có con số chung. Leaf cung cấp thêm module và tối ưu, nhưng lợi ích phụ thuộc workload. Một SMP nhiều plugin packet có thể hợp với Paper hơn một Leaf bật nhiều async.

Nên bật module nào đầu tiên?

Không bật theo thứ tự cố định. Hãy bắt đầu bằng module khớp hotspot Spark. Với lag lúc join/teleport/bay, async-chunk-send là ứng viên hợp lý; với pathfinding, thử async-pathfinding; với entity tracker hoặc parallel ticking, hãy để sau vì rủi ro cao hơn.

async-mob-spawning đã bật thì có cần chỉnh nữa không?

Thường không. Hãy xác nhận Paper per-player-mob-spawns: true, đo sản lượng farm và chỉ chỉnh tiếp nếu profiler cho thấy mob spawning còn là bottleneck.

DAB có làm farm hỏng không?

Có thể. DAB giảm tần suất AI của entity xa người chơi, nên farm dựa vào villager hoặc mob ở xa có thể thay đổi hành vi. Test từng farm và giữ entity quan trọng trong blacklist khi cần.

Có nên bật async-entity-tracker vì server có nhiều mob?

Chưa chắc. Module experimental chỉ đáng thử khi Spark chứng minh entity tracking là hotspot. Phải test NPC, visibility, metadata và plugin packet trước khi rollout.

Linear có giúp giảm lag không?

Linear chủ yếu tiết kiệm dung lượng và thay đổi cách ghi region. Nó không phải giải pháp đầu tiên cho MSPT; LINEAR_V2 còn có cảnh báo không ổn định và rủi ro mất dữ liệu.

Vì sao bật thêm worker mà TPS không tăng?

Có thể hotspot không nằm ở module đó, CPU đã bão hòa, queue thường xuyên đẩy task trở lại main thread hoặc plugin vẫn là nút thắt. Hãy đọc Spark trước/sau thay vì chỉ nhìn số thread.

Leaf có phù hợp production ở thời điểm này không?

Leaf có các nhánh phát hành khác nhau. Tại mốc kiểm tra 04/10/2026, Leaf 26.3 build 2 là bản mới nhất trên GitHub Releases nhưng vẫn được ghi là early dev; Leaf 26.2 build 123 cũng có cảnh báo không dùng production. Hãy dùng bản phù hợp với Minecraft/plugin, kiểm tra support và chỉ đưa lên production sau khi staging pass.

Nguồn tham khảo

• Leaf GitHub Repository

• Leaf 26.2 Release

• Leaf 26.2 Config Source

• Leaf Downloads

• Leaf Documentation

• Leaf Global Config

• Leaf - Optimize Leaf Server

• Paper - Getting started

• Paper - Profiling

• Spark - TPS và MSPT

• Spark - Tìm nguyên nhân lag spike