A l’hosting compartit, WordPress pot ser ràpid la major part del dia i aturar-se quan el compte arriba als límits de CPU, memòria, E/S o processos concurrents. Una notificació de límit demostra una restricció alhora; no identifica l’activitat de WordPress que va consumir el recurs.
Relacioneu les proves de cPanel amb les sol·licituds i els treballs abans d’actualitzar el pla o eliminar els connectors.
Llegeix l’historial de límits, no només l’ús actual
Obriu l’àrea d’ús de recursos de cPanel i reviseu els errors històrics. Depenent de la pila d’hosting, pot mostrar CPU, memòria física, entrada/sortida, IOPS, processos d’entrada i recomptes de processos.
Enregistreu les marques de temps exactes, la durada i quin límit s’ha assolit. Els gràfics actuals poden semblar normals després d’un breu incident.
La terminologia d’hosting varia. Utilitzeu la documentació del proveïdor per entendre si una "falla" significa limitació, treball rebutjat o simplement assolir una assignació.
Relaciona el recurs amb els símptomes probables
L’acceleració de la CPU pot allargar el treball de PHP i la base de dades. L’esgotament de la memòria física pot acabar amb els processos. Els límits d’E/S poden retardar les còpies de seguretat, les exploracions de programari maliciós i les escriptures grans de memòria cau. Els límits del procés d’entrada poden posar en cua les sol·licituds web concurrents.
Són hipòtesis, no diagnòstics. Compareu els registres d’errors web/PHP i els temps de resposta dels visitants al mateix moment.
Una resposta 508 o 503 pot ser una evidència útil. Captureu-lo sense demanar als clients que reprodueixin una compra fallida.
Troba el que va funcionar durant l’esdeveniment
Reviseu els registres d’accés agrupats per URL, estat i volum de sol·licituds. Comproveu cron de WordPress, Action Scheduler, còpies de seguretat i registres de seguretat. Busca:
- ràfegues a
wp-login.phpo XML-RPC; - URL de cerca o de filtrat cara;
- moltes sol·licituds AJAX sense memòria cau;
- tractament o importació d’imatges;
- còpies de seguretat i exploracions completes;
- Trànsit de bot amb cadenes de consulta úniques.
No bloquegeu un punt final només perquè apareix amb freqüència. Confirmeu si el trànsit és legítim i si els controls de tarifes afecten les integracions.
Comproveu la memòria cau i el comportament de PHP
Si les pàgines públiques normalment utilitzen memòria cau de pàgina completa, una purga àmplia pot enviar trànsit de sobte a través de PHP. Inspeccioneu l’estat de la memòria cau durant l’error quan els registres ho permetin.
Reviseu la versió de PHP, el límit de memòria i els registres d’errors. Un memory_limit alt no reserva memòria, però diversos processos grans poden superar l’assignació física del compte.
Eviteu configurar la memòria PHP al límit total del compte. WordPress, les tasques del servidor web i els treballadors simultanis necessiten un espai compartit.
Reduir la demanda de recursos específics
Relaciona la reparació amb la falla:
- optimitzar o emmagatzemar a la memòria cau les rutes PHP/base de dades lentes per a la CPU;
- reprogramar còpies de seguretat i exploracions per a E/S;
- importacions per lots i processament d’imatges;
- prevenir els corredors cron duplicats;
- memòria cau pàgines públiques segures;
- Limitar el trànsit abusiu a la capa adequada.
No apliqueu un canvi genèric "desactiva tots els connectors" en producció. Utilitzeu comparacions controlades o escenificades per identificar la propietat.
Cloudflare pot absorbir el trànsit que es guarda a la memòria cau i l’abús bàsic, però no soluciona PHP de pagament lent ni una còpia de seguretat local que consumeix E/S de disc.
Decidiu si el pla és realment subdimensionat
Després d’eliminar el treball evitable, compareu la demanda màxima normal amb l’assignació d’hosting. Una botiga de WooCommerce ocupada necessita una capacitat PHP sense memòria cau que pot ser que no proporcioni un petit pla compartit.
Pregunteu a l’amfitrió quins recursos garanteixen, els workers de PHP i les restriccions de la base de dades canvien de pla més alts. Més emmagatzematge per si sol no solucionarà l’acceleració de la CPU.
Conserveu els gràfics d’incidències perquè la decisió d’actualització es basi en una demanda repetida en lloc d’una col·lisió de seguretat.
Verificar fins al següent pic
Superviseu les mateixes mètriques de cPanel, els temps de resposta de WordPress i les accions empresarials. Confirmeu que els errors s’aturen o es redueixen materialment i que les còpies de seguretat, els formularis i els treballs programats encara s’han completat.
Sol·liciteu una avaluació quan els esdeveniments límit es repeteixen, els registres són difícils de correlacionar o el pagament es veu afectat. Compartiu primer segells de temps, captures de pantalla i resums de registre desinfectats; les credencials d’hosting haurien d’utilitzar un canal segur després d’acordar l’abast.