进程阻塞或磁盘损坏?负载和等待时间非常高,但 CPU/内存使用率较低

进程阻塞或磁盘损坏?负载和等待时间非常高,但 CPU/内存使用率较低

我正在使用一个虚拟服务器,它突然经历了非常长的等待时间(10/20/30 秒),甚至从昨天开始基本请求超时,而之前它已经使用了一年多,没有任何问题。这是我的配置:

  • 8 个 CPU vCore、32 GB 内存、800 GB SSD
  • 标准 Plesk Obsidian 及最新更新

该服务器通过 Apache 使用 PHP 和 MariaDB 运行几个网站,没有什么特别之处,传入或传出的流量并不多,服务器上的处理量也不大。虽然此虚拟服务器上的平均负载通常在 1 到 3 之间,但现在突然变成了 20-100... 一旦我开始任何一个Apache 或 MariaDB 服务。

通过htop我可以看到:

  • 最多 30 个处于“D”状态(不可中断睡眠)的进程
  • CPU 使用率非常低(大多数核心上低于 5% 甚至 0%)
  • 有足够的可用内存(磁盘空间也可用)
  • 没有未知/异常进程(主要与 Plesk、MariaDB 和 Apache 相关)

通过iotop我可以看到:

  • 磁盘活动非常有限,大部分时间读/写都为 0 或接近 0

vmstat 1 5给出以下输出

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs US SY ID WA st
 1 13      0 1055820      0 25834552    2    2   128    59    0   93  8  1 90  0  0
 2 14      0 975180      0 25870484    0    0    16     0    0  586 31  4 65  0  0
 1 16      0 910584      0 25873184    0    0   100    48    0  374  7  2 92  0  0
 0 16      0 920048      0 25883484    0    0    16    64    0  415  8  1 91  0  0
 0 15      0 954344      0 25883472    0    0    96  1432    0  383  1  0 99  0  0

因此,看起来好像有什么东西在阻止这些进程的执行,直到它们每隔一分钟左右才会执行一次。然后,我可以在其中一个网站上加载几个页面,这些进程不再出现,htop但再点击几次,突然又出现了同样的情况……

由于平均负载较高,通过 SFTP 或 SSH 等方式与此虚拟服务器的交互也比以前慢得多。我已经检查了 MariaDB 数据库的运行状况,没有发现任何问题,当 MariaDB 服务未运行时,负载问题也会发生。

我的问题:

  • 我该做什么或用什么来找出这些进程无法执行/阻碍它们的具体原因?
  • 是不是内存或磁盘有问题?我应该运行吗fsck(这需要让服务器离线)?

任何可以记录硬件相关问题的内容都会很有帮助。我查看了其他关于高平均负载的帖子,但找不到解决我的问题的方法。

更新

我注意到上面的bufferswpd始终为 0。这是 的输出cat /proc/meminfo,这可能是原因吗?

MemTotal:       33554432 kB
MemFree:          639036 kB
MemAvailable:   25227064 kB
Cached:         24259912 kB
Buffers:               0 kB
Active:         19847944 kB
Inactive:       12315884 kB
Active(anon):    7664604 kB
Inactive(anon):   572316 kB
Active(file):   12183340 kB
Inactive(file): 11743568 kB
Unevictable:       11228 kB
Mlocked:           28388 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:           8485104 kB
Writeback:             8 kB
AnonPages:       8236920 kB
Shmem:            328712 kB
Slab:             683440 kB
SReclaimable:     661120 kB
SUnreclaim:        22320 kB

输出iostat -d(但显示“40 CPU”,所以可能是整个服务器?):

Device       tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
somename     13805,99     41065,30   2557318,07 2443426623 152162982648

更新

被阻止进程的示例:

被阻止进程的示例

更新

与该托管商其他客户的持续讨论表明,这些虚拟服务器使用的虚拟化平台存在普遍问题(例如,资源无法提供给虚拟服务器)。一些客户已经遇到问题好几天了。一旦有更多信息可用,我会更新。

更新

以下是有关该托管商当前所存在的问题的德语新闻报道:Stratos V-Server 上的常驻状态

最后更新

经过一周时间,托管商似乎已经解决了此虚拟服务器的问题,对于使用其他虚拟服务器的一些客户来说,甚至花了近两周时间。主要原因是交换机之间的通信问题导致 io 操作延迟。详情可在此处找到:Strato:大规模 V 服务器攻击

相关内容