快捷導(dǎo)航

詳解SpringCloudGateway內(nèi)存泄漏問(wèn)題

更新時(shí)間：2020年07月16日 15:30:06 作者：如果悲傷有顏色，那么一定是黃昏

這篇文章主要介紹了詳解SpringCloudGateway內(nèi)存泄漏問(wèn)題，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧

SpringCloudGateway內(nèi)存泄漏問(wèn)題

項(xiàng)目完善差不多，在進(jìn)入壓力測(cè)試階段期間，發(fā)現(xiàn)了gateway有內(nèi)存泄漏問(wèn)題，問(wèn)題發(fā)現(xiàn)的起因是，當(dāng)時(shí)啟動(dòng)一臺(tái)gateway，一臺(tái)對(duì)應(yīng)的下游應(yīng)用服務(wù)，在壓力測(cè)試期間，發(fā)現(xiàn)特別不穩(wěn)定，并發(fā)量時(shí)高時(shí)低，而且會(huì)有施壓機(jī)卡住的現(xiàn)象，然后找到容器對(duì)應(yīng)的宿主機(jī)，并使用container stats命令觀察內(nèi)存，經(jīng)過(guò)觀察發(fā)現(xiàn)，壓力測(cè)試時(shí)內(nèi)存會(huì)暴漲，并由于超過(guò)限制最大內(nèi)存導(dǎo)致容器掛掉（這里由于用的swarm所以會(huì)自動(dòng)選擇節(jié)點(diǎn)重啟）最終發(fā)現(xiàn)由于之前測(cè)試服務(wù)器配置低，所以限制了堆大小為1g，容器cpu 1，容器內(nèi)存限制為了1g，經(jīng)過(guò)調(diào)整后將內(nèi)存改為4g且不限制容器資源的情況下，并發(fā)穩(wěn)定，單機(jī)qps也不錯(cuò)，但是多次壓力測(cè)試后依然會(huì)有卡住的問(wèn)題，觀察了日志之后確定為內(nèi)存泄漏

io.netty.util.internal.OutOfDirectMemoryError:
failed to allocate 16777216 byte(s) of direct memory
(used: 4110417927, max: 4116185088)

- LEAK: ByteBuf.release() was not called before it's garbage-collected.

發(fā)現(xiàn)問(wèn)題之后，我進(jìn)入容器內(nèi)dump了內(nèi)存快照，并下載到本機(jī)由jvisualvm分析，分析過(guò)程中并沒有發(fā)現(xiàn)異常情況，由于gateway底層是netty，所以懷疑是堆外內(nèi)存出了問(wèn)題，這時(shí)候我從快照中查詢bytebuff，依然很小，后來(lái)直接使用arthas去線上分析，分析發(fā)現(xiàn)堆內(nèi)存正常，gc也沒有問(wèn)題

最后為了快速測(cè)試出異常，我調(diào)小了堆外內(nèi)存大小,并配合nmt調(diào)查

-XX:NativeMemoryTracking=detail -XX:MaxDirectMemorySize=100M

在線上使用pmap去查看內(nèi)存，發(fā)現(xiàn)了很多的anon，并且每次并發(fā)都會(huì)增長(zhǎng)

轉(zhuǎn)移到本地進(jìn)行測(cè)試，發(fā)現(xiàn)內(nèi)存遠(yuǎn)超出分配的堆大小，最終確定為堆外內(nèi)存出了問(wèn)題

既然是堆外內(nèi)存出的問(wèn)題，我們就只關(guān)心是否申請(qǐng)了buff沒有釋放，通過(guò)對(duì)代碼的檢查發(fā)現(xiàn)，只有兩個(gè)地方使用到了相關(guān)的內(nèi)容

DataBuffer buffer = exchange.getResponse().bufferFactory().wrap(bytes);
    return serverHttpResponse.writeWith(Flux.just(buffer));

對(duì)上面的代碼進(jìn)行大量壓測(cè)后發(fā)現(xiàn)并無(wú)問(wèn)題，內(nèi)存沒有異常增長(zhǎng)不回收

ServerHttpRequest httpRequest = exchange.getRequest().mutate().headers(httpHeaders -> {
              httpHeaders.add(GatewayConstants.LOGIN_USER_KEY, JSON.toJSONString(s));
            }).build();
            return chain.filter(exchange.mutate().request(httpRequest).build());

還有一處就是修改請(qǐng)求頭這部分代碼，當(dāng)注釋掉這部分時(shí)，內(nèi)存穩(wěn)定沒有異常增長(zhǎng)，當(dāng)放開時(shí)，3000并發(fā)幾乎增加800M內(nèi)存，幾次就懟到了5g+，由于gateway內(nèi)置了一個(gè)請(qǐng)求頭工廠(AddRequestHeaderGatewayFilterFactory)，我去查看對(duì)應(yīng)的源代碼，是怎么實(shí)現(xiàn)的

如圖，除了多了解析配置之外和我寫的基本也一樣，那為何會(huì)內(nèi)存異常呢？只能去github上找找問(wèn)題看看有人遇到相同的事沒。

這個(gè)老哥遇到的問(wèn)題也類似，他是修改請(qǐng)求體的內(nèi)容時(shí)出現(xiàn)的

這個(gè)問(wèn)題我也遇到了

看起來(lái)這個(gè)問(wèn)題還是挺嚴(yán)重的，最后我也反手提了一個(gè)問(wèn)題

沒有啥回答，最后還是參考了一些別人的寫法最后內(nèi)存不會(huì)飆升了，但是不知其為何，還得繼續(xù)調(diào)查

到此這篇關(guān)于詳解SpringCloudGateway內(nèi)存泄漏問(wèn)題的文章就介紹到這了,更多相關(guān)SpringCloudGateway內(nèi)存泄漏內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: