L'esecuzione di qualsiasi comando restituisce "Impossibile allocare memoria" su Ubuntu Server


16

Sto usando Ubuntu 14.04. Di recente, quando eseguo l'accesso tramite SSH con il mio utente con privilegi sudo, ogni comando che eseguo genera un errore "Impossibile allocare memoria". Eccone alcuni che ho provato sulla mia console

myuser@mymachine:~$ whoami
-bash: fork: Cannot allocate memory
myuser@mymachine:~$ uname -a
-bash: fork: Cannot allocate memory

Anche se provo sudo reboot nowottengo l'errore sopra riportato, quindi non so cos'altro posso provare a sbloccare la mia istanza. L'host è DigitalOcean se questo è importante.

Modifica: per la risposta / suggerimento dato qui è l'output di "gratuito"

myuser@mymachine:~$ free
-bash: fork: Cannot allocate memory

Risposte:


12

Soluzione

Come indicato nei messaggi di errore, la macchina ha esaurito la memoria. Questo può essere per una serie di ragioni, ma fondamentalmente qualcosa sta divorando tutta la tua memoria e non ne lascia alcuna per un utilizzo dei comandi di base.

Suggerirei di riavviare il droplet (basta andare sul pannello di controllo del client e selezionare "Riavvia"), sshin e quindi eseguire topo htop. Tieni d'occhio l'utilizzo della memoria e vedi quale processo sta utilizzando tutta la memoria. Da lì, prova entrambi

  1. Killing / Rimozione del programma / processo difettoso

    AVVERTENZA : PER FAVORE, fai le tue ricerche se il processo è un processo di sistema essenziale, prima! Se un processo di sistema sta causando problemi di memoria, non limitarti a ucciderlo, fai delle ricerche su di esso e cerca modi specifici per gestirlo.
  2. Modifica della configurazione per quel programma / processo in modo che non consumi tutta la tua memoria.

Suggerimenti per evitare che il problema si ripeta

  • Qualcosa di buono da fare è aggiungere memoria di swap , poiché alloca più memoria se si sta esaurendo.
  • Ogni volta che installi programmi, assicurati di configurarli correttamente in modo che non funzionino in modo involontario (come consumare memoria)
  • Dopo ogni volta che aggiungi un pacchetto o fondamentalmente qualcosa di nuovo è configurato, controlla con htopo topper vedere quanta memoria stai usando con i programmi attuali. Se noti che stai usando quasi tutto, prova a chiarire alcuni passaggi e rimuovendo programmi / processi non necessari.
  • Se c'è qualcosa che viene avviato automaticamente (oltre ai processi di sistema, ovviamente!) Che non riconosci o che desideri avviare automaticamente, rimuovilo! Ma fai sempre la tua ricerca su cosa sia un processo prima di ucciderlo / eliminarlo, poiché potrebbe essere essenziale per le procedure di avvio o le funzioni di sistema, ecc.

7

Per uscire da questa condizione senza riavviare, è possibile attivare manualmente il killer OOM come segue:

echo 1 > /proc/sys/kernel/sysrq
echo f > /proc/sysrq-trigger
echo 0 > /proc/sys/kernel/sysrq

Riferimento


Hai qualche documentazione a supporto di questi comandi? Perché non solo sudo sysctl -w vm.oom_kill_allocating_task=1o permanentemente acceso/etc/sysctl.conf .
Pablo Bianchi,

1
Non sembra che farebbe la differenza, il sistema non raggiunge una condizione OOM effettiva se ciò accade a riposo perché nessun processo sta tentando di allocare memoria e non è possibile avviare processi aggiuntivi. E semi-indipendente, ma non saresti in grado di usare sudo o sysctl una volta in questo stato.
Luke F,

Questo ha funzionato per me. Non so come, non importa. Non ero nemmeno in grado di correre sudo rebootprima di eseguire questo. Grazie!
boulder_ruby,

0

A completamento della risposta accettata c'è un'altra cosa da considerare: il tuo sistema potrebbe esaurire gli handle di file o persino i buffer dei socket e avere ancora molta memoria pur dando lo stesso errore. Ciò è particolarmente vero se l'hosting condiviso impone limiti di tale natura. Sui sistemi OpenVZ, guarda il contenuto di

# cat / proc / user_beancounters

Questo ti darà nella colonna più a destra i primi superamenti. Se questo è vero, passa a un pacchetto di hosting più grande o dai la caccia al colpevole più probabile: il database mysql o mariadb che, in presenza di un'app PHP difettosa, può gestire il file con perdite a centinaia al secondo.

Questo può accadere anche se il tuo server web ha ssh aperto su Internet e accetta accessi con nome utente / password: anche se hai fail2ban in esecuzione, potresti aver attirato un tentativo di interruzione del dizionario distribuito che consuma anche molte risorse.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.