Mysql eroare 1040 prea multe conexiuni

Mysql eroare 1040 prea multe conexiuni

Care este eroarea de eroare Mysql 1040: Prea multe conexiuni. Această eroare înseamnă că în momentul în care limita pentru conectarea la baza de date este epuizată.
Apare de obicei în cazul în care fie întrebări prea complexe (care durează mult timp pentru a executa) sau în cazul în care există multe conexiuni concurente. De exemplu, de la 100 de utilizatori este inițiată o cerere simultană la baza de date, ca de exemplu în versiunea mea. În mod evident, acest lucru nu este posibil în utilizarea reală, ci pentru a colecta statistici, am avut nevoie de el. Deci, cum să fim?







Și totul este foarte simplu:

Opțiunea A
În cazul unor întrebări lente, le optimizăm, adăugăm indici etc.

Opțiunea B
Conexiuni simultane. În acest caz, le distribuim pentru diferite perioade de pornire, astfel încât acestea să nu fie executate în același timp. Ie eliminați următoarele opțiuni:

spune-mi ce înseamnă ... Error MySQL: Prea multe conexiuni

MySQL este un program care comunică prin "conexiuni". Vă puteți imagina ca ferestrele casierului de la stație, în care oamenii coadă. Deci, atunci când o mulțime de vizitatori care sunt ocupați toate conexiunile (sau, în acest exemplu, oamenii devin atât de mulți care nu se încadrează în toate birourile de construcție), MySQL scrie exact această greșeală. Pentru a evita aceasta, este necesar să se mărească numărul maxim de conexiuni la setările MySQL (creșterea numărului de ferestre la box-office, în scopul de a servi mai multe persoane) sau pentru a înțelege de ce interogări sunt atât de lent (pentru a optimiza activitatea casierilor pentru a trece mai multe persoane pe unitatea de timp). Cred că acum ar trebui să fie mai clar :)







Un alt lucru este că locul se termină. Și MySQL oferă această eroare

Nu am întâmpinat o astfel de greșeală, în cazurile în care locul se termină. Cu toate acestea, dacă este cazul, puteți verifica acest lucru uitandu-te la mysql-log. În cazurile de lipsă de spațiu, vor exista cu siguranță erori care vor raporta acest lucru. Pentru jurnalul Debian și Ubuntu se poate consulta aici:

Și poate să apară această eroare în cazul atacului dDOS?

Da, se poate. Dar este foarte ușor de verificat. Puteți merge la phpMyAdmin, de exemplu, sau prin consola mysql în sine, pentru a vedea o listă cu procesele curente. În consecință, în cazul DDOS, vom vedea o mulțime de procese în coada de așteptare. În continuare, de obicei, acționez astfel, la punctul de intrare (de exemplu, index.php), scriu doar un script care scrie ip pentru toți vizitatorii curenți, linie de linie într-un fișier:
file_put_contents ('ip.list', $ _SERVER ['REMOTE_ADDR'] FILE_APPEND | LOCK_EX);
Am plecat așa timp de 5 minute. Mai departe am deconectat înregistrarea într-un fișier și mă uit ce ip-shniki cel mai adesea trage un site. Și atunci ei pot da 503 de eroare sau trimise la datele stocate în memoria cache (de fapt, am scris la dosar nu este doar IP și matrice serializate a cărui IP este cheia, iar valoarea este numărul de atac, dar codul un pic mai mult, aici pentru a nu împinge Eu voi). Numai aici este necesar să fii prudent: este posibil să interzicem motoarele de căutare, dacă există o mulțime de informații, în special dinamice, iar serverul este slab. Prin urmare, dacă ip-shnik din care "ataș" vine una sau o pereche, atunci merită să ne uităm la cine este înregistrat prin whois. Și dacă acesta este înregistrat pe Google, nu trebuie să-l interzică, și ar trebui să fie adăugate la site-ul și pentru a limita Google.Webmaster viteza de scanare acolo sau pentru a profita de Directiva Crwl-Întârziere în robots.txt.







Trimiteți-le prietenilor: