Problemen met swap

[Cecil Westerhof]

Ik denk dat er problemen met mijn swap implementatie zijn. Als ik
bijvoorbeeld firefox afsluit, wat meestal erg veel swap gebruikt,
duurt dat heel erg lang. Vaak zo lang dat firefox crasht.
Op een ander systeem (met vergelijkbare installatie) heb ik wat dingen
getest.
Hier gaf 'free -h':
total used free shared buff/cache available
Mem: 7.6Gi 3.3Gi 1.3Gi 517Mi 3.0Gi 3.5Gi
Swap: 7.8Gi 1.2Gi 6.6Gi

En swapon gaf:
NAME TYPE SIZE USED PRIO
/dev/sda6 partition 7.8G 1.2G -2

Er was genoeg vrij geheugen, dus ik deed 'time swapoff /dev/sda6'.
Dit gaf:
real 0m18.287s
user 0m0.005s
sys 0m2.219s

Dit lijkt mij buitengewoon lang te duren.
Maar het werd nog interessanter. Toen ik weer een 'free -h' gaf, kreeg
ik:
total used free shared buff/cache available
Mem: 7.6Gi 2.4Gi 2.1Gi 524Mi 3.0Gi 4.3Gi
Swap: 0B 0B 0B

Het lijkt alsof swap geheugen kost i.p.v. vrij te geven. 🙀

Wat zou hier aan de hand kunnen zijn?

Dit is op een Debian 11 systeem.

[Eric Vissers]

Post by Cecil Westerhof
Ik denk dat er problemen met mijn swap implementatie zijn. Als ik
bijvoorbeeld firefox afsluit, wat meestal erg veel swap gebruikt,
duurt dat heel erg lang. Vaak zo lang dat firefox crasht.
Op een ander systeem (met vergelijkbare installatie) heb ik wat dingen
getest.

Firefox is niet het meest snelle programma. En maakt voor ieder tabblad
een apart process aan (veiliger?). Wat draait er nog meer op dat
systeem. Als er bijvoorbeeld ook nog een document wordt bewerkt in
LibreOffice en er draait ook nog een mailprogramma en weet ik wat nog
meer, en op het andere systeem niet, zou dat een verklaring kunnen zijn.

Post by Cecil Westerhof
total used free shared buff/cache available
Mem: 7.6Gi 3.3Gi 1.3Gi 517Mi 3.0Gi 3.5Gi
Swap: 7.8Gi 1.2Gi 6.6Gi
NAME TYPE SIZE USED PRIO
/dev/sda6 partition 7.8G 1.2G -2

De swap heeft een lagere prior, misschien was dit een programma wat op
de achtergrond op iets stond te wachten op input en door de kernel uit
de ram naar de swap is gezet.

Post by Cecil Westerhof
Er was genoeg vrij geheugen, dus ik deed 'time swapoff /dev/sda6'.
real 0m18.287s
user 0m0.005s
sys 0m2.219s
Dit lijkt mij buitengewoon lang te duren.

Het programma time meet alleen het commando wat daar achter uitgevoerd
wordt. Dit is geen nuttige informatie bij deze casus. Het geeft alleen
aan dat het 18.287s heeft gekost om wat in de swap zat terug te kopiëren
naar het geheugen.

Post by Cecil Westerhof
Maar het werd nog interessanter. Toen ik weer een 'free -h' gaf, kreeg
total used free shared buff/cache available
Mem: 7.6Gi 2.4Gi 2.1Gi 524Mi 3.0Gi 4.3Gi
Swap: 0B 0B 0B
Het lijkt alsof swap geheugen kost i.p.v. vrij te geven. 🙀

Inderdaad raar, waar wanneer is de eerste free -h gedraaid? En wanneer
de tweede? Wat is er, behalve de swapoff tussen in de tussentijd met het
systeem gebeurd?

Post by Cecil Westerhof
Wat zou hier aan de hand kunnen zijn?

Er zou een kapotte geheugen module kunnen zijn.

Hoe vol is de harde schijf? Een 'df -hl -t ext4' zou dat moeten laten
zin. Als bestandssysteem een andere is dan ext4 deze vervangen door dat
bestandssysteem.

Post by Cecil Westerhof
Dit is op een Debian 11 systeem.

[Cecil Westerhof]

Post by Eric Vissers

Post by Cecil Westerhof
Ik denk dat er problemen met mijn swap implementatie zijn. Als ik
bijvoorbeeld firefox afsluit, wat meestal erg veel swap gebruikt,
duurt dat heel erg lang. Vaak zo lang dat firefox crasht.
Op een ander systeem (met vergelijkbare installatie) heb ik wat dingen
getest.

