推 olys: 原來如此，之前就奇怪記憶體為什麼回收機制運作不佳 05/07 14:21
推 CardLin: 這問題我有遭遇過！基本上跟CPUtime與MBtime有很大的關聯 05/07 20:16
→ CardLin: 因為有段時間地磁場異常而造成CPU時間與主機板時間不同步 05/07 20:16
→ CardLin: TPS一直以來都不是問題，最主要的是玩家不要為小事吵架! 05/07 20:17
→ CardLin: 畢竟挖礦蓋房屋的TPS一點都不重要，重要的是不能遺漏封包 05/07 20:18
→ CardLin: 這我就更清楚了我有換過六張以上的網卡來運行我的伺服器! 05/07 20:20
→ CardLin: 基於不能透漏太多時間不同步的情況，我會用多組NTP監測喔 05/07 20:20
→ CardLin: 如果電腦能接個USB的GPS接收器到窗台接收GPS時間很不錯！ 05/07 20:21
→ CardLin: 這樣你每秒鐘就可接收到數個衛星傳送給你的時間訊號校正! 05/07 20:22
→ CardLin: 如此一來你的ＴＰＳ就能算得更精確而非軟硬體上的誤差值! 05/07 20:22
→ CardLin: 規則一定要訂的夠嚴謹不能有多個OP會有小圈圈的排擠效應! 05/07 20:24
推 mamaya3: 斷! 05/07 20:26
推 CardLin: 重新啟動主要是確保時間數值不會因為Overflow而發生異常! 05/07 20:30
→ CardLin: 畢竟早上六點重開就是要大家知道可以開始準備早餐去上班! 05/07 20:32
→ CardLin: 但考慮有些是早上要去開門工作的老闆所以五點重開也不錯! 05/07 20:33
→ CardLin: 但我覺得現在都已經電子化時代了，或許可以用日出為依據! 05/07 20:34
推 LPH66: 我怎麼覺得樓上有點搞錯原 PO 在討論的問題了... 05/07 20:38
→ LPH66: 這個 bug 應該是跟世界中的 entity 數量有關, 和時間沒啥關 05/07 20:39
→ LPH66: 時間在這個問題裡只是經過越久問題越嚴重而已 05/07 20:39
→ LPH66: 這裡的時間也是遊戲內時間而不是伺服器機器上的時間 05/07 20:41
推 CardLin: 我知道有些很厲害的玩家會從其他伺服器跑來繁殖別人農場! 05/07 20:41
→ LPH66: 跟 NTP 或 GPS 對時什麼的就更沒有關係了 05/07 20:41
→ CardLin: 致使農場動物過多而有 Small Overlap 的 Collision 情況! 05/07 20:42
→ CardLin: 如果時間異常根本就可能會影響農場中的動物繁殖的速度喔! 05/07 20:43
→ CardLin: 但如果時間異常到有負值的時候根本就會一直重複的繁殖了! 05/07 20:43
→ CardLin: 當然這是在硬體或作業系統Kernel有BUG的時候才會發生異常 05/07 20:48
→ CardLin: 還記得千禧年的時候其實喊得很大聲結果其實根本沒有異常! 05/07 20:49
→ CardLin: 所以其實網路病毒的情況真的要注意與謹慎小心評估再選擇! 05/07 20:50
→ CardLin: 畢竟有些BIOS擁有一些安全性處理器也有自己的時間容器吧~ 05/07 20:51
→ CardLin: 說錯了，有些CPU為了加速啟動而使用了特殊的開機程序較快 05/07 20:52
→ CardLin: 這樣較快的結果就有可能使用了不同的時間容器而發生異常! 05/07 20:53
推 CardLin: 當然網卡若有offload的功能也有自己的時間所以我才換網卡 05/07 20:56
→ CardLin: 讓我想起我的Marvell的網卡很穩定但有段時間開始亂丟封包 05/07 20:58
→ CardLin: 我還有換過Intel網卡但是那個驅動的IRQ使用率實在有點高! 05/07 20:59
→ CardLin: 我還試過Killer的網卡但因為好像沒有放出linux的驅動程式 05/07 21:01
→ CardLin: 所以最後我是選用了較ASIC大面積的Broadcom網卡才較穩定! 05/07 21:02
→ CardLin: 大家應該要清楚以前的Realtek在安裝linux的時候不會出現 05/07 21:03
→ CardLin: non-free driver的提示，代表Linux較能完整支援舊網路卡! 05/07 21:03
推 LPH66: …就說了這是遊戲內經過的模擬時間長, 而不是機器時間異常 05/07 21:11
→ LPH66: 他這個 bug 是在機器時間正常的機器上也會出現 (如一樓) 05/07 21:12
→ LPH66: 那所以跟機器時間有關的校時 / NTP / GPS 定時 / 網卡連線 05/07 21:13
→ LPH66: 等等之類的通通無關 05/07 21:13
推 CardLin: 因為在Traffic Offload的時候一定會反覆地與CPU校準時間! 05/07 21:22
→ CardLin: CPU發現網卡時間與CPU時間不同的話可能會hold住一段時間! 05/07 21:23
→ CardLin: 所以在DPC Latency很低的時候代表IRQ通常沒有異常的情況~ 05/07 21:24
→ CardLin: 大家應該要記得以前有個知名的linux系統有lowlatency核心 05/07 21:26
→ mamaya3: 可以去翻他以前的文 別跟他認真了XDDD 05/07 21:32
→ softpak: 囧 05/07 22:32
推 karuru: 上面到底在供三小 05/08 08:02
推 nick5487: 居然攻略到賣快板來了... 05/08 10:01
→ Kenqr: 其實是自動發廢文AI對吧 05/08 10:19
推 twosheep0603: 躁鬱症發作吧 哀 05/08 13:28
→ m01a011: 上面是複製貼上的感覺... 05/08 15:59
推 david50407: 只有我覺得卡林桑可以一直保持驚歎號在最後很厲害嗎XD 05/08 23:43
推 aalexx: 句尾幾乎都是驚嘆號XD 05/09 02:04
推 tonylo2ooo: 上面一堆廚，上次把你的project po上去，還被砲 05/10 10:00
→ softpak: po到哪被砲啊？我知道我的進度不是很快 05/10 12:30
→ softpak: 是蠻想知道哪個中文討論區有在討論的 XD 05/10 12:31
→ cras4202tw: 我都幾個月重開一次的 spigot 沒出現過你說的問題 05/10 22:00
可以請教一下是哪一個伺服器嗎?
想研究一下你的硬體跟伺服端的一些設定配置
還有遊戲規則
想比較一下差異
希望最後找到的問題不是卡林說的那個 囧
※ 編輯: softpak (140.116.20.16), 05/11/2017 00:00:18
→ cras4202tw: 不解釋創世神伺服器 伺服器跑在 ESXi 本身是 i7-7700k 05/11 10:16
→ cras4202tw: 32G RAM 我切割 4核心 4G 記憶體給它 05/11 10:16
→ cras4202tw: 系統是 Fedora server 25 05/11 10:16
→ softpak: 硬體看起來是不差，另外我看了一下規則，可能是生物限制 05/11 12:26
→ softpak: 上的問題 05/11 12:26
→ softpak: 前幾天去西瓜看 管理員是說大概是2到4個禮拜 甚至更久 05/11 12:28
→ softpak: 才會重開 05/11 12:28
→ softpak: 他的服跟nl一樣是沒有限制的 05/11 12:29
→ softpak: 而我這幾天發現伺服器一直在觸發全面檢查的機制，所以我 05/11 12:32
→ softpak: 認為應該是傳送門傳送物品這個功能的關係 05/11 12:32
→ softpak: 如果可以的話 麻煩有開服的板友 在lag重開前能否紀錄一 05/11 12:34
→ softpak: 下timing的狀況 然後確認伺服器是否有打開傳送門生怪的 05/11 12:34
→ softpak: 設定 05/11 12:34
經過了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