Comprendere l'utilizzo delle risorse di CloudLinux in cPanel

Tempo di lettura ca.: 16 minuti

Se un sito Web risponde temporaneamente a rilento, i processi si interrompono o gli errori si verificano solo sotto carico, dovresti controllare le risorse di hosting disponibili oltre agli errori PHP e allo spazio di archiviazione.

CURIAWEB utilizza CloudLinux per isolare gli account di hosting l'uno dall'altro e assegnare le risorse in modo controllato. In cPanel puoi farlo sotto Valori misurati → Utilizzo delle risorse verificare se il tuo account ha raggiunto i limiti delle risorse e quali risorse sono state particolarmente sollecitate in un determinato momento.

In questa guida ti mostriamo come aprire l'utilizzo delle risorse di CloudLinux, interpretare correttamente le metriche principali e distinguere tra un breve picco di carico e un effettivo problema di risorse.

Importante: Un valore elevato o un singolo picco di carico non significano automaticamente che ci sia qualcosa che non va nel tuo sito web. Ciò che conta è se un limite viene effettivamente raggiunto, con quale frequenza ciò accade e se il momento coincide con un problema visibile del sito web.

Che cosa fa CloudLinux? #

Su un sistema di hosting condiviso, più account di hosting utilizzano la stessa infrastruttura di server fisico.

CloudLinux assicura, tra le altre cose, che le risorse dei singoli account siano isolate l'una dall'altra. In questo modo, ad esempio, un sito Web con un carico elevato non può consumare risorse illimitate dell'intero server.

Per un singolo account di hosting, diverse risorse possono essere considerate e limitate separatamente.

Ciò include, a seconda della configurazione del server, in particolare:

  • Prestazioni della CPU
  • memoria fisica
  • Prestazioni di I/O
  • processi in arrivo simultanei
  • Numero totale dei processi

L'indicatore CloudLinux ti aiuta a riconoscere, quale risorsa sia stata utilizzata in quale momento.

Le risorse di CloudLinux non sono il tuo spazio di archiviazione #

Una delle distinzioni più importanti è quella tra spazio di hosting e risorse di sistema in esecuzione.

AreaSignificato
Spazio di archiviazioneSpazio per file, e-mail, database e altri dati archiviati
larghezza di bandadati trasferiti
Memoria fisicaMemoria di lavoro utilizzata dai processi in esecuzione
CPUPotenza di calcolo per i processi in corso
I/Ovelocità di trasmissione dei dati nelle operazioni di I/O
Processi di ingressoprocessi in arrivo elaborati contemporaneamente nel contesto CloudLinux LVE
ProcessiNumero di processi in esecuzione dell'account

Se vuoi scoprire quali file o email stanno occupando lo spazio del tuo hosting, utilizza invece Controllare lo spazio di archiviazione e la larghezza di banda in cPanel.

1. Apri Utilizzo delle risorse in cPanel #

Accedi al tuo cPanel di CURIAWEB e apri:

Valori misurati → Utilizzo delle risorse

L'interfaccia CloudLinux fornita lì mostra informazioni sull'utilizzo delle risorse del tuo account di hosting.

A seconda della versione attuale di CloudLinux e della configurazione del server, la visualizzazione e le etichette dei singoli valori potrebbero variare leggermente.

2. Prima verificare il riassunto #

Prima di analizzare i singoli diagrammi, dovresti considerare il riepilogo o lo stato attuale.

CloudLinux può indicare lì se il tuo account ha raggiunto i limiti delle risorse entro un determinato periodo di tempo.

Ciò è molto più significativo per la diagnosi rispetto al semplice accertamento che un grafico mostri un valore elevato in un dato momento.

Regola fondamentale: Non cercare prima il picco più alto nel grafico. Verifica prima se è stato raggiunto un limite e a quale momento ciò è accaduto.

3. Selezionare il periodo dell'analisi #

In caso di problemi sporadici, il periodo preso in considerazione è particolarmente importante.

Se, ad esempio, ieri il tuo sito Web è stato lento o non raggiungibile intorno alle 14:30, dovresti esaminare l'utilizzo delle risorse possibilmente per proprio quel periodo di tempo.

Un corretto flusso diagnostico è:

Rilevare il problema del sito web
↓
Annotare data e ora
↓
Aprire l'utilizzo delle risorse
↓
Selezionare il periodo di tempo appropriato
↓
Confrontare limiti e metriche