Firefox is niet het meest snelle programma. En maakt voor ieder tabblad
een apart process aan (veiliger?). Wat draait er nog meer op dat
systeem. Als er bijvoorbeeld ook nog een document wordt bewerkt in
LibreOffice en er draait ook nog een mailprogramma en weet ik wat nog
meer, en op het andere systeem niet, zou dat een verklaring kunnen zijn.

Ik weet dat firefox forse problemen geeft. Eet het meeste geheugen en
processortijd en wil load average ook fors omhoog gooien.
Maar ik heb het vermoeden dat er ook iets met swap aan de hand is. Ik
heb daar in het verleden rare dingen mee gezien. Maar omdat vaak mijn
swap gebruik hoger is dan vrij geheugen kan ik het daar op het
ogenblik niet testen, heb ik i.i.g. het swap gedeelte uit willen
zoeken.

Post by Eric Vissers

Post by Cecil Westerhof
total used free shared buff/cache available
Mem: 7.6Gi 3.3Gi 1.3Gi 517Mi 3.0Gi 3.5Gi
Swap: 7.8Gi 1.2Gi 6.6Gi
NAME TYPE SIZE USED PRIO
/dev/sda6 partition 7.8G 1.2G -2

De swap heeft een lagere prior, misschien was dit een programma wat op
de achtergrond op iets stond te wachten op input en door de kernel uit
de ram naar de swap is gezet.

Mijn probleem is niet het gebruik van swap, maar de hoeveelheid tijd
het kost om het terug te kopieren naar ram.

Post by Eric Vissers

Post by Cecil Westerhof
Er was genoeg vrij geheugen, dus ik deed 'time swapoff /dev/sda6'.
real 0m18.287s
user 0m0.005s
sys 0m2.219s
Dit lijkt mij buitengewoon lang te duren.

Achttien seconden om 1,2 GB van swap naar RAM te brengen lijkt me
buitengewoon lang.

Post by Eric Vissers
Het programma time meet alleen het commando wat daar achter uitgevoerd
wordt. Dit is geen nuttige informatie bij deze casus. Het geeft alleen
aan dat het 18.287s heeft gekost om wat in de swap zat terug te kopiëren
naar het geheugen.

Ja en dat lijkt mij dus ontzettend lang.

Post by Eric Vissers

Post by Cecil Westerhof
Maar het werd nog interessanter. Toen ik weer een 'free -h' gaf, kreeg
total used free shared buff/cache available
Mem: 7.6Gi 2.4Gi 2.1Gi 524Mi 3.0Gi 4.3Gi
Swap: 0B 0B 0B
Het lijkt alsof swap geheugen kost i.p.v. vrij te geven. 🙀

Inderdaad raar, waar wanneer is de eerste free -h gedraaid? En wanneer
de tweede? Wat is er, behalve de swapoff tussen in de tussentijd met het
systeem gebeurd?

Een 'free -hw' meteen gevolgd door de swapoff meteen gevolgd door een
'free -hw'.

Post by Eric Vissers

Post by Cecil Westerhof
Wat zou hier aan de hand kunnen zijn?

Er zou een kapotte geheugen module kunnen zijn.
Hoe vol is de harde schijf? Een 'df -hl -t ext4' zou dat moeten laten
zin. Als bestandssysteem een andere is dan ext4 deze vervangen door dat
bestandssysteem.

Hoogste gebruik is /var met 36%
En swap heeft een eigen partitie.

[Oscar]

Post by Eric Vissers

Post by Cecil Westerhof
Wat zou hier aan de hand kunnen zijn?

Er zou een kapotte geheugen module kunnen zijn.

Uhm.. nee. Dat geeft hele andere problemen.

[Oscar]

Post by Eric Vissers
Als bestandssysteem een andere is dan ext4 deze vervangen door dat
bestandssysteem.

Ik gebruik ZFS, een bestandssysteem systeem dat veel geheugen kost.
Toch ga ik echt nooit terug naar ext4. Wat is dat voor een advies?

[Eric Vissers]

Op Tue, 5 Sep 2023 07:09:06 -0000 (UTC)

Post by Oscar

Post by Eric Vissers
Als bestandssysteem een andere is dan ext4 deze vervangen door dat
bestandssysteem.

Ik gebruik ZFS, een bestandssysteem systeem dat veel geheugen kost.
Toch ga ik echt nooit terug naar ext4. Wat is dat voor een advies?

