AI "Killed" by the Linux OOM-Killer? 🛑 Stop the silent assassination.

The 2-min protocol to fix AI crashes:
✅ Strict Mode: vm.overcommit_memory = 2
✅ Full Alloc: vm.overcommit_ratio = 100
✅ Docker Shield: --oom-kill-disable

Stop Cloud "Memory Ballooning." Get 100% Dedicated RAM on #ServerMO Bare Metal. 🏢⚡

Read the full protocol:
🔗 https://www.servermo.com/howto/stop-linux-oom-killer-ai-crash/

#AI #Linux #PyTorch #DevOps #BareMetal #SysAdmin #MachineLearning #OOMKiller #SelfHosted

#HomeAssistant with #ZHA in #Podman just crashed hard.

The #ConBee 2 stick restarted (probably due to Frigate #FFmpeg #OOMKiller), thus the ttyACM-path changed.
But that didn't exist anymore.
So ZHA stopped running.

Didn't get this to work reliably without --privileged … so HA now runs in a privileged Podman container with passed through /dev.

#Linux #AppArmor #Debian

Sentry noticed an issue with my app that Apple's crash reporting did not. The app used way too much memory in one view and got killed by iOS. Sentry gave me all the info I needed to find out what had happened and fix it. I had some real dumb stuff in a view containing a list where each item was pretty heavy. No issues as long as the number of items was low, but quickly got into huge numbers with more items. So, very happy with what Sentry can do.

#ios #oomkiller #sentry #saved #my #bacon

Ein #Nextcloud vServer mit 2GB RAM mit MariaDB, Redis und Php 8.2 macht kein Spaß.

Das erste was dann immer fliegen geht ist die #MariaDB .
Also doch ein Swap-File anlegen 😕

#oomKiller

Los mensajes de error en linux pueden ser algo fatalistas. Out of Memory, Sacrifice child puede sonar como sacrifiquen a los niños y no me sorprenderia llegar a esa conclusion si hay un proceso que juzga y asesina en caso de que escasee la memoria RAM.

Esto puede ser una lección sobre como las copias de respaldo pueden salvar vidas.

Tabla de Contenido

Introducción

Administrar un servidor propio es una buena forma de obtener practica y experiencia, por lo que he ido recopilando información sobre el tema como la vez en la que un sitio web de WordPress cayó por una actualización.

https://interlan.ec/2022/11/03/incidente-colapso-de-instalacion-de-wordpress-al-actualizar-jetpack/

Debido a diversas circunstancias, actualmente tengo dos instancias VPS de idénticas características, cada una destinada a diferentes propósitos que en la practica resultan difusos; una para experimentos, otra para servicios web persistentes(paginas, blogs, herramientas)

Yo no tengo experiencia administrando servidores de forma profesional, pero a medida que he ido aprendiendo cosas, he caído en cuenta de que es necesario tener tanto una IP publica, como un equipo permanentemente conectado a la red, para lograr algunas cosas así que he ido aprendiendo cosas nuevas vez tras vez. Algunas, a costa de todos mis datos almacenados.

La historia de hoy comienza con un error común, que he subestimado al pensar que no pasaría nada:

Este error se solucionaba simplemente reiniciando el servicio, pero esta vez, en lugar de encender el servicio, la respuesta fue esta:

Este error no me resultaba nuevo puesto que también es un error normal, pero resultaba inesperado debido a que al volver a intentar reiniciar el servidor, salía de nuevo el mismo error. Algo no estaba yendo bien.

Mi falta de experiencia me condujo a hacer lo mismo que incluso un profesional haría; buscar en Google.

Por supuesto, Google me respondió de la misma forma fatalista como lo haría con una persona preocupada por su salud, solo que en mi caso, todas las soluciones pasaban por borrar la base de datos por completo e iniciar de cero. Terror y depresión instantánea.

Dado que esa instancia la utilizo para hacer experimentos, no hay muchos datos que valgan la pena ahí. A lo mucho los Logs del sistema domótico y los del bot para descargar música, que en general solo es información estadística (que ya perdí en otro evento catastrófico anterior). El problema era que también cree una instancia de Nextcloud, especialmente complicada de mantener.

Entre practica y practica le había tomado cariño y agregando plugin, empecé a agregar datos que puedo rescatar sin problema alguno. Lo complicado era volver a configurar todo Nextcloud de cero.

Busque en los logs del sistema tratando de entender lo que sucedía, pero no he habilitado un log de archivo por parte del servicio. Por supuesto, la carpeta estaba vacía.

¡Out of Memory! ¡Sacrifiquen a los niños!

citando de la base de conocimientos de neo4j.com:

The Out Of Memory Killer or OOM Killer is a process that the linux kernel employs when the system is critically low on memory. This situation occurs because the linux kernel has over allocated memory to its processes.

El Asesino para liberar memoria u OOM Killer, es un proceso que el kernel de Linux emplea cuando el sistema esta críticamente bajo de memoria. Esta situación ocurre porque el kernel de Linux ha sobre asignado memoria a sus procesos.

Echándole un ojo al dmesg, encontré este mensaje:

Esta información solo confirmaba mis sospechas, pero seguía sin dar con una solución. Decidí entonces apagar todos los servicios para empezar a borrar los archivos como decían las instrucciones. Hasta que se me ocurrió intentar por ultima vez levantar el servicio de mysqld. ¡Y se levantó!

A salvo. ¿Ahora que?

No es la primera vez en la que mi servidor cae. Pero si es la primera en la que lo hace tras optimizarlo y mimarlo tanto, por lo que pensé que lo mejor seria realizar un respaldo regular de las bases de datos para empezar. ¿Pero donde?

• Es posible crear una tarea programada con CRON para extraer una copia de seguridad en el mismo servidor, pero ¿de que serviría si esta cae junto a el?

• Para empezar, de todas formas, comenzare haciendo una copia de seguridad local regular.

• Es posible, mediante SSH, crear una copia de seguridad en un equipo físico, también con CRON. Hacerlo de forma regular permite poder restaurar hasta algún punto en el que no haya arruinado algo al travesear con las configuraciones.

• Debo investigar si es posible utilizar otros servicios en la nube para crear respaldos. Tal vez Google Drive o OneDrive, puesto que tampoco tengo algo tan valioso como para pagar un servicio en la nube.

• Y por supuesto, Todos los respaldos deben ser automáticos. Hacerlo de forma manual es probablemente mas inseguro que no hacerlo.

Consideraciones

Por el momento estoy investigando como hacer respaldos regulares, Locales, pero regulares, utilizando el cliente de consola MySQL y el automatizado de procesos CRON. Y realmente me esta gustando CRON. No entiendo por que le tuve tanto miedo si ha sido tan fácil de usar. Aunque tengo que conceder que todo lo que se maneje por consola es aterrador y mas si es poco o nada intuitivo.