Cosa può causare l'arresto di TUTTI i servizi su un server, pur rispondendo al ping? e come capire

Mi è capitato già due volte in pochi giorni che il mio server si è completamente spento, ovvero http, ssh, ftp, dns, smtp, praticamente TUTTI i servizi smettono di rispondere, come se il server fosse stato spento, tranne che risponde ancora al ping , che è ciò che più mi sconcerta.

Ho alcuni script php che causano un carico enorme (CPU e memoria) sul server in brevi raffiche, usati da un piccolo gruppo di utenti, ma di solito il server "sopravvive" perfettamente bene a queste esplosioni, e quando scende non coincidono mai con tali picchi di utilizzo (non sto dicendo che non può essere correlato, ma non succede subito dopo quelli).

Non ti sto chiedendo di essere in grado di dirmi magicamente la causa ultima di questi arresti anomali, la mia domanda è: esiste un singolo processo la cui morte può causare la caduta simultanea di tutti questi servizi? La cosa divertente è che tutti i servizi di rete non funzionano, tranne il ping. Se il server avesse esaurito il 100% della CPU con qualche processo, non risponderebbe neanche al ping. Se apache si arrestasse in modo anomalo a causa (ad esempio) di uno script php rotto, ciò avrebbe effetto solo su http, non su ssh e dns .... ecc.

Il mio sistema operativo è Cent OS 5.6

Ancora più importante, dopo il riavvio forzato del server, quali log di sistema dovrei guardare? / var / log / messages non rivela nulla di sospetto.

centos service server-crashes

— Matteo
fonte

Risposte:

( tl; dr ancora rispondere al ping è un comportamento previsto, controlla l'utilizzo della memoria)

Le richieste di eco ICMP (ovvero ping) sono gestite dallo stack di rete nel kernel, senza altra dipendenza.

Il kernel è noto come "residente in memoria", il che significa che sarà sempre conservato nella RAM e non può essere scambiato su disco come fa una normale applicazione.

Ciò significa che in situazioni in cui si esauriscono le applicazioni di memoria fisica vengono scambiate su disco, ma il kernel rimane dove si trova. Quando sia la memoria fisica che quella di scambio sono piene (e il sistema non è in grado di gestire a lungo i programmi) la macchina cadrà. Tuttavia, poiché a) il kernel è ancora in memoria eb) può rispondere alle richieste di ping senza l'aiuto di altro, il sistema continuerà a rispondere al ping nonostante tutto sia morto.

Per quanto riguarda il tuo problema, sospetterei fortemente problemi di memoria. Installa "sysstat" e usa il comando "sar" per vedere un registro di memoria / cpu / load / io load ecc.

Vorrei anche considerare di guardare dmesg o / var / log / messages per qualsiasi segno del killer OOM (killer fuori memoria) che viene invocato. Questo è il sistema di emergenza del kernel che inizierà a uccidere i processi in caso di esaurimento della memoria. La sua efficacia dipende in gran parte da quali processi vengono uccisi. Un singolo processo che consuma la memoria verrà eliminato in modo efficiente e la memoria liberata, tuttavia un sito Web basato su apache genererà i processi di sostituzione non appena un processo figlio viene ucciso.

— Coops
fonte

+1 per OOM Killer

— HTTP500,

Grazie mille, sono quasi sicuro che questo sia il problema, poiché sia la RAM che lo swap erano pieni prima dell'errore del server. (Riesco a vedere le statistiche del manager di ovh). Ed è probabilmente alcuni dei miei pazzi script php che usano molta memoria. Mi rompono comunque per un paio di ragioni. (1) sembra che la memoria divorata da PHP non venga successivamente liberata, ma non avrebbe senso; (2) in ogni caso, non vorrei aspettare un sistema operativo adeguato a morire completamente solo a causa di una (o anche un paio) processi che utilizzano troppa memoria ... Mi aspetterei a

— matteo

rifiutare di allocare memoria per i programmi che la richiedono quando non c'è abbastanza RAM per il corretto funzionamento del sistema ... Voglio dire, un programma difettoso o addirittura dannoso non dovrebbe mai essere in grado di distruggere l'intero sistema ...

— matteo,

@matteo Linux ha quello che chiama "overcommit": solo perché malloc()1 GB di RAM non significa in realtà che lo userai, quindi il gestore della memoria tiene traccia di quanta memoria il tuo programma pensa abbia e di quanta memoria il il programma ha effettivamente utilizzato, e in realtà funziona bene, il più delle volte. Almeno, fino a quando più di un programma non vuole effettivamente utilizzare tutto il 1GB che pensa di avere.

— DerfK,

@matteo Non vedo alcuna indicazione che si tratti di un problema OOM. Tipicamente, il killer OOM sceglierà specifici o processi che soddisfano determinati criteri, ma non ucciderebbe sempre un demone come ssh. Questo è sicuramente dal lato I / O. Non hai spiegato la tua situazione hardware / specifiche come ho richiesto nella mia risposta.

— ewwhite,

Di solito, si tratta di un problema di I / O o del sottosistema del disco. Spesso, questo viene associato a una media di carico del sistema estremamente elevata. Ad esempio, il sistema dettagliato nel grafico seguente non rispondeva (ma era pingabile) quando uno script funzionava male, bloccava un mucchio di file e il carico saliva a 36 ... su un sistema a 4 CPU.

inserisci qui la descrizione dell'immagine

I servizi che sono in esecuzione nella RAM e non richiedono l'accesso al disco continuano a funzionare ... Pertanto, lo stack di rete (ping) è attivo, ma gli altri servizi si bloccano quando è necessario l'accesso al disco ... SSH quando si fa riferimento a una chiave o ricerca password richiesta. SMTP tende a spegnersi quando la media del carico raggiunge circa 30 ...

Quando il sistema è in questo stato, prova un telecomando nmapcontro l'IP del server per vedere cosa succede.

La registrazione probabilmente non funziona se si tratta di un problema di disco o di archiviazione ...

Puoi descrivere la configurazione dell'hardware? Questa è una macchina virtuale? Qual è il layout di archiviazione?

Più che registrazione, vuoi vedere se riesci a rappresentare graficamente le prestazioni del sistema e capire quando ciò accade. Vedi se questo è correlato a un'attività specifica.

— ewwhite
fonte

Supponendo che questo sia il problema, c'è un modo per dire a SSH di mantenere le password in memoria, quindi anche se il server è in questo stato potrei almeno essere in grado di accedere tramite ssh ed eseguire alcuni comandi per vedere cosa sta succedendo?

— matteo,

Se è I / O, è necessario arrivare alla fine del problema. Se si tratta di un timeout dell'array di dischi o dell'interazione del driver, è diverso da uno script che esegue male o da un problema di contesa di risorse.

— ewwhite,