Tối Ưu Redstone Cho Máy Chủ SMP

Trên nhiều server SMP, phần gây lag rõ rệt nhất không phải là số người chơi mà là một góc bản đồ chứa farm sắt, farm XP hoặc kho máy lọc đồ (bằng đá đỏ) đang hoạt động trong các chunk được tải và tick. Khác với chunk hay entity, redstone gây lag một cách "âm thầm": một mạch nhỏ chạy sai cách vẫn hoạt động bình thường trong mắt người chơi, nhưng lại buộc main thread xử lý hàng nghìn block update và shape update (cập nhật trạng thái vật lý của block) mỗi giây.

Bài viết này hướng dẫn tối ưu redstone cho server SMP: từ việc hiểu vì sao redstone lại nặng hơn nhiều người tưởng, chọn đúng redstone implementation trên Paper/Leaf/Purpur, kiểm soát hopper, đến việc sửa cách thiết kế mạch để giảm tải mà không đổi hành vi chơi.

Mốc phiên bản: Bài được kiểm tra ngày 04/10/2026. Trang tải Paper đang cung cấp Paper 26.2 build 129; theo Getting started của PaperMC, Paper 26.1+ yêu cầu Java 25. Leaf và Purpur là fork của Paper nên phần lớn setting redstone-implementation trong bài áp dụng tương tự, nhưng hãy đối chiếu tài liệu của đúng phần mềm và phiên bản bạn đang chạy.

Tóm tắt nhanh

1. Backup world và config trước khi đổi bất kỳ setting nào.

2. Xác định khu vực nghi ngờ: farm, hopper sorting, farm XP hay một mạch clock chạy liên tục.

3. Chạy Spark ngay khi khu vực đó đang hoạt động, không đo lúc redstone đứng yên.

4. Đọc report để biết thời gian rơi vào block tick, block entity (hopper/piston) hay entity (mob farm).

5. Chỉ đổi một thứ mỗi lần: hoặc setting server, hoặc cách xây mạch.

6. Restart nếu setting yêu cầu (đổi redstone-implementation cần restart, không reload được bằng /paper reload).

7. Chạy lại đúng kịch bản cũ và so sánh MSPT p95/max.

8. Kiểm tra farm và mạch vẫn hoạt động đúng số liệu đã thống nhất với người chơi.

9. Giữ thay đổi nếu cả hiệu năng và hành vi redstone đều ổn; rollback nếu không.

Vì sao redstone lại nặng hơn cảm giác của người chơi?

Khi một block redstone đổi trạng thái, Vanilla không chỉ cập nhật đúng ô đó. Nó gửi block update cho các block liền kề, các block đó lại có thể kích hoạt tiếp block khác — gọi là update chuỗi (cascading update). Với dây redstone dust, một lần đổi tín hiệu có thể lan ra hàng chục block xung quanh vì mỗi đoạn dust đều phải tính lại cường độ tín hiệu.

Ba nguồn phổ biến khiến redstone SMP trở nên nặng:

• Clock chạy liên tục trong chunk đang ticking: redstone chỉ tạo tải khi chunk liên quan còn được tải và tick, chẳng hạn do người chơi ở gần, ticket, force-load hoặc cơ chế chunk loader phù hợp. Một clock trong chunk đã unload hoàn toàn sẽ không tiếp tục chạy.

• Dây dust dài và mạch phụ thuộc update order: dust càng dài, số block cần tính lại có thể tăng khi tín hiệu đổi. Quasi-connectivity không tự động gây lag, nhưng các contraption phức tạp dựa vào QC và thứ tự cập nhật có thể tạo chuỗi block/shape update lớn hơn; hãy đo đúng mạch trước khi kết luận.

• Hopper và block entity đi kèm: hopper được Vanilla tick mỗi tick dù đang rỗng, nên một hệ thống sorting hàng chục hopper luôn có chi phí nền, cộng dồn với phần redstone điều khiển nó.

Dây dust càng dài, một lần đổi tín hiệu càng kéo theo nhiều block cần cập nhật lại — đây là phần chi phí "ẩn" mà mắt thường không thấy được.