Un evento di risorse in un momento completamente diverso di solito non spiega il problema attuale del tuo sito web.

Comprendere l'utilizzo della CPU #

La CPU fornisce la potenza di calcolo. Gli script PHP, le operazioni di database e altri processi richiedono tempo CPU per eseguire le loro attività.

Un utilizzo elevato della CPU può essere causato, ad esempio, da:

  • molte visite simultanee al sito web
  • processi PHP intensivi dal punto di vista computazionale
  • operazioni di database estese
  • Importazioni ed esportazioni
  • Processi di backup o di manutenzione
  • Cronjob
  • plugin o applicazioni inefficienti
  • Accessi dei bot

Un utilizzo elevato della CPU è inizialmente solo un valore di misurazione. Ciò che conta è se il limite di CPU applicabile all'account viene effettivamente raggiunto.

Cosa succede quando si raggiunge il limite della CPU? #

Se un account utilizza interamente la potenza di CPU assegnatagli, CloudLinux può limitare l'ulteriore utilizzo della CPU.

In parole semplici, questo significa:

L'applicazione richiede più potenza di CPU
        ↓
Viene raggiunto il limite di CPU dell'account
        ↓
L'ulteriore elaborazione viene limitata
        ↓
I processi potrebbero richiedere più tempo

Per i visitatori, questo potrebbe manifestarsi, ad esempio, come un sito Web più lento.

Un limite di CPU non significa quindi necessariamente che un processo venga terminato immediatamente con un messaggio di errore visibile.

Breve picco della CPU o problema persistente? #

Un breve picco della CPU può essere del tutto normale per determinate attività.

Ad esempio, un'importazione può richiedere temporaneamente molta più potenza di calcolo rispetto al normale funzionamento del sito web.

Più critico è un modello come:

Limite della CPU regolarmente raggiunto
→ Sito web contemporaneamente lento
→ Stessa situazione che si ripete
→ Causa riproducibile

Dovresti quindi esaminare quale processo o applicazione sta causando il carico.

Comprendere la memoria fisica #

Memoria fisica indica la memoria RAM fisica utilizzata dai processi del tuo account di hosting all'interno dell'ambiente CloudLinux.

Questo valore non è lo stesso di:

  • il tuo spazio di hosting
  • le dimensioni del tuo sito web
  • il PHP-limite di memoria

Questa è una distinzione particolarmente importante.

Distinguere tra memoria fisica e PHP memory_limit #

Il PHP-limite di memoria limita la memoria che un singolo processo PHP può utilizzare in base alla sua configurazione PHP.

Il limite di CloudLinux per la memoria fisica, invece, considera il consumo di memoria dei processi dell'account di hosting su un livello diverso.

In sintesi:

Limite di memoria PHP

Un livello PHP superiorelimite di memoria pertanto non aumenta automaticamente il limite di memoria di CloudLinux.

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

Importante: Quando CloudLinux segnala un limite di memoria, non dovresti semplicemente aumentare il limite di memoria PHP. Ciò può rendere un problema di risorse ancora più evidente, poiché ai singoli processi PHP è consentito consumare più memoria.

Cosa può richiedere molta memoria RAM? #

Un maggiore consumo di memoria può essere causato, ad esempio, da più processi PHP in esecuzione contemporanea, da applicazioni complesse o da attività particolarmente intensive in termini di memoria.

Le situazioni tipiche sono:

  • grandi importazioni
  • Elaborazione delle immagini
  • ampi processi WordPress o WooCommerce
  • diverse richieste PHP parallele
  • Cronjob
  • Processi di backup o di manutenzione
  • codice applicativo difettoso o inefficiente

Comprendere l'I/O #

I/O sta per Input/Output e descrive, in modo semplificato, la velocità di trasferimento con cui i processi possono leggere o scrivere dati.

Ciò riguarda, ad esempio, l'accesso ai file.

Un'elevata attività di I/O può verificarsi, tra le altre cose, durante le seguenti attività:

  • grandi operazioni sui file
  • Backup
  • Decompressione di archivi di grandi dimensioni
  • importazioni massicce
  • Generazione della cache
  • di determinate applicazioni ad alta intensità di dati

Cosa succede in caso di limite di I/O? #

Se un processo richiede più prestazioni di I/O di quelle disponibili per l'account, l'elaborazione dei dati può essere limitata di conseguenza.

Ciò può comportare che le operazioni sui file o i processi dipendenti da esse richiedano più tempo.

