Multithreading .NetCore/NEST-ElasticSearch I/O问题或并发限制

我有一些问题已经有好几个星期了，我试了很多次都解决不了。 我有一个.NET核心应用程序，基本上就是整天索引和搜索文档。 这个应用程序允许在我的所有用例中并发调用Elastic，所以当我有一个大负载（比如几秒钟内1k个文档）时，我会毫无限制地调用Elastic（我没有找到任何限制，也许我应该限制线程…）。 我在生产中有2个ElasticSearch节点，它们为我的负载（根据Elastic的先决条件）提供了非常好的配置，16Go RAM，4vCPU

有时，似乎许多调用都会因此类错误而失败（我使用的是ApplicationInsights）：

我假设NEST正在做一个到弹性服务器的底层HTTP连接，只是超时/失败。 当我同时查看依赖项时，我可以看到运行时间超过100000毫秒的调用（但对于“正常”调用为4ms）

下面是一个索引示例：

我们的团队检查了所有通过网络的http路由，没有发现任何网络问题

当我们在两个节点上重新启动弹性服务并重新开始工作时，我们完全理解这是一个弹性问题。 两个节点的CPU和RAM使用率都很低。 我们“尝试”查看弹性原木，但实际上我们对此并不满意，但根据我们的“知识”，我们没有发现任何“异常”

我们正在一个接一个地为文档编制索引，从不臃肿。我们无法改变这一点，因为文档是通过ServiceBus队列从外部系统接收的，我们无法控制负载。因此，一条ServiceBus消息是对弹性服务器的单独PUT调用

我不能很容易地将其复制为honnest，但我希望使用NEST/ElasticSearch的人们能够提供一些反馈，以及他们如何管理自己的线程池

我是否应该限制弹性调用（例如使用信号量）

我应该更改弹性服务器配置吗

如果您需要更多信息，请告诉我

---

感谢您的帮助

您是否对群集进行了监视？如果是这样，抛出SocketException时服务器上的负载（CPU、Elasticsearch线程池）是什么样的？客户端还可以在发出请求时显示Tcp和Threadpool统计信息，这也可能有助于观察：您好，谢谢您的回答。当我们遇到这个异常时，服务器似乎没有受到压力，这是我的问题。通常情况下，服务器是根本原因，但我们几周前刚刚增加了CPU和RAM，在这个集群上从未见过一台服务器受到压力。谢谢你的链接，顺便说一句，如果它像是禁止流媒体，我不能在生产激活这个，对吗？对于性能问题和其他问题。。但我不知道这个选项，我会调查的。不幸的是，我无法“轻松”复制此问题