早上睡到很晚才醒,感覺我不太受天氣影響,因為冷氣早就已經停止運轉很久了,可能是昨天玩水消耗不少體力吧!一起來後就開始繼續前天未完成的實驗,試了幾個組合:Consumer Thread + Producer Thread、Consumer Thread + Producer Timer、Consumer Timer + Producer Thread以及Consumer Timer + Producer Timer,表現做好的是兩個都用Timer,但在分析原因時發現一個詭異的數據,將20萬筆浮點數寫入硬碟,即便用了網路上對於Java I/O Performace改善的方法,也還是需要300ms上下,也就是說之前我覺得5ms可以應付20萬浮點數寫入硬碟應該是假象,原因是兩個Timer都呼叫到同個(Main) Thread去處理資料產生跟寫入硬碟,講簡單點就是產生資料跟寫入硬碟是交替執行,其實沒趕上5ms的Deadline,記憶體沒爆掉也是同樣的原因,當兩個都是用Thread的時候就很明顯了,Producer明顯比Consumer快,記憶體大約2分鐘內就塞爆JVM預設的64MB上限。

  這可就麻煩了,雖然說以目前WiMAX模擬全部子層加進去跑,大概一秒才有2~3個Frame,換算下來大概也是350ms才會有一大筆的模擬資料送回Console端,但目前的實驗結果表示,效能改善有一定的極限,20萬筆浮點數大約是2台MS加2台BS的資料調變後的訊號量,也就是說,即便效能改善完畢,能夠模擬的環境大概也就是2台BS加上2台MS左右,想也沒用,就馬上對Console程式碼進行改造,先把SPMT的程式碼大概看了一下,了解流程後,有點傻眼,有人程式這樣寫的嗎?同樣的邏輯同樣的程式,為了Thread和Timer寫了兩個版本,這就算了,還是用comment的方式決定使用哪個版本,實在是受不了,於是先幫他們改成runtime決定執行thread還是timer,至少不是用註解來決定...

  經過小幅度的改造後,以33ms一次的頻率產生假資料,模擬可持續執行大約10分鐘還不會塞爆64MB的記憶體,比之前不到10秒就塞爆要好很多,但畫面更新率還是更不上去。看樣子,第一階段的效能改善成果還不錯,不過還得繼續實驗找出瓶頸所在才行,最起碼畫面看起來要平順才行!

dbi1463 發表在 痞客邦 PIXNET 留言(0) 人氣()