Un limite di I/O non è quindi la stessa cosa di uno spazio di archiviazione pieno.

Spazio di archiviazione esaurito
→ manca spazio per ulteriori dati

Limite I/O raggiunto
→ la velocità di trasmissione dei dati è limitata

Le IOPS possono essere visualizzate separatamente #

A seconda della configurazione di CloudLinux, è possibile aggiungere anche un valore per IOPS essere visualizzato.

Gli IOPS descrivono il numero di operazioni di input/output al secondo e pertanto non sono identici alla quantità di dati trasferiti al secondo.

In sintesi:

I/O
→ quanti dati vengono trasferiti per unità di tempo

IOPS
→ quante singole operazioni di I/O vengono eseguite per unità di tempo

Molte piccole operazioni sui file possono quindi generare un profilo di risorse diverso rispetto a poche grandi operazioni sui file.

Comprendere i processi di ingresso #

Processi di ingresso – spesso come EP designati – rientrano tra i valori di CloudLinux che vengono fraintesi più frequentemente.

Descrivono in modo semplificato il numero di processi in entrata che entrano contemporaneamente nell'ambiente CloudLinux LVE o che vi vengono elaborati contemporaneamente.

Ciò può includere in particolare richieste Web dinamiche.

Importante: I processi di ingresso non corrispondono al numero di visitatori del tuo sito web. Un visitatore non è automaticamente un processo di ingresso.

Perché i visitatori e i processi di ingresso non sono la stessa cosa #

Un visitatore può inviare più richieste in sequenza. Allo stesso tempo, richieste diverse possono richiedere tempi di elaborazione molto diversi.

Per il limite di EP è quindi la Simultaneità di processi rilevanti decisivo e non semplicemente il numero di visitatori al giorno.

Un sito web con molte richieste veloci e ben memorizzate nella cache può quindi comportarsi in modo diverso rispetto a un sito web con poche richieste dinamiche, ma molto lente.

Cosa succede quando si raggiunge il limite dei processi di immissione? #

Quando troppi processi corrispondenti devono essere elaborati contemporaneamente e viene raggiunto il limite EP, le richieste aggiuntive non possono essere elaborate normalmente.

In questo contesto, i visitatori possono ad esempio riscontrare errori come:

Limite di risorse 508 raggiunto

vedere.

Tratteremo la diagnosi specifica e la risoluzione nel prossimo articolo sotto Limite di risorse raggiunto: identificazione e risoluzione dei limiti di CloudLinux.

Comprendere il numero di processi #

CloudLinux può inoltre limitare il numero totale di processi di un account. Questo valore viene spesso chiamato Numero di processi rispettivamente NPROC definito.

Non si tratta solo di richieste Web in arrivo simultaneamente.

A seconda del rispettivo ambiente, diversi processi dell'account possono contribuire al totale dei processi in esecuzione.

Ecco perché I processi di immissione e il numero di processi non sono la stessa cosa.

Confrontare i processi di immissione e il numero di processi #

ValoreIn parole semplici
Processi di Ingressoprocessi in entrata simultanei o elaborati contemporaneamente
Numero di processi (NPROC)Numero totale dei processi in esecuzione dell'account

Pertanto un account può avere un problema di processo senza che EP e NPROC debbano necessariamente mostrare lo stesso comportamento contemporaneamente.

I guasti sono particolarmente importanti per la diagnosi #

Nell'analisi di CloudLinux, oltre ai valori attuali o medi, è possibile trovare anche i cosiddetti Guasti ovvero essere pertinenti agli eventi limite.

Un errore indica in modo semplificato che è stato raggiunto un limite di risorse.

Questo è spesso più significativo per la diagnosi rispetto a un diagramma la cui linea si trova semplicemente vicino al limite.

Consiglio pratico: Se vuoi sapere se un limite di risorse è stato realmente rilevante, presta particolare attenzione agli eventi di limite documentati e al loro tempismo.

100 % non ha lo stesso significato per ogni valore #

Le percentuali devono essere sempre lette nel contesto del rispettivo limite di risorsa.

Ad esempio, un valore della CPU pari a 100 % visualizzato nella panoramica delle risorse di hosting non significa automaticamente che l'intero server fisico sia utilizzato al 100 %.

Può fare riferimento alla risorsa assegnata al tuo account.

Pertanto, non utilizzare le percentuali come affermazione sul carico complessivo del server.

