Cách tối ưu Paper cho Minecraft Server SMP

Server SMP thường chạy khá mượt khi mới mở. Sau một thời gian, server có thể bắt đầu khựng khi người chơi tản ra khám phá, xây trading hall, bật nhiều farm, bay Elytra hoặc cài thêm plugin. Nhiều chủ server sẽ nghĩ ngay đến việc tăng RAM. Tuy nhiên, thêm RAM chỉ hiệu quả khi server thật sự thiếu bộ nhớ; nó không giúp CPU xử lý tick nhanh hơn và cũng không sửa được plugin đang chiếm quá nhiều thời gian trên luồng xử lý chính của server.

Bài viết này hướng dẫn bạn giảm lag Minecraft server bằng cách đọc đúng TPS, MSPT, dùng Spark tìm nguyên nhân và điều chỉnh Paper theo từng bước dễ kiểm tra.

Muốn tối ưu Paper cho server SMP mà vẫn giữ đúng trải nghiệm Survival, hãy làm theo thứ tự: đo hiệu năng -> tìm nguyên nhân -> chỉnh đúng chỗ -> thử lại -> tiếp tục theo dõi. Trong kỹ thuật, nguyên nhân làm cả server chậm đi thường được gọi là “nút thắt” hoặc bottleneck. Đừng tải một “config tối ưu” trên mạng rồi thay toàn bộ file trong một lần (vì mỗi server, mỗi phiên bản sẽ có một settings riêng)!

Lưu ý nhỏ: Bài được Research và Update ngày 09/09/2026. Trang tải Paper cho biết nhánh 26.2 đang được phát hành; số build thay đổi nhanh, vì vậy hãy kiểm tra trang tải chính thức ngay trước khi nâng cấp. Theo Getting started của PaperMC, Paper 26.1+ yêu cầu Java 25; Paper 1.20-1.21.11 dùng Java 21. Nếu bạn chạy nhánh khác, hãy đối chiếu lại tên setting trong tài liệu của đúng phiên bản.

Tóm tắt nhanh - quy trình tối ưu Paper hiệu quả

1. Sao lưu world và toàn bộ config (rất quan trọng nếu không muốn bay màu dữ liệu).

2. Note lại phiên bản Paper, Java, plugin, View Distance và Simulation Distance.

3. Tạo tải thực tế: người chơi online, farm hoạt động và hoạt động khám phá đang diễn ra.

4. Chạy Spark ngay lúc server bị lag, không đo khi server đang trống: /spark profiler --timeout 60.

5. Xác định phần đang chiếm nhiều thời gian: chunk, entity, redstone, plugin, bộ nhớ hay ổ đĩa.

6. Chỉ thay đổi một phần/nhóm setting mỗi lần.

7. Lặp lại cùng kịch bản, so MSPT, các đợt lag và cảm nhận gameplay.

8. Khôi phục cấu hình cũ ngay nếu farm, plugin hoặc cơ chế Survival hoạt động sai.

Gợi ý cho server mới: Quy trình trong bài có thể áp dụng với mọi nhà cung cấp. Nếu không muốn tự cài Java, dựng bảng điều khiển và cấu hình mạng từ đầu, bạn có thể tham khảo Minecraft Hosting của LumineCloud. Server được đặt tại Việt Nam, hỗ trợ Paper, chống DDoS, có sao lưu và đội ngũ hỗ trợ kỹ thuật chuyên nghiệp 24/7. Bạn nên bắt đầu bằng gói vừa đủ, sau đó mới nâng RAM, CPU hoặc dung lượng khi số liệu thực tế cho thấy cần thiết.

Paper là gì và vì sao phù hợp với server SMP?

Paper là phần mềm máy chủ Minecraft phát triển từ Spigot, tập trung vào hiệu năng, độ ổn định và khả năng mở rộng bằng plugin. Trong phần lớn trường hợp, Paper có thể thay thế trực tiếp CraftBukkit hoặc Spigot. Khi chuyển từ Vanilla, Paper cũng tự động xử lý thay đổi trong cấu trúc thư mục thế giới.

So sánh ngắn:

Paper không phải nút bấm “hết lag”. Điểm mạnh của Paper là cung cấp thêm công cụ để giảm công việc không cần thiết và tìm đúng phần đang quá tải. Nếu một plugin quét quá nhiều block trong mỗi tick, Paper vẫn phải chờ plugin đó chạy xong.

