Limite di risorse raggiunto: identificazione e risoluzione dei limiti di CloudLinux

Se il tuo sito web mostra temporaneamente il messaggio Limite delle risorse raggiunto mostra, il tuo account di hosting ha raggiunto un limite di risorse gestito da CloudLinux.

Il messaggio non significa automaticamente che l'intero server di hosting sia sovraccarico. CURIAWEB utilizza CloudLinux per isolare gli account di hosting l'uno dall'altro e fornire loro risorse definite. Se viene raggiunta una di queste cifre, CloudLinux può limitare l'ulteriore utilizzo delle risorse dell'account in questione.

In questa guida ti mostriamo come scoprire, quale limite di risorse è stato raggiunto, quando è successo e quale applicazione o attività potrebbe esserne responsabile.

Importante: Non cercare di risolvere il messaggio di errore apportando modifiche casuali a PHP, WordPress o cPanel. Apri prima l'utilizzo delle risorse di CloudLinux e verifica quale limite è stato effettivamente raggiunto.

Cosa significa „Resource Limit Is Reached“? #

CloudLinux gestisce diverse risorse di un account di hosting. A seconda della configurazione del server, queste includono, tra le altre:

• Prestazioni della CPU
• memoria fisica
• Prestazioni di I/O
• processi di inserimento simultanei
• Numero totale di processi in esecuzione

Se viene raggiunta una soglia corrispondente, l'ulteriore trattamento può essere limitato.

A seconda della risorsa interessata e della richiesta in fase di elaborazione, la cosa può manifestarsi in modo diverso.

I possibili sintomi includono, ad esempio:

• Il sito web risponde in modo insolitamente lento
• singole pagine non caricano
• Il backend risponde a intermittenza
• I processi PHP impiegano insolitamente molto tempo
• Le richieste falliscono sotto carico
• Limite di risorse 508 raggiunto viene visualizzato

Un errore 508 non è automaticamente un sovraccarico del server #

Una distinzione tecnica importante è:

L'account di hosting ha raggiunto il limite di CloudLinux
≠
l'intero server di hosting è sovraccarico

CloudLinux utilizza i cosiddetti limiti delle risorse LVE per separare i singoli account di hosting l'uno dall'altro.

Se il tuo account raggiunge un limite, ciò riguarda quindi anzitutto le risorse assegnate al tuo account.

Breve spiegazione: Il messaggio di errore dice inizialmente: „Questo account di hosting richiede al momento una quantità maggiore di una determinata risorsa rispetto a quella disponibile entro il limite attuale.“ Non dice ancora perché questo accada.

1. Annotare data e ora dell'errore #

Se il messaggio compare solo sporadicamente, il momento esatto della diagnosi è particolarmente importante.

Si prega di notare:

Data
Ora
Dominio interessato
URL interessato
Azione eseguita
Messaggio di errore visibile

Esempio:

28.08.2026
14:37
example.ch
/wp-admin/
508 Resource Limit Is Reached

Da questo momento in poi puoi esaminare le risorse di CloudLinux.

2. Apri l'utilizzo delle risorse di CloudLinux #

Accedi al tuo cPanel di CURIAWEB e apri:

Valori misurati → Utilizzo delle risorse

L'interfaccia CloudLinux mostra l'utilizzo delle risorse del tuo account di hosting e può indicare se sono stati raggiunti i limiti delle risorse.

Una spiegazione dettagliata di ciascun valore di misura è disponibile alla pagina Comprendere l'utilizzo delle risorse di CloudLinux in cPanel.

3. Selezionare il periodo di tempo adatto #

Seleziona un intervallo di tempo che includa il momento del problema.

Se l'errore si è verificato ad esempio alle 14:37, ti interessa in particolare l'utilizzo delle risorse intorno a quel momento.

Il superamento di un limite di ieri sera normalmente non spiega un errore di oggi pomeriggio.

4. Verificare quale limite è stato raggiunto #

Ora arriva il passo più importante: stabilisci, quale risorsa ha effettivamente raggiunto il suo limite.

A seconda della configurazione di CloudLinux, ad esempio, potrebbero essere rilevanti i seguenti valori:

Risorsa	Significato
CPU	potenza di calcolo disponibile
Memoria fisica	Memoria di lavoro dei processi dell'account
I/O	velocità di trasmissione dei dati nelle operazioni di I/O
IOPS	Numero di operazioni di I/O
Processi di ingresso	processi simultanei o elaborati contemporaneamente
Numero di processi	Numero totale dei processi in esecuzione dell'account

