我的世界服務器太卡怎麼辦 MC服務器優化攻略
我的世界很多玩家都有自己的服務器，但是很多玩家並不知道怎麼優化和維護服務器，從而導致服務器很卡，今天小編爲大家帶來的是我的世界服務器優化攻略，還不知道怎麼優化服務器的小夥伴不要錯過哦。
系統的選擇
(網頁後臺可以跳過本段)關於系統的選擇，Linux類系統(Centos、Redhat等)固然高效、穩定，但選擇系統也一定要考慮到自己的熟悉程度和學習能力。不要盲目爲了高效而選擇一個自己完全不熟悉甚至從未使用過的系統，一旦出現了突發情況，原本只需要幾分鐘解決的問題由於不熟悉系統的操作用幾個小時來解決，這樣真的合適麼?在內存足夠使用的情況下，Windows和Linux開服的性能差距幾乎可以忽略。但是如果你熟悉Linux的操作，我依然會推薦你使用Linux系統，畢竟大服需要的Mysql、Redis在Linux下的性能往往高過Windows不少。如果你有較強的學習能力，打算入坑Linux開服，我會推薦你使用Centos6.6(穩定性突出、可靠性不俗、大量教程和文檔)。
JVM版本的選擇
(網頁後臺可以跳過本段)JVM(Java Virtual Machine)也就是Java虛擬機，俗稱Java運行環境。關於選擇JRE還是JDK的選擇，我推薦使用JDK，JDK包括運行環境(JRE)，在此基礎上增加了一些性能調優工具如VisualVM。而JVM的版本，非常不推薦使用Java6，因爲有不少插件已經放棄了Java6的支持。Java7和 Java8則是不錯的選擇，如果不是模組服務器，推薦使用Java8，Java8相比Java7主要的性能提升便在於HashMap上，而無論Minecraft服務端本身還是插件都大量使用了HashMap。所以對於Minecraft服務器來說，使用Java8帶來的性能提升還是比較可觀的。
服務端的選擇
從服務端的選擇開始就註定了性能優劣的起步水平，現在依然有不少人認爲CraftBukkit(水桶服)的兼容性、穩定性要遠遠好於 Spigot(水龍頭)。然而這是一個誤區，Spigot是在CraftBukkit基礎上優化而來的，幾乎100%兼容原有的插件API，所以可以認爲只要同版本水桶服能用的插件就可以在Spigot上運行。如果你選擇使用1.7.10以下的版本開服(純淨服)，強烈推薦你使用Spigot服務端，Spigot相比水桶服擁有近百項的優化，例如異步加載、讀取區塊，限制實體的活動範圍，修復一些內存泄露的問題等等。所以同版本下可以很容易感受到 Spigot有着更出色的性能和更低的內存佔用。如果你開服的版本在1.8+，我會推薦你使用PaperSpigot服務端，這款服務端是在Spigot 基礎上優化而來的，相比Spigot有着顯著的性能提升(Tiles幾乎不再消耗CPU時間，爆炸算法優化，紅石不再卡服，流水算法優化，區塊壓縮節約內存，優化Spigot自帶的Anti X-ray等等)，並且有許多可自定義項目(船損壞依然掉落船，各種地形生成的開關等等)。在最後需要提醒的是，如果沒有特殊原因，建議使用最新版本的服務端，最新版本的服務端往往修復了目前已知的絕大多數BUG和有着更多的性能提升。例如目前的1.8.8版本就比1.8.7多修復了數個可以卡服、蹦服的 BUG(利用旗幟樣式堆疊卡服等)。
啓動腳本
(網頁後臺可以跳過本段)越多的啓動參數反而導致越多的性能損耗。在不瞭解JVM工作原理的情況下，不要隨隨便便增加一大堆無用的啓動參數。一般情況下指定最小內存、最大內存即可，Java7還需要指定一個大於等於128MB的MaxPermSize。GC回收模式等等參數都應該由JVM自動選擇，例如國外論壇流傳的使用G1GC可以優化MC性能，的確，G1GC減少了Full GC的時間，但是會額外增加10%~30%的CPU時間佔用，完全得不償失。還有流傳很廣的設置MaxGCPauseMillis參數。這個參數的含義是控制GC垃圾回收的最大時間。設置一個很小的數值的確從表面來看服務器沒有瞬卡的問題了，但是這樣會導致每次垃圾回收都不夠深入和全面，這樣的結果就是服務端運行時間越久越卡，而且很可能出現OOM(內存不夠了)直接蹦服。
例如Java7的開服參數可以是(大型插件非常多，MaxPermSize可以設置得更高)：
-Xms最小內存 -Xmx最大內存 -XX:MaxPermSize=128M -XX:+AggressiveOpts -XX:+UseCompressedOops
Java8的參數可以是：
-Xms最小內存 -Xmx最大內存 -XX:+AggressiveOpts -XX:+UseCompressedOops
* -XX:+AggressiveOpts的含義是儘可能的使用更多對性能有幫助的優化功能
* -XX:+UseCompressedOops的含義是指針壓縮，可以減少一定的內存佔用(64位才支持)
參數的優化
不要小瞧參數的修改帶來的優化空間，有時候只修改一個參數，就是在線100人TPS19和TPS16的差距。參數的調整分別爲 server.properties(原版服務器就有)，bukkit.yml(水桶服或者衍生版就有)，spigot.yml(Spigot或者衍生版就有)，paper.yml(PaperSpigot纔有)。
* 其中對性能有顯著影響的前面爲紅色的星號，有中等程度影響的爲藍色的星號，沒有顏色的星號是建議設置項
server.properties中可以優化性能的參數：
* view-distance，視距，默認值是10。含義是玩家的視距也就是加載的區塊範圍，默認是10個區塊，視距10加載的區塊是視距5的四倍。加載更多的區塊則需要更多的內存和運算能力。推薦將這個值設置在5或者6，如果在線人數非常多可以設置爲4。降低視距可以有效減少內存的佔用，也能有效提高 TPS，還可以減少寬帶的使用量。這個參數對性能提升是立竿見影的。
* generate-structures，默認值是true。含義是生成和計算一些特殊的環境，例如女巫塔、村民到達數量生成鐵傀儡等等。設置爲 false可以減少這些特殊環境生成和週期性檢查帶來的開銷。這個參數很少被提起，但是對性能的提升有着不少的幫助。例如我的服務器生存子服有130人左右在線，TPS在17左右，關閉這個功能後提高到了19左右。需要徹底關閉這個參數，還需要在spigot.yml中把save-structure- info設置爲false。並且關服後手動刪除每個世界(例如world、world_nether、world_the_end)下的data文件夾裡的Fortress.dat、Mineshaft.dat、Stronghold.dat、Temple.dat、Village.dat文件。
network-compression-threshold，默認值是256。這個參數只有1.8的服務端纔有，含義是網絡封包壓縮的閥值。例如設置爲16，代表封包大於16才被壓縮，設置成256代表着封包大於256才被壓縮。設置的值越小則會壓縮更多的封包，可以使得寬帶使用減少，提高網絡流暢程度，但是也會增加性能的開銷。如果性能夠用可以設置爲128，使得更多通訊封包被壓縮，一定程度上減少寬帶使用率又不會帶來太多的性能開銷。設置的值太小，例如小於等於32會明顯增加對性能的開銷，不建議這麼做。
bukkit.yml中可以優化性能的參數：
* spawn-limits，意思是限制實體的生成。這個並不是限制一個區塊生成多少實體，而是針對一個人可以生成多少實體。例如monsters: 70，在線人數只有10個人，則最多隻能生成700個怪物實體(殭屍、骷髏、蜘蛛等等)，適當的設置這些參數可以減少實體對性能的影響。
* chunk-gc，控制着區塊的回收，單位是Tick(1/20秒)，period-in-ticks是指每過多少tick回收一次需要回收的區塊，設置的太小會導致回收過於頻繁而影響性能，設置的太大會導致需要回收的區塊遲遲不回收使得內存佔用過大。合理的數值一般是300~400。load- threshold是指達到多少需要回收的區塊的時候才進行回收。例如設置成300，只有當需要回收的區塊到達300以上才進行回收，合理的設置這個數值可以使得額外只多佔用一丁點內存卻使得區塊回收的性能開銷可以被無視。一般設置爲300~600比較合適。
autosave，自動保存存檔(地圖、玩家數據等)的週期，單位是Tick(1/20秒)，如果你使用了定時保存的插件，例如Saveit、AutoSave等等，你可以將他設置爲0，即關閉這個功能。這樣可以減少服務器瞬卡發生的可能。
spigot.yml中可以優化性能的參數：
* user-cache-size，1.7.5以上版本纔有，其控制用戶緩存的大小，如果你的服務器玩家很多，可以設置的更大一些，例如5000。
* save-user-cache-on-stop-only，1.7.5以上版本纔有，其含義是是否只在服務器關閉/重啓的時候保存用戶緩存，設置爲true可以提高性能。
* view-distance，同server.properties裡的view-distance一樣。
* chunks-per-tick，是指每tick(1/20秒)掃描計算多少區塊，計算的內容是作物的生長。默認值是650，可以設置成350來提高性能。極端的情況可以設置成150，但是會使得作物生長的速度明顯變慢。
* max-tick-time: (僅較新的版本有該參數，如1.8.3+)是指每tick，實體和tile最多可以用的時間(單位是毫秒)，要明白其含義首先要解釋什麼是TPS，TPS 的意思是每秒有多少tick，最大值是20，也就是每秒tick20次，每次50毫秒。如果運算量過大導致每tick計算了超過了50毫秒，那麼TPS就會下降，一旦TPS低於15就會產生明顯的卡頓。在這參數中tile代表着熔爐、箱子、牌子、骷髏頭等等所能佔用的最大時間，entity是指的實體，例如動物、怪物、村民、展示框、掉落物、船、礦車等等。設置tile和entity的總和小於等於30則能明顯降低tile和entity對TPS的影響，而服務器運算資源幾乎一大半都是由這兩者消耗的。設置tile爲10，entity爲20比較合適，如果實體非常多，還可以設置tile爲 6，entity爲24。
* anti-xray，服務端自帶的反透視功能，俗稱假礦。這個功能相比插件版的假礦來說，額外內存佔用極少，少到可以忽略，並且礦物的變動計算是異步進行的，對TPS的影響很小。engine-mode爲1則是隱藏礦物，engine-mode爲2則是將非礦物也僞裝成礦物，engine-mode設置爲 2的效果最好，但是會額外吃一定的性能和寬帶，但是engine-mode設置爲1無法防禦礦追。具體如何權衡請自行決定。如果你不需要本功能，例如你是純RPG服務器，可以直接把enabled設置爲false關閉這個功能，提高性能。
nerf-spawner-mobs，簡單來說就是讓刷怪籠生成的怪物變成白癡，直觀感受就是刷怪籠刷出的怪不能攻擊了。默認爲false，意思是不開啓。設置爲true可以獲得一定的性能提升。
* entity-activation-range，這個參數是控制實體的活躍範圍，例如monsters: 32意思是在玩家附近32格範圍內的怪物纔會活躍(被計算AI等)，減少這個數值可以明顯提升性能，但是設置得過小會使得遊戲難度大幅降低。一般可以把 monsters設置爲24，animals設置爲12，misc設置爲2(misc主要是掉落物，設置2可以使得掉落物幾乎不再卡服)。
entity-tracking-range，這個參數是控制實體的可見範圍，這個參數不會影響性能，對寬帶的影響也極小。不建議修改這個參數，但是適當的降低數值可以減少客戶端的卡頓。
* random-light-updates，隨機的光照更新，設置爲true的話服務器會隨機更新光照，並且在區塊加載的第一個tick運算光照邏輯。設置爲false可以提高不少性能。
* save-structure-info，在前面已經介紹了。
max-bulk-chunks，1.7.10+纔有這個參數，意思是每個數據封包裡塞多少個區塊。適當提高這個數值，例如從10提高到15可以減少網絡卡頓和客戶端讀取區塊的速度，但是設置得過高會導致客戶端崩潰。
* max-entity-collisions，實體碰撞箱的閥值。建議設置爲2，可以減少密集卡服的問題。
* max-tnt-per-tick，每tick(1/20秒)最多計算多少TNT爆炸，設置爲20可以顯著防禦TNT蹦服。
paper.yml中可以優化性能的參數：
keep-spawn-loaded，spawn區塊是否常駐內存，設置爲false可以減少一定的內存佔用和計算量
* tick-next-tick-list-cap，每tick最大的運算量，減少數值可以提高TPS，例如設置爲8000
* tick-next-tick-list-cap-ignores-redstone，達到上面的運算閥值是否無視紅石運算，設置爲true可以顯著減少紅石對服務器性能的影響。
* optimize-explosions，是否開啓爆炸算法優化，設置爲true可以提升一定的服務器性能
* use-async-lighting，是否讓光照的邏輯運算異步化，設置爲true可以使得光照運算不再影響TPS，強烈推薦設置爲true
* cache-chunk-maps，是否緩存chunkmaps，可以讓區塊的數據更多得被複用，可以一定程度提高性能，推薦設置爲true