Vì lý do này, tối ưu redstone không nên bắt đầu bằng việc đổi config trước. Trước tiên cần biết phần nào của map thực sự đang chiếm MSPT.

Đo trước khi sửa: dùng Spark để khoanh vùng

Không nên đoán mạch nào gây lag chỉ bằng cách nhìn map. Hãy đứng gần khu vực nghi ngờ và chạy profiler trong lúc mạch hoạt động bình thường:

/spark profiler start --timeout 300
/spark tickmonitor --threshold-tick 50
/spark profiler --only-ticks-over 50

Trong report, redstone thường thể hiện dưới ba dạng khác nhau tùy vào phần nào của mạch đang nặng:

Nếu Spark không chỉ ra block tick hay block entity là hotspot, việc đổi redstone-implementation hoặc chỉnh hopper sẽ không mang lại khác biệt đáng kể — hãy tìm đúng nguyên nhân trước khi đổi config.

Bản đồ cấu hình liên quan đến redstone trên Paper

Theo tài liệu World configuration của Paper, các setting trên nằm trong config/paper-world-defaults.yml (áp dụng mọi world) hoặc <world>/paper-world.yml (áp dụng riêng một world). Không copy nguyên khối YAML từ bài hướng dẫn cũ vì tên setting có thể đã đổi qua các version.

Playbook 1: Chọn đúng redstone implementation

Tài liệu Paper liệt kê ba lựa chọn cho redstone-implementation:

• VANILLA (mặc định): hành vi giống hệt Vanilla, không tối ưu thêm.

• EIGENCRAFT: thuật toán của theosib, giảm một phần khối lượng tính toán so với Vanilla.

• ALTERNATE_CURRENT: thuật toán của Space Walker, được Paper mô tả là giúp giảm đáng kể lag từ redstone dust bằng cách tối ưu cách tính tín hiệu và giảm số block/shape update phát ra.

# config/paper-world-defaults.yml
misc:
  redstone-implementation: ALTERNATE_CURRENT
  alternate-current-update-order: HORIZONTAL_FIRST_OUTWARD

Điều quan trọng cần biết trước khi bật: cả EIGENCRAFT lẫn ALTERNATE_CURRENT đều thay đổi hành vi của redstone dust so với Vanilla, dù phần lớn thời gian sự khác biệt là không đáng kể với người chơi thông thường. Paper không công bố tài liệu chính thức mô tả đầy đủ khác biệt của Eigencraft; với Alternate Current, README của Space Walker là nguồn tham khảo chính thức nhất.

Vì vậy, trước khi bật trên world chính, hãy kiểm tra trên bản sao:

1. Bật ALTERNATE_CURRENT, restart (setting này không áp dụng qua /paper reload).

2. Test lại các mạch quan trọng: máy nông trại tự động, cối XP, cửa lật piston, mạch quasi-connectivity đặc biệt phức tạp.

3. Xác nhận thời gian giữa các bước của mạch (timing) không đổi.

4. Đo lại MSPT p95/max trong đúng kịch bản đã dùng trước đó.

5. Chỉ giữ nếu cả hiệu năng lẫn hành vi mạch đều đạt yêu cầu.

alternate-current-update-order chỉ có tác dụng khi dùng Alternate Current; nó quyết định server cập nhật dây và block liền kề theo hướng ngang trước hay dọc trước. Giá trị mặc định HORIZONTAL_FIRST_OUTWARD phù hợp với phần lớn map; chỉ đổi khi một mạch cụ thể phụ thuộc thứ tự cập nhật và hoạt động sai sau khi bật Alternate Current.

Playbook 2: Kiểm soát hopper đi kèm redstone

Rất nhiều mạch redstone trên SMP — máy phân loại, kho tự động, farm — đều dùng hopper để di chuyển item. Vanilla tick mọi hopper mỗi tick kể cả khi đang rỗng, nên một hệ thống có hàng chục đến hàng trăm hopper luôn có chi phí nền, độc lập với phần dây redstone điều khiển nó.