Quale misura sia opportuno adottare dipende essenzialmente da, quale di questi limiti è interessato.

5. Controllare guasti ed eventi limite #

Nell'analisi di CloudLinux, presta particolare attenzione ai cosiddetti Guasti rispettivamente eventi limite documentati.

Un valore elevato da solo non significa automaticamente che il limite sia stato superato o raggiunto.

Per la diagnosi è quindi importante:

Quale limite?
        ↓
Quando è stato raggiunto?
        ↓
Con che frequenza?
        ↓
Cosa era in esecuzione in quel momento?

Consiglio pratico: Un guasto nello stesso identico momento del tuo problema al sito web è molto più significativo di un qualsiasi carico elevato diverse ore prima.

Limite CPU raggiunto #

Se viene raggiunto il limite della CPU, il tuo account di hosting necessita in quel momento interamente della potenza di calcolo a sua disposizione.

CloudLinux può limitare ulteriormente l'utilizzo della CPU di conseguenza. I processi potrebbero quindi richiedere più tempo.

Le cause tipiche possono essere:

• molte chiamate a siti web dinamici
• processi PHP complessi
• plugin inefficienti
• operazioni di database estese
• Importazioni o esportazioni
• Cronjob
• Processi di backup o di manutenzione
• Bot o un numero insolitamente alto di accessi

Limite della CPU raggiunto solo brevemente #

Un singolo breve picco della CPU non rappresenta necessariamente un problema.

Ad esempio, se stai eseguendo un grosso import, l'utilizzo della CPU potrebbe aumentare temporaneamente in modo significativo.

Diventa più interessante quando:

• il limite della CPU viene raggiunto regolarmente
• il sito web rallenta contemporaneamente
• la situazione si verifica senza un'attività avviata manualmente
• il comportamento è riproducibile

Limite della CPU regolarmente alla stessa ora #

Se, ad esempio, la CPU raggiunge il suo limite circa alla stessa ora ogni giorno, controlla le attività pianificate.

I candidati tipici sono:

• Cronjob
• Importo
• Esporta
• Sincronizzazioni
• Attività di manutenzione
• Backup delle applicazioni

Spieghiamo come analizzare i cronjob difettosi o ad alta intensità di risorse su Cronjob non funziona: cause e soluzioni.

Avviare più cronjob contemporaneamente #

Quando più attività a elevato consumo di risorse si avviano contemporaneamente, il loro fabbisogno di risorse può sommarsi.

Esempio:

02:00 → Importazione prodotti
02:00 → Sincronizzazione dati
02:00 → Esportazione
02:00 → Processo di manutenzione

Se le applicazioni lo consentono, può essere utile distribuire tali attività nel corso del tempo.

Tuttavia, non modificare alcun cronjob impostato da un'applicazione senza conoscerne la funzione.

Limite di memoria fisica raggiunto #

Se il limite di CloudLinux per Memoria fisica viene raggiunto, i processi in esecuzione dell'account utilizzano troppa memoria all'interno del limite di risorse disponibile.

Le cause tipiche possono essere, ad esempio:

• molti processi PHP in esecuzione simultanea
• importazioni ad alto consumo di memoria
• Elaborazione delle immagini
• applicazioni estese
• diversi processi in background paralleli
• codice applicativo difettoso o inefficiente

La memoria fisica non è il limite di memoria di PHP #

Questi due valori vengono spesso confusi.

Il PHP-limite di memoria e il limite di CloudLinux per la memoria fisica operano a livelli diversi.

In sintesi:

PHP memory_limit
→ limite massimo di memoria di un processo PHP

CloudLinux Physical Memory
→ consumo di memoria dei processi dell'account all'interno della LVE

Se viene raggiunto il limite di memoria di CloudLinux, dovresti quindi non basta semplicemente aumentare il limite di memoria di PHP.

Spieghiamo come funzionano i limiti di PHP su Imposta limite di memoria PHP, dimensione di caricamento e tempo di esecuzione.

Attenzione: Un limite di memoria PHP più alto non assegna automaticamente più memoria CloudLinux al tuo account di hosting.

„Allowed memory size exhausted“ è un errore diverso #

Se nel registro degli errori compare un messaggio come:

Dimensione di memoria consentita di ... byte esaurita

