PTT遊戲區 / Minecraft (當個創世神)

[分享] Spigot的一個小BUG

看板Minecraft (當個創世神)作者 (喔喔喔)時間7年前 (2017/05/07 01:06), 7年前編輯推噓16(16推 0噓 57→)
留言73則, 14人參與, 最新討論串1/1
其實我發現這個問題一直都在 只是通常開服者會固定重啟伺服器 所以這個問題相較之下不是很嚴重 不過我相信還是有很多服開著不關也很少重開的 因為我的服也是這樣 所以也察覺到這個問題的嚴重性 相關的內容我也有同步發到spigot的論壇上 不過官方會不會改我就不清楚了 希望可以改掉這個問題 接下來就說一下這到底是什麼問題好了 就是伺服器如果好幾天不關 我的服是4~5天 這個tracker set的大小在我的伺服器裡就會成長到50萬以上 然後在沒玩家的情況下tps只有10左右 timing裡時間的花費則是30~40ms http://i.imgur.com/K7hvXH5.png
已經超過半個tick了 會LAG不意外? 這個問題我分了2個階段解決 第一階段是track的的平行化 問題是稍微有解決沒錯 但是沒玩家時TPS卻還是降到18左右(use 4 cores) 有玩家就會變成17 但問題是沒有人在線上到底要追蹤啥? 於是我認為應該是這個set裡的entry沒有正確的被刪除所導致 所以第二階段我做了一個全面檢查 目前是在玩家轉換世界時才會觸發這個檢查 因為經過傳送門都會頓我覺得應該沒差吧 XDDD 希望spigot能夠去修正這個問題 如果沒有 我的專案有修正 囧 不過目前還是在觀察階段 之前有確定確實是tracker set太大導致 因為我有測試這個set大於20萬就清空 然後tps一路19以上持續30多天的紀錄 期間玩家登入數跟頻率是差不多的 不過就是一些機關掛點 生物有時會不動這樣 XDDD 希望對大家有幫助 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.116.20.13 ※ 文章網址: https://www.ptt.cc/bbs/Minecraft/M.1494090377.A.EC7.html
推
05/07 14:21, , 1F
原來如此，之前就奇怪記憶體為什麼回收機制運作不佳
05/07 14:21, 1F
推
05/07 20:16, , 2F
這問題我有遭遇過！基本上跟CPUtime與MBtime有很大的關聯
05/07 20:16, 2F
→
05/07 20:16, , 3F
因為有段時間地磁場異常而造成CPU時間與主機板時間不同步
05/07 20:16, 3F
→
05/07 20:17, , 4F
TPS一直以來都不是問題，最主要的是玩家不要為小事吵架!
05/07 20:17, 4F
→
05/07 20:18, , 5F
畢竟挖礦蓋房屋的TPS一點都不重要，重要的是不能遺漏封包
05/07 20:18, 5F
→
05/07 20:20, , 6F
這我就更清楚了我有換過六張以上的網卡來運行我的伺服器!
05/07 20:20, 6F
→
05/07 20:20, , 7F
基於不能透漏太多時間不同步的情況，我會用多組NTP監測喔
05/07 20:20, 7F
→
05/07 20:21, , 8F
如果電腦能接個USB的GPS接收器到窗台接收GPS時間很不錯！
05/07 20:21, 8F
→
05/07 20:22, , 9F
這樣你每秒鐘就可接收到數個衛星傳送給你的時間訊號校正!
05/07 20:22, 9F
→
05/07 20:22, , 10F
如此一來你的ＴＰＳ就能算得更精確而非軟硬體上的誤差值!
05/07 20:22, 10F
→
05/07 20:24, , 11F
規則一定要訂的夠嚴謹不能有多個OP會有小圈圈的排擠效應!
05/07 20:24, 11F
推
05/07 20:26, , 12F
斷!
05/07 20:26, 12F
推
05/07 20:30, , 13F
重新啟動主要是確保時間數值不會因為Overflow而發生異常!
05/07 20:30, 13F
→
05/07 20:32, , 14F
畢竟早上六點重開就是要大家知道可以開始準備早餐去上班!
05/07 20:32, 14F
→
05/07 20:33, , 15F
但考慮有些是早上要去開門工作的老闆所以五點重開也不錯!
05/07 20:33, 15F
→
05/07 20:34, , 16F
但我覺得現在都已經電子化時代了，或許可以用日出為依據!
05/07 20:34, 16F
推
05/07 20:38, , 17F
我怎麼覺得樓上有點搞錯原 PO 在討論的問題了...
05/07 20:38, 17F
→
05/07 20:39, , 18F
這個 bug 應該是跟世界中的 entity 數量有關, 和時間沒啥關
05/07 20:39, 18F
→
05/07 20:39, , 19F
時間在這個問題裡只是經過越久問題越嚴重而已
05/07 20:39, 19F
→
05/07 20:41, , 20F
這裡的時間也是遊戲內時間而不是伺服器機器上的時間
05/07 20:41, 20F
推
05/07 20:41, , 21F
我知道有些很厲害的玩家會從其他伺服器跑來繁殖別人農場!
05/07 20:41, 21F
→
05/07 20:41, , 22F
跟 NTP 或 GPS 對時什麼的就更沒有關係了
05/07 20:41, 22F
→
05/07 20:42, , 23F
致使農場動物過多而有 Small Overlap 的 Collision 情況!
05/07 20:42, 23F
→
05/07 20:43, , 24F
如果時間異常根本就可能會影響農場中的動物繁殖的速度喔!
05/07 20:43, 24F
→
05/07 20:43, , 25F
但如果時間異常到有負值的時候根本就會一直重複的繁殖了!
05/07 20:43, 25F
→
05/07 20:48, , 26F
當然這是在硬體或作業系統Kernel有BUG的時候才會發生異常
05/07 20:48, 26F
→
05/07 20:49, , 27F
還記得千禧年的時候其實喊得很大聲結果其實根本沒有異常!
05/07 20:49, 27F
→
05/07 20:50, , 28F
所以其實網路病毒的情況真的要注意與謹慎小心評估再選擇!
05/07 20:50, 28F
→
05/07 20:51, , 29F
畢竟有些BIOS擁有一些安全性處理器也有自己的時間容器吧~
05/07 20:51, 29F
→
05/07 20:52, , 30F
說錯了，有些CPU為了加速啟動而使用了特殊的開機程序較快
05/07 20:52, 30F
→
05/07 20:53, , 31F
這樣較快的結果就有可能使用了不同的時間容器而發生異常!
05/07 20:53, 31F
推
05/07 20:56, , 32F
當然網卡若有offload的功能也有自己的時間所以我才換網卡
05/07 20:56, 32F
→
05/07 20:58, , 33F
讓我想起我的Marvell的網卡很穩定但有段時間開始亂丟封包
05/07 20:58, 33F
→
05/07 20:59, , 34F
我還有換過Intel網卡但是那個驅動的IRQ使用率實在有點高!
05/07 20:59, 34F
→
05/07 21:01, , 35F
我還試過Killer的網卡但因為好像沒有放出linux的驅動程式
05/07 21:01, 35F
→
05/07 21:02, , 36F
所以最後我是選用了較ASIC大面積的Broadcom網卡才較穩定!
05/07 21:02, 36F
→
05/07 21:03, , 37F
大家應該要清楚以前的Realtek在安裝linux的時候不會出現
05/07 21:03, 37F
→
05/07 21:03, , 38F
non-free driver的提示，代表Linux較能完整支援舊網路卡!
05/07 21:03, 38F
推
05/07 21:11, , 39F
…就說了這是遊戲內經過的模擬時間長, 而不是機器時間異常
05/07 21:11, 39F
→
05/07 21:12, , 40F
他這個 bug 是在機器時間正常的機器上也會出現 (如一樓)
05/07 21:12, 40F
→
05/07 21:13, , 41F
那所以跟機器時間有關的校時 / NTP / GPS 定時 / 網卡連線
05/07 21:13, 41F
→
05/07 21:13, , 42F
等等之類的通通無關
05/07 21:13, 42F
推
05/07 21:19, , 43F
建議原PO檢查網卡驅動!!
05/07 21:19, 43F
推
05/07 21:22, , 44F
因為在Traffic Offload的時候一定會反覆地與CPU校準時間!
05/07 21:22, 44F
→
05/07 21:23, , 45F
CPU發現網卡時間與CPU時間不同的話可能會hold住一段時間!
05/07 21:23, 45F
→
05/07 21:24, , 46F
所以在DPC Latency很低的時候代表IRQ通常沒有異常的情況~
05/07 21:24, 46F
→
05/07 21:26, , 47F
大家應該要記得以前有個知名的linux系統有lowlatency核心
05/07 21:26, 47F
→
05/07 21:32, , 48F
可以去翻他以前的文 別跟他認真了XDDD
05/07 21:32, 48F
→
05/07 22:32, , 49F
囧
05/07 22:32, 49F
推
05/08 08:02, , 50F
上面到底在供三小
05/08 08:02, 50F
推
05/08 10:01, , 51F
居然攻略到賣快板來了...
05/08 10:01, 51F
→
05/08 10:19, , 52F
其實是自動發廢文AI對吧
05/08 10:19, 52F
推
05/08 13:28, , 53F
躁鬱症發作吧 哀
05/08 13:28, 53F
→
05/08 15:59, , 54F
上面是複製貼上的感覺...
05/08 15:59, 54F
推
05/08 23:43, , 55F
只有我覺得卡林桑可以一直保持驚歎號在最後很厲害嗎XD
05/08 23:43, 55F
推
05/09 02:04, , 56F
句尾幾乎都是驚嘆號XD
05/09 02:04, 56F
推
05/10 10:00, , 57F
上面一堆廚，上次把你的project po上去，還被砲
05/10 10:00, 57F
→
05/10 12:30, , 58F
po到哪被砲啊？我知道我的進度不是很快
05/10 12:30, 58F
→
05/10 12:31, , 59F
是蠻想知道哪個中文討論區有在討論的 XD
05/10 12:31, 59F
→
05/10 22:00, , 60F
我都幾個月重開一次的 spigot 沒出現過你說的問題
05/10 22:00, 60F
可以請教一下是哪一個伺服器嗎? 想研究一下你的硬體跟伺服端的一些設定配置 還有遊戲規則 想比較一下差異 希望最後找到的問題不是卡林說的那個 囧 ※ 編輯: softpak (140.116.20.16), 05/11/2017 00:00:18
→
05/11 10:16, , 61F
不解釋創世神伺服器 伺服器跑在 ESXi 本身是 i7-7700k
05/11 10:16, 61F
→
05/11 10:16, , 62F
32G RAM 我切割 4核心 4G 記憶體給它
05/11 10:16, 62F
→
05/11 10:16, , 63F
系統是 Fedora server 25
05/11 10:16, 63F
→
05/11 12:26, , 64F
硬體看起來是不差，另外我看了一下規則，可能是生物限制
05/11 12:26, 64F
→
05/11 12:26, , 65F
上的問題
05/11 12:26, 65F
→
05/11 12:28, , 66F
前幾天去西瓜看 管理員是說大概是2到4個禮拜 甚至更久
05/11 12:28, 66F
→
05/11 12:28, , 67F
才會重開
05/11 12:28, 67F
→
05/11 12:29, , 68F
他的服跟nl一樣是沒有限制的
05/11 12:29, 68F
→
05/11 12:32, , 69F
而我這幾天發現伺服器一直在觸發全面檢查的機制，所以我
05/11 12:32, 69F
→
05/11 12:32, , 70F
認為應該是傳送門傳送物品這個功能的關係
05/11 12:32, 70F
→
05/11 12:34, , 71F
如果可以的話 麻煩有開服的板友 在lag重開前能否紀錄一
05/11 12:34, 71F
→
05/11 12:34, , 72F
下timing的狀況 然後確認伺服器是否有打開傳送門生怪的
05/11 12:34, 72F
→
05/11 12:34, , 73F
設定
05/11 12:34, 73F
經過了5天的觀察 確定是tracker set過大的問題 目前這個SET的大小小於10萬 timings 的結果也很正常 http://i.imgur.com/UD8a5Mf.png
就像剛開時的情況 至於觸發累積的機制還是不太明瞭 不過似乎用bungeecord傳送到別的dimention時不會使這個tracker累積 如果只是想單純的解決這個問題 可以選擇在你喜歡的地方 例如實體經過傳送門時來作全面檢查 程式碼如下(EntityTracker.java)： Set<EntityTrackerEntry> remove_untrack = Sets.newConcurrentHashSet(); public void untrackPlayer(EntityPlayer entityplayer) { Iterator iterator = this.c.iterator(); while (iterator.hasNext()) { EntityTrackerEntry entitytrackerentry = (EntityTrackerEntry) iterator.next(); entitytrackerentry.clear(entityplayer); } //remove all untrack here for (EntityTrackerEntry ete: this.c) { int exist_count = 0; for (Entity ent:this.world.entityList) { if (ent.getId() == ete.hashCode()) { exist_count++; } } if (exist_count == 0) { remove_untrack.add(ete); } } this.c.removeAll(remove_untrack); remove_untrack.clear(); } 綠色部分是新增的 意思是當玩家通過傳送門時比較c這個set裡的entry資料 跟當下world裡entityList的有沒有重複 沒有重複就表示這個entity沒有在運作 把這個entry從清單移除 每個dimention也就是每個wolrd都有各自的tracker清單 所以這樣移除是沒有問題的 感謝收看 ※ 編輯: softpak (140.116.16.132), 05/12/2017 09:31:39
‣ 更多 softpak 的文章
文章代碼(AID): #1P3WA9x7 (Minecraft)
Minecraft 近期熱門文章
更多 近期熱門文章 >>
PTT遊戲區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 softpak 的文章
文章代碼(AID): #1P3WA9x7 (Minecraft)