Durante la festività del Primo Maggio, il team di assistenza ha aggiornato l'ambiente server del sito Yitaobang, da PHP5.3 a PHP5.6, e dopo l'aggiornamento riuscito, la CPU del server è stata riportata a oltre il 90%, cifra che è rimasta alta. Controlla il server e scopri che più processi PHP-FPM causano un carico della CPU troppo elevato, facendo sì che il sito web non possa essere accessibile normalmente. Reinstallare più volte l'ambiente server e la versione PHP, e persino cambiare PHP in HHVM, non può risolvere il problema dell'elevato carico della CPU.
Processo operativo server E-Taobang (diagramma dell'architettura dei servizi): client utente → risoluzione dei nomi di dominio → nodo Baidu Cloud Acceleration (attacchi CDN/cache/anti-DDOS/CC) → nodo Alibaba Cloud Shield (attacchi anti-CC/DDOS/WAF) → server sorgente ECS (CSS, JS e immagini per la deviazione CDN), e Alibaba Cloud Cloud Shield non ha alcuna informazione sugli attacchi, quindi può essere completamente escluso come attacco.
Guardando i log nginx, i log php-fpm e i log lenti, non ci sono fattori anomali, e vedo molteplici informazioni TIME_WAIT dal comando netstat -n, causato dal segmento IP di 100.97.x.x (l'ultimo segmento IP è l'indirizzo IP del servizio di ascolto Alibaba Cloud SLB).
Senza ulteriori indugi, parliamo della soluzione specifica, che è stata infine gestita dal team professionale di gestione e manutenzione della Yitao Gang (V Station Power), e il risultato finale è stato che il carico CPU causato dalle impostazioni di monitoraggio del servizio dell'SLB era troppo elevato. Il servizio SLB originale ascolta la porta 80 del protocollo HTTP, e il controllo di salute del protocollo http invia regolarmente richieste http da più teste, con conseguente accesso continuo a lettura HTTP, con un php-fpm che fa sì che il carico della CPU superi il 90% per molto tempo, e la quota specifica di utilizzo del carico della CPU dipende dalla configurazione dell'ECS. Dopo aver cambiato il servizio di controllo della salute, l'uso della CPU va offline.
Se si verifica anche questa situazione, si modifica la configurazione del controllo di salute dell'ascolto dei servizi SLB dal protocollo HTTP 80 alla configurazione TCP protocollo 80 come segue:
|