Under 1. mai-høytiden oppgraderte serviceteamet servermiljøet på Yitaobang-nettsiden fra 5,3 PHP til 5,6 PHP, og etter vellykket oppgradering ble serverens CPU blåst opp til over 90 %, som har vært høyt. Sjekk serveren og finn at flere PHP-FPM-prosesser gjør CPU-belastningen for høy, noe som gjør at nettsiden ikke kan nås normalt. Å reinstallere servermiljøet og PHP-versjonen flere ganger, og til og med endre PHP til HHVM, kan ikke løse problemet med høy CPU-belastning.
E-Taobang-serveroperasjonsprosess (tjenestearkitekturdiagram): Brukerklient → domenenavnoppløsning → Baidu Cloud Acceleration Node (CDN/caching/anti-DDOS/CC-angrep) → Alibaba Cloud Shield-node (anti-CC/DDOS/WAF-angrep) → ECS-kildeserver (CSS, JS og bilder for CDN-omdirigering), og Alibaba Cloud Cloud Shield har ingen angrepsinformasjon, så det kan fullstendig utelukkes som et angrep.
Når jeg ser på nginx-loggene, php-fpm-loggene og slow loggene, er det ingen unormale faktorer, og jeg ser flere TIME_WAIT informasjon fra netstat -n-kommandoen, som skyldes IP-segmentet til 100.97.x.x (det siste IP-segmentet er IP-adressen til Alibaba Cloud SLB-lyttetjenesten).
Uten videre om og men, la oss snakke om den spesifikke løsningen, som til slutt ble håndtert av det profesjonelle drifts- og vedlikeholdsteamet i Yitao-gjengen (V Station Power), og det endelige resultatet var at CPU-belastningen forårsaket av SLBs serviceovervåkingsinnstillinger ble for høy. Den opprinnelige SLB-tjenesten lytter til HTTP-protokollport 80, og http-protokollens helsesjekk vil regelmessig sende http-forespørsler fra flere hoder, noe som resulterer i kontinuerlig tilgang til å lese HTTP, noe som resulterer i php-fpm som gjør at CPU-belastningen overstiger 90 % over lang tid, og den spesifikke CPU-belastningskvoten avhenger av konfigurasjonen i ECS. Etter å ha endret helsesjekktjenesten, går CPU-bruken offline.
Hvis denne situasjonen også oppstår, endre helsesjekkkonfigurasjonen for SLB-tjenestelytting fra HTTP-protokoll 80 til TCP-protokoll 80-konfigurasjon som følger:
|