服务器负载很小，但网站响应不佳
Server load is minimal but website responds poorly
我有 VPS hetzner。服务器位于德国。
它有 256GB RAM，6 个 CPU（12 个线程）。
我有一个文件，从昨天开始，它在一秒钟内被请求了大约 30 次。文件有 2 个 Select、2 个更新、2 个插入查询，所以我假设（不确定这是如何工作的）来自该文件服务器的每秒大约有 180 个请求。所以在这个请求开始之后，服务器上的所有网站都开始加载不佳。我使这个文件 运行 只是一个 select 查询，然后死了。这没有帮助。在 WHM 中，负载约为 0.02。
我检查了错误日志，没有 max_user_connection 或任何错误。
我启用了慢查询日志并检查了日志文件。什么都没有（我用 select sleep(10) 测试过它并且记录了这个查询）。
这是访问统计，请注意5月30日：
过去 24 小时的带宽统计数据：
ssl_log 中有很多这样的错误（当然是不同的 IP）：
188.121.206.150 - - [30/May/2018:19:50:03 +0200] "-" 408 - "-" "-"
我一直在网上搜索很多，但找不到任何解决方案。谁能至少告诉我应该监视什么或在哪里监视。我可以完全访问服务器内部可能存在的任何内容。感谢任何帮助。
UPDATE 1
我有子域：banners.analyticson.com（现在允许访问）并且我有所有请求的图像和 html5 文件。
以一张图片为例：https://banners.analyticson.com/img/suy8G1S6RU.jpg
加载需要太多时间。正如我所注意到的，这个子域有一些问题。
我之前提到的脚本（有 6 个查询）只是试图将这些横幅之一提供给用户，因此该脚本的结果是 return 来自 banners.analyticson.com.
的一个横幅
UPDATE 2
我检查了我的脚本，没问题。只需不到 1 秒即可完成。
我还检查了 Top 命令并且有一个结果。我不确定 $MEM 值是否合适。
您将不得不缩小问题范围...
存在多个潜在问题。
首先要消除的是您的新脚本在开发笔记本电脑上的性能 - 我假设您使用的是 PHP，因此请使用 profiling tools 来确定发生了什么。如果是数据库查询，您将通过查看探查器来了解是哪一个。
如果您的 PHP 脚本和数据库查询没有问题，接下来要看的是：听起来您在基础架构上遇到了一些瓶颈资源。在这些情况下，运行 作为单个请求正常运行的脚本开始排队等待瓶颈资源，并且每个新请求都会添加到队列中，直到整个服务器开始爬行。这可能有点令人费解 - 从 top 开始并继续挖掘。
接下来，我会查看 configuration of Apache to make sure everything is squeaky clean - Apache used to have a default to do a reverse DNS lookup for every request, which slows the server down rather impressively on production. You may also want to look at your SSL configuration - the error you report is linked to a load balancer issue。
如果它不像内存那么简单，CPU 等，那么你会遇到更深奥的问题。您可能需要增加负载测试装置，这样您就可以在不影响实时站点的情况下进行实验 - 通常，我在尽可能类似于实时站点的机器上执行此操作，使用 Apache JMeter 生成负载，并找到 "inflection point"。通常，您会看到响应时间随着并发请求的数量线性增加，直到遇到瓶颈资源，此时响应时间迅速增加。举个简单的例子，如果你有 10 个可用的数据库连接，响应时间应该线性增加到 10 个并发连接，然后从 11 个开始变得更大。
知道拐点在哪里并能够重新创建拐点可以让您在负载下使用 PHP profiling tools。这是一项 很多 的工作。
更新
您正在使用 php-cgi；这很容易成为 运行 宁 PHP 脚本的最低效的方式。您的服务器几乎没有出汗 - CPU 并且内存基本上处于闲置状态。 Here's 如何比较 运行 PHP；考虑更改为 mod_php.
我有 VPS hetzner。服务器位于德国。
它有 256GB RAM，6 个 CPU（12 个线程）。
我有一个文件，从昨天开始，它在一秒钟内被请求了大约 30 次。文件有 2 个 Select、2 个更新、2 个插入查询，所以我假设（不确定这是如何工作的）来自该文件服务器的每秒大约有 180 个请求。所以在这个请求开始之后，服务器上的所有网站都开始加载不佳。我使这个文件 运行 只是一个 select 查询，然后死了。这没有帮助。在 WHM 中，负载约为 0.02。
我检查了错误日志，没有 max_user_connection 或任何错误。
我启用了慢查询日志并检查了日志文件。什么都没有（我用 select sleep(10) 测试过它并且记录了这个查询）。
这是访问统计，请注意5月30日：
过去 24 小时的带宽统计数据：
ssl_log 中有很多这样的错误（当然是不同的 IP）：
188.121.206.150 - - [30/May/2018:19:50:03 +0200] "-" 408 - "-" "-"
我一直在网上搜索很多，但找不到任何解决方案。谁能至少告诉我应该监视什么或在哪里监视。我可以完全访问服务器内部可能存在的任何内容。感谢任何帮助。
UPDATE 1
我有子域：banners.analyticson.com（现在允许访问）并且我有所有请求的图像和 html5 文件。
以一张图片为例：https://banners.analyticson.com/img/suy8G1S6RU.jpg
加载需要太多时间。正如我所注意到的，这个子域有一些问题。 我之前提到的脚本（有 6 个查询）只是试图将这些横幅之一提供给用户，因此该脚本的结果是 return 来自 banners.analyticson.com.
的一个横幅UPDATE 2
我检查了我的脚本，没问题。只需不到 1 秒即可完成。 我还检查了 Top 命令并且有一个结果。我不确定 $MEM 值是否合适。
您将不得不缩小问题范围...
存在多个潜在问题。
首先要消除的是您的新脚本在开发笔记本电脑上的性能 - 我假设您使用的是 PHP，因此请使用 profiling tools 来确定发生了什么。如果是数据库查询，您将通过查看探查器来了解是哪一个。
如果您的 PHP 脚本和数据库查询没有问题，接下来要看的是：听起来您在基础架构上遇到了一些瓶颈资源。在这些情况下，运行 作为单个请求正常运行的脚本开始排队等待瓶颈资源，并且每个新请求都会添加到队列中，直到整个服务器开始爬行。这可能有点令人费解 - 从 top 开始并继续挖掘。
接下来，我会查看 configuration of Apache to make sure everything is squeaky clean - Apache used to have a default to do a reverse DNS lookup for every request, which slows the server down rather impressively on production. You may also want to look at your SSL configuration - the error you report is linked to a load balancer issue。
如果它不像内存那么简单，CPU 等，那么你会遇到更深奥的问题。您可能需要增加负载测试装置，这样您就可以在不影响实时站点的情况下进行实验 - 通常，我在尽可能类似于实时站点的机器上执行此操作，使用 Apache JMeter 生成负载，并找到 "inflection point"。通常，您会看到响应时间随着并发请求的数量线性增加，直到遇到瓶颈资源，此时响应时间迅速增加。举个简单的例子，如果你有 10 个可用的数据库连接，响应时间应该线性增加到 10 个并发连接，然后从 11 个开始变得更大。
知道拐点在哪里并能够重新创建拐点可以让您在负载下使用 PHP profiling tools。这是一项 很多 的工作。
更新
您正在使用 php-cgi；这很容易成为 运行 宁 PHP 脚本的最低效的方式。您的服务器几乎没有出汗 - CPU 并且内存基本上处于闲置状态。 Here's 如何比较 运行 PHP；考虑更改为 mod_php.