我在 Debian 10 的 VPS 上使用 Wordpress Multisite 运行大约 450 个简单的网站。以下是有关资源的一些数据：
root@hr711523385:~# free -mh
total used free shared buff/cache available
Mem: 57Gi 9,2Gi 1,2Gi 246Mi 47Gi 47Gi
Swap: 16Gi 9,9Gi 7,0Gi
root@hr711523385:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 40 bits physical, 48 bits virtual
CPU(s): 16
On-line CPU(s) list: 0-15
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 16
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 61
Model name: Intel Core Processor (Broadwell, IBRS)
Stepping: 2
CPU MHz: 3000.000
BogoMIPS: 6000.00
Virtualization: VT-x
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
L3 cache: 16384K
NUMA node0 CPU(s): 0-15
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ibrs ibpb tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat
root@hr711523385:~#
我正在使用 Plesk 18.0.48 来管理 VPS。几周以来，我所有的网站都变得非常慢，有时我会收到 504 nginx 错误。当我打开 SSH 终端时，一切都很慢：输入命令、编辑文件、下载远程文件（238.00 KiB/s！！）
这是 htop 给出的：
您看到资源问题了吗？ RAM 和 CPU 看起来不错（对我来说）！由于服务器仅用于运行wordpress网络，我认为WP是问题所在，但我找不到如何开始：是php-fm吗？阿帕奇？ mysqld？ ……问题的根源是谁？
更新
我请外部系统管理员进行更深入的研究，他使用 Telegraf 并向我发送了以下内容：
他说问题是磁盘 i/o (80 write/s) 但他仍然不知道原因！如何找到产生如此多磁盘 I/O 的原因？我认为是 mysqld，但我不确定（每个网站都会生成大约 10 个 UPDATE 查询，调查正在进行中）
答案1
“使用 Wordpress Multisite 的 450 个简单网站”：我确信该问题是由于 PHP-FPM 进程使系统过载而引起的。根本原因通常是恶意机器人正在攻击某些域。
- 检查域的 Web 服务器日志，找出哪个域收到了许多请求。
- 运行（以 root 身份）
ps aux | grep php-fpm找出存在哪些 PHP-FPM 进程、哪个用户拥有它们，然后直接从输出中获取它们与哪个域相关或运行（也以 root 身份）：strace -p <pid>其中<pid>是进程的进程 ID，观察他们在做什么（您将在输出中找到对域的引用）。 - 运行（以 root 身份）
watch "ps aux | sort -nrk 3,3 | head -n 20"观察 20 个负载进程，找出哪些进程最耗 CPU。
504 结果几乎肯定也是由 PHP 进程无响应造成的。要么是长时间运行的脚本陷入永无休止的循环，要么是 PHP-FPM 的 max_children 设置太低，以至于无法生成新的子进程，因此 Nginx 无法从网站获得响应。