L’error fatal indica el límit de memòria configurat i l’assignació que PHP ha intentat fer quan ja no quedava espai. El fitxer assenyalat no sempre és qui ha originat el consum: potser només ha demanat els últims bytes després que un altre component omplís la memòria.
Augmentar el límit pot permetre una càrrega legítima, però també pot deixar que un bucle exhaureixi tot el servidor. Mesura abans de canviar.
Conserva l’error fatal complet
Relaciona l’hora de la petició amb el registre PHP i anota els bytes permesos, l’assignació sol·licitada, el fitxer, la línia i la pila de crides.
Anota també:
petició web o CLI
URL o acció
versió i controlador de PHP
mida del carret, importació o imatge
canvi recent de codi o configuracióOculta noms de compte del servidor, valors de consultes i dades de clients.
Comprova els límits efectius
WordPress pot definir WP_MEMORY_LIMIT i WP_MAX_MEMORY_LIMIT, mentre que PHP i l’allotjament imposen els seus màxims. Consulta el valor dins del context web o CLI que realment falla.
error_log( 'Memory limit: ' . ini_get( 'memory_limit' ) );
error_log( 'Peak bytes: ' . memory_get_peak_usage( true ) );Utilitza un registre temporal protegit i retira’l després. No publiquis la configuració en una pàgina.
Reprodueix amb entrades mesurades
Utilitza un staging amb el mateix PHP i els mateixos connectors, amb dades anonimitzades. Compara una importació, imatge, pàgina o acció petita amb la que falla.
Si el pic creix aproximadament amb el nombre d’elements, probablement cal processar per lots. Si creix a cada callback repetit, busca acumulació o recursió.
Els perfiladors afegeixen càrrega; utilitza’ls en staging tret que la investigació en producció estigui controlada expressament.
Estableix una referència normal
Mesura la mateixa petició amb l’entrada vàlida més petita i després amb dades representatives. Registra el pic abans i després del callback principal del component.
Importa més la corba que el nombre absolut. Un cost fix pot ser acceptable; diversos megabytes addicionals per cada entrada fallaran quan el web creixi. Repeteix la petició per detectar memòries cau o variables estàtiques que augmenten dins d’un procés PHP persistent.
Localitza càrregues de dades sense límit
Busca a la ruta WP_Query, get_posts(), consultes directes i API que recuperin tots els registres. Demana només identificadors o els camps necessaris en lloc d’objectes complets.
$ids = get_posts( array(
'post_type' => 'post',
'posts_per_page' => 100,
'fields' => 'ids',
) );Pagina més en webs grans. El límit de 100 és un exemple, no una mida universal.
Revisa el processament de fitxers i mitjans
Una imatge gran ocupa molta més memòria quan es descomprimeix que el fitxer desat. Generar PDF, extreure arxius o regenerar miniatures també pot superar límits raonables.
Comprova dimensions en píxels, profunditat de color i mides d’imatge actives. Optimitza els originals i processa els mitjans en lots acotats mitjançant CLI o en segon pla.
No desactivis la validació de seguretat de les pujades per estalviar processament.
Aïlla el component responsable
Utilitza la pila de crides i una comparació controlada per desactivar en staging un sol connector, funció del tema o fragment propi. Examina a part els connectors obligatoris i els drop-ins.
Un error de memòria després d’actualitzar pot venir d’un ordre diferent de hooks o d’un registre duplicat. Compara versions i registres de canvis.
No editis el nucli ni desactivis elements de producció a l’atzar.
Ajusta la capacitat amb responsabilitat
Quan el pic normal mesurat sigui legítim i el límit resulti baix, augmenta’l des de cPanel, Plesk o una configuració PHP compatible.
Multiplica el consum per worker per la concurrència possible i deixa RAM per a MySQL, el servidor web i el sistema operatiu. Un sostre elevat per petició pot provocar que el sistema mati processos quan hi ha trànsit.
Per a tasques excepcionals de manteniment, utilitza CLI amb límits propis planificats.
Verifica el pic i la recurrència
Repeteix l’acció original i un cas límit més gran mentre registres el pic. Confirma que les pàgines públiques i les accions administratives concurrents continuen responent.
El manteniment recurrent hauria de seguir els errors de memòria i els pics després de cada desplegament. La reparació duradora identifica la càrrega, l’acota i estableix un límit avalat per la capacitat real del servidor.