Ram Lakshmanan在Elastic Load Balancer之后的多個(gè)AWS EC2實(shí)例上運(yùn)行的應(yīng)用程序中討論了一個(gè)奇怪的生產(chǎn)問(wèn)題。在本文中，查找有關(guān)錯(cuò)誤消息“ TCP：內(nèi)存不足-考慮調(diào)整tcp_mem”，如何處理以及有關(guān)內(nèi)存問(wèn)題和'dmesg'命令的一些結(jié)論性建議。

最近，我們遇到了一個(gè)有趣的生產(chǎn)問(wèn)題。一個(gè)應(yīng)用程序在Elastic Load Balancer后面的多個(gè)AWS EC2實(shí)例上運(yùn)行。該應(yīng)用程序在GNU / Linux OS，Java 8和Tomcat 8應(yīng)用程序服務(wù)器上運(yùn)行。

突然之間，一個(gè)應(yīng)用程序?qū)嵗兊脽o(wú)響應(yīng)。所有其他應(yīng)用程序?qū)嵗荚谡_處理流量。每當(dāng)從瀏覽器向該應(yīng)用程序?qū)嵗l(fā)送HTTP請(qǐng)求時(shí)，我們都會(huì)在瀏覽器上打印以下響應(yīng)。

Proxy Error  The proxy server received an invalid response from an upstream server.  The proxy server could not handle the request GET /. Reason: Error reading from remote server

我們使用了APM（應(yīng)用程序性能監(jiān)視）工具來(lái)檢查問(wèn)題。從APM工具中，我們可以觀察到CPU和內(nèi)存利用率是完美的。另一方面，從APM工具中，我們可以看到流量并沒(méi)有進(jìn)入這個(gè)特定的應(yīng)用程序?qū)嵗?。真是令人費(fèi)解。為什么流量沒(méi)有進(jìn)入？

我們登錄到該有問(wèn)題的AWS EC2實(shí)例。我們執(zhí)行了vmstat，iostat，netstat，top，df命令，以查看是否可以發(fā)現(xiàn)任何異常。令我們驚訝的是，所有這些出色的工具均未報(bào)告任何問(wèn)題。

對(duì)于下一步，我們重新啟動(dòng)了運(yùn)行該應(yīng)用程序的Tomcat應(yīng)用程序服務(wù)器。它也沒(méi)有任何區(qū)別。不過(guò)，這個(gè)應(yīng)用程序?qū)嵗緵](méi)有響應(yīng)。

DMESG命令

然后，我們?cè)诖薊C2實(shí)例上發(fā)出了' dmesg '命令。此命令顯示內(nèi)核的消息緩沖區(qū)。該命令的輸出通常包含設(shè)備驅(qū)動(dòng)程序產(chǎn)生的消息。在此命令生成的輸出中，我們注意到以下有趣的消息被重復(fù)打?。?/span>

[4486500.513856] TCP: out of memory -- consider tuning tcp_mem [4487211.020449] TCP: out of memory -- consider tuning tcp_mem [4487369.441522] TCP: out of memory -- consider tuning tcp_mem [4487535.908607] TCP: out of memory -- consider tuning tcp_mem [4487639.802123] TCP: out of memory -- consider tuning tcp_mem [4487717.564383] TCP: out of memory -- consider tuning tcp_mem [4487784.382403] TCP: out of memory -- consider tuning tcp_mem [4487816.378638] TCP: out of memory -- consider tuning tcp_mem [4487855.352405] TCP: out of memory -- consider tuning tcp_mem [4487862.816227] TCP: out of memory -- consider tuning tcp_mem [4487928.859785] TCP: out of memory -- consider tuning tcp_mem [4488215.969409] TCP: out of memory -- consider tuning tcp_mem [4488642.426484] TCP: out of memory -- consider tuning tcp_mem [4489347.800558] TCP: out of memory -- consider tuning tcp_mem [4490054.414047] TCP: out of memory -- consider tuning tcp_mem [4490763.997344] TCP: out of memory -- consider tuning tcp_mem [4491474.743039] TCP: out of memory -- consider tuning tcp_mem [4491859.749745] TCP: out of memory -- consider tuning tcp_mem [4492182.082423] TCP: out of memory -- consider tuning tcp_mem [4496318.377316] TCP: out of memory -- consider tuning tcp_mem [4505666.858267] TCP: out of memory -- consider tuning tcp_mem [4521592.915616] TCP: out of memory -- consider tuning tcp_mem

