本文介紹了Kafka kstream-kstream加入了滑動(dòng)窗口，內(nèi)存使用量隨著時(shí)間的推移不斷增長，直到OOM的處理方法，對(duì)大家解決問題具有一定的參考價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)吧！
問題描述
我在使用kstream聯(lián)接時(shí)遇到問題。我所做的是從一個(gè)主題中將3種不同類型的消息分離到新的流中。
然后與創(chuàng)建另一個(gè)流的兩個(gè)流進(jìn)行一次內(nèi)部聯(lián)接，最后我與新流和最后一個(gè)剩余的流進(jìn)行最后一次左聯(lián)接。
聯(lián)接的窗口時(shí)間為30秒。
這樣做是為了篩選出某些被其他郵件覆蓋的郵件。
我在Kubernetes上運(yùn)行此應(yīng)用程序，Pod的磁盤空間一直在無限增長，直到Pod崩潰。
我已經(jīng)意識(shí)到這是因?yàn)槁?lián)接將數(shù)據(jù)存儲(chǔ)在本地的tmp/kafka-stream目錄中。
這些目錄稱為：
KSTREAM-JOINTHIS…
KSTREAM-OUTEROTHER..
它存儲(chǔ)來自rocks Db的sst文件，并且這些文件無限增長。
我的理解是，由于我使用30秒的窗口時(shí)間，這些應(yīng)該在特定時(shí)間之后被清除，但事實(shí)并非如此。
我還將WINDOW_STORE_CHANGE_LOG_ADDITIONAL_RETENTION_MS_CONFIG更改為10分鐘，以查看是否有不同的更改。
我需要了解如何更改這一點(diǎn)。
推薦答案
窗口大小并不決定您的存儲(chǔ)要求，而是決定加入的寬限期。為了處理無序記錄，數(shù)據(jù)的存儲(chǔ)時(shí)間比窗口大小更長。在較新版本中，需要始終通過JoinWindows. ofTimeDifferenceAndGrace(...)指定寬限期。在舊版本中，您可以通過JoinWindows.of(...).grace(...)設(shè)置寬限期–如果未設(shè)置，則默認(rèn)為24小時(shí)。
配置WINDOW_STORE_CHANGE_LOG_ADDITIONAL_RETENTION_MS_CONFIG配置數(shù)據(jù)在集群中存儲(chǔ)的時(shí)間長度。因此，您可能也想減少它，但這無助于減少客戶端存儲(chǔ)需求。
這篇關(guān)于Kafka kstream-kstream加入了滑動(dòng)窗口，內(nèi)存使用量隨著時(shí)間的推移不斷增長，直到OOM的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，