Dat was gewoon een voorbeeld. Het kan zijn dat je hdd vol is. Zelf
gebruik ik ext4 en daar wordt standaard 5% gereserveerd voor root.

[Paul van der Vlis]

Post by Cecil Westerhof
Ik denk dat er problemen met mijn swap implementatie zijn. Als ik
bijvoorbeeld firefox afsluit, wat meestal erg veel swap gebruikt,
duurt dat heel erg lang. Vaak zo lang dat firefox crasht.
Op een ander systeem (met vergelijkbare installatie) heb ik wat dingen
getest.
total used free shared buff/cache available
Mem: 7.6Gi 3.3Gi 1.3Gi 517Mi 3.0Gi 3.5Gi
Swap: 7.8Gi 1.2Gi 6.6Gi
NAME TYPE SIZE USED PRIO
/dev/sda6 partition 7.8G 1.2G -2
Er was genoeg vrij geheugen, dus ik deed 'time swapoff /dev/sda6'.
real 0m18.287s
user 0m0.005s
sys 0m2.219s
Dit lijkt mij buitengewoon lang te duren.
Maar het werd nog interessanter. Toen ik weer een 'free -h' gaf, kreeg
total used free shared buff/cache available
Mem: 7.6Gi 2.4Gi 2.1Gi 524Mi 3.0Gi 4.3Gi
Swap: 0B 0B 0B
Het lijkt alsof swap geheugen kost i.p.v. vrij te geven. 🙀
Wat zou hier aan de hand kunnen zijn?
Dit is op een Debian 11 systeem.

Misschien vind je mijn gegevens interessant, ook Debian 11.
-----------
***@laptopp:~# free -h
total used free shared buff/cache
available
Mem: 7,7Gi 2,5Gi 2,9Gi 1,2Gi 2,3Gi
3,6Gi
Swap: 11Gi 3,0Gi 8,7Gi
***@laptopp:~# time swapoff -a

real 0m36,897s
user 0m0,000s
sys 0m3,647s
***@laptopp:~# free -h
total used free shared buff/cache
available
Mem: 7,7Gi 4,0Gi 694Mi 1,9Gi 2,9Gi
1,3Gi
Swap: 0B 0B 0B
***@laptopp:~#
-----------

Groet,
Paul

[Cecil Westerhof]

Post by Paul van der Vlis

Post by Cecil Westerhof
Ik denk dat er problemen met mijn swap implementatie zijn. Als ik
bijvoorbeeld firefox afsluit, wat meestal erg veel swap gebruikt,
duurt dat heel erg lang. Vaak zo lang dat firefox crasht.
Op een ander systeem (met vergelijkbare installatie) heb ik wat dingen
getest.
total used free shared buff/cache available
Mem: 7.6Gi 3.3Gi 1.3Gi 517Mi 3.0Gi 3.5Gi
Swap: 7.8Gi 1.2Gi 6.6Gi
NAME TYPE SIZE USED PRIO
/dev/sda6 partition 7.8G 1.2G -2
Er was genoeg vrij geheugen, dus ik deed 'time swapoff /dev/sda6'.
real 0m18.287s
user 0m0.005s
sys 0m2.219s
Dit lijkt mij buitengewoon lang te duren.
Maar het werd nog interessanter. Toen ik weer een 'free -h' gaf, kreeg
total used free shared buff/cache available
Mem: 7.6Gi 2.4Gi 2.1Gi 524Mi 3.0Gi 4.3Gi
Swap: 0B 0B 0B
Het lijkt alsof swap geheugen kost i.p.v. vrij te geven. 🙀
Wat zou hier aan de hand kunnen zijn?
Dit is op een Debian 11 systeem.

Misschien vind je mijn gegevens interessant, ook Debian 11.
-----------
total used free shared buff/cache
available
Mem: 7,7Gi 2,5Gi 2,9Gi 1,2Gi 2,3Gi
3,6Gi
Swap: 11Gi 3,0Gi 8,7Gi
real 0m36,897s
user 0m0,000s
sys 0m3,647s
total used free shared buff/cache
available
Mem: 7,7Gi 4,0Gi 694Mi 1,9Gi 2,9Gi
1,3Gi
Swap: 0B 0B 0B
-----------

Hm, interessant. Dan zou je zeggen dat mijn resultaat helemaal niet
bizar waren. Het leek mij extreem lang te duren, maar dat is het
blijkbaar niet. Tenzij we beiden hetzelfde probleem hebben. ;-) Maar
dat lijkt me niet erg waarschijnlijk.

