Minecraft 伺服器玩家變多，不代表要立刻升到最大方案。先在平常尖峰記錄卡頓、在線人數、主機資源和日誌，再判斷瓶頸是 CPU tick 負載、記憶體不足，還是磁碟空間／讀寫。如果原因判錯，升級某個資源也不一定改善遊戲體感。
先用可重複的情境量測
選一段平常會發生問題的時段，記錄同時在線人數、玩家是否探索新地形、正在執行的活動，以及面板資源圖表。不要拿空服數字跟週末尖峰比較，也不要在同一輪測試同時改核心、插件和啟動參數。先記錄目前狀態，之後每次只調整一項，才看得出改動有沒有幫助。
| 觀察到的現象 | 優先檢查 | 可能的下一步 |
|---|---|---|
| 遊戲 tick 延遲，RAM 尚有餘裕 | CPU、主執行緒、區塊生成或插件／模組 | 查看 profiler 報告，針對耗時來源處理。 |
| 出現記憶體不足、程序被終止或頻繁 GC 停頓 | Java heap 與整個容器的記憶體限制 | 核對啟動設定、移除不必要負載，再評估記憶體方案。 |
| 上傳更新失敗、世界接近方案空間上限 | 磁碟空間與檔案傳輸限制 | 清理確認可刪的舊日誌或測試檔，並詢問升級空間方式。 |
CPU 與 tick：看伺服器是否來得及運算
Paper 的 /mspt 指令可查看每個 tick 的耗時；要維持 20 TPS，MSPT 通常需低於 50 毫秒。Paper 文件建議用 spark 分析實際發生問題時的工作負載。若 tick 過慢，先找出高耗時的插件、模組、實體或區塊生成工作；單純增加 RAM 不會自動修復主執行緒瓶頸。不同主機商的 CPU 配額標示方式也可能不同，應詢問實際資源含義，避免直接拿百分比做跨方案比較。
RAM 與磁碟：先分清指標
記憶體要看錯誤和趨勢，不要只看到使用量偏高就升級。Paper 的排錯說明指出，Java heap 和容器記憶體是不同數值；應留意 OOM、程序被中止或 GC 停頓等症狀。可先閱讀RAM 指南及卡頓排查教學。磁碟則檢查目前用量、世界成長、日誌與更新暫存需求；不要刪除不熟悉的世界檔或模組資料來騰空間。
小步升級，並預先想好回退方式
確認瓶頸後，再向主機商詢問可調整的資源、費用差額、變更時是否停機、伺服器位址是否保留，以及之後能否降回原方案。選一個低峰時段調整，記錄變更前後相同情境下的 MSPT、資源圖表和錯誤日誌。如果效果不明顯，回到資料分析，不要連續升級多項資源而失去判斷依據。改核心或大量刪除檔案前，先確認可用副本；DiamondHost 託管備份需付費，服務內容請以官方商店為準。
若瓶頸看起來在 CPU，先確認服務商如何計算配額，再參考CPU 配額與效能比較指南，避免只憑面板上的百分比決定是否升級。
常見問題
玩家一多就該加 RAM 嗎？
不一定。先看是否有記憶體不足、程序遭終止或 GC 停頓；如果伺服器 tick 過慢但記憶體仍有餘裕，應先檢查 CPU 負載和 profiler 報告。
TPS 正常但玩家仍覺得卡，可能是主機資源嗎？
可能，但也要檢查網路延遲、特定玩家端效能和短暫的 tick 尖峰。記錄問題發生時間並查看相同時段的日誌或分析報告，較容易找到原因。
升級後覺得沒有差，該怎麼辦？
比較升級前後相同玩法和相近在線人數的量測結果，再確認原先判斷的瓶頸是否正確。若服務商允許降級，可依實際規則評估調回合適方案。