comparece, è stato raggiunto il limite di memoria PHP di un processo PHP.

Questo è tecnicamente da distinguere da un limite di memoria fisica CloudLinux.

Verifica quindi il messaggio di errore specifico prima di modificare le impostazioni.

Limite di processi di immissione raggiunto #

Processi di ingresso rispettivamente EP descrizione semplificata dei processi che entrano contemporaneamente nell'ambiente CloudLinux LVE o che vi vengono elaborati.

Il limite dei PE può diventare particolarmente rilevante in presenza di molte richieste dinamiche da elaborare contemporaneamente.

Se viene raggiunta questa soglia, le richieste aggiuntive non possono essere elaborate normalmente.

In questo contesto, in particolare, un:

Limite di risorse 508 raggiunto

verificarsi.

I processi di registrazione non sono il vostro numero di visitatori #

Un limite di EP pari a un determinato valore, ad esempio, non significa che solo un numero corrispondente di persone possa visitare il tuo sito web contemporaneamente.

I visitatori e i processi di ingresso sono metriche diverse.

Ciò che è decisivo, tra le altre cose, è quanto a lungo vengono elaborate le richieste dinamiche.

In sintesi:

richiesta veloce
→ Il processo si conclude rapidamente
→ La risorsa si libera di nuovo

richiesta lenta
→ Il processo rimane attivo più a lungo
→ Possono crearsi più processi simultanei

Per questo motivo, un'applicazione lenta può gravare maggiormente sul limite di EP anche in presenza di traffico comparativamente moderato.

Che cosa può causare molti processi di inserimento? #

Le possibili cause includono, ad esempio:

• numerose richieste dinamiche simultanee
• lenta elaborazione PHP
• lente operazioni di database
• pagine dinamiche non memorizzate nella cache
• Bot o accessi automatizzati
• processi applicativi a lungo termine

Con WordPress o WooCommerce non è quindi rilevante solo il numero di visitatori, ma anche l'efficienza con cui vengono elaborate le singole richieste.

Limite del numero di processi raggiunto #

CloudLinux può inoltre limitare il numero totale di processi di un account di hosting.

Questo valore viene spesso utilizzato come NPROC rispettivamente Numero di processi definito.

A differenza dei processi di inserimento, NPROC non considera solo i processi web che si verificano contemporaneamente.

Anche altri processi in esecuzione dell'account possono essere rilevanti.

Esaminare molti processi #

Se il limite dei processi viene raggiunto regolarmente, verifica in particolare:

• cron job in parallelo
• processi PHP a lungo in esecuzione
• Attività in background
• Processi di importazione ed esportazione
• diverse applicazioni all'interno dello stesso account di hosting

Anche una vecchia installazione di test può eseguire attività in background, anche se non viene più utilizzata attivamente.

Limite di I/O raggiunto #

Il limite di I/O riguarda la velocità con cui i processi possono leggere o scrivere dati.

Se le prestazioni I/O disponibili vengono sfruttate completamente, i processi che ne dipendono potrebbero rallentare.

I fattori scatenanti tipici possono essere:

• grandi operazioni sui file
• Backup
• Decompressione di archivi di grandi dimensioni
• importazioni estese
• molte operazioni di scrittura
• Generazione della cache

Differenziare tra limite di I/O e spazio di archiviazione pieno #

Un limite I/O non significa che lo spazio di hosting sia pieno.

Limite di I/O
→ velocità delle operazioni sui file limitata

Spazio di archiviazione esaurito
→ spazio insufficiente o assente per ulteriori dati

Puoi controllare l'effettivo consumo di memoria sotto Controllare lo spazio di archiviazione e la larghezza di banda in cPanel.

Limite IOPS raggiunto #

Se nella tua analisi CloudLinux inoltre IOPS visualizzati, questo valore descrive il numero di operazioni di I/O al secondo.

Molte piccole operazioni sui file possono quindi esaurire un limite di IOPS, anche se la quantità totale di dati trasferiti non sembra particolarmente grande.

Quale risorsa è stata raggiunta? #

La seguente panoramica aiuta a fare una prima classificazione:

Limite	Tipici primi punti di controllo
CPU	PHP, Plugin, Cronjob, Importazioni, Traffico
Memoria fisica	processi intensivi di memoria e paralleli
Processi di ingresso	richieste dinamiche simultanee ovvero lente
Numero di processi	Processi in background, cron job, attività parallele
I/O	Backup, operazioni sui file, archivi, importazioni
IOPS	moltissime singole operazioni sui file