Met 2,9 GB vrij geheugen en 3,0 GB swap zou ik geen swapoff hebben
gedaan.

[Paul van der Vlis]

Post by Cecil Westerhof

Post by Paul van der Vlis

Post by Cecil Westerhof
Ik denk dat er problemen met mijn swap implementatie zijn. Als ik
bijvoorbeeld firefox afsluit, wat meestal erg veel swap gebruikt,
duurt dat heel erg lang. Vaak zo lang dat firefox crasht.
Op een ander systeem (met vergelijkbare installatie) heb ik wat dingen
getest.
total used free shared buff/cache available
Mem: 7.6Gi 3.3Gi 1.3Gi 517Mi 3.0Gi 3.5Gi
Swap: 7.8Gi 1.2Gi 6.6Gi
NAME TYPE SIZE USED PRIO
/dev/sda6 partition 7.8G 1.2G -2
Er was genoeg vrij geheugen, dus ik deed 'time swapoff /dev/sda6'.
real 0m18.287s
user 0m0.005s
sys 0m2.219s
Dit lijkt mij buitengewoon lang te duren.
Maar het werd nog interessanter. Toen ik weer een 'free -h' gaf, kreeg
total used free shared buff/cache available
Mem: 7.6Gi 2.4Gi 2.1Gi 524Mi 3.0Gi 4.3Gi
Swap: 0B 0B 0B
Het lijkt alsof swap geheugen kost i.p.v. vrij te geven. 🙀
Wat zou hier aan de hand kunnen zijn?
Dit is op een Debian 11 systeem.

Misschien vind je mijn gegevens interessant, ook Debian 11.
-----------
total used free shared buff/cache
available
Mem: 7,7Gi 2,5Gi 2,9Gi 1,2Gi 2,3Gi
3,6Gi
Swap: 11Gi 3,0Gi 8,7Gi
real 0m36,897s
user 0m0,000s
sys 0m3,647s
total used free shared buff/cache
available
Mem: 7,7Gi 4,0Gi 694Mi 1,9Gi 2,9Gi
1,3Gi
Swap: 0B 0B 0B
-----------

Hm, interessant. Dan zou je zeggen dat mijn resultaat helemaal niet
bizar waren. Het leek mij extreem lang te duren, maar dat is het
blijkbaar niet. Tenzij we beiden hetzelfde probleem hebben. ;-) Maar
dat lijkt me niet erg waarschijnlijk.

Bij stond hij al lang aan, en veel open in Firefox.

Post by Cecil Westerhof
Met 2,9 GB vrij geheugen en 3,0 GB swap zou ik geen swapoff hebben
gedaan.

Een groot deel was buff/cache. Volgens mij kan het dan geen kwaad.

Verder doet swapoff het niet als het niet lukt volgens mij.

Groet,
Paul

[Cecil Westerhof]

Post by Paul van der Vlis

Post by Cecil Westerhof

Post by Paul van der Vlis

Post by Cecil Westerhof
Ik denk dat er problemen met mijn swap implementatie zijn. Als ik
bijvoorbeeld firefox afsluit, wat meestal erg veel swap gebruikt,
duurt dat heel erg lang. Vaak zo lang dat firefox crasht.
Op een ander systeem (met vergelijkbare installatie) heb ik wat dingen
getest.
total used free shared buff/cache available
Mem: 7.6Gi 3.3Gi 1.3Gi 517Mi 3.0Gi 3.5Gi
Swap: 7.8Gi 1.2Gi 6.6Gi
NAME TYPE SIZE USED PRIO
/dev/sda6 partition 7.8G 1.2G -2
Er was genoeg vrij geheugen, dus ik deed 'time swapoff /dev/sda6'.
real 0m18.287s
user 0m0.005s
sys 0m2.219s
Dit lijkt mij buitengewoon lang te duren.
Maar het werd nog interessanter. Toen ik weer een 'free -h' gaf, kreeg
total used free shared buff/cache available
Mem: 7.6Gi 2.4Gi 2.1Gi 524Mi 3.0Gi 4.3Gi
Swap: 0B 0B 0B
Het lijkt alsof swap geheugen kost i.p.v. vrij te geven. 🙀
Wat zou hier aan de hand kunnen zijn?
Dit is op een Debian 11 systeem.

