Aposto que o sistema na verdade não "congelou" (no sentido de que o kernel estava travado), mas apenas não respondia. As chances são de estar apenas trocando muito, fazendo com que o desempenho interativo e o rendimento do sistema caiam como uma pedra.
Você poderia desativar o swap, mas isso apenas altera o problema de desempenho ruim para processos eliminados por OOM (e toda a diversão que isso causa), juntamente com desempenho reduzido devido ao cache de disco menos disponível.
Como alternativa, você pode usar limites de recursos por processo (normalmente chamados de rlimit e / ou ulimit ) para remover a possibilidade de um único processo, levando uma quantidade ridícula de memória e causando a troca, mas isso simplesmente avança você entreter território com processos que morrem em momentos inconvenientes porque eles queriam um pouco mais de memória do que o sistema estava disposto a dar a eles.
Se você soubesse que faria algo que provavelmente causaria uso massivo de memória, provavelmente poderia escrever um programa que fizesse um mlockall() e, em seguida, executasse seu shell; que o manteria na memória e seria a coisa mais próxima de "manter um núcleo responsivo" que você provavelmente obteria (porque não é que a CPU esteja sendo superutilizada, é esse o problema).
Pessoalmente, eu assino o método "não faça coisas estúpidas" de controle de recursos. Se você tem root, você pode causar todo tipo de dano a um sistema, e fazer qualquer coisa que você não conheça os resultados prováveis é um negócio arriscado.