înregistrare Logare
Puncte:0
avatar Server

Serverul OpenLiteSpeed ​​de pe EC2 expiră pe site-ul mic de comerț electronic

drapel ph
aldo_91

Sper că vă descurci bine - rulez un site Wordpress cu Woocommerce pe un server web OpenLiteSpeed ​​care, în condiții de utilizare intensă a PHP, începe să arate erori Timed-out 504.Găzduiesc totul în AWS și mă chinui să identific cauzele erorilor 504 și ce ar putea fi îmbunătățit pentru a le evita. Iată câteva detalii:

Configurare AWS:

  • Serverul web este instalat într-o instanță t3.medium cu Ubuntu 20.04 amd64 și 50 Gb de stocare EBS (optimizare I/O activată). În prezent sunt utilizați aproximativ 10 Gb.
  • Rulează PHP 7.4 și
  • Folosesc două distribuții CloudFront pentru CDN: una pentru imagini de server (în S3) și cealaltă pentru fișiere CSS/JS de server.
  • Am un ELB pentru a gestiona traficul către serverul Web, Timpul de inactivitate este setat la 300 de secunde.
  • Am o instanță RDS db.t3.small (100Gb gp2) care rulează Mariadb 10.5.13, dimensiunea bazei de date este de aproximativ 1,5 gGb.
  • Folosesc Redis ElastiCache cu trei noduri cache.t3.micro.

Statistici site:

  • Site-ul are aproximativ 1.000 de accesări pe săptămână.
  • Aproximativ 350 de pagini de produse și 50 de pagini.
  • Dimensiunea paginii variază de la 500 kb la 13,5 Mb.

Care este problema?

  • Site-ul expiră și afișează erori 504 atunci când utilizează funcții PHP grele, cum ar fi încărcarea produselor (și atașarea imaginilor la acestea), încărcarea imaginilor, prin golirea memoriei cache OLS de mai multe ori (aproximativ 3-4) într-un interval mic de timp sau navigarea prin site-ul deschizând o grămadă de pagini de produse și adăugându-le în coș.
  • EC2 CPUUtilization arată vârfuri maxime la 99%, dar lățimea de bandă a rețelei pare în regulă atingând vârfuri maxime la 2,0 Gb, iar creditele CPU rămân constante.
  • Conexiunile Db ajung la 50 pe minut, iar utilizarea CPU fluctuează între 20% și 30%.
  • Creditul de explozie rămâne constant.
  • stderr.log arată mult „Limita maximă de proces pentru copii atinsă: 35, suplimentar: 0, curent: 35, ocupat: 35, vă rugăm să măriți LSAPI_CHILDREN.”.

Capturi de ecran (instanță EC2):

CPUUtilization%

NetIn+NetOut

Soldul creditelor CPU

Ce am incercat pana acum:

  • Am încercat să măresc numărul maxim de conexiuni și procese copii la 350, dar problema expirării rămâne.
  • Am crescut limita de memorie php.ini la 512 MB, dar nu a făcut nicio diferență.
  • Am încercat să măresc stocarea db de la 30 Gb la 100 Gb, fără noroc.
  • Am încercat să măresc stocarea instanței EC2 de la 30 Gb la 50 Gb, dar din nou nu am avut succes.

Întrebări/Ajutor necesar:

  • Pe baza configurării mele, ce valori (și agregarea lor) ar trebui să caut pentru a identifica cauzele rădăcină expirate? AWS are atât de multe informații încât sunt confuz cu privire la ceea ce ar putea muta de fapt acul.
  • Ar trebui să-mi extind instanța EC2 pentru a permite mai multă putere CPU? 0r ar trebui să-mi extind instanța RDS? sau niciuna? Am un buget limitat, așa că această opțiune nu este chiar fezabilă.
  • Există vreo configurație la serverul web pe care aș putea să o încerc? Mi-aș putea încărca fișierul conf dacă asta ajută.
  • Ar trebui să mut totul într-o găzduire gestionată și să trăiesc fericiți pentru totdeauna?

Mulțumesc anticipat

34
0 + 0
drapel jp
Eric
Pentru un server cu 2 CPU și 4 GB RAM, ștergerea memoriei cache nu ar trebui să provoace problema de timeout PHP. Poate că puteți trimite un bilet la [email protected] pentru asistență suplimentară.
0
Răspunde
Tim avatar
drapel gp
Tim
1000 de accesări pe săptămână reprezintă o solicitare la fiecare _zece minute_, ceea ce este inactiv, aveți o cantitate masivă de hardware pentru acea încărcătură mică. Sau sarcina ta este mai mare? Cum folosești 2 GB pe minut, adică 86 TB/lună, ceea ce este MASIV pentru 1000 de accesări pe oră. Nu există nicio posibilitate ca procesorul tău să fie la 100%, uită-te la asta ca problema ta principală - folosește utilitarul Linux „de sus” ca punct de plecare. Instanța dvs. va fi epuizată din creditele CPU, deoarece CPU-ul este fixat la 100%, rulând pe linia de bază, care reprezintă 20% dintr-un nucleu, ceea ce ar putea cauza timeout-uri PHP. Cred că trebuie să vă revizuiți întrebarea pentru acuratețe.
0
Răspunde
drapel ph
aldo_91
@Eric multumesc, o sa fac.
0
Răspunde
drapel ph
aldo_91
@Tim mulțumesc pentru contribuții. Mi-am editat întrebarea pentru a clarifica că mă refer la vârfuri maxime și nu la medie pe minut, creditele CPU arată neschimbate. Am adăugat link-uri către graficele CPUUtilization, NetIn+NetOut și soldul creditului CPU pentru instanță.
0
Răspunde
Tim avatar
drapel gp
Tim
Asa e mai bine. Ești sigur că sunt doar 1000 de solicitări de pagini pe săptămână? Este foarte scăzut pentru utilizarea procesorului respectiv. Activați accesul PHP / jurnalele de erori și reproduceți problema. Editați-vă întrebarea pentru a include jurnalul de acces la serverul web, jurnalul de acces PHP / erori și jurnalul de eroare a serverului web pentru acea singură cerere. În mod ideal, faceți asta pentru câteva solicitări diferite. Bănuiesc că problema este în PHP, care este foarte înfometat de procesor, dar nivelul CPU este bun și creditele CPU sunt bune.
0
Răspunde
Tim avatar
drapel gp
Tim
Un alt pas posibil de diagnosticare este să vă opriți instanța, să o schimbați la un tip de instanță mare timp de 15 minute (m5.4xlarge sau ceva), să încercați să reproduceți problema, să o opriți și să o schimbați înapoi. Și mai bine faceți acest lucru cu o a doua instanță restaurată dintr-un instantaneu, astfel încât site-ul dvs. să nu se defecteze dacă îl puteți gestiona și utilizați o instanță spot pentru a reduce costurile.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

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.