长腿少妇视频小说,AV大黑逼,亚洲日本精品A在线观看,国产又粗又猛又黄又湿视频

您當(dāng)前的位置 :環(huán)球傳媒網(wǎng)>資訊 > 正文
案例分享-full gc導(dǎo)致k8s pod重啟
2023-05-04 10:34:27 來(lái)源:博客園 編輯:

在之前的記一次k8s pod頻繁重啟的優(yōu)化之旅中分享過(guò)對(duì)于pod頻繁重啟的一些案例,最近又遇到一例,繼續(xù)分享出來(lái)希望能給大家?guī)?lái)些許收獲。


(資料圖片)

問(wèn)題現(xiàn)象

報(bào)警群里突然顯示某pod頻繁重啟,我隨即上去查看日志,主要分這么幾步:

1.查看pod重啟的原因,kubectl descirbe pod

Last State:     Terminated      Reason:       Error      Exit Code:    137

上面的Reason:Error太寬泛了,不能直觀(guān)的知道原因,Exit code:137一般表示程序被SIGKILL中斷信號(hào)殺死,異常原因可能為:

https://cloud.tencent.com/document/product/457/42945

首先排除OOMKilled情況,剩余的就是livenessProbe(存活檢查)失敗。

2.查看pod事件,kubectl descirbe pod,重點(diǎn)關(guān)注輸出的Events部分

Warning  Unhealthy  2m56s (x8 over 7m16s)   kubelet            Liveness probe failed: Get http://10.244.11.136:8080/jc_actuator_1/health: net/http: request canceled (Client.Timeout exceeded while awaiting headers)Normal   Killing    2m56s                   kubelet            Container enterprise-service failed liveness probe, will be restarted

熟悉的健康檢查失敗(超時(shí)),是什么導(dǎo)致超時(shí)呢,繼續(xù)找日志。

3.結(jié)合之前的排查經(jīng)驗(yàn),我認(rèn)為gc的嫌疑最大,所以查看gc日志

貼一部分日志,可以看到Full GC很繁忙,而且每次結(jié)束后內(nèi)存幾乎沒(méi)有釋放,應(yīng)用已經(jīng)是處于停擺狀態(tài),接下來(lái)要做的就是找出Full GC的兇手。

