La vera domanda è:perché stai correndo senza swap? Soprattutto se riscontri (seri) problemi di prestazioni relativi all'esaurimento della RAM? Sai che non avere swap può effettivamente rallentare il tuo sistema, vero?
La soluzione più ovvia è aggiungere un po' di spazio di swap, e non lasciare che il tuo sistema ti caghi addosso. Considerando quanto sia economico lo spazio su disco, non riesco a pensare a nessuna situazione comune in cui dovresti mai costruire un sistema senza swap.
Per quanto riguarda la risposta alla tua domanda, non ricordo tutti i dettagli di basso livello sul perché lo scambio è importante anche su sistemi in cui non hai intenzione di esaurire la memoria, ma ci sono state discussioni sulla mailing list del kernel Linux sul fatto che è ragionevole eseguire sistemi senza swap (e non ci sono state molte risposte conclusive). Il consenso generale è in genere avere sempre swap , e regola lo swapiness secondo necessità.
Inoltre, penso che tu stia fraintendendo alcuni importanti avvertimenti riguardo al killer OOM di Linux. Prima di tutto, fare affidamento su di esso per gestire i tuoi problemi di memoria insufficiente è una pessima idea (tm). Può essere molto indiscriminato su ciò che uccide, ed è del tutto possibile che rimarrai con un sistema instabile o addirittura inutilizzabile. Sì, tenta di uccidere i processi recenti che consumano molta memoria (una piccola salvaguardia per cercare di catturare un processo in fuga), ma non ci sono garanzie. L'ho visto uccidere ssh, uccidere i processi Xen (su un server host virtuale Xen, causando l'arresto anomalo delle VM) e in un caso ha ucciso NFS.
Per quanto riguarda l'IO. . . Non so con certezza cosa potrebbe causarlo. Forse un filesystem o un processo relativo al disco è stato interrotto? Forse un processo ha una sorta di funzionalità "cache su disco" incorporata quando non è in grado di allocare memoria sufficiente?
Un'altra nota, se si tratta di un desktop, è necessario lo scambio per la sospensione su disco. Se si tratta di un server, affidarsi a OOM è mai una buona idea, in quanto compromette la stabilità per, beh, nessuna buona ragione.
[1] I sistemi incorporati rappresentano l'unica eccezione ovvia e non sono particolarmente comuni (e se hai a che fare con sistemi incorporati, sarai già a conoscenza dei requisiti).
Penso che AndreasM l'abbia colpito in testa (il motivo per cui il disco va tutto thrashy.) Gli eseguibili sono paginati su richiesta, quindi durante il normale funzionamento avrai quasi tutti i tuoi eseguibili e le librerie che si trovano nella buona vecchia RAM fisica. Ma quando la RAM si esaurisce, ma non abbastanza da consentire l'esecuzione del killer esaurito, queste pagine vengono rimosse dalla RAM. Quindi ti ritrovi in una situazione in cui le pagine vengono rimosse:all'inizio, nessun problema, perché vengono rimosse prima utilizzate meno di recente e vengono espulse le pagine che non stai utilizzando comunque. Ma poi, elimina quelli che sei utilizzando, solo per doverli richiamare subito indietro in pochi istanti dopo. Città thrash.
Fondamentalmente, se qualcosa utilizzasse solo un po' più di RAM, probabilmente avresti l'effetto di OOM killer, ma non eri ancora lì. Come alcuni hanno detto, OOM killer è indiscriminato, è davvero più un'ultima risorsa per evitare un panico del kernel che qualcosa che dovresti considerare di usare nel normale funzionamento. Se disponi di una configurazione personalizzata, prenderei in considerazione l'idea di scrivere un demone per monitorare la memoria libera e uccidere utilizzando la politica di tua scelta quando si avvicina al pieno.