【发布时间】：2021-10-10 11:43:55
【问题描述】：
设置： 天蓝色云 Virtual M. nº1：（Debian 8 核） Docker 与应用程序 (API) Django Rest 与 Gunicorn（17 个同步工作者）
Virtual M nº2：（Debian 4 核心） 数据库 MySQL
注意：API 收到用户的用户调用，对 MySQL 进行 4 次 django ORM 查询（仅选择）并返回 OK 或错误。
我们每秒从 Apache JMeter 发出 220 个请求，时间不受限制。这些调用是 100% 成功的，平均需要 1200 毫秒， 我们控制 8 个 CPU 的工作负载，它们以 + -50% 的速度工作
根据我们的要求，直到这里一切都完美。
麻烦：
在 X Time 之后，突然间，响应时间几乎增加了三倍，平均达到 4000 毫秒。 CPU 达到 100%（htop 显示每个条的一半红色） （调用仍然 100% 成功）
我们经过数百次结构化测试后的分析：
时间 X 通常取决于自上次失败以来经过的时间（时间的三倍），通常是该时间的一半。 示例 1：如果此时它失败（即需要 4000 毫秒）并且我停止测试 2 分钟，则测试开始良好并在一分钟（大约）后再次失败。 示例 2：如果我停止它 1 小时，则需要 30 分钟才能失败。 示例 3：如果我停止它 15 小时，它需要 7 小时才能失败（大约）。
X Time 不依赖于 Docker 或服务器，因为如果我停止测试（当它失败时）我重新启动两个服务器并再次激活测试，从测试到失败需要一半的时间停下来。
MySQL 运行良好时（每次调用 1200 毫秒），每秒处理 700-800 次选择并有 5 到 7 个连接，当它失败时，它会下降到 180 个选择并连接大约 15 个用户。 我们尝试抛出外部查询来查看问题是否是基础被阻塞并且它响应非常快。 我们尝试了同步和异步工作者，它表现出相同的行为。 我们将 Gunicorn 换成了 UWSGI，它做的事情完全相同。 我们尝试了多个 gunicorn 配置并显示相同的行为。
有人可以帮助我吗？ 可能是一个雷鸣般的羊群问题？ 我不知道这是内核问题还是我不得不打电话给exorsist。
【问题讨论】：
标签： mysql django linux jmeter gunicorn