私は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:~#
VPSを管理するためにPlesk 18.0.48を使用しています。数週間、私のすべてのウェブサイトが非常に遅くなり、時には504 nginxエラーが発生します。 SSH端末を開くと、コマンド入力、ファイル編集、リモートファイルダウンロードなど、すべてが遅くなります（238.00 KiB / s！）。
これがhtopが提供するものです：
リソースの問題が見えますか？ RAMとCPUがよさそうです！サーバーはwordpressネットワークを実行するためにのみ使用されるため、WPは問題のようですが、どのように開始するかを見つけることができません。 php-fmですか？ Apache？ mysqld? …問題の原因は誰ですか？
修正する
外部システム管理者に詳細を確認するよう依頼し、彼はTelegrafを使って私に次のことを送りました。
彼は問題がディスクI / O（80書き込み/秒）だと言ったが、それでもなぜそれがわからない！ディスクI / Oが多すぎる原因をどのように見つけることができますか？ mysqldのようですが、よくわかりません。 （各サイトで約10個のUPDATEクエリが生成され、調査が進行中です。）
答え1
「WordPress Multisiteを使用した450の簡単なウェブサイト」：この問題は、PHP-FPMプロセスによってシステムに過負荷が発生したために発生したと確信しています。根本的な原因は通常、悪意のあるボットが特定のドメインを攻撃するためです。
- ドメインのウェブサーバーログを確認して、どのドメインが多数のリクエストを受けているかを確認します。
- （rootとして）実行して、
ps aux | grep php-fpmどのPHP-FPMプロセスが存在するか、どのユーザーがプロセスを所有しているかを確認し、どのドメインに関連付けられているか実行しているか（rootとして）出力から直接インポートします。プロセスのプロセスIDはstrace -p <pid>どこにあり、観察します。<pid>実行する操作（出力でドメインへの参照を見つけることができます）。 - ルートとして実行し、
watch "ps aux | sort -nrk 3,3 | head -n 20"ロードされた20のプロセスを観察して、どのプロセスが最も多くのCPUを消費しているかを確認します。
504 結果は、応答しない PHP プロセスが原因であることがほぼ確実です。長期実行スクリプトが無限ループに閉じ込められているか、PHP-FPMのmax_childrenが低すぎるため、新しいサブプロセスを作成できず、NginxはWebサイトから応答を取得できません。