我们正在Elastic Beanstalk上运行节点API应用程序，并且正在将Dynamo用于数据库，而将Redis用于Elastic Cache。我通过对节点API运行请求调用循环来加载测试，模拟大约20,000个同时进行呼叫的用户。
它运行良好一段时间。它总共可以达到30,000多个电话。然后我开始无法连接到发电机和redis。我得到以下内容：
＆＃34;难以接近的主持人：dynamodb.us-west-2.amazonaws.com'. This service may not be available in the us-west-2＆＃39; 。区域\＆＃34; \＆＃34;代码\＆＃34;：\＆＃34; UnknownEndpoint \＆＃34; \＆＃34;堆\＆＃34;：\＆＃34; UnknownEndpoint ：难以接近的主持人：`dynamodb.us-west-2.amazonaws.com＆＃39;。＆＃34;
＆＃34; Redis与xxxxxx-lt-001.19atpm.0001.usw2.cache.amazonaws.com:6379的连接失败 - getaddrinfo ENOTFOUND＆＃34;
但在那一段时间里，它已经相当幸福地运行了很长一段时间。
我在应用服务器上看到大约20,000 / 30,000个连接。我看到我的呼叫到那时的响应时间不到200毫秒，突然间他们跳了长度，稳定地越来越长。我已将应用服务器上的打开文件数量增加到100,000，节点的最大连接数增加到50,000。
应用服务器是C4.xlarge。 CPU没有达到30％。 Dynamo和Redis都没有接近它们的极限，远非如此。网络峰值为40,000,000，网络峰值为100,000,000。
我现在完全难过了。有什么建议吗？
/etc/security/limits.conf文件：
ulimit -a
的结果核心文件大小（块，-c）0 数据seg大小（kbytes，-d）无限制 调度优先级（-e）0 文件大小（块，-f）无限制 待处理信号（-i）59742 最大锁定内存（kbytes，-l）64 最大内存大小（千字节，-m）无限制 打开文件（-n）100000 管道大小（512字节，-p）8 POSIX消息队列（字节，-q）819200 实时优先级（-r）0 堆栈大小（千字节，-s）8192 cpu时间（秒，-t）无限制 最大用户进程（-u）59742 虚拟内存（kbytes，-v）无限制 文件锁（-x）无限
更多信息 - 我在消息日志中发现了一些关于＆＃34; nf_conntrack的错误：表已满，丢包。＆＃34;所以我按照以下网页中的建议来增加表的大小。这让我更进一步，高达45,000左右的电话。然后它真的从桌子上掉了下来。立即从亚秒级响应时间到25秒响应时间。
答案 0 :(得分：1)
在这种情况下，似乎有几个较小的盒子会在导致网络爆炸之前耗尽他们的CPU。 c4.xlarge没有。部分原因可能是节点集群在节点v 12之前的版本中工作的方式很差，其中循环法没有平等地使用所有CPU。