Què importa primer: WordPress obre connexions de base de dades a través de peticions PHP. Massa connexions poden resultar del tràfic, treballadors encallats, consultes lentes, bots, una fuga de connexió o diversos llocs que comparteixen una base de dades de mida inferior.
Què indica realment aquest símptoma
Un valor max_ connections més alt pot postposar l’error mentre augmenta la pressió de memòria. La llista de processos actius i la condició de petició mostren si la capacitat o el treball ineficient és la veritable restricció.
Recull proves abans de canviar res
- Enregistrar el temps d’error i els llocs afectats en el mateix servidor de base de dades.
- Inspecciona connexions actives i per dormir, usuaris, servidors i durada de la consulta.
- Compara el comptatge de treballadors PHP-FPM amb la capacitat de connexió de la base de dades.
- Comprova consultes lentes registres, pics de trànsit, cron i treballs de còpia de seguretat.
Causes més habituals
- Trànsit o sobrecàrrega de bot: Moltes PHP concurrents demanen connexions legítimament obertes.
- Consultes lentes: Les connexions romanen ocupades perquè el treball de la base de dades pren massa temps.
- Piscina PHP de mida gran: Més treballadors poden arribar a la base de dades del que pot servir de forma segura.
- Pressió dels equips compartits: Un altre lloc o tasca consumeix el pressupost de connexió comú.
Seqüència segura de diagnòstic i reparació
- Reduir o bloquejar el tràfic abusiu i pausar el treball per lots no essencial.
- Trobi i optimi les consultes amb connexions més llargues.
- Alinia els límits del treballador PHP, la memòria de la base de dades i les connexions max _ com un model de capacitat.
- Afegeix el monitorització per a l’ús de la connexió i els intents rebutjats abans de tornar a la càrrega normal.
Com distingir entre les causes probables
No tractis Trànsit o sobrecàrrega de bot i Consultes lentes com a causes equivalents. Moltes PHP concurrents sol· liciten connexions legítimament obertes. En canvi, les connexions romanen ocupades perquè el treball de la base de dades pren massa temps. Per a distingir- les, usa aquestes dues comprovacions: Enregistrar el temps d’error i els llocs afectats en el mateix servidor de base de dades; i inspecciona connexions actives i per dormir, usuaris, servidors i durada de la consulta. Amb aquestes dades podràs decidir si convé aplicar la primera acció controlada —Reduir o bloquejar el tràfic abusiu i pausar el treball per lots no essencial — o si has de conservar l’estat actual i ampliar la investigació.
En un lloc de WordPress en producció, repeteix la petició que falla mentre comprova una pàgina que funciona correctament i l’àrea d’administració. Un error aïllat en una ruta requereix un rollback més acotat que un problema que afecta PHP, la base de dades o totes les peticions. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.
Què no has de fer
No reinicieu repetidament la base de dades com l’única solució. Neteja l’evidència i podeu interrompre les escriptures mentre la mateixa càrrega es reconstrueix immediatament.
Com verificar la reparació
- L’ús de la connexió màxima es manté per sota d’un llindar de seguretat documentat.
- Representative unmemòria caud peticions completes sense errors de connexió.
- Les consultes lentes i el tràfic abusiu es controlen o eliminen.
Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.
CRITERI D’INCIDENT WP REPAIR
Com acotar l’error sense endevinar
Un valor max_ connections més alt pot postposar l’error mentre augmenta la pressió de memòria. La llista de processos actius i la condició de petició mostren si la capacitat o el treball ineficient és la veritable restricció.
Enregistrar el temps d’error i els llocs afectats en el mateix servidor de base de dades.
Inspecciona connexions actives i per dormir, usuaris, servidors i durada de la consulta.
Compara el comptatge de treballadors PHP-FPM amb la capacitat de connexió de la base de dades.
Comprova consultes lentes registres, pics de trànsit, cron i treballs de còpia de seguretat.
Què ha de quedar verificat
- l’ús de la connexió màxima es manté per sota d’un llindar de seguretat documentat.
- Representative unmemòria caud peticions completes sense errors de connexió.
- Les consultes lentes i el tràfic abusiu es controlen o eliminen.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
Simplement elevar max_ concections resoldrà això permanentment?+
L’augment de max_ connections pot postposar l’error alhora que augmenta la pressió de memòria en el servidor de base de dades, sense indicar per què s'estan consumint les connexions. Comprova la llista de processos actius i la durada de la consulta revela si la capacitat o el treball ineficient és la restricció real.
El reinici de la base de dades és una forma raonable d’eliminar aquest error quan succeeix?+
No, no com una solució repetida. Reiniciar aclareix l’evidència necessària per diagnosticar la causa i podeu interrompre les escriptures, i la mateixa càrrega sovint reconstruir la mateixa pressió de connexió immediatament després. Identificar les consultes lentes o l’augment de trànsit darrere d’ella en el seu lloc.
Com puc saber si això és causat per tràfic real versus una fuga de connexió en el meu propi codi?+
La inspecció de les connexions actives i dormints junt amb els seus usuaris, hosts i durada de la consulta mostra si moltes peticions diferents es connecten legítimament o si un nombre menor de connexions romanen obertes molt més temps de l’esperat. Una fuga es mostra típicament com connexions dorments que no s'aclareixen fins i tot quan el trànsit és normal.
Si el meu lloc és a hosting compartit, podria ser un altre lloc la causa real dels meus errors de connexió?+
Sí. A hosting compartit, un altre lloc o tasca de fons pot consumir el pressupost de connexió comú per a tot l’host de base de dades, produint aquest error en un lloc que no està sota càrrega inusual. Gravar el temps d’error i els llocs afectats en el mateix host de base de dades ajuda a confirmar si la pressió és compartida.