Recent m-am trezit cu un site web (Prestashop e-commerce pe o mașină Centos PHP-FPM /Apache / MySql) care nu răspundea și nu răspundea solicitărilor web.
După investigație, problema s-a datorat unui apel API făcut cu php-curl către un endpoint care era temporar offline, în interiorul unui fișier PHP al aplicației care a fost rechemat în toate paginile site-ului.
Apelul cURL a fost efectuat greșit fără o setare CURLOPT_TIMEOUT_MS, astfel încât utilizatorii care mi-au vizitat site-ul au completat rapid numărul maxim de conexiuni php, blocând procesele php-fpm și împiedicând serverul meu să primească alte conexiuni de intrare.
Mă întreb dacă se poate preveni/identifica rapid și eficient o astfel de problemă „în producție” de la terminal dacă se întâmplă din nou (mai ales pentru a înțelege rapid care este endpoint-ul blocat sau pentru a identifica fișierul din care este generat scriptul care a blocat serverul) , deoarece în cazul meu a trebuit să verific problema la „nivel de aplicație” și nu de pe server, deoarece:
- lansând „top”, serverul arată lista de procese php-fpm blocate fără nicio informație suplimentară pentru a înțelege problema (de asemenea, media de încărcare a serverului a fost de aproximativ 0,00, deoarece nu a existat aproape nicio activitate din cauza conexiunilor blocate).
- Lansarea „netstat -nputw” îmi arată o mulțime de conexiuni interne în starea TIME_WAIT, dar din nou nu există informații despre întreruperea „vinovat” (aș putea vedea punctul final apelat de php-curl cu netstat sau o comandă de rețea similară?)
- Lansând o „rătăcire” a proceselor php-fpm văd o mulțime de fișiere implicate, dar acest lucru nu este de mare ajutor deoarece site-ul, cu trafic mediu, deschide zeci și zeci de fișiere.
- Jurnalele serverului web m-au informat doar despre conexiunile timeout la resursele web, dar nu și despre scriptul care conține apelul problematic cURL.
Multumesc pentru ajutor.
