Groups | Search | Server Info | Login | Register


Groups > linux.debian.user.catalan > #7994

Re: Memoria virtual o fitxers temporals

From Narcis Garcia <debianlists@actiu.net>
Newsgroups linux.debian.user.catalan
Subject Re: Memoria virtual o fitxers temporals
Date 2026-02-04 20:50 +0100
Message-ID <MkR2V-fJT2-5@gated-at.bofh.it> (permalink)
References <MjWo1-f8mU-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Gràcies Josep, he creat un fitxer Swap en una petita unitat SSD, i em 
sembla què resol prou.
Suposo què així el nucli Linux prioritza millor el què va a Swap i el 
què es queda en RAM (com la cache de fitxers).


El 2/2/26 a les 8:14, Josep Lladonosa ha escrit:
> Hola, Narcís,
> He demanat resposta a una amiga llestota (IA) ;-) :
> 
> 
> El que veus no és que Linux estigui fent “swap camuflada” amb arxius 
> temporals, sinó que quan vas molt just de RAM el nucli entra en un estat 
> de *thrashing* i fa moltíssima E/S a disc abans o en comptes d’activar 
> l’OOM killer, fins i tot sense cap partició de swap configurada.[1][2][3]
> 
> ## Què passa quan et quedes sense RAM
> 
> Quan la RAM s’omple, el nucli intenta recuperar memòria abans de matar 
> res:[1][2][3]
> - Descarta pàgines de cache de fitxers (lectures/escriptures addicionals).
> - Recarrega codi i dades que acaba de descartar quan un procés les torna 
> a necessitar.
> - Si tens *tmpfs* (per exemple `/tmp` a memòria), aquesta memòria 
> compiteix amb la resta i pot acabar pressionant més el sistema encara 
> que no tinguis swap.[4][5]
> 
> Això genera molta E/S a disc (relectura constant de fitxers, journaling, 
> log, etc.) i la màquina “s’amorra”, tot i que no hi ha cap swap activa. 
> [2][3]
> 
> El nucli *no* crea automàticament fitxers de swap ni converteix els 
> temporals en swap, però sí que els temporals en *tmpfs* “consumeixen 
> RAM” i, si hi hagués swap, es podrien buidar parcialment cap a swap.[4] 
> [6][5]
> 
> ## Com evitar-ho (o almenys controlar-ho)
> 
> Hi ha diverses estratègies; en la pràctica n’acabaràs combinant algunes:
> 
> - **Activar una mica de swap “d’emergència”** (fitxer, no cal partició) 
> amb `swappiness` molt baix (per exemple 1–10) perquè només s’utilitzi 
> quan ja vas al límit, i així evites el thrashing més salvatge.[1][7][2]
> - **Fer servir zram/zswap**: swap comprimit en RAM, molt ràpid, que et 
> dona un coixí addicional sense castigar tant el disc físic.[8][2]
> - **Configurar límits de memòria per procés** amb `systemd` 
> (`MemoryMax=`) o `ulimit` per a sessions interactives, de manera que un 
> procés “boig” mori abans de portar tot el sistema al límit.[1][2]
> - **Activar i conèixer les tecles Magic SysRq** (Alt+SysRq+f) per forçar 
> l’OOM killer quan vegis que la màquina s’està morint però encara tens 
> una mica de control.[2][9]
> - **Vigilar on poses /tmp o altres tmpfs**: si `/tmp` és *tmpfs* molt 
> gran, un programa que hi aboqui molts fitxers pot pressionar molt la 
> RAM; pots limitar-ne la mida o posar-lo en disc si no tens swap.[4][5]
> 
> ## Per què no veus clar qui és el culpable
> 
> Quan la màquina entra en thrashing, eines com `top` o `iotop` 
> pràcticament no responen o ho fan amb molt retard, i quan es recupera ja 
> s’han tancat processos i la situació ha canviat.
> Si vols diagnosticar-ho millor, pots:
> - Habilitar *logging* del `oom-killer` i revisar `dmesg` o `/var/log/ 
> kern.log` després de l’episodi.[1][3]
> - Deixar `iostat`, `pidstat` o `atop` en segon pla enregistrant dades 
> periòdicament per tenir un “històric” a revisar quan la màquina torni a 
> ser usable.[7][9]
> 
> En resum: no és que Linux faci swap amb temporals de forma oculta, sinó 
> que el seu comportament fora de memòria és bastant agressiu en E/S i, 
> sense un mínim de swap o límits, acaba en thrashing abans de matar 
> processos; posar una mica de swap “controlada” o zram i limitar 
> processos acostuma a ser la manera més efectiva de prevenir aquests 
> “amorraments”.[1][6][2]
> 
> Citations:
> [1] system freezes rather than invoking OOM killer. https:// 
> bbs.archlinux.org/viewtopic.php?id=233843 <https://bbs.archlinux.org/ 
> viewtopic.php?id=233843>
> [2] Why is Linux so bad at handling OOM scenarios? https:// 
> www.reddit.com/r/linuxquestions/comments/1fh3cjf/ 
> why_is_linux_so_bad_at_handling_oom_scenarios/ <https://www.reddit.com/ 
> r/linuxquestions/comments/1fh3cjf/ 
> why_is_linux_so_bad_at_handling_oom_scenarios/>
> [3] out of memory with no swap causes disk activity https:// 
> bbs.archlinux.org/viewtopic.php?id=48319 <https://bbs.archlinux.org/ 
> viewtopic.php?id=48319>
> [4] use swap when /tmp its out of space https://bbs.archlinux.org/ 
> viewtopic.php?id=151122 <https://bbs.archlinux.org/viewtopic.php?id=151122>
> [5] Correct location for temporary files, to save write endurance ... 
> https://discussion.fedoraproject.org/t/correct-location-for-temporary- 
> files-to-save-write-endurance-on-nvme/105072 <https:// 
> discussion.fedoraproject.org/t/correct-location-for-temporary-files-to- 
> save-write-endurance-on-nvme/105072>
> [6] Temporary files: RAM or disk? https://lwn.net/Articles/499645/ 
> <https://lwn.net/Articles/499645/>
> [7] System suddenly using all available swap, but plenty of free ... 
> https://discussion.fedoraproject.org/t/system-suddenly-using-all- 
> available-swap-but-plenty-of-free-memory/79411 <https:// 
> discussion.fedoraproject.org/t/system-suddenly-using-all-available-swap- 
> but-plenty-of-free-memory/79411>
> [8] the system is unusable on high disk io usage - openSUSE https:// 
> www.reddit.com/r/openSUSE/comments/nl3q5p/ 
> the_system_is_unusable_on_high_disk_io_usage/ <https://www.reddit.com/r/ 
> openSUSE/comments/nl3q5p/the_system_is_unusable_on_high_disk_io_usage/>
> [9] Linux oom behavior always has had complaints[0]. Hope it ... 
> https://news.ycombinator.com/item?id=26451319 <https:// 
> news.ycombinator.com/item?id=26451319>
> [10] How to fix high memory utilization caused by swap file in ... 
> https://www.facebook.com/groups/linuxforbeginners/posts/853503369795772/ 
> <https://www.facebook.com/groups/linuxforbeginners/posts/853503369795772/>
> 
> 
> --
> Salutacions...Josep
> --
> 
> El ds., 31 de gen. 2026, 18:51, Narcis Garcia <debianlists@actiu.net 
> <mailto:debianlists@actiu.net>> va escriure:
> 
>     Hola debianites;
> 
>     Tinc un ordinador amb suficient memòria RAM per a les tasques habituals.
>     No tinc configurada memòria d'intercanvi (swap) perquè prefereixo què,
>     si faig quelcom on l'ordinador es queda sense prou memòria, en comptes
>     d'amorrar-se amb el disc dur trenqui el procés o el sistema es queixi.
> 
>     Doncs resulta què quan carrego alguna cosa extraordinària i/o amb
>     moltes
>     aplicacions i dades obertes, el sistema s'amorra fent no-sé-què amb el
>     disc dur.
>     Quan es recupera la situació (perquè he aconseguit tancar finestres
>     lentament) ja és tard per a esbrinar què és el què està fent lectures o
>     escriptures a disc.
> 
>     Algú sap quina explicació té això?
>     Què potser el nucli Linux utilitza arxius temporals en comptes de Swap?
> 
>     I com ho puc evitar?
> 
>     Gràcies.
> 
>     -- 
> 
>     Narcis Garcia
> 
>     __________
>     I'm using this dedicated address because personal addresses aren't
>     masked enough at this mail public archive. Public archive administrator
>     should remove and omit any @, dot and mailto combinations against
>     automated addresses collectors.
> 

-- 

Narcis Garcia

__________
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should remove and omit any @, dot and mailto combinations against 
automated addresses collectors.

Back to linux.debian.user.catalan | Previous | NextPrevious in thread | Find similar


Thread

Memoria virtual o fitxers temporals Narcis Garcia <debianlists@actiu.net> - 2026-01-31 19:00 +0100
  Re: Memoria virtual o fitxers temporals Josep Lladonosa <jlladono@gmail.com> - 2026-02-02 08:20 +0100
    Re: Memoria virtual o fitxers temporals Narcis Garcia <debianlists@actiu.net> - 2026-02-04 20:50 +0100

csiph-web