Hiểu TPS và MSPT trước khi tối ưu

Minecraft đặt mục tiêu chạy 20 tick mỗi giây. Điều đó có nghĩa server chỉ có khoảng 50 mili-giây để hoàn thành toàn bộ công việc của một tick. Trong khoảng thời gian rất ngắn này, server phải xử lý chuyển động, dữ liệu mạng, AI của mob, tìm đường, redstone, block entity như rương/hopper và plugin.

• TPS (Ticks Per Second): số tick server hoàn thành trong một giây. Mục tiêu là 20 TPS.

• MSPT (Milliseconds Per Tick): thời gian cần để xử lý một tick. Càng thấp càng tốt.
  
  

  

Nếu một tick mất 30 ms, server xử lý xong rồi chờ khoảng 20 ms trước tick tiếp theo. Nếu tick mất 70 ms, tick sau phải trễ; TPS bắt đầu giảm và gameplay chậm lại.

Mốc 35 ms trong bảng là mức tham khảo để server còn dư sức xử lý khi lượng người chơi tăng. Đây không phải quy tắc bắt buộc của Paper. Mốc quan trọng cần nhớ là 50 ms: vượt mốc này trong thời gian dài sẽ khiến TPS giảm.

Vì sao chỉ nhìn TPS là chưa đủ?

TPS có thể vẫn hiển thị gần ~20 trong khi người chơi cảm thấy giật từng đợt. Một vài tick 200-300 ms có thể bị che bởi trung bình của nhiều tick nhanh. Vì vậy cần xem đồng thời:

• MSPT trung bình, thấp nhất, cao nhất và mốc 95% (p95) nếu công cụ có hiển thị.

• Đợt lag có xuất hiện cùng lúc với autosave, teleport, tạo chunk mới, farm hay một lệnh plugin không.

• Mức dùng CPU của luồng chính, RAM Java, hoạt động dọn bộ nhớ (GC), ổ đĩa và mạng.

• Trải nghiệm thật của người chơi: đặt block chậm, mob đứng hình, bị kéo ngược vị trí hay ping cao.

p95 là thời gian mà 95% số tick không vượt quá. Chỉ số này giúp bạn nhận ra các tick chậm rõ hơn so với khi chỉ nhìn giá trị trung bình.

Trước khi tối ưu - hãy tìm nguyên nhân gây lag

Paper hiện khuyến nghị dùng Spark để kiểm tra hiệu năng. Theo tài liệu profiling của Paper, Spark đã được tích hợp sẵn từ Paper 1.21. Công cụ Timings cũ không còn được duy trì và đã bị tắt mặc định.

Vài lệnh chẩn đoán tối thiểu bạn cần biết

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

• healthreport cho biết tổng quan về Java, CPU, RAM và tình trạng server.

• profiler start --timeout 600 ghi lại hoạt động của server trong 10 phút. Hãy chạy khi lag đang xảy ra.

• tickmonitor thông báo khi một tick mất nhiều thời gian hơn mức bạn đặt.

• --only-ticks-over chỉ ghi lại các tick chậm. Có thể bắt đầu với 50-100 ms rồi điều chỉnh theo tình trạng thực tế.

/tps và /mspt vẫn hữu ích để kiểm tra nhanh, nhưng tài liệu lệnh Paper ghi rõ /spark là lệnh nên dùng cho thông tin hiệu năng.

Đọc triệu chứng trước khi mở config

Các file cấu hình cần biết trên Paper hiện hành

Các bài cũ có thể nhắc paper.yml hoặc world-settings.default. Đó không phải cấu trúc file hiện hành. Không chép block YAML cũ vào Paper 26.2.

View Distance và Simulation Distance khác nhau thế nào?

View Distance (vùng dữ liệu được gửi tới máy người chơi)

view-distance là bán kính chunk mà server gửi cho người chơi. Giá trị mặc định theo tài liệu là 10, phạm vi hợp lệ 3-32. Bán kính 10 tương ứng một hình vuông tối đa khoảng (2 x 10 + 1)^2 = 441 chunk quanh một người chơi trước khi tính vùng chồng lấn.

