Puncte:1

Cache-ul MariaDB se răcește peste noapte

drapel cn

Rulăm o stivă LAMP care include MariaDB 10.5.15 pe Centos 7. Este un server dedicat cu 4 CPU-uri și 8 GB RAM.

Nu am avut nicio problemă până în ultimele săptămâni, când am observat că interogările lente durează 8-9 secunde în jurnalul de interogări lente.

Aceste interogări sunt împotriva mai multor baze de date INNODB, dar întotdeauna tabele mari (adică peste 10.000 de rânduri). Ele apar întotdeauna între orele 6:00 și 8:00.

Tabelele în cauză au indecși și aceleași interogări se execută în mai puțin de o secundă de obicei.

Am descoperit că, conectându-mă la server la 8 dimineața într-o duminică și interogând aceste tabele mari cu instrucțiuni simple select, ar dura 8-9 secunde pentru a se executa. Apoi, pentru restul zilei, chiar și după miezul nopții, orice interogări asupra acelui tabel ar fi rapid.

Orele 6:00 - 8:00 ar fi, de asemenea, momentul în care lucrurile „revin la viață” după o perioadă de inactivitate la primele ore.

Se pare că există un fel de cache care se răcește și trebuie să se încălzească, dar nu sunt sigur de ce a început să se întâmple brusc după ani de utilizare fără probleme. Nu există un proces uriaș care rulează pe server peste noapte despre care știu, iar serverul nu este sub încărcare atunci când se întâmplă acest lucru.

Monitorizăm sarcina procesorului 24/7 și verificăm periodic numărul de conexiuni la Apache și MariaDB care rămân moderat scăzut pe tot parcursul zilei. De obicei, există aproximativ 3 GB de memorie liberă, cu excepția bufferelor și a memoriei cache.

Editați | ×

În mod jenant, am descoperit că interogările lente în cauză de fapt nu foloseau indecși și făceau o scanare completă a tabelului. O interogare inițială poate dura câteva secunde, apoi pentru restul zilei, chiar și scanarea completă a tabelului durează mai puțin de o secundă. Presupun că acesta este un fel de cache de disc care se răcește peste noapte.

Deși s-ar putea să nu pară neobișnuit ca o scanare completă a unui tabel să aibă probleme de performanță, totuși pare ciudat că acest lucru a devenit dintr-o dată o problemă din senin.

Puncte:0
drapel ua

Se pare că ai exclus o gunoială nocturnă și un proces lent?

Mai multe sugestii de depanare:

Reduceți setarea globală a timp_de_interogare_lung și păstrați slowlog-ul pornit; s-ar putea să-l prinzi pe răufăcător.

Cât de des rulează interogarea dvs.? Ceea ce pescuiesc aici este să restrâng timpul când lucrurile devin încet.

Verifica AFIȘAȚI STAREA GLOBALĂ CA „Uptime” Dacă aceasta este mai mică de 86400, atunci MariaDB a repornit cu mai puțin de 24 de ore în urmă. În acest caz, ar trebui să puteți fixa ora aproape la secundă. (Dar nu identificați cauza).

Arată-ne interogarea, plus AFIȚI CREATE TABLE și EXPLICA... S-ar putea să vă putem ajuta să o accelerați (de exemplu, printr-un index mai bun sau o reformulare a interogării), eliminând astfel problema (deși fără a rezolva cauza).

MrCarrot avatar
drapel cn
`uptime` este acum câteva zile (de când am repornit ultima dată manual). Nu cred că revizuirea schemei tabelului va ajuta, deoarece aceasta afectează mai multe tabele din mai multe baze de date (toate mari, dar toate utilizând indecși corespunzători). Ieri am rulat un crobjob care a apelat una dintre interogări la fiecare 15 minute, sperând să identific ora când lucrurile merg prost (bănuiesc că 6 dimineața, dar ar putea fi mai devreme). În această dimineață, nu sunt înregistrate interogări lente. S-ar putea ca jobul cron să mențină baza de date caldă sau ar putea fi o coincidență. Îl voi lăsa câteva zile și apoi reduc setarea `long_query_time`
MrCarrot avatar
drapel cn
În mod jenant, am descoperit că interogările lente în cauză de fapt nu foloseau indecși și făceau o scanare completă a tabelului. O interogare inițială poate dura câteva secunde, apoi pentru restul zilei, chiar și scanarea completă a tabelului durează mai puțin de o secundă. Presupun că acesta este un fel de cache de disc care se răcește peste noapte. Deși s-ar putea să nu pară neobișnuit ca o scanare completă a unui tabel să aibă probleme de performanță, totuși pare ciudat că acest lucru a devenit dintr-o dată o problemă din senin.
drapel ua
@MrCarrot - Memorarea în cache pe disc... Ai un controler RAID hardware? Alergi în Cloud? Dacă „nu” la ambele, nu m-aș aștepta ca un „disk cache” să fie răspunsul. InnoDB folosește „buffer_pool” în RAM.
MrCarrot avatar
drapel cn
Discul este o unitate SSD cu RAID1 (este un server dedicat). M-am îngrijorat că poate unitatea se defecta sau matricea RAID sub încărcare, dar compania de găzduire susține că este în regulă. Bănuiesc că s-ar putea să se răcească piscina tampon.

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.