Controllare cosa era in esecuzione al momento dell'errore #

Dopo aver identificato il limite interessato, dovresti scoprire quale attività si è svolta nello stesso momento.

Verifica ad esempio:

• È stato eseguito un import?
• È stato eseguito un cronjob?
• È stato creato un backup?
• c'è stato un numero insolitamente alto di visitatori?
• C'erano bot attivi?
• è stato appena aggiornato WordPress?
• È stata avviata una sincronizzazione?
• è stato elaborato un grande archivio?

Solo questo collegamento tra Limite + Orario + Attività porta a una diagnosi affidabile.

7. Controllare il registro degli errori di cPanel nello stesso momento #

Se il sito web mostra contemporaneamente errori PHP o del server, apri inoltre:

Valori misurati → Errore

Verifica lì se nello stesso momento è stato registrato un messaggio di errore corrispondente.

Spiegheremo come leggere queste voci su Leggere il log degli errori di cPanel e trovare gli errori del sito web.

I limiti di CloudLinux e gli errori PHP possono verificarsi insieme #

Un problema di risorse e un errore di applicazione non si escludono a vicenda.

Per esempio, un processo difettoso può:

funzionare in modo inusualmente lungo
        ↓
consumare molta CPU o memoria
        ↓
raggiungere il limite di CloudLinux

In questo caso il limite di risorse è una conseguenza del vero problema dell'applicazione.

Indagare su WordPress come causa #

In WordPress, plugin, temi e attività in background possono avere un impatto significativo sul consumo di risorse.

Se il problema è iniziato subito dopo una modifica, verifica in particolare:

• plugin appena installato
• Aggiornamento del plugin
• Aggiornamento tema
• Aggiornamento di WordPress
• nuova funzione di importazione
• Plugin di backup
• Plugin di sicurezza o statistica
• codice individuale

Spiegheremo come investigare sistematicamente i conflitti di plugin e temi su Identificare e risolvere i conflitti tra plugin e temi WordPress.

Prendi in considerazione WP-Cron e le attività in background #

WordPress utilizza eventi programmati propri per varie attività in background.

I plugin possono, ad esempio, fare in modo che:

• Elaborare le e-mail
• Sincronizza dati
• Aggiorna feed
• Creare report
• Pulire i dati
• Eseguire aggiornamenti o altre attività di manutenzione

Un'attività di background ad alto consumo di risorse può quindi verificarsi anche quando non stai eseguendo nulla tu stesso nel backend di WordPress.

prestare particolare attenzione a WooCommerce #

WooCommerce gestisce numerose operazioni dinamiche e attività in background.

Questi possono includere, ad esempio:

• Carrello
• Cassa
• Conto cliente
• Ordini
• Importazioni di prodotti
• Sincronizzazioni
• azioni pianificate delle estensioni

In un negozio online dovresti quindi verificare con attenzione quale compito è stato eseguito al momento dell'evento di risorsa.

Considerare Action Scheduler di WordPress #

WooCommerce e numerose estensioni di WordPress utilizzano l'Action Scheduler per le attività in background.

Se si sono accumulate molte attività in sospeso o non riuscite, ciò può contribuire a un'attività di background ricorrente.

Se il tuo problema di risorse si verifica regolarmente, perciò può essere rilevante anche la coda delle attività programmate all'interno dell'applicazione in questione.

Verificare la presenza di bot e crawler come causa #

Gli accessi automatizzati possono causare un consumo significativo di risorse, in particolare quando vengono richiamati molti URL dinamici.

Un bot non deve necessariamente essere un attaccante malintenzionato.

Inoltre:

• Motori di ricerca
• Crawler SEO
• Servizi di monitoraggio
• Crawler di prezzi o di contenuti
• scanner automatizzati

possono generare numerose richieste.

Confrontare le statistiche degli accessi con l'evento della risorsa #

Se un limite coincide con un traffico insolitamente elevato, puoi anche utilizzare gli strumenti di cPanel sotto Valori misurati usare.

A seconda dell'analisi, lì sono disponibili, tra gli altri, dati sui visitatori, sulla larghezza di banda, di accesso grezzo e statistici.

Questo ti permette di valutare meglio se un picco di carico coincide con un aumento del traffico dati.

Il traffico non è automaticamente la causa #

