La verdadera pregunta es, ¿por qué se está ejecutando sin intercambio? ¿Especialmente si está viendo problemas de rendimiento (graves) relacionados con quedarse sin RAM? Sabes que no tener intercambio puede hacer que tu sistema sea más lento, ¿verdad?
La solución obvia es agregar algo de espacio de intercambio y no dejar que su sistema se deshaga de usted. Teniendo en cuenta lo barato que es el espacio en disco, no puedo pensar en ninguna situación común en la que debas nunca construir un sistema sin intercambio.
En cuanto a responder a su pregunta, no recuerdo todos los detalles de bajo nivel sobre por qué el intercambio es importante incluso en sistemas en los que no va a agotar la memoria, pero ha habido argumentos en la lista de correo del Kernel de Linux sobre si es razonable ejecutar sistemas sin intercambio (y no ha habido muchas respuestas concluyentes). El consenso general suele ser siempre tener swap y ajuste el intercambio según sea necesario.
Además, creo que está malinterpretando algunas advertencias importantes con respecto al asesino OOM de Linux. En primer lugar, confiar en él para manejar sus problemas de falta de memoria es una muy mala idea (tm). Puede ser muy indiscriminado sobre lo que mata, y es muy posible que te quedes con un sistema inestable o incluso inutilizable. Sí, intenta eliminar los procesos recientes que consumen mucha memoria (una protección menor para tratar de detectar un proceso que se escapa), pero no hay garantías. Lo he visto eliminar ssh, eliminar procesos Xen (en un servidor host virtual Xen, lo que hace que las máquinas virtuales se bloqueen) y, en un caso, eliminó NFS.
En cuanto al IO. . . No sé a ciencia cierta qué podría estar causando. ¿Quizás se eliminó un sistema de archivos o un proceso relacionado con el disco? ¿Quizás un proceso tiene algún tipo de funcionalidad de "caché a disco" incorporada cuando no puede asignar suficiente memoria?
Otra nota, si se trata de un escritorio, se requiere intercambio para Suspender a disco. Si es un servidor, confiar en OOM es nunca una buena idea, ya que compromete la estabilidad por, bueno, ninguna buena razón.
[1] Los sistemas integrados son la única excepción obvia, y no son particularmente comunes (y si se trata de sistemas integrados, ya conocerá los requisitos).
Creo que AndreasM lo ha golpeado en la cabeza (la razón por la que el disco se vuelve loco). Los ejecutables se paginan bajo demanda, por lo que en el funcionamiento normal tendrá casi todos sus ejecutables y bibliotecas en una buena memoria RAM física. Pero cuando la memoria RAM se agota, pero no lo suficiente como para que se ejecute el asesino de falta de memoria, estas páginas se desalojan de la memoria RAM. Así que terminas con una situación en la que las páginas son desalojadas; al principio, no hay problema, porque primero son desalojadas las menos usadas recientemente y se eliminan las páginas que no estás usando de todos modos. Pero luego, expulsa a los que eres usando, solo para tener que volver a paginarlos momentos después. Thrash ciudad.
Básicamente, si algo usara un poco más de RAM, probablemente tendrías el asesino OOM activado, pero aún no estabas allí. Como algunos han dicho, OOM killer es indiscriminado, en realidad es más un último recurso para evitar un kernel panic que algo que debería considerar usar en el funcionamiento normal. Si tiene alguna configuración personalizada, consideraría escribir algún demonio para monitorear la memoria libre y matar usando la política de su elección cuando se acerque al máximo.