Isolamento e limiti
Isolamento e limiti è un modulo opzionale che fa quello che su altri pannelli fa CloudLinux: ogni account ha limiti di CPU, memoria, processi, disco e connessioni al database, e il suo PHP è isolato dagli altri account. È incluso in tutti i piani, senza licenze in più e senza kernel modificato: usa quello che Ubuntu 24.04 e 26.04, AlmaLinux 9 e Rocky Linux 9 hanno già (systemd e cgroup v2). Su AlmaLinux e Rocky SELinux resta attivo: il pannello aggiunge le poche regole che servono al modulo.
Il modulo non è installato di norma: finché non lo installi non cambia nulla sul server. Con pochi siti di solito non serve; diventa utile quando sullo stesso server ci sono i siti di più account.
Installare e disinstallare
Da Server › Isolamento e limiti (amministratori): la pagina controlla prima i requisiti del server, poi Installa. Il PHP di ogni account passa in un servizio suo; i siti restano online (il PHP di ogni account si ferma per circa due decimi di secondo). Con l'installer: KOAPANEL_ISOLATION=1.
Disinstalla riporta il server com'era: tutti i siti tornano al PHP condiviso della loro versione, i limiti non valgono più.
Il modulo ha una sua versione, diversa da quella del pannello: la trovi in cima alla sua pagina, con l'elenco delle versioni e delle novità di ognuna (per esempio la 1.1.0 è arrivata con KoaPanel 0.28.0).
Ogni account usa in più circa 10 MB di memoria per il suo PHP (con 150 account, circa 1,5 GB); con PHP su richiesta solo gli account visitati di recente. Installare o disinstallare il modulo su un server con 150 account richiede un paio di minuti, e i siti restano online.
PHP su richiesta
Sui server con molti account visitati di rado conviene attivare PHP su richiesta (pagina del modulo): il PHP di un account parte alla prima visita e si ferma dopo 15 minuti senza richieste (si può cambiare), liberando la sua memoria. La prima pagina dopo una pausa aspetta il tempo di avvio, di solito meno di un decimo di secondo; nel frattempo le richieste restano in coda, nessuna va persa. Anche dopo un riavvio del server il PHP degli account parte solo quando serve. Attivarlo o disattivarlo ferma il PHP di ogni account per un istante.
I limiti
| Limite | Cosa vuol dire |
|---|---|
| CPU (%) | 100 = un core intero. Oltre, il PHP dell'account rallenta |
| Memoria (MB) | quando l'account arriva al limite il processo che esagera viene fermato (la sua pagina dà errore), gli altri continuano |
| Processi | processi e thread insieme: PHP, cron, WP-CLI |
| I/O (MB/s) | lettura e scrittura su ogni disco dei siti |
| Operazioni su disco (IOPS) | letture e scritture al secondo su ogni disco: frena chi fa tante piccole operazioni (cache su file, sessioni) anche senza muovere molti MB |
| Richieste PHP contemporanee | quante pagine PHP dell'account sono servite nello stesso momento, per tutti i suoi siti (gli entry processes di CloudLinux); le altre aspettano il loro turno invece di prendersi CPU e memoria del server. Conta i processi PHP: se un sito dell'account ne tiene occupati molti, gli altri suoi siti possono aspettare qualche secondo. Vale per ogni versione PHP usata dall'account |
| Connessioni al database | connessioni contemporanee di ogni utente MariaDB dei siti dell'account |
| CPU del database (%) | con il limitatore del database attivo: quanto lavora MariaDB per l'account (100 = un core, media di un minuto). Se lo supera, per 5 minuti ogni utente del database dell'account può aprire solo 2 connessioni: il database rallenta per quell'account e non per gli altri (come il MySQL Governor di CloudLinux) |
| Durata massima di una query (s) | con il limitatore del database attivo: una query che dura di più viene interrotta, e il sito riceve un errore per quella pagina |
| Email all'ora | con il limite delle email attivo: email che l'account può mandare in un'ora, dal PHP dei suoi siti (mail(), form di contatto, WooCommerce) e dalle sue caselle insieme. Oltre il limite l'account non può più inviare finché la sua ultima ora non torna sotto: le email già in coda partono, le nuove vengono rifiutate (predefinito 300) |
| File (cartelle comprese) | limite morbido, come lo spazio su disco: il conteggio si aggiorna ogni 15 minuti, al 90% arriva un'email al titolare e al rivenditore, oltre il limite non si creano nuovi siti. I siti esistenti continuano a funzionare |
0 vuol dire illimitato. I limiti di un account si decidono così, dal primo che c'è:
- sull'account (per esempio dalle opzioni del modulo WHMCS, o da Limiti e uso › Cambia i limiti);
- nel suo pacchetto (Pacchetti, sezione Risorse);
- i limiti predefiniti del server (pagina del modulo): 1 core, 1 GB, 200 processi, 50 MB/s, 1024 IOPS, 20 richieste PHP contemporanee, 20 connessioni, CPU del database 100%, query e file illimitati.
Se il modulo era già installato prima della versione 0.28, IOPS e richieste PHP contemporanee restano illimitati finché non li imposti tu: l'aggiornamento non cambia i limiti dei siti. Un client che manda solo alcuni limiti (per esempio il modulo WHMCS 1.2) lascia gli altri come sono.
Tutti questi limiti (memoria, I/O, CPU e gli altri) stanno nel pannello, non nei file di systemd o di PHP-FPM, che il pannello riscrive da questi valori. Gli aggiornamenti di KoaPanel li mantengono: dalla 0.88.0 i limiti predefiniti in uso vengono salvati nel pannello, quindi anche se una versione nuova cambia i suoi valori di partenza quelli del tuo server restano come sono. Una modifica fatta a mano nei file delle unità, invece, si perde.
I siti degli amministratori non hanno limiti. I limiti li decide solo l'amministratore del server; i rivenditori li vedono.
Limiti dei rivenditori
L'amministratore può dare a un rivenditore dei limiti complessivi (CPU, memoria, processi, disco e IOPS) per tutti i suoi account insieme, da Limiti e uso › Rivenditori › Cambia i limiti. Si aggiungono a quelli di ogni account: se gli account di un rivenditore insieme arrivano al tetto, rallentano solo loro, e gli account degli altri rivenditori e dell'amministratore non se ne accorgono. Senza limiti complessivi valgono solo quelli dei singoli account.
Un sito che supera i suoi limiti rallenta solo il proprio account: gli altri continuano come prima.
L'isolamento
Il PHP e i cron di ogni account vedono il sistema in sola lettura, nella cartella dei siti solo i propri siti (quelli degli altri account non ci sono proprio), una /tmp privata, nessuna cartella /home o /root e solo i propri processi. Si aggiunge ai controlli che il pannello fa già (utente separato per ogni sito, open_basedir, funzioni pericolose disattivate).
Rientrano nei limiti dell'account anche i cron dei suoi siti, WP-CLI, gli aggiornamenti di WordPress fatti dal pannello e la cache Redis di ogni sito.
Link simbolici e SFTP
Il server web segue un link simbolico solo se appartiene al proprietario del file a cui punta (come SecureLinks di CloudLinux): un sito non può pubblicare, con un link, i file di un altro sito, per esempio il suo wp-config.php. Dalla 0.78.2 è attiva su tutti i server, anche senza il modulo; si spegne dalla pagina del modulo (Protezione dei link simbolici).
Le sessioni SFTP di un sito hanno gli stessi limiti di CPU, memoria, processi e disco del suo account (ogni sessione separatamente), oltre a vedere solo la cartella del sito come già prima.
Limiti e uso
La pagina Limiti e uso mostra per ogni account l'uso di CPU, memoria, processi e disco (grafici delle ultime 24 ore e dei 30 giorni) e le volte in cui ha raggiunto un limite. Gli amministratori vedono tutti gli account, i rivenditori i propri account, ogni utente il proprio account.
Gli amministratori vedono in cima anche i Siti senza account: quelli dell'amministratore, che non hanno limiti di CPU e memoria e quindi non sono contati negli account (per esempio un sito migrato lasciando «Amministratore»). Scegli l'account e premi Assegna: il PHP del sito passa sotto i limiti di quell'account e da quel momento il sito compare nel suo uso. Per un utente nuovo crea prima l'account in Account.
Quando un account raggiunge i suoi limiti arriva un'email (al massimo una al giorno per account) agli amministratori e al suo rivenditore, e anche al titolare dell'account, con il marchio del rivenditore e il collegamento a Limiti e uso. L'email al titolare si spegne dalla pagina del modulo (Avvisi agli utenti). Se succede spesso il sito ha un problema (un plugin, un attacco, troppo traffico) oppure serve un pacchetto con più risorse.
Tempo reale
La scheda Tempo reale di Limiti e uso è come lvetop di CloudLinux: per ogni account l'uso degli ultimi secondi, aggiornato ogni 3 secondi finché la pagina è aperta (Pausa lo ferma). Le colonne sono CPU, memoria, processi, PHP (le richieste PHP servite in quel momento, contro il limite di richieste contemporanee), disco (MB al secondo letti e scritti) e IOPS; ogni valore ha la barra rispetto al limite dell'account, arancione dal 70% e rossa dal 90%. Nello stato compaiono «Al limite di CPU», «Al limite di memoria» o «Al limite di processi» quando l'account ci è arrivato in quei secondi.
Di norma si vedono solo gli account al lavoro; togli Solo gli account al lavoro per vederli tutti, cerca per nome o ordina per CPU, memoria, disco, processi o errori. Gli amministratori vedono in cima il server (carico, CPU, attesa del disco, memoria, disco più pieno) e la riga dei Siti senza account; i rivenditori vedono anche il totale dei loro account.
Un clic su un account apre i suoi processi con la CPU degli ultimi secondi, la memoria, da quanto tempo girano, il sito e il comando, e gli errori dei suoi siti; da lì si va alle Statistiche dell'account o al gestore dei processi per fermarne uno.
Errori dei siti
In fondo alla scheda Tempo reale ci sono i siti con errori negli ultimi 15 minuti, nell'ultima ora o nelle ultime 24 ore, letti dai log di nginx di ogni sito:
- Pagine non riuscite: le risposte 5xx (500 errore dello script, 502 PHP non ha risposto, 503 servizio non disponibile, 504 tempo scaduto, 508 limite di risorse raggiunto), su quante richieste;
- PHP occupato: PHP ha rifiutato la richiesta perché le richieste contemporanee dell'account erano tutte in uso (o PHP era fermo): è l'errore tipico di un account al limite;
- Tempo scaduto: PHP non ha risposto in tempo;
- Memoria PHP esaurita e Tempo PHP esaurito: uno script ha superato
memory_limitomax_execution_time(si alzano dalla pagina del sito, PHP); - altri errori fatali di PHP.
Per ogni sito c'è l'ultimo errore con l'ora e il pulsante Log, che apre i log completi del sito. Gli stessi errori compaiono sotto l'account quando lo apri; un sito con almeno 10 errori negli ultimi 15 minuti finisce anche negli avvisi della barra in alto.
Limitatore del database
È facoltativo e spento di norma: si attiva dalla pagina del modulo (Limitatore del database). Da acceso vale la durata massima delle query, si misura la CPU del database di ogni account e nei grafici c'è anche il database. Quando la CPU del database supera il limite, nella pagina compare «DB limitato» con l'ora in cui le connessioni tornano normali; conta come limite raggiunto. Per misurarlo il modulo attiva le statistiche per utente di MariaDB (userstat), e le spegne quando lo disattivi o disinstalli il modulo. Il limite di connessioni al database vale anche con il limitatore spento.
La scheda Classifica mette in ordine gli account degli ultimi 7 o 30 giorni: prima quelli che hanno raggiunto i limiti in più giorni, poi quelli che usano più CPU. Chi li ha raggiunti in 3 giorni o più ha l'etichetta «Pacchetto più grande».
Ogni lunedì mattina arriva il rapporto settimanale via email: agli amministratori con tutti gli account, a ogni rivenditore con i suoi account. Parte solo se qualche account ha raggiunto i limiti e si spegne dalla pagina del modulo.
I rivenditori vedono anche l'uso di tutti i loro account insieme rispetto ai loro limiti complessivi.
Limite delle email
È facoltativo e spento di norma: si attiva dalla pagina del modulo (Limite delle email) e serve il modulo Posta. Da acceso il pannello conta ogni minuto le email mandate da ogni account e, quando supera il suo limite all'ora, lo blocca: un sito bucato che manda spam si ferma lì e il server non finisce nelle liste nere. In Limiti e uso compare «Email bloccate» e c'è il grafico delle email inviate; arriva l'email dei limiti raggiunti. Il blocco si toglie da solo quando l'ultima ora torna sotto il limite. Resta anche il limite di 200 email all'ora per ogni casella del modulo Posta.
X-Ray: cosa rallenta un sito
Facoltativo e spento di norma (pagina del modulo, X-Ray siti lenti). Da acceso, per ogni pagina PHP che dura più dei secondi scelti (5 di norma) il PHP registra dove si trovava in quel momento. Nella pagina dell'account in Limiti e uso, per ogni sito, trovi il colpevole (il plugin o il tema di WordPress, il core, o il file), le funzioni più lente (database, chiamate esterne, attese) e gli script, con gli ultimi esempi. Si tengono 7 giorni.
Importare i limiti da CloudLinux
Nella migrazione via SSH da un server cPanel su CloudLinux, collegato come root, il pannello legge anche i limiti LVE di ogni account e li mostra accanto all'account. Con il modulo installato, un amministratore può spuntare Importa i limiti di CloudLinux: CPU (SPEED), RAM (PMEM), richieste PHP contemporanee (EP), processi (NPROC), I/O e IOPS diventano i limiti dell'account qui. Se porti più account in uno solo, vale il limite più alto di ognuno (illimitato vince). La velocità della CPU espressa in MHz non si importa.
Cosa non fa
Niente kernel modificato e niente selettori di versione per Ruby, Python o Node: copre PHP e WordPress, cioè quasi tutto l'hosting condiviso.