2023-04-22T14:30:58.772+0000: 574.764: [Full GC (Allocation Failure) 2023-04-22T14:30:58.772+0000: 574.764: [Tenured: 2097151K->2097151K(2097152K), 3.6358812 secs] 2569023K->2568977K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.6359987 secs] [Times: user=3.64 sys=0.00, real=3.63 secs] 2023-04-22T14:31:02.410+0000: 578.402: [Full GC (Allocation Failure) 2023-04-22T14:31:02.410+0000: 578.402: [Tenured: 2097151K->2097151K(2097152K), 3.5875116 secs] 2569023K->2568980K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.5876388 secs] [Times: user=3.59 sys=0.00, real=3.59 secs] 2023-04-22T14:31:05.999+0000: 581.991: [Full GC (Allocation Failure) 2023-04-22T14:31:05.999+0000: 581.991: [Tenured: 2097152K->2097151K(2097152K), 3.5950824 secs] 2569024K->2568987K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.5951774 secs] [Times: user=3.59 sys=0.00, real=3.60 secs] 2023-04-22T14:31:09.596+0000: 585.587: [Full GC (Allocation Failure) 2023-04-22T14:31:09.596+0000: 585.587: [Tenured: 2097151K->2097151K(2097152K), 3.5822343 secs] 2569023K->2568849K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.5823244 secs] [Times: user=3.58 sys=0.00, real=3.58 secs] 2023-04-22T14:31:13.180+0000: 589.172: [Full GC (Allocation Failure) 2023-04-22T14:31:13.180+0000: 589.172: [Tenured: 2097151K->2097151K(2097152K), 3.6316461 secs] 2569020K->2568910K(2569024K), [Metaspace: 119380K->119380K(1163264K)], 3.6317393 secs] [Times: user=3.63 sys=0.00, real=3.64 secs] 2023-04-22T14:31:16.813+0000: 592.805: [Full GC (Allocation Failure) 2023-04-22T14:31:16.813+0000: 592.805: [Tenured: 2097151K->2097151K(2097152K), 3.6070671 secs] 2569021K->2568907K(2569024K), [Metaspace: 119380K->119380K(1163264K)], 3.6071998 secs] [Times: user=3.60 sys=0.00, real=3.60 secs] 2023-04-22T14:31:20.425+0000: 596.417: [Full GC (Allocation Failure) 2023-04-22T14:31:20.425+0000: 596.417: [Tenured: 2097151K->2097151K(2097152K), 4.7111087 secs] 2569020K->2568899K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 4.7112440 secs] [Times: user=4.71 sys=0.00, real=4.71 secs] 2023-04-22T14:31:25.142+0000: 601.133: [Full GC (Allocation Failure) 2023-04-22T14:31:25.142+0000: 601.133: [Tenured: 2097151K->2097151K(2097152K), 3.8752248 secs] 2569023K->2568899K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 3.8753506 secs] [Times: user=3.88 sys=0.01, real=3.87 secs] 2023-04-22T14:31:29.021+0000: 605.012: [Full GC (Allocation Failure) 2023-04-22T14:31:29.021+0000: 605.012: [Tenured: 2097151K->2097151K(2097152K), 3.5892311 secs] 2569023K->2568910K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 3.5893335 secs] [Times: user=3.59 sys=0.00, real=3.59 secs] 2023-04-22T14:31:32.612+0000: 608.604: [Full GC (Allocation Failure) 2023-04-22T14:31:32.612+0000: 608.604: [Tenured: 2097151K->2097151K(2097152K), 3.5236182 secs] 2569023K->2568915K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 3.5237085 secs] [Times: user=3.52 sys=0.00, real=3.52 secs] 
背景知識(shí)

我們的服務(wù)部署在k8s中,k8s可以對(duì)容器執(zhí)行定期的診斷,要執(zhí)行診斷,kubelet 調(diào)用由容器實(shí)現(xiàn)的 Handler (處理程序)。有三種類(lèi)型的處理程序:

ExecAction:在容器內(nèi)執(zhí)行指定命令。如果命令退出時(shí)返回碼為 0 則認(rèn)為診斷成功。

TCPSocketAction:對(duì)容器的 IP 地址上的指定端口執(zhí)行 TCP 檢查。如果端口打開(kāi),則診斷被認(rèn)為是成功的。

HTTPGetAction:對(duì)容器的 IP 地址上指定端口和路徑執(zhí)行 HTTP Get 請(qǐng)求。如果響應(yīng)的狀態(tài)碼大于等于 200 且小于 400,則診斷被認(rèn)為是成功的。

每次探測(cè)都將獲得以下三種結(jié)果之一:

Success(成功):容器通過(guò)了診斷。