Giảm từ 10 xuống 8 không chỉ giảm 20%: số vị trí chunk lý thuyết giảm từ 441 xuống 289, khoảng 34%. Tải thực tế còn phụ thuộc việc người chơi đứng gần nhau hay phân tán, cache, tốc độ di chuyển và plugin bản đồ.

View Distance chủ yếu ảnh hưởng:

• Số chunk cần load và giữ trong RAM.

• Dữ liệu chunk gửi qua mạng.

• Áp lực khi người chơi khám phá nhanh.

• Tầm nhìn của người chơi.

Simulation Distance (vùng server thực sự cập nhật)

simulation-distance là bán kính chunk mà server cập nhật các hoạt động gameplay quanh người chơi. Mob, redstone, farm, furnace, crop, block entity và nhiều hệ thống khác chỉ tạo tải tick đáng kể khi nằm trong vùng hoạt động tương ứng.

Simulation Distance thường có tác động trực tiếp hơn lên MSPT. Giảm quá thấp có thể làm:

• Farm dừng sớm khi người chơi lùi ra xa.

• Mob AI và pathfinding ngừng ngoài vùng tick.

• Redstone hoặc máy tự động không hoạt động như người chơi kỳ vọng.

• Khu vực SMP có cảm giác kém sống động.

Mốc thử ban đầu, không phải cấu hình chung cho mọi server

Với SMP khoảng 10-30 người chơi, có plugin vừa phải và người chơi thường xuyên khám phá, bạn có thể bắt đầu một vòng thử nghiệm tại:

# server.properties - mốc ban đầu để so sánh trước và sau
view-distance=8
simulation-distance=5

Sau đó, hãy kiểm tra farm, khả năng sinh mob và tầm nhìn. Nếu MSPT vẫn thấp và người chơi muốn nhìn xa hơn, tăng view-distance từng 1 chunk. Nếu entity hoặc redstone vẫn là phần gây nặng, thử giảm simulation-distance từng 1 chunk. Không thay cả hai cùng lúc, nếu không bạn sẽ khó biết thay đổi nào thật sự có tác dụng.

Tối ưu chunk cho SMP

Khi người chơi di chuyển, server phải xử lý chunk theo ba bước khác nhau:

• Load: đọc chunk đã có từ ổ đĩa vào RAM.

• Generate: tạo địa hình và công trình cho chunk mới. Bước này thường nặng hơn load.

• Send: nén và gửi dữ liệu chunk tới máy người chơi.

Paper đã tối ưu sẵn quá trình xử lý chunk và đặt giới hạn tốc độ trong paper-global.yml. Mặc định hiện hành gồm player-max-chunk-load-rate: 100 và player-max-chunk-send-rate: 75. Ở một số tùy chọn, giá trị -1 hoặc 0 có ý nghĩa đặc biệt. Vì vậy, đừng tăng tất cả các con số hoặc tự đặt số luồng theo số core CPU khi chưa đọc tài liệu chính thức.

Những setting Paper nên hiểu trước khi đổi

Nếu Spark cho thấy việc đi vào chunk chưa tải xong gây ra các đợt lag, bạn có thể thử:

# config/paper-world-defaults.yml
chunks:
  prevent-moving-into-unloaded-chunks: true

Hãy thử bằng Elytra và teleport trên bản sao của server trước khi áp dụng cho server chính. Setting này có thể làm thay đổi cảm giác di chuyển, vì vậy không nên bật chỉ vì một bài hướng dẫn gọi nó là “tối ưu”.

Có nên tạo sẵn chunk (pregenerate world)?

Pregeneration là quá trình tạo sẵn chunk trước khi người chơi bước vào. Paper hiện đại không bắt buộc server nào cũng phải làm việc này, nhưng nó vẫn hữu ích khi:

• Mở season mới và dự kiến nhiều người khám phá cùng lúc.

• CPU xử lý việc tạo thế giới mới khá chậm.

• Dùng Dynmap/BlueMap hoặc muốn giới hạn bản đồ bằng world border.

• Muốn chuyển tải tạo địa hình sang thời gian bảo trì.

Tạo sẵn chunk chỉ giảm việc tạo địa hình trong lúc người chơi khám phá. Server vẫn phải tải chunk, gửi chunk và xử lý entity, plugin. Quá trình này cũng tốn dung lượng ổ đĩa và thời gian. Hãy đặt world border riêng cho Overworld, Nether và End trước khi chạy.

