最近我们遇到了一个有趣的生产问题。此应用程序在弹性负载平衡器后面的多个AWS EC2实例上运行。应用程序运行在GNU/Linux操作系统、java8、tomcat8应用服务器上。突然，nba大数据，一个应用程序实例没有响应。所有其他应用程序实例都正确处理了流量。每当HTTP请求从浏览器发送到此应用程序实例时，云端云服务器，我们都会得到以下响应，并打印在浏览器上。

我们使用APM（应用程序性能监视）工具来检查问题。从APM工具中，我们可以观察到CPU、内存的利用率是完美的。另一方面，通过APM工具，我们可以观察到流量没有进入这个特定的应用程序实例。真是令人费解。为什么交通不畅通？

我们登录了这个有问题的AWS EC2实例。我们执行vmstat、iostat、netstat、top、df命令来查看是否可以发现任何异常。令我们惊讶的是，所有这些伟大的工具都没有报告任何问题。

下一步，我们重新启动了运行该应用程序的Tomcat应用服务器。这也没什么区别。不过，这个应用程序实例根本没有响应。

然后我们在这个EC2实例上发出了"dmesg"命令。这个命令打印内核的消息缓冲区。此命令的输出通常包含设备驱动程序生成的消息。在这个命令生成的输出中，我们注意到重复打印以下有趣的消息：

我们很感兴趣地看到这个错误消息："TCP:内存不足-考虑调优TCP\u mem"。这意味着内存不足错误正在TCP级别发生。我们一直教导内存不足的错误只会发生在应用程序级别，而不会发生在TCP级别。

因此，大数据，我们求助于谷歌上帝的帮助。在google上搜索"TCP:内存不足-考虑调优TCP\u mem"，云快卖，只显示了12个搜索结果。但对于一篇文章来说，他们都没有太多的内容。甚至有一篇文章是用我们听不懂的外语写的。所以，我们不确定如何解决这个问题。在没有其他解决方案的情况下，我们继续实施通用解决方案，即"重启"。我们重新启动了EC2实例，以推迟立即发生的火灾。万岁！！重新启动服务器立即解决了问题。显然，这个服务器有好几天没有重新启动（比如超过70天），可能是因为应用程序的TCP内存限制已经饱和。我们联系了一位在世界一流科技公司工作的聪明朋友，top返利，寻求帮助。这位朋友问我们为以下内核属性设置的值：

core.netdev\u最大积压工作

core.rmem\u最大值

core.wmem\u最大值

ipv4.tcp\最大syn\积压

ipv4.tcp\ rmem

网络ipv4.tcp_wmem

老实说，这是我们第一次听说这些属性。我们发现下面是在服务器中为这些属性设置的值：

我们的朋友建议更改如下所示的值：

他提到设置这些值将消除我们所面临的问题。与你分享价值观（因为这可能对你有帮助）。显然，与他提供的值相比，我们的值已经非常低了。

结论

这里有几个结论，我们想得出：

即使是现代行业标准的APM（应用程序性能监视）工具也没有完全解决我们今天面临的应用程序性能问题。"dmesg"命令是您的朋友。当应用程序没有响应时，您可能希望执行此命令，它可能会指出有价值的信息内存问题不必发生在我们编写的代码中，它甚至可以发生在TCP/内核级别。