Ce cauzează avertismentul "max_user_connections" în frontend-ul WordPress?
În prezent primesc această eroare doar în frontend (nu în /wp-admin):
Warning: mysqli_real_connect(): (HY000/1203): Utilizatorul xxx are deja mai multe conexiuni active decât 'max_user_connections' în
/hermes/.../public_html/myhome/wp-includes/wp-db.php la linia 1489
Warning: mysql_connect(): Utilizatorul xxx are deja mai multe conexiuni active decât 'max_user_connections' în
/hermes/.../public_html/myhome/wp-includes/wp-db.php la linia 1515
Eroare la stabilirea conexiunii cu baza de date
Și mă întreb cum apare această eroare când sunt singurul vizitator? Folosesc WP 4.5.
Am contactat gazda care a fost suficient de amabilă să răspundă astfel:
În prezent site-ul tău afișează
'Eroare la stabilirea conexiunii cu baza
de date' deoarece utilizatorul bazei
de date a depășit limita de conexiuni
concurrente permise pentru un
utilizator al unei baze de date, care
este de 10. Acesta este motivul pentru
care site-ul încarcă eroarea de bază
de date. Scriptul aruncă eroarea de
conexiuni concurrente când numărul
de conexiuni la baza de date
depășește limita setată pe server. În
platforma noastră shared, permitem
maximum 10 conexiuni concurrente
la o bază de date, ceea ce este ideal
în platforma shared și nu este posibil
să creștem această limită. Limita de
interogări pentru site-ul tău va fi
resetată în câteva ore, așa că ar trebui
să poți accesa baza de date după
câteva ore.
Există două cazuri în care scriptul
încarcă eroarea de mai sus: primul
când există un trafic mare pe site și
conexiunile concurrente la baza de
date ating limita, iar al doilea caz este
când conexiunea la baza de date nu
este închisă în script, chiar și pentru
un trafic moderat scriptul încarcă
eroarea de conexiuni concurrente.
Pentru a depăși această problemă,
trebuie să închizi conexiunea la baza
de date imediat după preluarea
conținutului necesar din baza de
date. Pentru a închide conexiunea la
baza de date poți folosi funcția PHP
mysql_close() cu parametrul de
conexiune. Acest lucru te va ajuta să
folosești limita de conexiuni la baza
de date mai eficient.
Cu alte cuvinte, totul este în regulă la noi, este o eroare din partea WP.

Nu este legat de WordPress, așa că nu sunt sigur dacă am dreptul să răspund aici, dar totuși poți crește max_user_connections
în fișierul de configurare MySQL my.cnf, deoarece doar testezi.
Există mai multe cauze pentru epuizarea conexiunilor, cele mai comune fiind atunci când serverul Web/Aplicativ creează un număr neașteptat de mare de conexiuni din cauza unei configurații greșite sau a unui script care scurg conexiuni sau creează prea multe conexiuni din eroare.
Soluția: Unii oameni cresc max_connections
la un număr foarte mare, astfel încât MySQL să nu rămână fără conexiuni niciodată.
Totuși, acest lucru poate provoca probleme de utilizare a resurselor, consumând memorie și poate determina serverul MySQL să facă swap sau să fie oprit de procesul OOM killer sau să aibă o performanță foarte slabă din cauza unei conteste ridicate.

Dar apoi gazda spune că este o eroare WP. Am inclus răspunsul lor în mesajul meu de mai sus. Te rog verifică.

Este posibil să ai o invazie de mysql_connect()
fără să o închizi. Practică proastă în WordPress apropo. Gândește-te.