Lưu ý về Chunky: PaperMC Hangar ghi Chunky 1.5.3 hỗ trợ Paper 26.1-26.1.2, chưa ghi 26.2. Nếu đang dùng Paper 26.2, hãy kiểm tra trang Versions, đọc lịch sử thay đổi và thử trên bản sao trước khi cài vào server chính.

Entity, mob và item gây lag như thế nào?

Không phải entity nào cũng tạo ra mức tải giống nhau. Villager phải dùng AI để tìm giường, bàn nghề và đường đi. Item rơi phải được cập nhật và gộp lại. Mob farm còn có quá trình sinh mob, AI, va chạm và vật phẩm rơi. Armor stand hoặc display entity thường nhẹ hơn, nhưng số lượng quá lớn vẫn có thể gây lag.

Đừng giảm mob cap trước khi biết vấn đề

entities.spawning.per-player-mob-spawns hiện mặc định là true. Tùy chọn này giúp phân chia giới hạn mob hợp lý hơn giữa các người chơi. Giảm spawn-limits có thể làm server nhẹ hơn, nhưng cũng khiến hang động ít mob, farm cho sản lượng thấp và thế giới kém sinh động.

Thứ tự nên làm:

1. Dùng Spark để xác nhận việc sinh mob, AI hoặc va chạm đang chiếm nhiều thời gian.

2. Dùng /paper entity list * <world> để xem entity đang tick và không tick.

3. Xác định khu vực tập trung villager, animal, item hoặc minecart.

4. Thiết kế lại khu vực/farm trước khi giảm toàn server.

5. Nếu vẫn cần, chỉnh theo world và giảm từng bước nhỏ.

Giới hạn va chạm và phạm vi hoạt động của entity

collisions.max-entity-collisions trong Paper hiện mặc định là 8. Giảm giá trị này có thể giúp server xử lý nhanh hơn khi nhiều entity bị dồn vào một chỗ. Đổi lại, cách entity đẩy nhau và gamerule maxEntityCramming có thể hoạt động khác trước.

entity-activation-range trong spigot.yml quy định khoảng cách mà entity còn được server cập nhật. Nếu giảm quá thấp, mob có thể phản ứng chậm, iron farm hoặc trading hall cũng có thể chạy sai. Hãy thử trực tiếp tại khu farm và so sánh trước/sau.

Ví dụ dưới đây chỉ nên thử khi Spark cho thấy va chạm entity là phần gây nặng rõ rệt:

# config/paper-world-defaults.yml
collisions:
  max-entity-collisions: 4

Nếu kết quả không cải thiện đáng kể hoặc gameplay thay đổi, trả về mặc định 8.

Item entity

Paper hỗ trợ entities.spawning.alt-item-despawn-rate để đặt thời gian biến mất riêng cho từng loại item. Tính năng này mặc định đang tắt. Nó có thể hữu ích với cobblestone, netherrack hoặc sản phẩm phụ của farm. Tuy nhiên, chỉ nên bật khi Spark cho thấy item rơi là nguyên nhân gây nặng và người chơi đã được thông báo rõ.

Không nên dùng plugin “clear lag” để quét và xóa toàn bộ entity theo lịch như giải pháp đầu tiên. Cách này có thể làm người chơi mất đồ, trong khi chính lần quét cũng có thể tạo ra một đợt lag mới.

Redstone, hopper và farm

Chọn cách Paper xử lý redstone

Paper 26.2 cho phép:

• VANILLA - hành vi Vanilla, mặc định.

• EIGENCRAFT - thuật toán thay thế.

• ALTERNATE_CURRENT - tối ưu tính toán redstone dust.

Hai cách xử lý thay thế có thể giảm các lần cập nhật không cần thiết, nhưng chúng cũng có thể thay đổi hành vi của redstone dust. Nếu SMP có máy redstone phức tạp, hãy sao chép world và thử từng farm trước.

# Chỉ thử trên server kiểm tra khi Spark cho thấy redstone gây nặng
misc:
  redstone-implementation: ALTERNATE_CURRENT

Hopper