Một chuỗi hopper phân loại luôn có chi phí nền vì server phải kiểm tra container hai đầu mỗi tick, kể cả khi không có item nào di chuyển.

Theo tài liệu spigot.yml của Paper và SpigotMC Wiki, ba giá trị quan trọng nằm trong world-settings.default.ticks-per và hopper-amount:

# spigot.yml
world-settings:
  default:
    ticks-per:
      hopper-transfer: 8
      hopper-check: 1
    hopper-amount: 1

Tăng hopper-transfer giúp giảm số lần hopper phải xử lý mỗi giây, nhưng làm farm/sorting chạy chậm hơn theo đúng tỷ lệ đó — đây là đánh đổi tốc độ farm lấy hiệu năng, không phải "tối ưu miễn phí". Hãy đổi từng bước nhỏ (ví dụ 8 → 10 → 12) và kiểm tra sản lượng farm sau mỗi lần đổi, thay vì nhảy thẳng lên giá trị lớn.

Ngoài ba setting trên, Paper còn cung cấp trong paper-world-defaults.yml:

# config/paper-world-defaults.yml
hopper:
  cooldown-when-full: true
  ignore-occluding-blocks: false

cooldown-when-full (mặc định bật) giúp hopper không cố kéo item liên tục khi đích đến đã đầy. ignore-occluding-blocks chỉ nên bật nếu server có nhiều hopper minecart hoặc hopper đặt trong block occluding và Spark xác nhận đây là hotspot; đổi setting này có thể ảnh hưởng vài thiết kế phụ thuộc hành vi kiểm tra container hiện tại.

Playbook 3: Thiết kế lại mạch thay vì chỉ đổi config

Với nhiều server SMP, phần tiết kiệm MSPT lớn nhất không đến từ config mà từ cách người chơi xây mạch. Một vài nguyên tắc thiết kế giúp giảm tải mà không thay đổi kết quả cuối của farm:

• Tắt clock khi không dùng. Một cối XP hay máy nông trại chạy 24/7 dù không ai đứng cạnh vẫn tốn MSPT mỗi tick. Thêm một lever hoặc redstone torch để bật/tắt thủ công, hoặc dùng cảm biến (ví dụ daylight sensor, ổ khóa bằng lever) để dừng mạch khi không cần.

• Rút ngắn dây dust khi có thể. Thay một đoạn dust dài bằng comparator hoặc repeater ở những điểm hợp lý giúp giảm số block cần cập nhật lại mỗi lần tín hiệu đổi, vì comparator/repeater không lan tín hiệu ra các ô xung quanh như dust.

• Đánh giá quasi-connectivity theo từng contraption. QC không phải nguyên nhân lag mặc định. Rủi ro xuất hiện khi thiết kế phụ thuộc nhiều vào update order, piston và chuỗi block/shape update; hãy profile mạch đang chạy thay vì cấm QC theo nguyên tắc chung.

• Thu gọn footprint của khu máy. Đặt hopper/dispenser có tổ chức giúp dễ quản lý, cô lập hotspot và tránh nhiều cụm máy cùng hoạt động rải rác. Việc gom block entity không tự làm giảm simulation distance; chunk có được tải hay không vẫn do vị trí người chơi và cơ chế ticket/chunk loader quyết định.

• Giới hạn số piston bắn đồng thời trong các mạch lớn. Piston chain kích hoạt hàng loạt cùng lúc (dùng trong máy nén, TNT duper, một số máy nông trại lớn) tạo ra rất nhiều block/shape update trong một tick. Nếu không bắt buộc phải đồng bộ tuyệt đối, tách thành các đợt bắn nối tiếp giúp trải chi phí ra nhiều tick thay vì dồn vào một tick.

• Cẩn trọng với hopper clock và hopper minecart chain dài. Đây là dạng mạch có chi phí nền cao nhất trong nhóm hopper vì hopper minecart vẫn cần kiểm tra va chạm/kết nối mỗi tick.

Dồn toàn bộ piston vào một tick dễ tạo lag spike; tách thành các đợt bắn nối tiếp giúp trải chi phí ra nhiều tick khi mạch không bắt buộc đồng bộ tuyệt đối.