Mai întâi, doriți să activați erorile pentru $wpdb
, abstractizarea bazei de date din WordPress:
$GLOBALS['wpdb']->show_errors;
Altfel, niciuna dintre conexiunile voastre la baza de date nu va eșua și nu va întrerupe cu o instanță de \WP_Error
. Codul implicit de eroare este 500
.
Următoarea eroare provine din \wpdb::db_connect()
:
Eroare la stabilirea conexiunii la baza de date
Există două cazuri în care db_connect()
este utilizată:
- Conectarea la baza de date
- Verificarea dacă există o conexiune la baza de date
Doar primul caz este permis să eșueze. Dacă conexiunea ar eșua în timp ce se efectuează doar verificarea, ea nu va eșua și nu va arunca această eroare. Conexiunea este realizată de \wpdb_driver::connect()
, care verifică dacă conexiunea este activă și disponibilă. Acest lucru vă spune că problema reală este chiar conexiunea în sine. Puteți verifica acest lucru (fără glumă) în următorul fișier:
# interface-wp-db-driver.php
<?php
abstract class wpdb_driver {
Este mai bine să nu vă gândiți dacă există vreo corelație între calitatea generală a codului WordPress și înțelegerea profundă a interfețelor și claselor abstracte aici.
Chiar înainte ca conexiunea la baza de date să fie declarată "eșuată" și eroarea să fie afișată, există o linie interesantă:
require_once WP_CONTENT_DIR . '/db-error.php';
Aceasta înseamnă că încărcarea unui Drop In are loc înainte ca totul să die
. Puteți folosi acest lucru și puteți începe un mecanism de depanare acolo. Aveți întregul nucleu WordPress disponibil aici. Puteți începe să vă trimiteți emailuri, să înregistrați aceste erori într-un stack ELK/Kibana, Spark sau orice alt stack, într-un SaaS sau chiar în Slack (sau doar într-un fișier text). Înregistrați-vă erorile acolo, înregistrați ce se întâmplă, afișați rute, cereri, detalii despre conexiunea la baza de date, orice credeți că v-ar putea ajuta.

Aceasta a fost de fapt o eroare din temă. După ce toate testele au eșuat, am cerut creatorului temei să examineze și a reparat-o, recunoscând eroarea. Mulțumesc.

Poți, te rog, să adaugi eroarea exactă și soluția (reparația lui) ca răspuns? Acest lucru ar putea ajuta alți utilizatori care întâmpină aceeași problemă, altfel întrebarea ta va rămâne deschisă pentru totdeauna. Mulțumesc.

Mi s-a cerut să trimit datele de autentificare și după aceea nu sunt sigur ce a făcut exact autorul, dar da, este posibil să fi aplicat unele remedieri. Tot ce știu este că tema a fost actualizată. Așadar, aș sugera altora care se confruntă cu probleme similare să actualizeze nucleul WP și, de asemenea, tema la versiunile actualizate. Mulțumesc.

@Ramnath Îmi pare rău, dar aceasta nu este o soluție. Ai externalizat problema aici, te rog spune autorului să răspundă aici sau întreabă-l pentru remedieri. Vei dori să înțelegi singur acest lucru în cazul în care va trebui să reconstruiești site-ul după un hack sau pentru că gazda ta a eșuat sau din alte circumstanțe.

Serverele web sunt multitaske... Presupunând că tema ta nu încearcă să acceseze baza de date direct (nu prin clasa WPDB), fiecare conexiune a utilizatorului ar trebui să corespundă unui timp de viață al procesării unei cereri pe care WordPress o gestionează.
Presupunând acest lucru, probabil ai o gestionare lentă a fiecărei cereri, în combinație cu mai multe cereri gestionate "simultan", ceea ce se poate întâmpla dacă tema ta încarcă conținut dinamic cu AJAX.
(acesta este în esență ceea ce ți-a spus gazdă, ceea ce are sens)

Am pățit asta odată și eram convins că firma de hosting a greșit sau că vreun hacker a pătruns pe site. S-a dovedit a fi o interogare care dura de aproximativ 6 ori mai mult pentru fiecare termen adăugat, timpul crescând foarte rapid. Odată ce destui utilizatori au început să ruleze această interogare, gata. Operația nu se mai termina și conexiunile la baza de date nu se închideau. Aș lua în considerare posibilitatea să ai niște scripturi asemănătoare și, de asemenea, să instalezi pluginul Query Monitor și să navighezi atât pe front-end cât și pe back-end pentru a identifica interogările lente.