Un limite di risorse durante il traffico intenso non significa necessariamente che solo il numero di visitatori sia il problema.

Se singole pagine dinamiche vengono elaborate molto lentamente, anche un traffico moderato può portare a molti processi in esecuzione simultanea.

Perciò bisognerebbe sempre esaminare anche l'efficienza dell'applicazione.

Verifica la cache #

Nelle pagine web dinamiche, un caching adeguato può ridurre notevolmente il numero di operazioni PHP e di database per le visualizzazioni di pagine ricorrenti.

CURIAWEB offre con AccelerateWP una soluzione di ottimizzazione incentrata su WordPress.

Puoi trovare ulteriori informazioni su AccelerateWP in cPanel spiegato.

Non installare più sistemi di cache uno sopra l'altro #

Quando viene raggiunto un limite di risorse, una reazione errata comune è quella di installare contemporaneamente diversi plugin per le prestazioni.

Questo può:

• causare conflitti
• Gestire i contenuti della cache in modo contraddittorio
• complicare la ricerca degli errori
• compromettere le funzioni dinamiche

Utilizza pertanto un'ottimizzazione controllata e verifica il risultato dopo ogni modifica.

La cache non risolve ogni problema #

La memorizzazione nella cache può essere particolarmente utile in caso di chiamate frontend ripetute.

Ma non risolve, ad esempio, automaticamente:

• cronjob difettosi
• importazioni che richiedono molte risorse
• Processi di backend
• determinate attività di WooCommerce
• codice applicativo difettoso
• operazioni di database insolitamente grandi

La causa deve quindi essere ulteriormente identificata.

Controlla la versione di PHP #

Una versione di PHP idonea e supportata dall'applicazione può essere rilevante per le prestazioni e la stabilità.

Su CURIAWEB gestisci la versione PHP del tuo dominio fondamentalmente tramite il MultiPHP-Manager.

Non cambiare ciecamente la versione di PHP solo a causa di un errore di risorse.

Verifica prima quale versione supportano il tuo sito web, i tuoi plugin e i tuoi temi.

Controlla le estensioni PHP #

Se contemporaneamente si verificano messaggi di errore relativi a funzioni o classi PHP mancanti, potrebbe essere rilevante anche un'estensione PHP richiesta.

Spieghiamo la procedura su Attivare e gestire le estensioni PHP in cPanel.

Non confondere i limiti di PHP con i limiti di CloudLinux #

Impostazioni PHP come:

memory_limit
max_execution_time
upload_max_filesize
post_max_size

non sono limiti di CloudLinux.

Se ad esempio CloudLinux segnala un limite di CPU o di Entry Process, questo problema non verrà risolto se tu upload_max_filesize o limite di memoria aumenti.

Controllare lo spazio di archiviazione #

Anche uno spazio di hosting pieno non è un limite di CPU di CloudLinux.

Se riscontri contemporaneamente problemi di scrittura, aggiornamento o invio di e-mail, dovresti controllare anche lo spazio di archiviazione disponibile.

Puoi trovare la procedura in Controllare lo spazio di archiviazione e la larghezza di banda in cPanel.

Considerare più siti Web nell'account #

Quando più siti Web vengono gestiti all'interno dello stesso account di hosting, condividono le risorse di quell'account.

Questo significa:

Sito A
Sito B
Sito C
Cronjob
Processi in background
        ↓
risorse dell'account condivise

Il problema delle risorse non deve quindi essere necessariamente causato dal dominio in cui hai visto per primo il messaggio di errore.

Non dimenticare le vecchie installazioni di test #

Un vecchio sito di test di WordPress può continuare a essere visitato dai bot ed eseguire attività in background.

Pertanto, anche le installazioni non più attivamente utilizzate possono richiedere risorse.

In caso di problemi ricorrenti, verifica quali applicazioni sono ancora effettivamente presenti nell'account di hosting.

I siti web di staging possono anche eseguire processi #

Una copia di staging è tecnicamente un altro sito web.

Se lì sono attivi WordPress, plugin, cron job o altri processi in background, anche questi potrebbero utilizzare risorse.

Tieni quindi conto anche degli ambienti di test e di staging.

Esaminare criticamente i plugin di backup #

I plugin di backup per WordPress possono, a seconda della configurazione, generare grandi quantità di dati:

• leggere
• comprimere
• scrivere
• trasferire

