有时，我们的 Linux LAMP 服务器（使用 PHP-FPM、HW RAID 上的薄 LVM 上的 XFS、Centos8）会变得无法访问并停止响应 HTTP(S) 请求。
通过集中日志记录，我们发现在这些情况下，平均负载会迅速飙升至数百，而越来越多的进程（systemd-journald、php 进程、内核 xfs/dm 线程……）进入 D 状态。根据 iostat 和 pidstat，CPU 和磁盘负载并不大，而平均负载徘徊在 170 左右，这很奇怪。从 htop/ps 输出来看，没有单个或一组流氓进程可以解释这种行为。只是标准进程似乎遇到了某种“障碍”。
磁盘监控中唯一奇怪的一点是，在这些过载事件期间，iostat 会间歇性地报告分区 /var 的 w_await 相当高（2500-5000 毫秒，而其他分区（如 /var/log、/var/lib/mysql）大多不会超过 10 毫秒）。这个分区大部分时间应该很安静，因此不清楚为什么 iostat 会在那里报告如此长的 w_await 时间。
唯一的解决方案就是对服务器进行电源循环。
这种情况发生在两台同类服务器上，其他服务器上从未发生过。这似乎是某种 FS/块层/控制器/磁盘故障；许多进程突然开始等待磁盘或内核中的其他内容，但根据 iotop/iostat，磁盘并没有做太多事情。
有没有办法查询 Linux 内核 FS/块层/控制器驱动程序它们究竟在对存储做什么以及代表哪个进程？ iotop/iostat 等标准工具仅告诉我 I/O 活动进程的名称和磁盘分区活动，但没有告诉我哪些进程访问哪个磁盘分区以及它们在那里到底在做什么。
答案1
在这种情况下，我发现它有助于限制堆栈上部连接的数量。
当超过 100积极的进程在运行，它们相互竞争。它们争夺资源（CPU 等）。最终结果是全部进程运行得更慢，有时你觉得唯一的解决办法就是重新启动服务器。
对于 MariaDB，我建议打开 slowlog，以便您可以识别对系统影响最大的查询。然后加快速度。如果您需要帮助，请提供查询、其 Explain 和 Create Table。更多： http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog
加快一些查询可能会降低 170 平均负载和 I/O，从而缓解瓶颈。