Google cloud platform 429，尽管有足够的净空，但qps非常低

这里是云中的幻影。我有一个非常低的qps服务，提供HTML和后续资源。因此，它通常处于空闲状态，然后在5秒内接收20个请求，并发度远低于10，其中并发限制为80。我观察到，客户机通常会从云运行中接收429，通常是在服务处于非活动状态之后，即使实例仍处于运行状态（因此这不是冷启动问题）。这可以在第一个请求上，但通常在序列中间的某个地方（即图标，CSS不加载）。 该实例是并发的、响应迅速的，可以轻松地处理负载，但Cloud Run不允许这样做。也没有其他实例被旋转，尽管我们甚至没有达到2的最大值。这表明云运行出于某种原因估计需要2个以上的实例

以下是根据日志编辑的典型请求序列：

... 20 min idle ...
I 2020-03-27T18:21:27.619317Z GET 307 288 B 5 ms
I 2020-03-27T18:21:27.706580Z GET 302 0 B 0 ms
I 2020-03-27T18:21:27.760271Z GET 200 5.83 KiB 5 ms
I 2020-03-27T18:21:27.838066Z GET 200 1.89 KiB 4 ms
I 2020-03-27T18:21:27.882751Z GET 200 1.05 KiB 4 ms
I 2020-03-27T18:21:27.886743Z GET 200 582 B 3 ms
I 2020-03-27T18:21:27.893060Z GET 200 533 B 4 ms
I 2020-03-27T18:21:27.897352Z GET 200 5.35 KiB 4 ms
I 2020-03-27T18:21:27.899086Z GET 200 11.38 KiB 6 ms
I 2020-03-27T18:21:27.905967Z GET 200 22.48 KiB 13 ms
I 2020-03-27T18:21:27.906113Z GET 200 592 B 13 ms
I 2020-03-27T18:21:27.907967Z GET 200 35.08 KiB 14 ms
...500ms...
I 2020-03-27T18:21:28.434846Z GET 200 2.76 MiB 50 ms
I 2020-03-27T18:21:28.465552Z GET 200 2.29 MiB 67 ms <= up to here all resources served from image
...2500ms...
I 2020-03-27T18:21:31.086943Z GET 200 2.95 KiB 706 ms <= IO-bound, talking to backend api
...1600ms...
W 2020-03-27T18:21:32.674973Z GET 429 14 B 0 ms   <= !!!
W 2020-03-27T18:21:32.675864Z GET 429 14 B 0 ms   <= !!!
W 2020-03-27T18:21:32.676292Z GET 429 14 B 0 ms   <= !!!
I 2020-03-27T18:21:32.684265Z GET 200 547 B 6 ms
I 2020-03-27T18:21:32.686695Z GET 200 504 B 9 ms
I 2020-03-27T18:21:32.690580Z GET 200 486 B 12 ms

---

这看起来像是一个云运行，我建议将其加上星号以接收通知并加快解决。

云运行的云监控指标：CPU利用率显示了什么？如果增加内存，行为是否会改变？感谢回来。CPU利用率@99p左右的时间是20%的最大值。我可以玩内存。现在我已经将最大实例数更改为10，并将观察更长的时间，到目前为止不再观察429（但使用量也非常少）。谢谢，这个问题最终得到了确认，显然现在已经得到了解决。

template:
    metadata:
...
      annotations:
...
        autoscaling.knative.dev/maxScale: '2'
    spec:
      timeoutSeconds: 900
...
      containerConcurrency: 80
      containers:
...
        resources:
          limits:
            cpu: 1000m
            memory: 244Mi