Ciò può influenzare la CPU, l'I/O, la memoria e i tempi di esecuzione dei processi.

Se i problemi di risorse si verificano regolarmente durante un backup tramite plugin, dovresti controllarne la pianificazione e la configurazione.

Grandi archivi possono consumare più risorse contemporaneamente #

La creazione o l'estrazione di un grande archivio ZIP può, ad esempio, contemporaneamente:

• CPU
• I/O
• IOPS
• Memoria RAM

rivendicare.

Pertanto, non considerare un singolo valore di misurazione se più risorse risultano anomale nello stesso momento.

Eseguire controlli sulle importazioni #

Se un'importazione di grandi dimensioni raggiunge regolarmente i limiti delle risorse, verifica se l'applicazione utilizzata supporta pacchetti di elaborazione più piccoli o una dimensione dei batch diversa.

Durante un'importazione di prodotti, ad esempio, può essere più efficiente elaborare sottoinsiemi controllati invece di forzare una quantità di dati estremamente elevata in un'unica operazione.

L'impostazione più opportuna dipende dalla specifica applicazione.

Considerare i problemi del database #

Operazioni di database lente o molto complesse possono far sì che i processi PHP rimangano attivi più a lungo.

Ciò consente l'accumulo di ulteriori processi sotto carico.

Un limite di risorse può quindi essere anche il sintomo di un'applicazione o di una query di database inefficiente.

Processi difettosi anziché un limite più alto #

Se un singolo processo difettoso consuma risorse inutilmente, un semplice aumento del limite non sarebbe una soluzione sostenibile.

Esempio:

Il plugin genera un ciclo infinito
        ↓
CPU costantemente alta
        ↓
Limite CPU raggiunto

La vera soluzione consiste quindi nel correggere il processo difettoso, anziché limitarsi ad assegnargli più CPU.

Quando più risorse possono effettivamente avere senso #

Non ogni limite di risorsa è riconducibile a un errore.

Un sito web tecnicamente pulito e ben ottimizzato può richiedere più risorse a causa del suo effettivo volume di utilizzo.

Ciò può verificarsi, ad esempio, in:

• traffico fortemente cresciuto
• amppi negozi online
• numerosi accessi dinamici simultanei
• applicazioni web ad alta intensità di risorse
• regolari grandi attività di elaborazione

essere il caso.

Prima di giungere a questa conclusione, tuttavia, si dovrebbe verificare se le risorse esistenti vengono utilizzate in modo efficiente.

Importante: „Più risorse“ e „Ottimizzare il sito web“ non sono in opposizione. Un'applicazione in crescita può aver bisogno di entrambi: software efficiente e una configurazione di hosting adeguata alle reali esigenze.

Quando l'ottimizzazione è più opportuna #

Un'ottimizzazione dovrebbe essere posta in primo piano in particolare quando:

• un singolo plugin causa un carico estremo
• si verifichino errori o cicli infiniti
• eseguire cronjob non necessari in parallelo
• Il traffico dei bot è insolitamente alto
• La memorizzazione nella cache (caching) è assente o configurata in modo errato
• vecchie installazioni eseguono processi non necessari
• un'operazione di database lavora in modo inefficiente

Quando verificare risorse aggiuntive #

Risorse aggiuntive possono invece essere utili se:

• il sito Web funzioni tecnicamente in modo corretto
• non sono presenti processi di errore evidenti
• l'applicazione è già stata opportunamente ottimizzata
• i limiti dovuti a un utilizzo legittimo vengono regolarmente raggiunti
• il fabbisogno effettivo di risorse è aumentato stabilmente

La decisione dovrebbe essere presa in base alle risorse misurate e all'applicazione effettiva, e non unicamente sulla base di un singolo messaggio di errore.

Il problema si è verificato solo una volta #

Se un limite di risorse è stato raggiunto una sola volta durante un'attività eccezionale e non si è più verificato in seguito, non vi è automaticamente la necessità di un intervento duraturo.

Esempi:

• grande importazione una tantum
• Migrazione
• Creazione di un grande archivio
• eccezionale picco di traffico

Documenta l'evento e osserva se si ripete.

Il problema si verifica quotidianamente #

Se lo stesso limite viene raggiunto circa alla stessa ora ogni giorno, ciò depone spesso a favore di un processo ricorrente.

Verifica:

Cronjob
Attività in background di WordPress
Azioni pianificate di WooCommerce
Backup
Sincronizzazioni
Importazioni
Esportazioni