Distinguere tra limite dell'account e carico del server #

Se il tuo account di hosting raggiunge un limite di CloudLinux, non ne consegue automaticamente che l'intero server di hosting sia sovraccarico.

CloudLinux serve proprio a isolare le risorse dei singoli account l'una dall'altra.

In sintesi:

L'account ha raggiunto il proprio limite di risorse
≠
l'intero server è sovraccarico

Questa distinzione è fondamentale per l'interpretazione dei valori.

I valori medi possono nascondere brevi picchi #

Un valore medio su un periodo di tempo più lungo può sembrare normale, nonostante all'interno di questo periodo si sia verificato un picco di carico breve e intenso.

Se il tuo sito web ha avuto problemi solo per pochi minuti, dovresti quindi considerare un periodo di tempo il più possibile adeguato e tenere conto degli eventi di limite.

Un singolo picco non fa ancora una diagnosi #

Supponendo che l'utilizzo della CPU raggiunga brevemente un valore elevato, mentre:

  • il sito web funziona normalmente
  • non vengono documentati limiti
  • non si verifichino errori
  • il valore successivamente scende di nuovo

Non c'è quindi automaticamente alcun bisogno di agire.

Un picco di carico può essere semplicemente sorto da un compito appena eseguito.

I limiti ricorrenti sono più rilevanti #

Decisamente più interessante è un modello come:

ogni giorno verso le 02:00
→ la CPU aumenta notevolmente
→ l'I/O aumenta
→ vengono raggiunti i limiti
→ contemporaneamente il sito web risponde lentamente

Un simile schema ricorrente depone a favore di un'analisi più approfondita dei processi in corso in quel momento.

Confrontare i cronjob con gli eventi delle risorse #

Se i problemi di risorse si verificano regolarmente alla stessa ora, controlla anche i cronjob pianificati.

Un processo di importazione, esportazione, backup o sincronizzazione può determinare un carico ricorrente.

Spiegheremo come investigare sui problemi dei cronjob su Cronjob non funziona: cause e soluzioni.

Diversi cronjob allo stesso tempo #

Se più cronjob a elevato utilizzo di risorse si avviano esattamente nello stesso momento, le relative richieste possono sommarsi.

Per esempio:

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

Se le rispettive applicazioni sono flessibili nel tempo, può essere opportuno distribuire gli orari di avvio.

Non modificare tuttavia i programmi predefiniti di un'applicazione senza averli prima verificati.

I backup possono richiedere risorse #

I processi di backup e archiviazione possono consumare CPU, I/O e altre risorse a seconda del volume.

Se si verifica un picco di carico durante un backup, la correlazione temporale è quindi rilevante.

Ciò non significa tuttavia automaticamente che il backup sia difettoso.

Le importazioni e le esportazioni possono causare picchi di carico #

Grandi importazioni ed esportazioni di dati sono esempi tipici di operazioni temporaneamente intensive in termini di risorse.

Un'importazione di prodotti WooCommerce, un'operazione estesa sul database o l'elaborazione di molti file possono richiedere temporaneamente molte più risorse rispetto al normale funzionamento del sito web.

Plugin WordPress come possibile causa #

In WordPress i plugin possono eseguire attività in background, query di database o connessioni esterne.

Se un problema di risorse inizia immediatamente dopo l'installazione o l'aggiornamento di un plugin, questa correlazione temporale dovrebbe essere indagata.

Il plugin non risulta quindi ancora automaticamente provato come causa.

Una diagnosi sistematica dei conflitti si trova su Identificare e risolvere i conflitti tra plugin e temi WordPress.

WooCommerce richiede spesso una maggiore elaborazione dinamica #

I negozi online contengono molte aree che non possono essere trattate semplicemente come pagine statiche.

Carrello, checkout, account cliente, ordini, attività in background e varie estensioni possono causare ulteriore elaborazione dinamica.

Un negozio WooCommerce non dovrebbe quindi essere paragonato a un semplice sito web informativo basandosi unicamente sul numero di visitatori.

I bot possono consumare risorse #

Non solo i visitatori umani generano carico.

Bot, crawler e scanner automatizzati possono inviare molte richieste a un sito web.

Se un carico di risorse insolito si verifica contemporaneamente a un forte traffico, anche le statistiche di accesso o i log di accesso possono quindi essere rilevanti.

Molti visitatori non significano automaticamente problemi di risorse #