Những thay đổi này không cần restart server và không phụ thuộc phiên bản Paper, nên có thể áp dụng ngay cả khi server chưa sẵn sàng đổi redstone-implementation.

update-pathfinding-on-block-update - liên quan gián tiếp nhưng đáng chú ý

Theo tài liệu Paper, mỗi khi một block đổi trạng thái, Vanilla có thể tính lại đường đi (pathfinding) của mob gần đó để phản ứng với thay đổi địa hình. Với server có nhiều farm và mạch redstone chạy liên tục, việc này cộng dồn thành chi phí đáng kể trên các entity xung quanh, dù bản thân mob không liên quan trực tiếp đến mạch.

# config/paper-world-defaults.yml
misc:
  update-pathfinding-on-block-update: false

Paper mô tả việc tắt setting này có thể cải thiện hiệu năng đáng kể trong khi gần như không ảnh hưởng cơ chế gameplay, và đặc biệt khuyến nghị khi server có nhiều entity cùng lúc với farm hoặc redstone clock đang hoạt động — đúng tình huống của phần lớn SMP có farm tự động. Đây là một trong số ít setting "được nhiều, mất ít" mà bạn có thể thử sớm trong quá trình tối ưu redstone.

An toàn - max-block-ticks và max-fluid-ticks

Một mạch redstone lỗi (hoặc bị lợi dụng để phá server, dân kỹ thuật thường gọi là "lag machine") có thể tạo ra một chuỗi block update gần như vô hạn trong một tick, khiến server treo. Paper có hai giới hạn an toàn cho việc này:

# config/paper-world-defaults.yml
environment:
  max-block-ticks: 65536
  max-fluid-ticks: 65536

Theo tài liệu Paper, đây là biện pháp an toàn để tránh server bị treo khi có lượng lớn block hoặc fluid tick bất thường trong một tick. Giữ giá trị mặc định trừ khi bạn đã xác nhận bằng Spark rằng một mạch hợp lệ, quy mô lớn của chính server đang bị chặn bởi giới hạn này — trường hợp đó hiếm và nên được test kỹ trên staging trước khi tăng giới hạn trên world chính.

Quy trình áp dụng trên staging

Giống các thay đổi hiệu năng khác, đừng đổi redstone-implementation hay hopper timing trực tiếp trên world production.

Vòng A: sao chép và test cơ bản

• Sao chép world (đặc biệt khu vực có farm/redstone phức tạp) sang staging.

• Giữ config mặc định, xác nhận mọi mạch hoạt động đúng như trên production.

Vòng B: đổi một setting

• Chỉ đổi redstone-implementation, hoặc chỉ đổi hopper timing, không đổi cả hai cùng lúc.

• Restart, test lại toàn bộ mạch quan trọng đã liệt kê trước đó.

Vòng C: đo và so sánh

• Chạy lại đúng kịch bản Spark ban đầu.

• So sánh MSPT p95/max, số block/block-entity tick trong report.

Vòng D: quyết định

• Giữ thay đổi nếu hiệu năng tốt hơn và mạch vẫn đúng hành vi đã thống nhất.

• Rollback nếu bất kỳ farm quan trọng nào sai timing hoặc sai sản lượng.

Checklist tối ưu redstone

Trước khi chỉnh

1. Backup world và toàn bộ config.

2. Dùng Spark khoanh vùng đúng khu vực/loại chi phí (block tick, block entity, hay entity).

3. Ghi lại timing và sản lượng hiện tại của các farm quan trọng để so sánh sau này.

Khi chỉnh

1. Đổi một setting hoặc một mạch mỗi lần.

2. Thử update-pathfinding-on-block-update: false sớm nếu server có nhiều entity quanh farm.

3. Test redstone-implementation trên staging trước khi đưa lên production.

4. Tăng hopper-transfer từng bước nhỏ, không nhảy thẳng lên giá trị lớn.

5. Rà lại các mạch dùng nhiều quasi-connectivity hoặc piston chain lớn.