Paper mặc định đã bật hopper.cooldown-when-full: true. Tùy chọn hopper.disable-move-event: true có thể giảm tải khi plugin theo dõi sự kiện InventoryMoveItemEvent. Tuy nhiên, nó cũng có thể làm hỏng plugin bảo vệ, shop hoặc hệ thống tự động hóa. Vì vậy, giữ giá trị mặc định false sẽ an toàn hơn nếu bạn chưa kiểm tra kỹ.

Thực tế nên làm trước:

• Tắt farm khi kho đã đầy.

• Dùng water stream để giảm chuỗi hopper nếu thiết kế cho phép.

• Tránh hopper clock chạy 24/7.

• Chia khu công nghiệp ra khỏi spawn đông người.

• Chạy Spark lúc farm hoạt động, không chỉ nhìn tổng số hopper rồi đoán.

Plugin có thể gây lag ra sao?

Plugin thường gây vấn đề khi:

• Quét nhiều chunk hoặc entity trên luồng xử lý chính.

• Ghi dữ liệu hoặc gọi dịch vụ web theo cách bắt server phải chờ.

• Chạy một tác vụ trong mỗi tick nhưng không chia nhỏ công việc.

• Cập nhật hologram, scoreboard, gói tin hoặc placeholder cho mọi người chơi quá thường xuyên.

• Xung đột với plugin khác hoặc dùng API cũ.

Không thể đánh giá server chỉ bằng số lượng plugin. Một plugin xử lý kém có thể nặng hơn hàng chục plugin nhỏ. Trong biểu đồ Spark, hãy mở nhánh mang tên plugin để xem phần nào chiếm nhiều thời gian. Sau đó kiểm tra trang lỗi và lịch sử cập nhật của đúng phiên bản plugin. Hãy thử tắt plugin trên bản sao của server và khởi động lại; không dùng /reload vì Paper cảnh báo lệnh này dễ làm trạng thái plugin bị lỗi.

RAM và CPU - server SMP cần bao nhiêu?

Không thể chọn cấu hình chỉ dựa vào số slot. Mười người cùng đứng ở spawn sẽ nhẹ hơn nhiều so với mười người bay theo mười hướng khác nhau. Bảng dưới đây chỉ là mốc ban đầu để thử tải, không phải cam kết server chắc chắn chứa được từng ấy người.

Khi chọn hosting, đừng chỉ so dung lượng RAM. Server Paper còn phụ thuộc nhiều vào tốc độ xử lý trên một nhân CPU và tốc độ đọc/ghi world. Đây là lý do các gói Minecraft Hosting của LumineCloud sử dụng AMD Threadripper 3960X hoặc Ryzen 9 9950X cùng ổ NVMe Samsung 990 PRO. Bảng điều khiển cho phép xem CPU, RAM, TPS và nâng tài nguyên mà không cần tự quản trị VPS. Cách tiết kiệm hợp lý là thuê cấu hình vừa đủ, đo trong giờ cao điểm rồi mới nâng cấp.

Dấu hiệu thiếu RAM

• Lượng RAM Java sử dụng tăng sát mức tối đa và GC phải dọn bộ nhớ liên tục.

• Log xuất hiện OutOfMemoryError, tiến trình bị tắt hoặc server sập sau một thời gian chạy.

• Giảm View Distance làm lượng RAM sử dụng giảm rõ, dù TPS có thể không thay đổi nhiều.

Dấu hiệu thiếu CPU hoặc quá tải tick

• MSPT cao trong khi Java vẫn còn nhiều RAM trống.

• Lag xuất hiện ngay khi AI của mob, redstone hoặc tác vụ plugin chạy.

• Giảm Simulation Distance cải thiện rõ.

• Spark cho thấy luồng xử lý chính luôn bận và gần như không có thời gian chờ.

Minecraft có thể chạy một số công việc phụ song song, nhưng vòng lặp tick vẫn phải xử lý lần lượt. Vì vậy, nhiều vCore (nhân CPU ảo) không bù được cho một nhân chính quá chậm. Ổ NVMe giúp tải và lưu world nhanh hơn, còn ping thấp giúp kết nối phản hồi tốt hơn. Tuy nhiên, cả hai đều không thay thế được CPU khi MSPT đang quá cao.

Nếu cần tối ưu JVM/GC, đọc thêm Hướng dẫn tối ưu JVM Flag cho server Minecraft. Đừng đổi flags cùng lúc với Paper config, nếu không bạn sẽ không biết thay đổi nào tạo ra khác biệt.