Un alto numero di visitatori da solo dice poco sulle risorse del server necessarie.

Tra gli elementi decisivi vi sono:

  • quante richieste simultanee vengono effettuate
  • quanto velocemente PHP le elabora
  • quanto siano efficienti le query sui database
  • quali contenuti possono essere memorizzati nella cache
  • quali plugin o applicazioni sono coinvolti

Un sito web ben ottimizzato può quindi gestire molte più richieste rispetto a un sito tecnicamente inefficiente con un'applicazione comparabile.

La memorizzazione nella cache può ridurre il carico dinamico #

Se i contenuti non devono essere generati completamente da zero tramite PHP e il database a ogni richiesta, la memorizzazione nella cache può ridurre significativamente il carico dinamico del server.

CURIAWEB mette a disposizione uno strumento corrispondente in cPanel con AccelerateWP.

Puoi trovare ulteriori informazioni su AccelerateWP in cPanel spiegato.

La memorizzazione nella cache non risolve ogni problema di risorse #

Un cache aiuta soprattutto in caso di richieste che possono essere memorizzate in modo sensato.

Ad esempio, non risolve automaticamente:

  • cronjob difettosi
  • processi di backend estremamente complessi
  • operazioni di database mal programmate
  • determinate attività in background di WooCommerce
  • perdite di memoria o codice difettoso

Di conseguenza, non attivare indiscriminatamente sistemi di cache aggiuntivi se la vera causa è sconosciuta.

L'uso di più plugin di cache può essere problematico #

Maggiore caching non significa automaticamente maggiore velocità.

Diverse soluzioni di cache e ottimizzazione che lavorano contemporaneamente possono influenzarsi a vicenda o generare una complessità non necessaria.

Utilizza pertanto una configurazione controllata e adatta all'ambiente di hosting.

La versione di PHP può influenzare l'utilizzo delle risorse #

Le versioni di PHP differiscono, tra le altre cose, in termini di prestazioni e compatibilità software.

Una versione di PHP obsoleta o inadatta all'applicazione può quindi essere rilevante anche indirettamente per l'analisi delle risorse.

La versione PHP di un dominio viene gestita in CURIAWEB fondamentalmente tramite il MultiPHP-Manager.

Non cambiare PHP solo perché un valore di risorsa è alto. Verifica prima la compatibilità della tua applicazione.

Il limite di memoria PHP non è un'impostazione di prestazioni #

Un errore comune consiste nel modificare semplicemente la versione di PHP di un sito web lentolimite di memoria aumentare notevolmente.

Il memory limit fornisce a un processo PHP semplicemente un limite massimo di memoria consentito.

Ciò non rende automaticamente PHP più veloce e non mette a disposizione dell'account di hosting ulteriore potenza di calcolo della CPU.

Controllare il registro degli errori in parallelo #

Se un sito web mostra errori contemporaneamente, dovresti esaminare il registro degli errori oltre ai valori di CloudLinux.

Sotto Leggere il log degli errori di cPanel e trovare gli errori del sito web spieghiamo come classificare i tipici messaggi di PHP e del server web.

Problema di risorse o errore PHP? #

Entrambi i problemi possono causare sintomi simili.

OsservazionePunto di controllo importante
Errore fatale di PHPRegistro degli errori
Dimensione della memoria consentita esauritaLimite di memoria PHP e applicazione
Limite CloudLinux documentatoUtilizzo delle risorse
Limite delle risorse raggiuntoLimiti CloudLinux
Il sito web è sporadicamente lentoConfronta il timestamp con risorse e log
Spazio di archiviazione esauritoUtilizzo dello spazio di archiviazione

Non equiparare il limite della CPU a un database lento #

Se un'applicazione richiede molta CPU, potrebbe essere coinvolta una query di database inefficiente. Tuttavia, il solo valore della CPU non lo dimostra.

Al contrario, un'applicazione lenta può essere rallentata da API esterne, accesso ai file o altri fattori, senza che la CPU sia costantemente al limite.

Il grafico delle risorse ti mostra era viene gravata – non mostra automaticamente quale codice di programma specifico è la causa.

Il display di CloudLinux non è un debugger di processi #

CloudLinux ti aiuta a circoscrivere i colli di bottiglia delle risorse in base al tempo e al tipo di risorsa.

L'annuncio dice, per esempio:

Il limite della CPU è stato raggiunto alle 14:32

Non significa automaticamente:

Il plugin XYZ è colpevole

Per l'effettiva analisi delle cause, devi combinare il momento temporale con attività del sito web, cronjob, log, aggiornamenti o altre informazioni tecniche.

Ciò che è accaduto immediatamente prima del problema delle risorse #

Se l'utilizzo delle risorse è anomalo solo da poco tempo, verifica modifiche come:

  • nuovo plugin installato
  • Plugin o tema aggiornato
  • nuovo sito web importato
  • Cronjob configurato
  • Soluzione di backup modificata
  • nuova campagna di marketing avviata
  • Il traffico è aumentato notevolmente
  • Estensione WooCommerce attivata
  • Versione PHP modificata

Il legame temporale è un indizio importante, ma non ancora una prova.

Riprodurre in modo mirato il picco di carico dopo la modifica #

Se una determinata azione è potenzialmente responsabile dell'elevato carico, puoi – a patto che l'azione sia ripetibile senza rischi – osservare il processo in modo mirato.

Per esempio:

Controllare l'utilizzo delle risorse
        ↓
Prendere nota del tempo
        ↓
Eseguire l'azione interessata
        ↓
Controllare nuovamente l'utilizzo delle risorse

Non eseguire più volte processi di pagamento, spedizione, importazione o altri processi modificanti se non ne conosci il comportamento in caso di ripetizione.

Gestire più siti Web nello stesso account cPanel #

Se più domini o applicazioni vengono gestiti all'interno dello stesso account di hosting, possono condividere le risorse dell'account.

Un elevato utilizzo di risorse non deve quindi necessariamente provenire dal sito web in cui noti il problema per primo.

Considera tutte le applicazioni e i processi in background dell'account in questione.

Le installazioni vecchie o dimenticate possono generare risorse #

Un'installazione di test di WordPress non più attiva può continuare a:

  • essere chiamati dai bot
  • Esegui WP-Cron
  • Carica plugin
  • elaborare attività automatiche

Se sono presenti più installazioni nell'account di hosting, dovresti quindi considerare anche i sistemi di test meno recenti.

Confrontare i valori delle risorse dopo l'ottimizzazione #

Se hai trovato e risolto una causa specifica, confronta successivamente l'utilizzo delle risorse in condizioni il più possibile simili.

Esempio:

Prima:
Limite CPU raggiunto più volte al giorno

Modifica:
processo in background difettoso corretto

Dopo:
nessun errore CPU nel periodo comparabile

In questo modo puoi valutare molto meglio se la misura è stata effettivamente d'aiuto.

Non eseguire più ottimizzazioni contemporaneamente #

Se tu contemporaneamente:

cambi PHP
modifichi la cache
disattivi i plugin
sposti i cronjob
ottimizzi il database

e il carico diminuisce successivamente, non sai quale misura ne sia stata la responsabilità.

Procedi quindi in modo controllato e graduale durante la diagnosi.

Quando è effettivamente rilevante un limite di risorse? #

Un limite è particolarmente rilevante quando si sommano più fattori:

  • il limite viene effettivamente raggiunto
  • l'evento si ripete
  • il momento coincide con un problema del sito web
  • il comportamento è riproducibile o riconducibile a un processo

D'altra parte, un singolo picco di carico breve senza effetti visibili non dovrebbe essere sopravvalutato.

Risorse tipiche e loro importanza #

RisorsaSignificatoPrima di procedere, esaminare il limite
CPUPotenza di calcoloProcessi PHP, applicazione, cron job, traffico
Memoria fisicaMemoria di lavoro dei processi dell'accountprocessi paralleli e a elevato consumo di memoria
I/OVelocità di trasferimento dei dati nelle operazioni sui fileBackup, Archivio, Importazione, Operazioni sui file
IOPSNumero di operazioni I/Omolte piccole operazioni sui file
Processi di ingressoprocessi simultanei/elaborati contemporaneamenterichieste dinamiche simultanee
Numero di processiNumero totale di processi in esecuzioneprocessi in background, attività parallele

Analizzare sistematicamente i valori di CloudLinux #

  1. Prendi nota della data e dell'ora del problema del sito web.
  2. Apri Valori misurati → Utilizzo delle risorse.
  3. Scegli un periodo di tempo adatto.
  4. Verifica se CloudLinux segnala un limite di risorse raggiunto.
  5. Identificare la risorsa interessata.
  6. Verifica la presenza di guasti ed eventi limite.
  7. Confronta il loro momento con il problema del sito web.
  8. Controlla cronjob, importazioni, backup e altre attività in questo momento.
  9. In caso di errori del sito web, controlla anche il log degli errori.
  10. Modifica poi in modo mirato una sola possibile causa.
  11. Confronta nuovamente l'utilizzo delle risorse dopo la modifica.

