Puncte:1

De ce aplicația noastră Tomcat Java deschide brusc sute de conexiuni la baza noastră de date?

drapel it

Avem o aplicație Tomcat care rulează pe Elastic Beanstalk și baza noastră de date MySQL este găzduită pe AWS RDS (2 sau 3 instanțe t3.medium). De când am făcut upgrade de la MySQL 5 la MySQL 8 (în prezent 8.0.23), am avut o problemă care apare aproximativ o dată pe săptămână.De cele mai multe ori baza de date este în regulă, dar apoi, dintr-o dată, numărul de conexiuni crește vertiginos (uneori chiar depășind limita de 307 de conexiuni într-un interval de 1 minut, ceea ce este, de asemenea, ceva pe care nu îl obținem. Cum este este capabil să depășească această limită?) și asta face ca instanțele Elastic Beanstalk să devină degradate. Uneori, întreaga bază de date se blochează după acele conexiuni.

În timp ce monitorizez JVM-ul aplicației cu VisualVM, am ajuns să observ că, în timpul acelor vârfuri de conexiune, Tomcat creează brusc zeci de fire de lucru. Bănuiesc că fiecare dintre acele fire stabilește o nouă conexiune la baza de date. Deși am putea limita numărul acestor fire de execuție (în primul rând serverele nu ar fi capabile să gestioneze atât de multe fire de execuție), dorim să înțelegem ce cauzează acest lucru. De ce creează Tomcat atât de multe fire și conexiuni la baza noastră de date? Este aceasta o cauză sau o consecință a problemelor din baza de date? Unde ar trebui să căutăm pentru a găsi rădăcina problemei?

Am căutat mult pe Google, încercând să găsesc oameni care au avut probleme similare pentru a face lumină asupra problemei. De asemenea, am încercat să analizăm cele mai scumpe interogări și alte informații despre performanța bazei de date, dar se pare că nu există un model clar.

Wilson Hauck avatar
drapel jp
Spike se limpezește într-un timp - cât timp? Cum vă readuceți sistemul la linie?
Helder Sérvio avatar
drapel it
@WilsonHauck , atunci când are loc vârful, verificările de sănătate a echilibrului de încărcare încep să eșueze, ceea ce face ca Elastic Beanstalk să reducă instanțele și să le înlocuiască, ceea ce, la rândul său, rezolvă problema.
Puncte:1
drapel ua

Unde ar trebui să căutăm pentru a găsi rădăcina problemei?

  • Activați slowlog-ul în MySQL și (după vârf) investigați ce interogări rulau în acel moment. Dacă slowlog-ul nu arată prea mult, coborâți timp_de_interogare_lung înainte de următorul vârf.
  • (Nu știu dacă Tomcat are un jurnal.)
  • Se întâmplă la aceeași oră în fiecare zi sau săptămână?
  • Când face Amazon backup-uri?
  • Dacă ești online când se întâmplă, vezi dacă poți face AFIȘAȚI LISTA DE PROCES;. Păstrează-te conectat; poate fi dificil să vă conectați când vedeți vârful.
  • „VARIABILA” MySQL max_connections controlează 307. Creșterea acestuia poate amâna vârful vârfului, dar poate înrăutăți lucrurile. (Nu văd asta ca pe o „soluție”.)
  • Tomcat poate [probabil] să rețină conexiunile în exces fără a răni prea mult lucrurile; probabil că va fi mai bine să accelerați Tomcat decât să schimbați 307. Când MySQL are „o mulțime de conexiuni ocupate”, le oferă fiecăruia acces egal la resurse; aceasta are ca efect încetinirea toate conexiuni.
Helder Sérvio avatar
drapel it
Am aruncat deja o privire la jurnalul de interogări lente și am reușit să eliminăm/refactorizăm câteva interogări scumpe cu normă întreagă atunci când situația era cu adevărat îngrozitoare (DB se prăbușește tot timpul), dar totuși, nu explică de ce problema a început să apară abia după trecerea la MySQL 8. Tomcat are un jurnal, dar nu l-am stocat după ce instanțele au fost distruse. Vom face asta data viitoare și vom arunca o privire pe fire. Și nu, variază foarte mult ca frecvență și timp. Nu se suprapune cu copiile de rezervă.
Wilson Hauck avatar
drapel jp
@HelderSérvio Cerere de informații suplimentare, vă rugăm. Tipul instanței AWS - dimensiunea RAM, # nuclee, orice dispozitiv SSD sau NVME pe serverul MySQL Host? Postați pe pastebin.com și distribuiți linkurile. Din rădăcina dvs. de conectare SSH, rezultă text de: A) SELECTARE COUNT(*) FROM information_schema.tables; B) AFIȚI STARE GLOBALĂ; după minim 24 de ore UPTIME C) AFIȘAȚI VARIABILELE GLOBALE; D) AFIȚI LISTA COMPLETĂ DE PROCES; E) STARE; nu AFIȚI STARE, doar STARE; pentru analiza de reglare a sarcinii de lucru a serverului pentru a oferi sugestii.
Helder Sérvio avatar
drapel it
@WilsonHauck . Serverele sunt 2-3 instanțe t4g.small (2 GiB, 2 vCPU), în timp ce baza de date este (o singură, m-am înșelat când am spus că este 2-3) instanță t3.medium (4 GiB, 2 vCPU), cu SSD gp2. Nu am acces direct la baza de date, așa că mă tem că nu vă pot arăta rezultatul acelor interogări.Cu toate acestea, șeful meu mi-a dat un dump din tabelul de interogări lente. În esență, ceea ce se întâmplă este că, la un moment dat, toate interogările încep să devină mai lente (densitatea interogărilor lente crește foarte mult), până când unele ajung în jur de 2 sau 3 minute. Performanța RDS arată așteptări lungi pentru LOCK_table_cache.
Wilson Hauck avatar
drapel jp
@HelderSérvio Ați putea publica informațiile de interogare lentă furnizate de șeful dvs.? Ar putea șeful dvs. să ruleze cele enumerate mai sus, să posteze datele pe pastebin.com și să ne împărtășiți linkurile pentru analiza volumului de lucru al instanței dvs. t3.medium?
drapel ua
„Densitatea crește” -- Adesea, o singură interogare precipită aglomerația. `SHOW PROCESSLIST` poate observa uneori asta, dar obținerea acesteia este dificilă. Slowlog-ul brut poate arăta uneori care interogare este interogarea obraznică. ("Digerarea" interogării este mai bună pentru a afla care interogare este cea mai dificilă pentru sistem.)

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.