Quy trình tối ưu Paper theo từng bước

Bước 1: Note lại các dữ liệu/mốc quan trọng ở hiện tại

• Paper build và Java version.

• Số người chơi online.

• View/Simulation Distance.

• Plugin và phiên bản.

• MSPT trung bình, cao nhất và mốc 95% nếu có.

• Hoạt động đang diễn ra.

Bước 2: tái hiện tải

Chọn một thời điểm cố định trong 10-15 phút: cùng số người, cùng farm, cùng tuyến bay và cùng lệnh plugin. Chạy Spark khi vấn đề đang xảy ra.

Bước 3: đổi một biến

Ví dụ: chỉ đổi Simulation Distance từ 6 xuống 5. Giữ nguyên View Distance, plugin và JVM flags.

Bước 4: kiểm tra cả hiệu năng lẫn gameplay

Không chỉ ghi TPS. Hãy test:

• Farm có còn đúng sản lượng chấp nhận được không.

• Villager có restock và tìm workstation không.

• Redstone timing có sai không.

• Bay Elytra hoặc teleport có làm người chơi bị kéo ngược không.

• MSPT p95/max có giảm không.

Bước 5: Note lại các thay đổi và cách khôi phục

Mỗi thay đổi nên có ngày thực hiện, lý do, số liệu trước/sau và cách trở về cấu hình cũ. Nếu hiệu năng chỉ tốt hơn một chút nhưng trải nghiệm người chơi bị ảnh hưởng rõ, hãy bỏ thay đổi đó.

Checklist tối ưu Paper

Trước khi mở server

1. Dùng bản Paper phù hợp với phiên bản world và plugin.

2. Dùng Java đúng yêu cầu: Java 25 cho Paper 26.1+, Java 21 cho 1.20-1.21.11.

3. Sao lưu và thử khôi phục bản sao lưu.

4. Nếu tự quản trị VPS/dedicated, chừa RAM cho hệ điều hành, database, panel, backup và dịch vụ khác; không cấp toàn bộ RAM vật lý cho Java. Với managed/container hosting, hãy theo giới hạn container và hướng dẫn của nhà cung cấp — RAM của host OS thường không bị trừ khỏi gói của bạn theo cùng cách, trừ khi nhà cung cấp ghi rõ.

5. Đánh giá View Distance theo tầm nhìn và lưu lượng chunk; đánh giá Simulation Distance theo vùng gameplay cần tick. Không gộp hai giá trị thành một khuyến nghị cố định và chỉ đổi từng giá trị một.

6. Đặt world border riêng cho Overworld, Nether và End nếu cần.

7. Chỉ tạo sẵn chunk khi server thật sự cần và plugin tương thích.

8. Kiểm tra phiên bản, lịch sử cập nhật và thư viện đi kèm của từng plugin.

9. Thử farm, villager, redstone và teleport trên bản sao của server.

Sau khi server hoạt động

1. Theo dõi TPS như chỉ báo nhanh, không dùng nó làm chẩn đoán duy nhất.

2. Theo dõi MSPT trung bình, cao nhất và các đợt tăng vọt trong giờ cao điểm.

3. Chạy Spark khi sự cố đang diễn ra.

4. Kiểm tra việc tải, tạo và gửi chunk khi người chơi khám phá.

5. Kiểm tra entity theo world và khu vực đông farm.

6. Kiểm tra villager AI, collision, hopper và redstone.

7. Kiểm tra tác vụ plugin trên luồng xử lý chính.

8. Kiểm tra RAM và GC trước khi mua thêm RAM.

9. Ghi số liệu trước/sau và giữ bản cấu hình cũ để khôi phục.

Khi nào nên nâng cấp hosting?

Tóm lại, tối ưu Paper cho server SMP không có nghĩa là tắt càng nhiều tính năng càng tốt. Mục tiêu là cân bằng hiệu năng + độ ổn định + trải nghiệm chơi: server vẫn còn sức xử lý khi đông người, các đợt lag được kiểm soát và farm quan trọng vẫn hoạt động đúng.

Nếu đã đo bằng Spark và chỉnh Paper hợp lý nhưng MSPT vẫn cao trong giờ đông người, giới hạn có thể nằm ở hiệu năng đơn nhân CPU, ổ đĩa hoặc tài nguyên của gói đang thuê. Bạn có thể đọc bài so sánh VPS và Minecraft Hosting để chọn mô hình phù hợp.