Failure(失?。喝萜魑赐ㄟ^(guò)診斷。

Unknown(未知):診斷失敗,因此不會(huì)采取任何行動(dòng)。

針對(duì)運(yùn)行中的容器,kubelet 可以選擇是否執(zhí)行以下三種探針,以及如何針對(duì)探測(cè)結(jié)果作出反應(yīng):

livenessProbe:指示容器是否正在運(yùn)行。如果存活態(tài)探測(cè)失敗,則 kubelet 會(huì)殺死容器, 并且容器將根據(jù)其重啟策略決定未來(lái)。如果容器不提供存活探針, 則默認(rèn)狀態(tài)為 Success。

readinessProbe:指示容器是否準(zhǔn)備好為請(qǐng)求提供服務(wù)。如果就緒態(tài)探測(cè)失敗, 端點(diǎn)控制器將從與 Pod 匹配的所有服務(wù)的端點(diǎn)列表中刪除該 Pod 的 IP 地址。初始延遲之前的就緒態(tài)的狀態(tài)值默認(rèn)為 Failure。如果容器不提供就緒態(tài)探針,則默認(rèn)狀態(tài)為 Success。

startupProbe: 指示容器中的應(yīng)用是否已經(jīng)啟動(dòng)。如果提供了啟動(dòng)探針,則所有其他探針都會(huì)被 禁用,直到此探針成功為止。如果啟動(dòng)探測(cè)失敗,kubelet 將殺死容器,而容器依其重啟策略進(jìn)行重啟。如果容器沒(méi)有提供啟動(dòng)探測(cè),則默認(rèn)狀態(tài)為 Success。

以上探針介紹內(nèi)容來(lái)源于https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

尋找原因

前面提到是由于Full GC STW導(dǎo)致jvm無(wú)法提供服務(wù),那我們就看看是什么導(dǎo)致Full GC,具體的手段就是獲取heap dump文件,然后分析,什么時(shí)機(jī)去獲取呢?

這里采用的辦法是守株待兔,開(kāi)兩個(gè)窗口,一個(gè)盯著gc日志,當(dāng)看到有大量Full GC產(chǎn)生時(shí)在另一個(gè)窗口生成heap dump文件。

接下來(lái)通過(guò)Eclipse MAT工具分析dump文件

原因一目了然,是導(dǎo)出excel導(dǎo)致,涉及的數(shù)據(jù)接近10w條,且列比較多。

分析代碼

大概看了一下導(dǎo)出的代碼,問(wèn)題集中在以下四點(diǎn):

1.查詢(xún)數(shù)據(jù)沒(méi)有使用分頁(yè);

2.使用的Apache poi工具本身性能不好,內(nèi)存占用過(guò)高;

3.導(dǎo)出沒(méi)有限流,對(duì)于極度消耗資源的操作必須要控制并發(fā),保護(hù)系統(tǒng);

4.同步導(dǎo)出,用戶(hù)等待時(shí)間過(guò)長(zhǎng)時(shí)會(huì)選擇重試,對(duì)系統(tǒng)來(lái)講是雪上加霜。

改進(jìn)措施

1.查詢(xún)分頁(yè),保證往excel寫(xiě)數(shù)據(jù)時(shí)內(nèi)存中只會(huì)有一頁(yè)數(shù)據(jù);

2.使用性能更好的工具,如easyexcel;

3.異步導(dǎo)出,控制同時(shí)導(dǎo)出的并發(fā)數(shù);

經(jīng)過(guò)這三步改造以后,導(dǎo)出導(dǎo)致的Full GC問(wèn)題得以改善,上線(xiàn)一周再?zèng)]有發(fā)現(xiàn)由于大數(shù)據(jù)量的導(dǎo)出導(dǎo)致的pod重啟問(wèn)題。

推薦閱讀

1.容器服務(wù)pod異常排查

https://cloud.tencent.com/document/product/457/42945

2.通過(guò)Exit Code定位 Pod 異常退出原因

https://cloud.tencent.com/document/product/457/43125

3.pod異常問(wèn)題排查

https://help.aliyun.com/document_detail/412618.html#6

4. easyexcel

http://easyexcel.opensource.alibaba.com/

關(guān)鍵詞:

相關(guān)閱讀
分享到:
版權(quán)和免責(zé)申明

凡注有"環(huán)球傳媒網(wǎng)"或電頭為"環(huán)球傳媒網(wǎng)"的稿件,均為環(huán)球傳媒網(wǎng)獨(dú)家版權(quán)所有,未經(jīng)許可不得轉(zhuǎn)載或鏡像;授權(quán)轉(zhuǎn)載必須注明來(lái)源為"環(huán)球傳媒網(wǎng)",并保留"環(huán)球傳媒網(wǎng)"的電頭。

Copyright ? 1999-2017 cqtimes.cn All Rights Reserved 環(huán)球傳媒網(wǎng)-重新發(fā)現(xiàn)生活版權(quán)所有 聯(lián)系郵箱:8553 591@qq.com