La ejecución de cualquier comando devuelve "No se puede asignar memoria" en Ubuntu Server

16

Estoy usando Ubuntu 14.04. Recientemente, cuando inicio sesión a través de SSH con mi usuario con privilegios de sudo, cada comando que ejecuto da como resultado un error de "No se puede asignar memoria". Aquí hay algunos que probé en mi consola

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

Incluso si lo intento sudo reboot now, aparece el error anterior, así que no sé qué más puedo intentar desbloquear mi instancia. El host es DigitalOcean si eso importa.

Editar: Por la respuesta / sugerencia dada aquí es la salida de "gratis"

myuser@mymachine:~$ free
-bash: fork: Cannot allocate memory
server bash ram reboot memory-usage Dave
fuente

Respuestas:

12

Solución

Como dice en los mensajes de error, su máquina se ha quedado sin memoria. Esto puede ser por varias razones, pero básicamente, algo está consumiendo toda su memoria y no deja nada ni siquiera para el uso de comandos básicos.

Te sugiero que reinicies tu gotita (solo ve al panel de control de tu cliente y selecciona "Reiniciar"), sshy luego ejecuta topo htop. Vigile el uso de la memoria y vea qué proceso está utilizando toda la memoria. A partir de ahí, intente

  1. Matar / Eliminar el programa / proceso defectuoso

    ADVERTENCIA : ¡ Por favor , investigue si el proceso es un proceso esencial del sistema, primero! Si un proceso del sistema está causando problemas de memoria, no solo lo mate, investigue y busque formas específicas de tratarlo.
  2. Cambiando la configuración de ese programa / proceso para que no consuma toda tu memoria.

Sugerencias para evitar que el problema vuelva a ocurrir

  • Algo bueno para hacer es agregar memoria de intercambio , ya que asigna más memoria si se está quedando sin.
  • Siempre que instales programas, asegúrate de configurarlos correctamente para que no funcionen de manera no deseada (como consumir memoria)
  • Después de cada vez que agrega un paquete o básicamente se configura algo nuevo, verifique con htopotop para ver cuánta memoria está usando con los programas actuales. Si nota que está utilizando casi todo, intente eliminar algunos revisando y eliminando programas / procesos innecesarios.
  • Si hay algo que se está iniciando automáticamente (¡además de los procesos del sistema, por supuesto!) Que no reconoce o no desea que se inicie automáticamente, ¡elimínelo! Pero siempre investigue qué es un proceso antes de eliminarlo / eliminarlo, ya que podría ser esencial para los procedimientos de arranque o las funciones del sistema, etc.
TheOdd
fuente
7

Para salir de esta condición sin reiniciar, puede activar el asesino OOM manualmente de la siguiente manera:

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

Referencia

Luke F
fuente
¿Tiene alguna documentación que respalde esos comandos? ¿Por qué no solo sudo sysctl -w vm.oom_kill_allocating_task=1o permanentemente encendido/etc/sysctl.conf ?
Pablo Bianchi
1
No parece que eso haga una diferencia, el sistema no alcanza una condición OOM real si esto sucede en reposo porque ningún proceso está tratando de asignar memoria y no se pueden iniciar procesos adicionales. Y no está relacionado, pero no podrás usar sudo o sysctl una vez en este estado.
Luke F
Esto funcionó para mí. No sé cómo, no me importa. Ni siquiera podía correr sudo rebootantes de ejecutar esto. ¡Gracias!
boulder_ruby
0

Para completar la respuesta aceptada, hay una cosa adicional a tener en cuenta: su sistema puede quedarse sin identificadores de archivos o incluso buffers de zócalo y aún así tiene mucha memoria mientras da el mismo error. Esto es especialmente cierto si el alojamiento compartido impone límites de tal naturaleza. En los sistemas OpenVZ, mire el contenido de

# cat / proc / user_beancounters

Esto le dará en la columna de la derecha los primeros excesos. Si esto es cierto, muévase a un paquete de alojamiento más grande o busque al culpable más probable: la base de datos mysql o mariadb que puede, en presencia de una aplicación PHP defectuosa, filtrar los archivos a cientos por segundo.

Esto también puede suceder si su servidor web tiene ssh abierto a Internet y acepta inicios de sesión de nombre de usuario / contraseña: incluso si tiene el funcionamiento de fail2ban, puede haber atraído un intento de interrupción del diccionario distribuido que también consume muchos recursos.

aquaherd
fuente