Il momento ricorrente è un indizio particolarmente prezioso.

Il problema si presenta solo con molti visitatori #

Se i limiti delle risorse si verificano esclusivamente in presenza di un traffico elevato, dovresti esaminare:

• quale limite viene raggiunto
• quali URL vengono visitati più frequentemente
• se queste pagine vengono elaborate in modo dinamico
• se la memorizzazione nella cache degli oggetti (object caching) viene utilizzata in modo sensato
• se i bot causano parte del carico
• la rapidità con cui vengono elaborate le singole richieste

Osservare solo il numero di visitatori non è sufficiente per una diagnosi tecnica.

Il problema si verifica solo nel backend di WordPress #

Il backend di WordPress contiene molte aree che non possono essere completamente messe nella cache come le pagine pubbliche.

Se i problemi di risorse si verificano solo con determinate attività di amministrazione, dovresti esaminare esattamente quell'azione.

Esempi:

• Importazione prodotti
• Creazione di report
• Modifica di massa
• Scansione dei plugin
• Pulizia del database

Il problema si verifica solo durante il checkout #

Su WooCommerce, il checkout è un processo dinamico.

Se i problemi di risorse si verificano esclusivamente lì, non si dovrebbe semplicemente memorizzare nella cache l'intero sito web.

Esamina invece i plugin coinvolti nel checkout, i servizi di pagamento, le operazioni sul database e le connessioni esterne.

Problema dopo l'aggiornamento del plugin #

Se l'utilizzo delle risorse aumenta in modo significativo subito dopo un aggiornamento del plugin, la correlazione temporale è un indizio importante.

Verifica:

• Registro delle modifiche e requisiti di sistema
• Compatibilità PHP
• nuove funzioni di sfondo
• Messaggi di errore
• Conflitti con altre estensioni

Non modificare contemporaneamente più altri componenti, poiché ciò rende la diagnosi più difficile.

Problema dopo il cambio di PHP #

Se il problema si verifica immediatamente dopo una modifica della versione di PHP, controlla:

• Compatibilità dell'applicazione
• Plugin e temi
• estensioni PHP richieste
• Registro degli errori
• Valori delle risorse prima e dopo il cambio

Un passaggio controllato alla versione PHP precedentemente funzionante può rappresentare un utile passo diagnostico, a condizione che tale versione continui a essere supportata e sia idonea per l'applicazione.

Problema dopo la migrazione #

Se un sito web migrato richiede un numero insolitamente alto di risorse sul nuovo hosting, verifica tra le altre cose:

• Versione PHP
• Estensioni PHP
• Cronjob
• Configurazione della cache
• vecchi percorsi assoluti
• Errore di applicazione
• installazioni di test duplicate

Una migrazione può evidenziare differenze nella configurazione del server o dell'applicazione che non erano state notate in precedenza.

Non eseguire tutte le misure contemporaneamente #

Se tu contemporaneamente:

modifichi il PHP
disattivi i plugin
riconfiguri la cache
modifichi i cronjob
ottimizzi il database

e il problema scompare successivamente, non sai quale modifica abbia effettivamente aiutato.

Procedi quindi in modo controllato:

un'ipotesi
↓
una modifica mirata
↓
testare di nuovo
↓
confrontare le risorse

Controllare l'utilizzo delle risorse dopo una modifica #

Dopo un'ottimizzazione non dovresti solo verificare se il messaggio di errore è scomparso.

Controlla anche se i valori delle risorse sottostanti sono migliorati.

Esempio:

Prima:
Limite EP raggiunto più volte al giorno

Modifica:
corretto il processo in background lento

Dopo:
nessun errore EP nel periodo di tempo comparabile

In questo modo ottieni una prova decisamente migliore del fatto che la misura sia stata effettivamente efficace.

Diagnosticare sistematicamente il limite di risorse raggiunto #

1. Annotare data, ora e URL interessato.
2. Apri Valori misurati → Utilizzo delle risorse.
3. Seleziona il periodo di tempo adatto.
4. Verifica quale limite è stato raggiunto.
5. Controlla guasti ed eventi limite.
6. Confronta il loro momento con il problema del sito web.
7. Verifica quali processi o attività erano in esecuzione in quel momento.
8. Controlla i cronjob e le attività in background.
9. Verifica plugin, temi e azioni programmate di WordPress.
10. In caso di errori del sito web, controlla anche il log degli errori.
11. Controlla traffico insolito o bot.
12. Modifica una sola possibile causa alla volta.
13. Esegui nuovamente il test.
14. Confronta i valori di CloudLinux prima e dopo la modifica.

