降低Linux上ASP Core的性能

经过大量的故障排除后，我对该问题进行了大幅编辑。潜在的问题是相同的，但我设法单独进行了复制，从而使我的关注点从以前变得不太相关。

我正在将高性能ASP Core 3.1站点从Azure Web Apps迁移到DigitalOcean Kubernetes。我现在正在进行两个Linux部署。

在上述两个部署之一（流量最大的部署中）中，我看到请求花费越来越多的时间，直到请求开始超时为止。对于Kubernetes，我的活动探测器随后杀死了容器，从而留下了如下的执行时间：

在我的原始草案中，我错误地将问题归结为Kubernetes与内存进行通讯的方式，因为内存压力似乎随着响应时间的增长而上升，并且我怀疑在与也不断增加的CPU配合使用时出现页面调度问题，似乎在其他任何地方都无法复制。

但是现在，

我设法使该问题在以前没有的香草Linux上重现。我不确定发生了什么变化，因为我仍在使用相同的部署。但是我不会抱怨，因为这应该可以使故障排除更加容易。

将我们带到htop。我不确定这是否很奇怪，但是该过程似乎正在旋转很多线程。执行几分钟后，似乎稳定在4,900。

在遇到许多线程时，故障开始。 App Insights告诉我这是System.OutOfMemoryException中的System.Threading.Tasks.Task.ScheduleAndStart。

同时，内存可能有趣，也可能不有趣。实际使用的RAM保持在800-1,000 MB之间，这很多，但是与我在本地看到的一致。该服务器具有8 GB的RAM，因此可以。

但是虚拟内存很大。我认为它什么都没有，并且虚拟内存可能会引起误解，但它攀升至43.7 GB。我假设这是高任务数的结果。

CPU似乎在两种状态之间花费时间50/50。首先，所有四个核心的挂出率在0-10％之间，可能会有一些峰值，但没有任何异常。这就是我所期望的。
但是突然之间，所有四个内核在几（10-20）秒钟内都固定为100％。

此问题似乎与an issue on CoreCLR极其相似，该问题原来是由于生命周期管理不当所致，但经过很多研究，我什么都找不到（Roslyn分析仪也找不到）

我只是在这里撞墙而已。我还可以尝试解决什么问题？

一些环境信息：

您拥有的启动时间很长（5分钟）。没有准备就绪探针，这意味着您的容器即使在完全准备好处理请求之前也可能正在接收请求。您知道为什么期望5分钟启动以及为什么没有辐射度探针吗？