Misschien vind je mijn gegevens interessant, ook Debian 11.
-----------
total used free shared buff/cache
available
Mem: 7,7Gi 2,5Gi 2,9Gi 1,2Gi 2,3Gi
3,6Gi
Swap: 11Gi 3,0Gi 8,7Gi
real 0m36,897s
user 0m0,000s
sys 0m3,647s
total used free shared buff/cache
available
Mem: 7,7Gi 4,0Gi 694Mi 1,9Gi 2,9Gi
1,3Gi
Swap: 0B 0B 0B
-----------

Hm, interessant. Dan zou je zeggen dat mijn resultaat helemaal niet
bizar waren. Het leek mij extreem lang te duren, maar dat is het
blijkbaar niet. Tenzij we beiden hetzelfde probleem hebben. ;-) Maar
dat lijkt me niet erg waarschijnlijk.

Bij stond hij al lang aan, en veel open in Firefox.

Zelfde bij mij. Maar dat zou naar mijn menig geen invloed moeten
hebben: met swapoff zou gewoon dingen die in swap staan terug gezet
moeten worden in het geheugen. Wat relatief snel zou moeten gebeuren.
Of zie ik weer eens iets over het hoofd?

Post by Paul van der Vlis

Post by Cecil Westerhof
Met 2,9 GB vrij geheugen en 3,0 GB swap zou ik geen swapoff hebben
gedaan.

Een groot deel was buff/cache. Volgens mij kan het dan geen kwaad.

Zoals ik het heb begrepen is niet alles wat in buff/cache vrij te
geven en zou je je moeten baseren op wat free zegt.

Post by Paul van der Vlis
Verder doet swapoff het niet als het niet lukt volgens mij.

Ik ben misschien wat te voorzichtig, maar ik zou een GB meer vrij
willen hebben dan op swap staat.

[Oscar]

Post by Paul van der Vlis
Verder doet swapoff het niet als het niet lukt volgens mij.

Jawel hoor. Er worden vanzelf een paar processen gekilled, net zolang
tot het wel lukt. Kijk eens in je dmesg of de OOM-Killer bezig is geweest.

Misschien ook wel een idee voor Cecil. Staan er rare dingen in de output
van 'dmesg -Tk' of 'journalctl -t kernel' ?

[Cecil Westerhof]

Post by Oscar

Post by Paul van der Vlis
Verder doet swapoff het niet als het niet lukt volgens mij.

Jawel hoor. Er worden vanzelf een paar processen gekilled, net zolang
tot het wel lukt. Kijk eens in je dmesg of de OOM-Killer bezig is geweest.

Dan was het goed dat ik paranoïde was. ;-)

Post by Oscar
Misschien ook wel een idee voor Cecil. Staan er rare dingen in de output
van 'dmesg -Tk' of 'journalctl -t kernel' ?

Als ik weer een swapoff kan doen zal ik eens kijken. Op het ogenblik
meer dan een GB op swap dan vrij geheugen.

[Paul van der Vlis]

Post by Oscar

Post by Paul van der Vlis
Verder doet swapoff het niet als het niet lukt volgens mij.

Jawel hoor. Er worden vanzelf een paar processen gekilled, net zolang
tot het wel lukt. Kijk eens in je dmesg of de OOM-Killer bezig is geweest.

Er is geen OOM-killer bezig geweest bij mij.

Het is mij vaker gebeurd dat swapoff het niet deed.

Groet,
Paul

Post by Oscar
Misschien ook wel een idee voor Cecil. Staan er rare dingen in de output
van 'dmesg -Tk' of 'journalctl -t kernel' ?

[Oscar]

Post by Cecil Westerhof
total used free shared buff/cache available
Mem: 7.6Gi 3.3Gi 1.3Gi 517Mi 3.0Gi 3.5Gi
Swap: 7.8Gi 1.2Gi 6.6Gi

[...]

Post by Cecil Westerhof
total used free shared buff/cache available
Mem: 7.6Gi 2.4Gi 2.1Gi 524Mi 3.0Gi 4.3Gi
Swap: 0B 0B 0B
Het lijkt alsof swap geheugen kost i.p.v. vrij te geven. 🙀

Of er is iets gestopt in de tussentijd.

Post by Cecil Westerhof
Wat zou hier aan de hand kunnen zijn?

Geen idee. Is dit reproduceerbaar?

Doe anders eens:

ps auxfw > ps-before.txt; swapoff -a; ps auxfw > ps-after.txt

en dan: vimdiff ps-before.txt ps-after.txt

Je mag ipv van vimdiff ook een andere side-by-side editor pakken. Maar
je kan dan mooi zien wat er allemaal geheugen gebruikt voor en na de
aktie.

