Puncte:2

Apache „îngheață” de câteva ori pe zi

drapel in
JYD

Scriu aici după săptămâni petrecute luptă cu o problemă care face ca Apache să nu mai răspundă până când este repornit. Se întâmplă de 3/4 ori pe zi, uneori după ore, alteori după câteva minute, alteori după o zi. Nu există nicio relație (cel puțin nu există dovezi) cu numărul de conexiuni simultane la server: se întâmplă atât în ​​perioada de trafic intens (între orele 8.00 - 18.00), cât și pe timpul nopții când accesele sunt foarte reduse.

Configurare: VM pe Vmware ESXi Rel. 7 - OS: Ubuntu 20.04, Apache 2.4.41, PHP 8.0.15, Drivere MSSQL 17.8.1.1-1. 6 CPU "Xeon(R) Gold 5218", 12Gb Ram. 3 site-ul care rulează în PHP „pur” (fără CMS precum Wordpress, Drupal, Ruby On Rails etc). Awstats arată că cel din intranet fără acces extern servește < 10k pagini zi, celelalte aproximativ 200k pagini difuzate pe zi. De cele mai multe ori, utilizarea procesorului este de aproximativ 1%, iar memoria este de aproximativ 2 Gb. Când apare problema, nu sunt detectate „spikes” CPU/Memorie/rețea.

Atunci am instalat si configurat Monit că la fiecare 20 de secunde testează cu curl această pagină web PHP minimă:

<?php
echo "ok";
?>

În mod normal, se imprimă „ok”. În timpul „înghețului”, nici măcar această pagină simplă nu este difuzată; curl se termină cu eroare de timeout și declanșează monit pentru a face un „service apache2 restart”. După 2/3 secunde, site-ul revine la funcționalitatea normală (până la următoarea înghețare).

Urmează o listă de remedieri nereușite (nu în ordine cronologică):

  • A eliminat certbot-Letsencrypt și a folosit un certificat SSL achiziționat de Sectigo
  • S-a schimbat Apache de la mpm_worker la mpm_event
  • Au dezactivat o grămadă de module Apache neutilizate
  • Au dezactivat o grămadă de module PHP neutilizate
  • S-au dezactivat majoritatea joburilor cron necritice (chiar nu există dovezi că înghețarea are loc în timpul execuției joburilor cron).
  • S-a schimbat adaptorul de rețea virtuală de la VMXNET3 la E1000
  • Jurnalizare verbosă activată: nu sunt înregistrate informații/erori utile, pur și simplu există un interval de timp de 25-30 de secunde de la ultima pagină difuzată chiar înainte de blocarea și prima difuzare la finalizarea repornirii.
  • Activat de câteva zile mod_log_forensic: nu (!) erorile sunt raportate folosind utilitarul check_forensic
  • A verificat de două ori câteva reguli de rescriere în .conf și în .htaccess
  • S-a schimbat configurația Apache; valorile relevante sunt:
    StartServers 10
    MinSpareThreads 40
    MaxSpareThreads 120
    ThreadLimit 100
    ThreadsPerChild 75
    MaxRequestWorkers 450
    MaxConnectionsPerChild 1000

Nu există o corelație evidentă între „ultima” pagină/fișier difuzată înainte de problemă: uneori este o pagină PHP (evident nu este aceeași), alteori o imagine png/jpeg. Citirea jurnalelor Nu pot găsi solicitări anormale/malformate/excesive ale clientului.

Problema este 99,99% legată de Apache, serviciul PHP-fpm funcționează perfect și nu este necesar să-l reporniți după o înghețare. Toate celelalte servicii de rulare ale serverului nu sunt afectate.

Înainte de a scrie aici, am citit o mulțime de pagini web, dar nu am găsit niciun indiciu util (pentru mine).

Multumesc in adv

Ciao

JYD

drapel jp
Când Apache se blochează, verificați starea procesului cu `ps`. Verificați Apache `mod_status`. Utilizați „strace” pentru a afla ce fac procesele.
drapel fr
Poate că numărul de fire httpd influențează acest lucru? Deoarece este o mașină virtuală, poate rulează pe hypervisor cu memorie ram balooning?
drapel in
JYD
@AlexD Adaug un strace la un fișier și voi posta aici rezultatele
drapel in
JYD
@kazak Fără memorie „balonată”, monitorul ESX arată întotdeauna 0 KB. Toți cei 12 Gb sunt rezervați acestui VM
drapel in
JYD
In sfarsit am prins-o!!!!
drapel in
JYD
Problema a fost demonul „incron” al sistemului de fișiere configurat greșit și cu jurnalul dezactivat. În fișierul său de configurare, unul dintre evenimentele urmărite a avut o comandă greșită. Când activez fișierul jurnal al lui incron, pornește .log crește cu sute de linii/sec și ajunge rapid la dimensiunea de zeci de MB. Acest comportament ciudat a fost cauzat de un caracter de evadare greșit în fișierul său de conf: într-o linie era un „$\” în loc de un „\$” care făcea o condiție de cursă foarte previzibilă. S-a rezolvat, apache-ul a dispărut.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.