Nếu đang tìm Minecraft Hosting có cấu hình mạnh, chi phí hợp lý và hỗ trợ tại Việt Nam, bạn có thể tham khảo LumineCloud. Hệ thống có console thời gian thực, quản lý file/SFTP, sao lưu, chống DDoS và theo dõi CPU/RAM/TPS ngay trên trình duyệt. Nhờ đó, bạn có thể sửa config, chạy lại bài thử, xem kết quả và khôi phục khi cần mà không phải tự dựng toàn bộ hệ thống quản trị.

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

Paper có giúp Minecraft server giảm lag không?

Có. Paper có nhiều cải tiến hiệu năng và công cụ quản trị hơn Vanilla/Spigot. Tuy nhiên, Paper không thể tự sửa một plugin quá nặng hoặc phần cứng không đủ mạnh. Bạn vẫn nên dùng Spark để tìm đúng nguyên nhân.

TPS Minecraft bao nhiêu là tốt?

Mục tiêu là 20 TPS. Nếu TPS thấp hơn trong thời gian dài, server đang không hoàn thành tick đúng hạn. Hãy xem thêm MSPT và báo cáo Spark để biết nguyên nhân.

MSPT bao nhiêu là bình thường?

Dưới 50 ms cho phép server giữ 20 TPS. Tuy nhiên, không nên để MSPT chạy sát 50 ms liên tục. Server cần một khoảng dư để xử lý khi người chơi tăng hoặc nhiều farm cùng hoạt động. Hãy theo dõi cả MSPT trung bình và các lần tăng vọt.

View Distance bao nhiêu là tốt cho SMP?

Không có một số chung. Bắt đầu từ giá trị hiện tại, tăng hoặc giảm từng 1 chunk rồi đo lại. View Distance chủ yếu liên quan lượng dữ liệu chunk và tầm nhìn; số người phân tán, RAM và mạng đều ảnh hưởng.

Simulation Distance nên để bao nhiêu?

Bắt đầu từ giá trị hiện tại của server, thay đổi từng 1 chunk và so sánh trước/sau. Simulation Distance thấp hơn có thể giảm tải tick nhưng cũng làm mob, farm và redstone ngừng hoạt động sớm hơn.

Có cần pregenerate chunk cho server SMP không?

Không bắt buộc với mọi server Paper. Việc tạo sẵn chunk hữu ích trước khi mở map cho đông người hoặc khi bạn muốn chuyển phần tạo địa hình sang giờ bảo trì. Luôn kiểm tra xem plugin có hỗ trợ đúng phiên bản Paper đang dùng hay không.

Tại sao server nhiều RAM nhưng vẫn lag?

RAM dùng để chứa dữ liệu đang hoạt động, nhưng không làm luồng xử lý chính chạy nhanh hơn. Nếu MSPT vẫn cao khi Java còn nhiều RAM trống, hãy kiểm tra CPU, entity, redstone, chunk và plugin.

Có nên dùng config tối ưu tải trên mạng không?

Không nên thay toàn bộ. Config có thể dành cho phiên bản cũ hoặc đánh đổi quá nhiều cơ chế Survival. Chỉ lấy từng ý, đối chiếu tài liệu chính thức rồi so sánh trước và sau trên bản sao của server.

Có thể thuê hosting Paper SMP ở đâu?

Nếu Spark cho thấy phần cứng hiện tại là giới hạn và bạn ưu tiên máy chủ đặt tại Việt Nam, có thể tham khảo Minecraft Hosting của LumineCloud. Dịch vụ hỗ trợ Paper, sử dụng CPU xung cao và ổ NVMe, kèm chống DDoS, sao lưu cùng hỗ trợ kỹ thuật tiếng Việt 24/7. Hãy chọn gói dựa trên số người chơi, plugin và kết quả Spark thay vì chỉ nhìn số slot quảng cáo.

Nguồn tham khảo

• Paper Downloads

• Paper - Getting started

• Paper - Profiling

• Paper - Commands

• Paper - Global configuration

• Paper - World configuration

• Spark - TPS và MSPT

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

• Chunky trên PaperMC Hangar