Cosa non dovresti fare #

Evita in particolare:

• Aumentare il limite di memoria di PHP senza diagnosi in modo estremo
• installare più plugin di cache contemporaneamente
• Cambiare le versioni di PHP a caso
• Eliminare i cronjob senza conoscerne la funzione
• Disattivare in massa plugin e temi contemporaneamente
• cancellare file di grandi dimensioni per sicurezza
• interpretare un singolo picco isolato come un problema di hosting permanente

Regola fondamentale: Un errore di risorse non si risolve in modo affidabile modificando il maggior numero possibile di impostazioni. Devi prima scoprire quale limite viene raggiunto e quale processo richiede risorse in quel momento.

Il sito web non mostra un errore 508, ma è lento #

Un account di hosting può raggiungere i limiti delle risorse senza che ogni visitatore riceva necessariamente una pagina 508 visibile.

Le limitazioni della CPU o dell'I/O possono, ad esempio, manifestarsi inizialmente con un'elaborazione più lenta.

Se un sito web è sporadicamente lento, dovresti quindi controllare l'utilizzo delle risorse di CloudLinux nel momento in questione, anche in assenza di un errore 508 visibile.

Nessun limite CloudLinux raggiunto #

Se CloudLinux non mostra eventi di limite pertinenti nel periodo di tempo in questione, dovresti estendere la risoluzione dei problemi ad altri livelli.

Le possibili cause includono, ad esempio:

• Errore PHP
• Problemi di database
• servizi esterni
• DNS
• SSL
• Errore di plugin o tema
• Problemi di browser o di frontend

Non cercare di risolvere un problema di risorse se le metriche non ne forniscono alcuna prova.

Quando dovresti contattare il supporto di CURIAWEB? #

Se il tuo account di hosting raggiunge regolarmente i limiti di CloudLinux e non riesci a identificare chiaramente l'applicazione o l'attività responsabile, documenta il problema nel modo più dettagliato possibile.

Sono particolarmente utili:

• dominio interessato
• URL o funzione interessata
• Data e ora esatte
• messaggio di errore visibile
• limite CloudLinux interessato
• guasti visualizzati ed eventi di limite
• Frequenza del problema
• modifiche recenti
• cron job in esecuzione, importazioni o attività in background
• voci di registro degli errori rilevanti

Questi dati consentono di valutare molto più rapidamente se si è in presenza di un processo difettoso, di una possibilità di ottimizzazione o di un fabbisogno di risorse permanentemente maggiore.

Riepilogo #

Il messaggio Limite delle risorse raggiunto significa che il tuo account di hosting ha raggiunto un limite di risorse gestito da CloudLinux. Non significa automaticamente che l'intero server di hosting sia sovraccarico.

Apri prima Valori misurati → Utilizzo delle risorse e verifica il periodo di tempo in cui si è verificato il problema. Successivamente, è fondamentale determinare quale limite sia stato effettivamente raggiunto.

CPU, memoria fisica, processi attivi, numero di processi, I/O e IOPS descrivono risorse differenti. Di conseguenza, anche le possibili cause differiscono.

Un limite di CPU può essere causato, ad esempio, da processi PHP complessi, cron job o da un elevato carico dinamico. Un limite EP indica invece un numero eccessivo di processi in arrivo elaborati contemporaneamente. La memoria fisica, d'altra parte, non deve essere confusa con il PHPlimite di memoria essere confuso.

Confronta sempre gli eventi di limite con l'orario esatto del problema del sito web. Successivamente, verifica i cronjob, le attività in background di WordPress, i plugin, le importazioni, i backup, il traffico e i log degli errori.

Inoltre, un limite di risorse non è automaticamente la prova che il tuo pacchetto di hosting sia fondamentalmente troppo piccolo. Codice difettoso, cron job sfavorevoli o una mancata ottimizzazione possono causare un carico non necessario. Al contrario, un sito web tecnicamente pulito e molto cresciuto potrebbe effettivamente richiedere stabilmente più risorse.

La regola più importante è: Prima identificare il limite interessato, poi trovare l'attività che lo causa e solo dopo decidere se ottimizzare, correggere o se effettivamente servono più risorse.