Cosa non dovresti fare in presenza di alti valori di risorse #

Evita in particolare le seguenti decisioni avventate:

  • Aumentare drasticamente il limite di memoria PHP in modo forfettario
  • Cambiare la versione di PHP senza controllo di compatibilità
  • disattivare più plugin contemporaneamente
  • Eliminare file preventivamente
  • installare più plugin di cache
  • Rimuovere i cronjob in modo casuale
  • interpretare un singolo picco come un sovraccarico permanente

Consiglio pratico: L'analisi delle risorse è una diagnosi temporale. La domanda non è solo „Quale valore è alto?“, ma soprattutto „Quale limite è stato raggiunto e quando, e cosa è successo esattamente in quel momento?“

Se il sito Web è lento, ma non vengono raggiunti limiti #

Se CloudLinux non mostra eventi di limite rilevanti, non dovresti continuare a cercare di forzare un problema di risorse.

Un sito web lento può avere numerose altre cause.

A ciò appartengono, ad esempio:

  • lenti database queries
  • API esterne
  • immagini grandi o mal ottimizzate
  • JavaScript nel browser
  • Plugin o temi
  • caching mancante o inadeguato
  • Dipendenze DNS o di rete

CloudLinux è quindi solo una possibile causa, che hai già potuto circoscrivere meglio grazie ai dati delle misurazioni.

Se il sito web non è affatto raggiungibile #

In caso di un sito Web completamente irragiungibile, non dovresti guardare esclusivamente la schermata di CloudLinux.

DNS, configurazione del dominio, SSL, server web, PHP, applicazione e altri livelli possono essere altrettanto rilevanti.

Trattiamo la diagnosi completa sotto Sito web non raggiungibile: diagnosticare sistematicamente gli errori di hosting.

Quando dovresti contattare il supporto di CURIAWEB? #

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

Sono particolarmente utili:

  • dominio o applicazione interessati
  • Data e ora del problema
  • risorsa interessata
  • eventi di limite visibili o guasti
  • comportamento visibile del sito web
  • se il problema si verifica regolarmente o solo una volta
  • modifiche recenti
  • cron job, importazioni o altre attività in esecuzione in questo momento
  • eventuali voci rilevanti nel log degli errori

Più precisamente è noto il momento, più facilmente è possibile associare un evento di risorsa a una determinata attività.

Riepilogo #

Sotto Valori misurati → Utilizzo delle risorse puoi verificare nel cPanel di CURIAWEB come il tuo account di hosting utilizza le risorse gestite da CloudLinux.

Tra le metriche più importanti figurano la CPU, la memoria fisica, l'I/O, eventualmente gli IOPS, gli Entry Processes e il numero totale di processi.

Questi valori non devono essere confusi con lo spazio di archiviazione o la larghezza di banda. Allo stesso modo, la memoria fisica di CloudLinux non è la stessa del PHP-limite di memoria.

Per la diagnosi non sono importanti solo i valori di misura elevati. È fondamentale, in particolare, se un limite di risorse sia stato effettivamente raggiunto, quando ciò sia avvenuto e se il momento coincida con un problema visibile del sito web.

I processi di entry non corrispondono al numero dei tuoi visitatori. Inoltre, un valore della CPU pari a 100 % nella schermata delle risorse non significa automaticamente che l'intero server di hosting sia completamente saturo.

Brevi picchi di carico possono essere normali in caso di importazioni, backup, cronjob o altre attività. Eventi di limite ricorrenti, invece, insieme a un sito Web lento o difettoso, dovrebbero essere analizzati più attentamente.

Confronta gli eventi delle risorse con i cron job, gli aggiornamenti, il traffico, i log degli errori e altre attività nello stesso momento. Successivamente, modifica sempre una sola causa potenziale alla volta e verifica se il comportamento migliora.

La regola più importante è: Non cercare il valore più alto, ma collegare il reale evento limite al momento e all'attività che lo ha causato.

Ultimo aggiornamento 28 agosto 2026
Questo articolo è stato utile?
Contenuto
Consenso ai cookie con Real Cookie Banner