集群間同步導致的記憶體溢位 二

2021-09-27 02:00:43 字數 2323 閱讀 5049

現在網路發展這麼迅速,傳統的程式架構已經不適合這個高速發展的時代了,現在基本上都是分布式,微服務,它們之間的端點都是用集群來搭建的,有的訊息佇列,像kafka,註冊中心,像zookeeper都是集群化,更別說快取(redis),mysql了,更得集群化啊,其實前面那篇文章用nginx也與集群化相識,比如tomcat當伺服器,那它就是集群化的tomcat

1、案例介紹:有乙個基於b/s的mis系統(管理資訊系統),硬體為兩台2個cpu,8gb記憶體的hp小型機,伺服器是weblogic9.2,每台機器啟動了3個weblogic例項,構成了乙個6個節點的親和式集群,由於是親和式集群,所以沒有進行session同步,但是有一些資料需要部分資料在各個節點進行共享,所以後面用jbosscache構建了乙個全域性快取(記住這裡不是redis集群),服務正常使用一段時間後不定期出現多次的記憶體溢位情況,記憶體溢位異常不出現的時候,服務記憶體**狀況一直正常,每次記憶體**後都能恢復到乙個穩定的可用空間,懷疑是程式某些不常用的**路徑中存在記憶體洩漏,但是程式並未更新公升級過,也沒有什麼特別的操作,讓服務帶著-xx:+heapdumponoutofmemoryerror(生成堆的heapdump檔案),發現裡面存在大量的org.jgroups.protocols.pbcast.nakack物件 ,

2、jbosscache初步介紹

jbosscache是基於自家的jgroups進行集群間的資料通訊,jgroups使用協議棧的方式來實現收發資料報的各種所需特性自由組合,資料報接收和傳送時要經過每層協議棧的up()和down()方法,其中nakack棧用於保障各個包的有效順序及重發

3、jbosscache造成的問題的分析

由於資訊失敗有重發的可能性,在確認所有註冊在cms(group membership service)的節點都收到了正確的資訊之前傳送的資訊必須儲存在記憶體中,

4、mis的服務端有一些重要的細節造成的問題

而此mis的服務端中有乙個負責安全校驗的全域性filter,每當接收到請求時,均會更新最後一次操作時間,並將這個時間同步到所有的節點,使得乙個使用者在一段時間內不能在多台機器上登入,在服務使用過程中,往往乙個頁面會產生數次乃至數十次的請求,因此這個過濾器導致集群各個節點之間的網路互動特別頻繁(因為需要同步到各個節點),當網路情況不滿足情況時,重發資料就會堆積,最後造成記憶體溢位

5、最後的結果

看到上面差不多有點頭緒了吧,其實出現案例中的問題既有mis系統本身的缺陷的,也有jbosscache的缺陷共同導致的,

最重要的缺陷是這一類被集群共享的資料要使用類似jbosscache這種集群快取來同步的話,可以允許讀操作頻繁,因為資料在本地有乙個副本但是不能寫頻繁,這樣會帶來很大的網路開銷

redis集群和它的區別要說一樣也有點一樣,當redissession資料共享時,其實session了就有redis的一部分副本,和sessionid相關聯的,但是也不完全一樣,如果不提共享的話,redis更像乙個快取的平台,所有的都存在裡面,誰要哪個資料給誰哪的資料,誰寫就往redis裡寫,現在spring-data-redis 2.0以上不再用jedis了,改用lettuce了,用netty做底層

記憶體洩漏導致記憶體溢位(OOM)

開發中遇到這樣乙個bug,調整之前做的乙個意見反饋頁面布局,輸入框中限制字數200字,超過時自動刪除不顯示。自定義了乙個可監聽並限制輸入字數的edittext,貼上 測試過程中發現如果一次性往輸入框中貼上幾百上千個文字時程式就會閃退,報的錯誤是 上網查了一下這個錯誤的意思是棧滿溢位的錯誤。檢視錯誤行...

Linux集群間時間同步

1.時間伺服器配置 必須root使用者 1 檢查ntp是否安裝 rpm qa grep ntp ntp 4.2.6p5 10.el6.centos.x86 64 fontpackages filesystem 1.41 1.1.el6.noarch ntpdate 4.2.6p5 10.el6.ce...

漢字轉拼音的導致的記憶體溢位

上班來得第乙個任務就是把漢字轉化為拼音 主要用於搜尋名字 在網上收到了pinyin4j的開源庫,並且找了一下使用示例,感覺寫得蠻好的,就採用了他的方法,如下 public static setgetpinyin string src catch badhanyupinyinoutputformatc...