Eu vou adivinhar aqui, levando em consideração a observação do OP de que o problema pode ser revertido alterando swappiness de volta para 60.
O kernel do Linux geralmente compromete a disponibilidade da memória. Se você reduzir swappiness , você diz para usar o espaço de troca em menor grau para a RAM que os programas precisam, como balanceado contra o uso da RAM para dados de arquivos armazenados em cache. Se você definir swappiness para 0, você solicitará que seu espaço de troca não seja usado.
No entanto, mesmo com swappiness de 0, o kernel do Linux alterará seu comportamento, uma vez que estima que está próximo de uma condição de "falta de memória". Antes disso, simplesmente não armazenará em cache nenhum dado de arquivo na RAM. Mas, uma vez que ele esteja ficando sem memória, ele mudará sua estratégia e usará qualquer área de troca disponível, apesar da configuração swappiness (a menos que certas condições especiais sejam aplicadas).
Você relata que vê esse fenômeno durante a inicialização. Esta é uma situação em que muitos processos são iniciados em paralelo, começam a analisar suas configurações, alocam memória sob demanda, etc.
Embora a alteração de swappiness de 60 tp 30 não altere o espaço total para execução, talvez isso mude a quantidade de memória que o kernel relata para estar disponível. Ou pode mudar o comportamento em relação ao momento em que a condição da OOM é determinada.
Então, se você tiver apenas memória RAM suficiente e swap para tudo o que vai começar, o efeito que você vê pode ser um comportamento infeliz quando o kernel transiciona de sobrescrever para realmente fornecer memeory, ou quando ele começa a acreditar que uma condição de falta de memória está se tornando mais provável. O código em vmscan.c por exemplo (responsável por liberar memória na RAM) abruptamente mude seu comportamento dependendo de tal mudança drástica de condições.