Sau khi chỉnh

1. MSPT p95/max tốt hơn trong cùng kịch bản.

2. Không có mạch nào sai timing hoặc sai sản lượng.

3. Không có log lỗi mới liên quan block entity/piston.

4. Ghi lại thay đổi, ngày thực hiện và cách rollback.

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

Nếu đã đo bằng Spark, chọn đúng redstone-implementation, chỉnh hopper hợp lý và rà lại thiết kế mạch nhưng MSPT vẫn cao khi farm hoạt động đồng thời với giờ đông người, giới hạn có thể nằm ở hiệu năng đơn nhân CPU chứ không còn ở cấu hình. Redstone và block entity đều chạy trên main thread, nên một CPU có IPC tốt vẫn quan trọng hơn số nhân trong trường hợp này.

Nếu đang tìm nơi thuê Minecraft Hosting để test các thay đổi trên staging trước khi đưa lên production, bạn có thể tham khảo Minecraft Hosting của LumineCloud. Hệ thống hỗ trợ Paper, có console thời gian thực, quản lý file/SFTP, sao lưu và theo dõi CPU/RAM/TPS ngay trên trình duyệt, giúp bạn dựng nhanh một bản sao server để thử nghiệm mạch redstone trước khi áp dụng cho world chính.

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

Nên bật ALTERNATE_CURRENT cho mọi server SMP có redstone không?

Không có câu trả lời chung. Alternate Current giúp giảm chi phí redstone dust rõ rệt trên server có nhiều mạch, nhưng nó thay đổi cách tính tín hiệu so với Vanilla. Hãy test trên staging với đúng các mạch quan trọng của server trước khi bật trên production.

Đổi redstone-implementation có cần restart không?

Có. Đây không phải setting reload được qua /paper reload; cần restart server sau khi đổi.

Tăng hopper-transfer có làm hỏng máy phân loại không?

Không hỏng, nhưng làm chậm theo đúng tỷ lệ số tick bạn tăng thêm. Nếu máy phân loại hoặc farm phụ thuộc timing chính xác giữa nhiều hopper, hãy test kỹ trước khi đổi giá trị mặc định.

update-pathfinding-on-block-update: false có ảnh hưởng gameplay không?

Theo Paper, tác động lên gameplay là gần như không đáng chú ý trong khi lợi ích hiệu năng có thể lớn, đặc biệt khi có nhiều entity gần farm/redstone clock. Đây là một trong những setting an toàn để thử sớm.

Tại sao một mạch nhỏ lại gây lag nhiều hơn cả một farm mob lớn?

Vì redstone dust có thể lan cập nhật ra nhiều block liền kề mỗi khi đổi tín hiệu. Nếu clock nằm trong chunk đang ticking, nó có thể lặp việc này mỗi tick; còn khi chunk unload hoàn toàn, mạch không tiếp tục chạy. Chi phí thực tế vẫn phải được xác nhận bằng profiler.

max-block-ticks/max-fluid-ticks có nên tăng lên để mạch lớn chạy được không?

Nên cẩn trọng. Đây là giới hạn an toàn chống server bị treo vì chuỗi update bất thường. Chỉ tăng sau khi đã xác nhận bằng Spark rằng một mạch hợp lệ, không phải lỗi thiết kế, đang chạm giới hạn này.

Có nên dùng plugin chống lag redstone của bên thứ ba không?

Có thể cân nhắc, nhưng hãy hiểu rõ plugin đó thay đổi gì trước khi cài lên production — một số plugin giới hạn số block update hoặc tick redstone mỗi khu vực, có thể ảnh hưởng đến các máy móc hợp lệ của người chơi nếu đặt ngưỡng quá thấp. Luôn test trên staging trước.

Nguồn tham khảo

• Paper - World configuration

• Paper - spigot.yml

• Paper Downloads

• Paper - Getting started

• Paper - Profiling

• Alternate Current README (Space Walker)

• SpigotMC Wiki - spigot.yml

• Spark - TPS và MSPT

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

• GameRant - Minecraft Redstone Contraptions (nguồn ảnh bìa)