Se hai svolto il lavoro di amministratore di sistema abbastanza a lungo, hai visto i temuti incidenti "Il server è lento". Per molto tempo, questo tipo di incidenti mi farebbe venire un buco nello stomaco. Come diavolo fai a risolvere qualcosa di così soggettivo? Il "lento" di un utente di tutti i giorni potrebbe essere causato semplicemente da altri processi (programmati o meno) che eseguono e consumano più risorse del solito, oppure qualcosa potrebbe effettivamente non funzionare nel server.
Quando ho iniziato a lavorare come amministratore di sistema, rispondevo immediatamente con:"Ho bisogno di maggiori informazioni su questo". Bene, di solito l'utente non è in grado di fornire ulteriori informazioni, perché non sa cosa sta succedendo dietro le quinte o come spiegare cosa sta vedendo a parte "è solo lento". Al giorno d'oggi, prima ancora di rispondere all'utente, controllo alcune cose.
Accesso iniziale
C'è molto che puoi dire accedendo all'host. Puoi accedere a tutti? L'accesso è lento o è sospeso? Il ssh il comando ha tre livelli di debug, ognuno dei quali ti fornisce una miriade di informazioni prima ancora che tu sia sul sistema. Per abilitare il debug, aggiungi un ulteriore v al -v opzione. Ad esempio, un debug di livello tre, che è quello che uso esclusivamente, sarebbe:
[~]$ ssh -vvv hostname.domain.com
I "Big 3" (ovvero CPU, RAM e I/O su disco)
Ora, diamo un'occhiata alle tre principali cause di rallentamento del server:CPU, RAM e I/O del disco. L'utilizzo della CPU può causare una lentezza generale sull'host e difficoltà a completare le attività in modo tempestivo. Alcuni strumenti che utilizzo quando guardo la CPU sono top e sar .
Controllo dell'utilizzo della CPU con top
La top l'utilità ti dà uno sguardo in tempo reale su cosa sta succedendo con il server. Per impostazione predefinita, quando top si avvia, mostra l'attività per tutte le CPU:
Questa visualizzazione può essere modificata premendo il tasto numerico 1, che aggiunge maggiori dettagli sui valori di utilizzo per ciascuna CPU:
Alcune cose da cercare in questa visualizzazione sarebbero la media del carico (visualizzata sul lato destro della riga superiore) e il valore di quanto segue per ciascuna CPU:
us:questa percentuale rappresenta la quantità di CPU consumata dai processi utente.sy:questa percentuale rappresenta la quantità di CPU consumata dai processi di sistema.id:questa percentuale rappresenta il livello di inattività di ciascuna CPU.
Ognuno di questi tre valori può darti un'idea abbastanza buona e in tempo reale del fatto che le CPU siano vincolate dai processi dell'utente o dai processi di sistema.
Per spiegare veramente la media del carico sarebbe necessario un articolo a sé stante. Ai fini di questo articolo, parlerò in generale. I tre valori medi di carico da sinistra a destra rappresentano medie di un minuto, cinque minuti e 15 minuti. Di nuovo, parlando molto in genere, se vedi che la media di un minuto supera il numero di CPU fisiche che hai, è molto probabile che il sistema sia vincolato alla CPU.
Nota: Per ulteriori informazioni sulla media del carico e sul motivo per cui alcune persone pensano che sia un numero sciocco, dai un'occhiata alla ricerca approfondita di Brendan Gregg.
Controllo tutti i "Big 3" con sar
Per i dati storici sulle prestazioni della CPU mi affido a sar comando, fornito da sysstat pacchetto. Sulla maggior parte delle versioni server di Linux, sysstat è installato per impostazione predefinita, ma in caso contrario, puoi aggiungerlo con il gestore pacchetti della tua distribuzione. Il sar l'utilità raccoglie i dati di sistema ogni 10 minuti tramite un lavoro cron situato in /etc/cron.d/sysstat (CentOS 7.6). Ecco come controllare tutti i "3 grandi" utilizzando sar .
Nota: Se hai appena installato sar per seguire questo articolo, dai al comando un po' di tempo per registrare prima i dati.
Il comando sar -u fornisce informazioni su tutte le CPU del sistema, a partire da mezzanotte:
Come con top , le cose principali da controllare qui sono %user , %system , %iowait e %idle . Queste informazioni possono dirti da quanto tempo il server ha avuto problemi.
Nel complesso, il sar comando può fornire molte informazioni. Poiché questo articolo spiega solo un rapido controllo di ciò che sta accadendo sul server, dai un'occhiata a man sar per analizzare ulteriormente queste informazioni.
Per controllare le prestazioni della RAM, utilizzo sar -r , che ti danno l'utilizzo della memoria di quel giorno:
La cosa principale da cercare nell'utilizzo della RAM è %memused e %commit . Una breve parola sul %commit campo:questo campo può mostrare oltre il 100% poiché il kernel Linux esegue regolarmente un overcommit della RAM. Se %commit è costantemente superiore al 100%, questo risultato potrebbe essere un indicatore del fatto che il sistema ha bisogno di più RAM.
Per le prestazioni di I/O del disco, utilizzo sar -d , che fornisce l'output di I/O del disco utilizzando solo il nome del dispositivo. Per ottenere il nome dei dispositivi, utilizzare sar -dP :
Per questo output, guardando %util e %await ti darà un buon quadro generale dell'I/O del disco sul sistema. Il %util campo è abbastanza autoesplicativo:è l'utilizzo di quel dispositivo. Il await contiene la quantità di tempo che l'I/O trascorre nello scheduler. L'attesa è misurata in millisecondi e, nel mio ambiente, ho visto che qualsiasi cosa maggiore di 50 ms inizia a causare problemi. Tale soglia può variare nel tuo ambiente.
Se uno di questi comandi mostra un problema, puoi tornare indietro per vedere quando i problemi del server sono iniziati usando sar {-u, -r, -d, -dP} -f /var/log/sa/sa<XX> (dove XX è il giorno del mese che desideri cercare).
A questo punto, di solito ho una buona idea di cosa sta succedendo attualmente sul server e cosa è successo nelle ultime 48 ore circa. Risponderò all'utente con risposte più informate. Ad esempio:"Non vedo alcuna indicazione di lentezza dell'host nelle ultime 24 ore. Prova a utilizzare un nuovo profilo di stucco per ssh e fammi sapere se continui ad avere problemi."
Un altro esempio:"Al momento non vedo nulla che causi problemi su questo host, ma ho notato un carico maggiore della CPU $time . È stato allora che hai visto dei problemi? In tal caso, prova ora e fammi sapere se continui a riscontrare problemi."
Ti viene l'idea. Avere le informazioni fornite guardando il login iniziale e quindi eseguendo alcuni sar i comandi, che generalmente richiedono meno di 10 minuti per essere eseguiti, fanno molto per evitare più domande e raggiungere una risoluzione più velocemente.