我們很高興看到此錯(cuò)誤消息：“ TCP：內(nèi)存不足-請(qǐng)考慮調(diào)整tcp_mem ”。這意味著在TCP級(jí)別發(fā)生內(nèi)存不足錯(cuò)誤。我們一直教導(dǎo)說(shuō)，內(nèi)存不足錯(cuò)誤只會(huì)在應(yīng)用程序級(jí)別發(fā)生，而不會(huì)在TCP級(jí)別發(fā)生。

還請(qǐng)參見(jiàn)： 誰(shuí)？為什么？什么？固定？– System.gc（）

問(wèn)題之所以令人著迷，是因?yàn)槲覀兠刻於荚诤粑@個(gè)OutOfMemoryError問(wèn)題。我們構(gòu)建了故障排除工具，如GCeasy和 HeapHero，以方便工程師調(diào)試在應(yīng)用程序級(jí)別（Java，Android，Scala，Jython…應(yīng)用程序）發(fā)生的OutOfMemoryError。關(guān)于這個(gè)OutOfMemoryError主題，我們已經(jīng)寫(xiě)了幾個(gè)博客。但是我們很沮喪地看到OutOfMemory在設(shè)備驅(qū)動(dòng)程序級(jí)別發(fā)生。我們從來(lái)沒(méi)有想到穩(wěn)定的Linux操作系統(tǒng)也會(huì)在設(shè)備驅(qū)動(dòng)程序級(jí)別出現(xiàn)問(wèn)題。受這個(gè)問(wèn)題困擾，我們不確定如何進(jìn)一步進(jìn)行。

因此，我們求助于Google God的幫助。搜尋搜索詞：“ TCP：內(nèi)存不足-考慮調(diào)整tcp_mem”，僅顯示12個(gè)搜索結(jié)果。除了一篇文章，他們都沒(méi)有太多的內(nèi)容。即使是一篇用外國(guó)語(yǔ)言寫(xiě)的文章，我們也聽(tīng)不懂。因此，我們不確定如何解決此問(wèn)題。

現(xiàn)在沒(méi)有其他解決方案了，我們繼續(xù)實(shí)施了通用解決方案，即“重啟”。我們重新啟動(dòng)了EC2實(shí)例，以撲滅即時(shí)起火。歡呼?。≈匦聠?dòng)服務(wù)器可立即解決問(wèn)題。顯然，該服務(wù)器已經(jīng)幾天沒(méi)有重啟（例如超過(guò)70天以上）?？赡苡捎谶@個(gè)原因，應(yīng)用程序可能具有飽和的TCP內(nèi)存限制。

我們與一位在世界一流技術(shù)公司工作的聰明朋友取得了聯(lián)系。這個(gè)朋友問(wèn)我們?yōu)橐韵聝?nèi)核屬性設(shè)置的值：

• net.core.netdev_max_backlog

• net.core.rmem_max

• net.core.wmem_max

• net.ipv4.tcp_max_syn_backlog

• net.ipv4.tcp_rmem

• net.ipv4.tcp_wmem

老實(shí)說(shuō)，這是我們第一次聽(tīng)到這些特性。我們發(fā)現(xiàn)以下是在服務(wù)器中為這些屬性設(shè)置的值：

net.core.netdev_max_backlog = 1000 net.core.rmem_max = 212992 net.core.wmem_max = 212992 net.ipv4.tcp_max_syn_backlog = 256 net.ipv4.tcp_rmem = 4096        87380   6291456 net.ipv4.tcp_wmem = 4096        20480   4194304

我們的朋友建議更改以下值：

net.core.netdev_max_backlog=30000 net.core.rmem_max=134217728 net.core.wmem_max=134217728 net.ipv4.tcp_max_syn_backlog=8192 net.ipv4.tcp_rmem=4096 87380 67108864 net.ipv4.tcp_wmem=4096 87380 67108864

他提到設(shè)置這些值將消除我們面臨的問(wèn)題。我正在與您分享價(jià)值觀（因?yàn)檫@可能會(huì)對(duì)您有所幫助）。顯然，與他提供的價(jià)值相比，我們的價(jià)值非常低。

結(jié)論

以下是我們要得出的一些結(jié)論：

• 甚至現(xiàn)代的行業(yè)標(biāo)準(zhǔn)APM（應(yīng)用程序性能監(jiān)視）工具也不能完全解決我們今天面臨的應(yīng)用程序性能問(wèn)題。

• ' dmesg '命令是您的朋友。您可能希望在應(yīng)用程序無(wú)響應(yīng)時(shí)執(zhí)行此命令，它可能會(huì)指出有價(jià)值的信息。

• 內(nèi)存問(wèn)題不必在我們編寫(xiě)的代碼中發(fā)生，甚至可以在TCP /內(nèi)核級(jí)別發(fā)生。