In plaats van 'ps auxfw' kun je misschien beter dit gebruiken:
ps x -o pid,vsz,rss,size,command --sort rss

Voor de betekenis van die kolommen, zie man ps. Je kan zo wat inzicht
krijgen in het geheugengebruik van een proces. Grofweg: VSZ is de
hoeveelheid geheugen dat een proces gevraagd, maar mogelijk nog niet
gebruikt heeft. RSS is het werkelijke RAM-gebruik, zonder het deel wat
in swap zit. SIZE is ruwweg RSS+Swap.

[Cecil Westerhof]

Post by Oscar

Post by Cecil Westerhof
total used free shared buff/cache available
Mem: 7.6Gi 3.3Gi 1.3Gi 517Mi 3.0Gi 3.5Gi
Swap: 7.8Gi 1.2Gi 6.6Gi

[...]

Post by Cecil Westerhof
total used free shared buff/cache available
Mem: 7.6Gi 2.4Gi 2.1Gi 524Mi 3.0Gi 4.3Gi
Swap: 0B 0B 0B
Het lijkt alsof swap geheugen kost i.p.v. vrij te geven. 🙀

Of er is iets gestopt in de tussentijd.

Lijkt me niet erg waarschijnlijk (er zat heel weinig tijd tussen de
free's), maar je weet het maar nooit.

Post by Oscar

Post by Cecil Westerhof
Wat zou hier aan de hand kunnen zijn?

Geen idee. Is dit reproduceerbaar?

Dit heb ik voor zover ik me kan herinneren nooit eerder gehad. En ook
niet opnieuw. Maar ik was heel erg verbaasd toen het gebeurde.

Post by Oscar
ps auxfw > ps-before.txt; swapoff -a; ps auxfw > ps-after.txt
en dan: vimdiff ps-before.txt ps-after.txt
Je mag ipv van vimdiff ook een andere side-by-side editor pakken. Maar
je kan dan mooi zien wat er allemaal geheugen gebruikt voor en na de
aktie.
ps x -o pid,vsz,rss,size,command --sort rss
Voor de betekenis van die kolommen, zie man ps. Je kan zo wat inzicht
krijgen in het geheugengebruik van een proces. Grofweg: VSZ is de
hoeveelheid geheugen dat een proces gevraagd, maar mogelijk nog niet
gebruikt heeft. RSS is het werkelijke RAM-gebruik, zonder het deel wat
in swap zit. SIZE is ruwweg RSS+Swap.

Bedankt voor het huiswerk. Ik ga ermee aan de slag zodra ik een
swapoff kan doen.

[Cecil Westerhof]

Post by Cecil Westerhof
Ik denk dat er problemen met mijn swap implementatie zijn. Als ik
bijvoorbeeld firefox afsluit, wat meestal erg veel swap gebruikt,
duurt dat heel erg lang. Vaak zo lang dat firefox crasht.
Op een ander systeem (met vergelijkbare installatie) heb ik wat dingen
getest.
total used free shared buff/cache available
Mem: 7.6Gi 3.3Gi 1.3Gi 517Mi 3.0Gi 3.5Gi
Swap: 7.8Gi 1.2Gi 6.6Gi
NAME TYPE SIZE USED PRIO
/dev/sda6 partition 7.8G 1.2G -2
Er was genoeg vrij geheugen, dus ik deed 'time swapoff /dev/sda6'.
real 0m18.287s
user 0m0.005s
sys 0m2.219s

Dit zou op zich nog kunnen kloppen, maar ik heb nu een situatie die
volgens mij wel een probleem is op het originele systeem.

In /etc/fstab staat:
/dev/mapper/HDVG-swap none swap sw,pr=10 0 0
/home/swapfile none swap sw,pr=5 0 0

swapon gaf:
NAME TYPE SIZE USED PRIO
/dev/dm-4 partition 9.3G 4G -2
/home/swapfile file 32G 0B -3

Na een 'swapoff /dev/dm-4' gaf swapon:
NAME TYPE SIZE USED PRIO
/home/swapfile file 32G 440K -2

Maar de benodigde tijd was schrikbarend:
real 16m3.74s
user 0m0.00s
sys 0m23.27s
perc 2.41

Het was wel zo dat firefox een 2,3 GB van die swap voor zijn rekening
nam. En firefox met swap lijkt rare resultaten te geven.

Met dmesg en journalctl zag ik dat de laatste kernel messages bijna
een week oud waren. Dus op kernel niveau gaat er niets fout.