Swap of death.. Går det att få linux att swappa lika effektivt som windows??... Linux fryser sig vid swappning

Permalänk
Medlem

har ni generellt problem med swap eller FireFox oavsett Dist??

jag har för ca 5 år sedan haft ett liknade problem, men då gick jag ned till 32bit OS från 64bit OS på en Linux MINT maskin, som sendan hade samma problem på en Linux Fedora i 64bit versionen, å den datorn var inte direkt gammal för att CPUn skulle orsaka det.

men sedan dess har jag inte haft sånna problem på någon Linux dist.

Visa signatur

|Workstation: AMD Ryzen 9 7900X 4.7GHz | ASRock X670E | AMD Radeon 7900 XT | 32GB DDR5 | NVMe 2.0TB | HDD 4.0TB |
|Fedora Srv VM Host: AMD Threadripper 2920x | ASUS PRIME X399-A | 24GB DDR4 | 10TB Storage |
|HTPC: AMD Ryzen 3 2200G 3.7 GHz | Gigabyte B450M DS3H | Radeon Vega 8 | 8GB RAM | SSD 120GB | *Test rig för div Linux distar, drivers m.m.

Permalänk
Medlem

provade du att använda ett addon som inaktiverar oanvända tabbar? det drar ner ram-användandet rejält för mig i alla fall

Visa signatur

"Det här systemet fungerar urkasst." - operatör.
"Hur ska det fungera då?" - jag
"Gör så att det fungerar som jag vill." - operatör.
/facepalm

Permalänk
Medlem
Skrivet av anon309108:

Okej... jaa, jag har efterforskat lite om detta problem och typ alla människor oavsett engelsktalande forum eller svenska tar enklaste lösningen att gå runt problemet istället för att lösa problemet. Som jag förstått är detta en 14år gammal bugg i kerneln tydligen.
Det är en smått intressant inställning många här i världen har att se på problem...varför lösa problemet/buggen när man kan köpa mer ram och SSD hårddiskar och skjuta på problemet något år till o sedan köpa mer o mer o mer.. *hihi*

.

Jag är jäkligt trött idag efter en hård vecka.. så jag ska svara på alla andra inlägg så fort jag kan..
Se om vi här inne på sweclockers kan lösa världsproblemet som gäckat linuxvärlden såååå länge.
Jag är ingen programmerare och jag är ingen linux expert.. men jag är ganska bra på research.

Se det från den andra sidan: Varför lösa ett problem som eventuellt tar väldigt många arbetstimmar att lösa istället för att bara uppgradera en (förhållandevis) billig komponent.

Permalänk

Det finns en separat kernel patch, UKSM, som scannar igenom ram för att hitta minnessidor ("pages") som är likadana och slår ihop dem.
Testade det för ca 2 år sedan och det sparade ca 150 MB som mest för mig men jag har aldrig många flikar öppna och startar om datorn dagligen.

https://github.com/dolohow/uksm

Länk, versaler
Permalänk
Inaktiv
Skrivet av Otur:

provade du att använda ett addon som inaktiverar oanvända tabbar? det drar ner ram-användandet rejält för mig i alla fall

Jag ägnade ettpar dagar med att läsa på och sedan dressera firefox så det inte är en sådan extrem "memory hog" som det är känt för och jag lyckades. Jag kör det nu på min ena bärbara för att utvärdera för o nackdelar med de moddarna.

Men på test maskinen är det helt orört för att problemet ska uppstå, då jag vill försöka se om det går att hitta en lösning på swap death fenomenet.
Det vore ju kul om man kan lösa det.

Permalänk
Inaktiv
Skrivet av WDac:

har ni generellt problem med swap eller FireFox oavsett Dist??

jag har för ca 5 år sedan haft ett liknade problem, men då gick jag ned till 32bit OS från 64bit OS på en Linux MINT maskin, som sendan hade samma problem på en Linux Fedora i 64bit versionen, å den datorn var inte direkt gammal för att CPUn skulle orsaka det.

men sedan dess har jag inte haft sånna problem på någon Linux dist.

För min del så har fenomenet uppstått på flera olika distar och på olika datorer... dock är det mer sällsynt att det uppstår ju mer Ram minne som finns.. som de även talat om i flertalet av de länkar som jag postade.
Jag läste att fenomenet vart mer förekommande på 64bitars än vad det var på 32bitars, så det verkar vara en markant skillnad, dock har jag inte listat ut vad o varför.

Permalänk
Inaktiv
Skrivet av Chrisj:

Se det från den andra sidan: Varför lösa ett problem som eventuellt tar väldigt många arbetstimmar att lösa istället för att bara uppgradera en (förhållandevis) billig komponent.

Precis.. men det är ju så med mycket här i världen... problemlösningar är ofta enklaste vägen.. kan man kringgå problemet så är det latare/lättare än att lösa problem. sådant ser man på daglig basis i politiken och på arbetsplatser, biltillverkning osv,

Jag ser det så här..
Om man kan lösa detta fenomenet så är det miljövänligt.. Man kan återanvända gammal hårdvara och man kan sänka idioti-konsumtionen.
Men även ur annat perspektiv... det finns miljontals människor runt om i världen som lever i fattigdom.. de kan inte köpa nya datorer utan övertar gamla från bekanta osv... om de då kan gynnas, så varför inte?

Problemlösning är kul för vissa här i världen och det är det som gynnar många människor och det driver även utveckling framåt.
Jag är långtidssjukskriven och jag har väldigt många arbetstimmar att offra. Så varför inte lixom... samt jag lär mig väldigt mycket om linux på kuppen.

och ni får underhållande läsning här på sweclockers då jag bjussar på alla mina tabbar o okunskap. *hahaha*

Permalänk
Inaktiv
Skrivet av FattarNiInte:

Det finns en separat kernel patch, UKSM, som scannar igenom ram för att hitta minnessidor ("pages") som är likadana och slår ihop dem.
Testade det för ca 2 år sedan och det sparade ca 150 MB som mest för mig men jag har aldrig många flikar öppna och startar om datorn dagligen.

https://github.com/dolohow/uksm

Nice Den ska jag kika på..

Permalänk
Inaktiv

Liten uppdatering..
Skiten bråkar inte.

Så för att utesluta att inte sista FF versionen fått någon memoryhog buggfix så startar jag om från noll med nyinstallation av LMDE och jag tar en äldre FF version som jag vet är minneshungrig och jag börjar med noll tweaks för att först återskapa swap idiotin.

Utan några moddar och FF har jag about:config inaktiverat disk.cache och så lyckades jag få fenomenet att uppstå.
Nu har jag aktiverat disk cache på swap partitionen och ska belasta systemet igen.. sedan ska jag testa att aktivera zswap efter nästa lockup.. osv osv.

Har ni förslag på minneskrävande program så jag kan skapa fenomenet snabbare än att surfa i FF i två dagar.

Permalänk
Medlem
Skrivet av anon309108:

Har ni förslag på minneskrävande program så jag kan skapa fenomenet snabbare än att surfa i FF i två dagar.

Från en av buggrapporterna du länkade fanns en som använt programmet "stress", jag använde det när jag testade tidigare. Du kan hitta det i paketsystemet. I en terminal kan du sen skriva t.ex.:

stress --vm 2 --vm-bytes 2G --vm-keep

så skapas två processer som allokerar 2 Gigg vardera, och ligger och accessar minnet om och om igen som jag förstod mansidan. Ctrl-C avbryter. Jag startade ett par sådana och fyllde det sista från firefox.

Du kan också begränsa minnet vid boot, beroende på hur bekväm du är med att redigera kernelns kommandorad inifrån grub-menyn. Kernel-argumentet heter "mem=...". Men använda stress är nog enklare.

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX

Permalänk
Medlem

Det görs arbeten på kernel hela tiden och man bör nog vara hyfsat i frontlinjen med kernversioner för att se om saker har blivit bättre - bl.a görs det stora insatser på filsystemet BTRFS där det har blivit markanta skillnader gentemot äldre kärn-versioner i avseende tung disk-access och stallningstedenser mm.

De senaste versionerna ligger idag på 5.10.1 sist jag kollade på https://www.kernel.org/

mycket för att man inte skall sitta och jaga fel på äldre kernel och OS-versioner som ändå kommer att fasas ut inom inte allt för lång framtid..

Till detta kan det vara skillnad i swap-hantering om de går direkt på en partition för swap på disken eller om det går igenom filsystemet på en fil för swap - idag så föredrar man ofta bara det senare med swap på fil i många distributioner och struntar att allokera en dedicerad swap-partition när man installerar en Linux-distrubition på en disk.

Permalänk
Medlem

Jag kollade tidigare igenom diskussionen från kernel-mejllistan, som i sin tur länkades från phoronix.

https://lkml.org/lkml/2019/8/4/15

I den diskussionen verkar de vara överens om att det handlar om att minnet är på gränsen i något avseende - antingen nästan slut, eller att working set (det minne som accessas hela tiden och därför inte meningsfullt kan swappas ut) har fyllt hela fysiska minnet (oavsett om det finns swaputrymme kvar eller inte).

Problemen för TS uppstår innan swap är full, vilket tyder på att det handlar om att working set är större än RAM. Det är troligen så att firefox låter script mm i inaktiva flikar köra vidare, så länge fliken är öppen, vilket stämmer med vad jag kunnat se på mitt eget system. Javascript t.ex. pausar inte för att jag växlar till en annan flik. Det kan också förklara varför TS upplever mer problem på 64bit system än på 32bit - då väldigt mycket körs i tolkade skripspråk typ javascript, som inte kräver att programmeraren funderar på storlek på numeriska variabler mm. Jag vore inte förvånad om samma Javascript-kod kräver mer minne på 64bit system.

Lösningen som diskuteras på mejllistan är följaktligen hur de ska få OOM-killer att sparka in lite tidigare, innan systemet fryser. Men då blir frågan återigen vilket problem som egentligen ska lösas - är du @anon309108 nöjd med en lösning som innebär 1) att innehåll i en slumpmässig flik dödas när minnet börjar bli fullt, så att du märker att det är dags att sluta fylla fler flikar? För det är vad kernel-folket tycks se som lösningen på problemet. Eller var du mer ute efter 2) att kunna jobba vidare med samma belastning, t.ex. genom att försöka nyttja swap bättre? I det senare fallet så ligger nog hela lösningen med Firefox, troligen genom plugin eller dylikt som pausar innehåll i inaktiva flikar, så att de sedan kan swappas ut. Förutsatt att detta alls är möjligt.

Om min gissning om problemet är korrekt, så är det inte kostigt att du får thrashing, det är ju det förväntade beteendet av ett system som försöker ha ett större working set än det finns fysisk RAM. Jag känner mest igen det från Windows9X-tiden, då man räknade RAM i Mb. Jag har också svårt att tro att moderna Windows-versioner skulle klara det bättre. Du skrev innan att det fungerat bättre för dig på Windows, men jag undrar om det har med minneshanteringen att göra. Kan det vara så att du haft mindre igång då? Det kan ju också vara skillnader i webläsarens implementation, kan hända att 40 flikar på Windows tar lika mycket minne som 50 flikar på Linux, eller så.

En annan möjlighet är att Windows gör något annat som får gränssnittet att krokna i en långsammare takt, så att du märker tidigare att minnet är på väg att ta slut och mer eller mindre medvetet anpassar ditt användande. T.ex. genom att tidigare börja swappa ut minnessegment som accessas "lagom" ofta, och börjar småthrasha lite s.a.s. Medan Linux försöker jobba så effektivt som möjligt tills minnet är helt slut. Jag skulle tro att detta är vad kernel-folket föredrar, varför de nog vill se en lösning baserad på en aggressivare OOM-killer.

Jag kan ha fel i mina gissningar, men jag tycker förklaringen verkar rimlig. Från desktop-användar-perspektivet så skulle man då vilja ha en något tidigare varning att minnet håller på att ta slut, så att man varken behöver döda processer slumpvis eller hamna i en oändlig thrashing-loop. Bäst vore kanske ett explicit meddelande av något slag, som man kan välja att ignorera.

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX

Permalänk
Inaktiv
Skrivet av Oegat:

Från en av buggrapporterna du länkade fanns en som använt programmet "stress", jag använde det när jag testade tidigare. Du kan hitta det i paketsystemet. I en terminal kan du sen skriva t.ex.:

stress --vm 2 --vm-bytes 2G --vm-keep

så skapas två processer som allokerar 2 Gigg vardera, och ligger och accessar minnet om och om igen som jag förstod mansidan. Ctrl-C avbryter. Jag startade ett par sådana och fyllde det sista från firefox.

Du kan också begränsa minnet vid boot, beroende på hur bekväm du är med att redigera kernelns kommandorad inifrån grub-menyn. Kernel-argumentet heter "mem=...". Men använda stress är nog enklare.

Tackar för tipset
Jag kan stoppa in en 1GB modul i datorn om jag vill det, men jag tänkte använda 4GB då det var standard på win7 OEM datorer som finns ett överflöd av i folks "garderober".. Det kan skapa en marknad för de med dålig ekonomi och återanvändning av saker istället för att kasta dem på tippen eller ha som brevpressar
Sedan finns det sådana där konstiga människor, som mig exempelvis som samlar på gamla retromaskiner.

Men det här är väldigt lärorikt måste jag säga.

Permalänk
Inaktiv
Skrivet av xxargs:

Det görs arbeten på kernel hela tiden och man bör nog vara hyfsat i frontlinjen med kernversioner för att se om saker har blivit bättre - bl.a görs det stora insatser på filsystemet BTRFS där det har blivit markanta skillnader gentemot äldre kärn-versioner i avseende tung disk-access och stallningstedenser mm.

De senaste versionerna ligger idag på 5.10.1 sist jag kollade på https://www.kernel.org/

mycket för att man inte skall sitta och jaga fel på äldre kernel och OS-versioner som ändå kommer att fasas ut inom inte allt för lång framtid..

Till detta kan det vara skillnad i swap-hantering om de går direkt på en partition för swap på disken eller om det går igenom filsystemet på en fil för swap - idag så föredrar man ofta bara det senare med swap på fil i många distributioner och struntar att allokera en dedicerad swap-partition när man installerar en Linux-distrubition på en disk.

Jag håller med... att jaga ett problem om det skulle vara löst i nyare kernel, det är ju bara att försöka uppfinna hjulet en gång till..
Dock verkar detta fenomen följa med hela tiden, men det märks bara på low-end maskiner.. Man får ju inte förglömma att Linux kernel är avsedd för servrar som sedan anpassats i distros för desktops.. och att jämföra en servers workload och en desktop är ju äpplen o päron lixom
Som min server har ju hårdvara som spöar mina nyaste stationära ihop.. den har ju SAS i raid med dubbla xenon och 64GB ram.. som kan expanderas till 92, 96 eller 128.. jag minns inte specen och på den maskinen sitter man ju inte o surfar o arbetar med på samma sätt som en desktop. Så på den tror jag linux fungerar felfritt.. dock kör jag windows server på den just nu.

Det med swap på fil kanske är en bättre lösning än swap-partition, så det ska jag definitivt kika på.. för så jobbar ju win-skrot.
Jag tackar för din synvinkel, det ger mig mer att utforska

Permalänk
Inaktiv
Skrivet av Oegat:

Jag kollade tidigare igenom diskussionen från kernel-mejllistan, som i sin tur länkades från phoronix.

https://lkml.org/lkml/2019/8/4/15

I den diskussionen verkar de vara överens om att det handlar om att minnet är på gränsen i något avseende - antingen nästan slut, eller att working set (det minne som accessas hela tiden och därför inte meningsfullt kan swappas ut) har fyllt hela fysiska minnet (oavsett om det finns swaputrymme kvar eller inte).

Problemen för TS uppstår innan swap är full, vilket tyder på att det handlar om att working set är större än RAM. Det är troligen så att firefox låter script mm i inaktiva flikar köra vidare, så länge fliken är öppen, vilket stämmer med vad jag kunnat se på mitt eget system. Javascript t.ex. pausar inte för att jag växlar till en annan flik. Det kan också förklara varför TS upplever mer problem på 64bit system än på 32bit - då väldigt mycket körs i tolkade skripspråk typ javascript, som inte kräver att programmeraren funderar på storlek på numeriska variabler mm. Jag vore inte förvånad om samma Javascript-kod kräver mer minne på 64bit system.

Lösningen som diskuteras på mejllistan är följaktligen hur de ska få OOM-killer att sparka in lite tidigare, innan systemet fryser. Men då blir frågan återigen vilket problem som egentligen ska lösas - är du @Marie SWE nöjd med en lösning som innebär 1) att innehåll i en slumpmässig flik dödas när minnet börjar bli fullt, så att du märker att det är dags att sluta fylla fler flikar? För det är vad kernel-folket tycks se som lösningen på problemet. Eller var du mer ute efter 2) att kunna jobba vidare med samma belastning, t.ex. genom att försöka nyttja swap bättre? I det senare fallet så ligger nog hela lösningen med Firefox, troligen genom plugin eller dylikt som pausar innehåll i inaktiva flikar, så att de sedan kan swappas ut. Förutsatt att detta alls är möjligt.

Om min gissning om problemet är korrekt, så är det inte kostigt att du får thrashing, det är ju det förväntade beteendet av ett system som försöker ha ett större working set än det finns fysisk RAM. Jag känner mest igen det från Windows9X-tiden, då man räknade RAM i Mb. Jag har också svårt att tro att moderna Windows-versioner skulle klara det bättre. Du skrev innan att det fungerat bättre för dig på Windows, men jag undrar om det har med minneshanteringen att göra. Kan det vara så att du haft mindre igång då? Det kan ju också vara skillnader i webläsarens implementation, kan hända att 40 flikar på Windows tar lika mycket minne som 50 flikar på Linux, eller så.

En annan möjlighet är att Windows gör något annat som får gränssnittet att krokna i en långsammare takt, så att du märker tidigare att minnet är på väg att ta slut och mer eller mindre medvetet anpassar ditt användande. T.ex. genom att tidigare börja swappa ut minnessegment som accessas "lagom" ofta, och börjar småthrasha lite s.a.s. Medan Linux försöker jobba så effektivt som möjligt tills minnet är helt slut. Jag skulle tro att detta är vad kernel-folket föredrar, varför de nog vill se en lösning baserad på en aggressivare OOM-killer.

Jag kan ha fel i mina gissningar, men jag tycker förklaringen verkar rimlig. Från desktop-användar-perspektivet så skulle man då vilja ha en något tidigare varning att minnet håller på att ta slut, så att man varken behöver döda processer slumpvis eller hamna i en oändlig thrashing-loop. Bäst vore kanske ett explicit meddelande av något slag, som man kan välja att ignorera.

Intressant jag gillar din input

För att först svara på frågan.. Ja om en flik dödas är nog bättre, för den går alltid att öppna upp igen via Historik o nyligen stängda flikar/fönster Så det är ju att föredra än att datorn fryser i en timma

En idé som slagit mig är att kswapd går in för sent och för på tok för aggressivt.. den kickar in när det bara finns runt 128MB ram ledigt och när den börjar jobba så räcker det med något litet som får den att pika till 100% använd ram och där med fryser det sig, då i/o processen för kswapd har så hög prio att systemet fryser även att cpun är obelastad
Så om man skulle kunna få en effektivare swap som tidigare föreslog som swap-fil eventuellt kan ha.. men även att kswapd går in tidigare, redan vid 512 eller kanske ännu tidigare och då jobbar mindre aggressivt och mer som en bakgrundsprocess och då har en buffert om en minneskrävande pik kommer så kanske det hinner swappa undan utan att det fryser sig utan bara upplevs lite segare som winskrot gör.... Detta skulle med största sannolikhet vara väldigt destruktivt i en server, så det är ju inget som skulle vara en lösning som kernel uppdatering.
Men som även någon tidigare sa, så borde skrivbord o vissa processer inte swappas ut, utan ligga kvar i minnet, så att om swaphysterin uppstår så svarar det grafiska iallafall.
Och kunde man få detta effektivt, så skulle man kunna promota det till någon distro som vänder sig till just low-end maskiner.. då behöver inte folk vara kunniga utan med sina windows-kunskaper bara installera en distro som vänder sig till hårdvara med låg prestanda.

Jag skyller på Julen o tomten där jag önskar näst intill omöjliga saker.*hahaha*

*hihi* sååå sant, så sant... hederliga win95 och första utgåvan av 98.. det ger minnen. Jag installerade 98se på en retrodator i våras.. det var nostalgi på hög nivå. Fördelen med 98se var ju att man slapp bråka med botbar diskett o drivrutiner till cd-romen.

Japp det stämmer att jag upplever att winskrot hanterar det bättre, så jag är bombsäker på att det har med minneshanteringen att göra.. För att citera en ur en reddit diskussion.. It seems that Windows is better at failing than Linux is
Jag har belastat windows mer än linux och på mindre mängd ramminne, jag graderade enbart upp ramminnet till 8GB i två av laptopsen på grund av att linux var mer minneshungrigt(i de stationära blev det mer då de har 4slottar istället för laptopsens 2minnes slottar).. Det är dualboot windows7 och i win har jag satt upp egen storlek på växlingsfil, detta satte jag upp när jag gjorde installationen för masssssor år sedan och hade 4GB ram.. men då satte jag eget värde. Ursprunglig storlek 6GB och maximal storlek 16GB.. och windows är ju lite "speciellt", det växlar ju ut saker även om det finns ledigt ramminne. och jag tror det är därför man ofta med windows o mer ram upplever windows segare, för att det hela tiden växlar ut sakerna i pagefilen även att ledigt minne finns. Nu vet jag inte hur win10 beter sig då jag bojkottar win10spyware.. men 7:an var ju så. Och jag tror att det är därför det är svårare att lyckas få windows att trasha på samma sätt.. det är en större buffert ledigt minne och swap-processen är inte lika aggressiv utan mer en bakgrundsaktivitet som hela tiden småjobbar... så det är nog därför man kan se hårddisklampan i windows konstant småblinkar o vilar aldrig när man använder minneskrävande program.
Men det är vad jag tror är stora skillnaden.
Jag har läst på flera ställen där folk även påpekar att Firefox är mer minneshungrigt Linux än i windows.. Vilket är lite intressant, för mozilla är väl mer "linux än windows" i koden? eller?

Gissningar är bra, så fortsätt med dem, det är ju sådant som man kan forska vidare på o få idéer utav, så fortsätt med dem.
Jag gissar ju på hööög nivå när det kommer till linux... 2års erfarenhet med max 1års små-tweakande är inte något jag direkt kan skryta med. *hahaha*.... ni alla har garanterat pysslat med linux mycket längre än mig.

Idag är jag seg, men jag hoppas jag svara på det du fråga om.

Permalänk
Medlem

Häpp! Jag tror jag har hittat förklaringen till varför disken thrashar när minnet tar slut, även om inget swap finns påslaget.

Se första svaret här: https://unix.stackexchange.com/questions/24625/how-to-complet... (svarar inte på postarens fråga, men förklarar vad som händer)

Som jag förstår förklaringen så kan Linux, om minnet samt swap är slut (eller swap inte finns), kasta ut själva programkoden från laddade program. Detta eftersom koden alltid finns i binärfilerna på disken (alltså i */bin, motsv. .exe på Windows). Det som händer då är att så fort det blir programmets tur att köra, så laddas koden in igen från de exekverbara filerna. Men om minnet fortfarande är fullt så måste något annat programs kod kastas ut. Å så håller det på, tills mer minne frigörs på annat sätt.

På ett sätt är det ju smart, ingen mening att lagra kod dubbelt på t.ex. swap, när den redan finns på andra platser på disken. Men det gör att systemet har ett sätt att kunna vägra ge upp när minnet är nästan slut, och utnyttja disken som reservspace, även när ingen swap finns eller är ledigt.

Tror inte det ensamt förklarar hur du kan få thrashing även när swap är halvfull, som du beskriver i ett av de tidiga inläggen. Däremot om working set tar upp hela fysiska minnet, så att du ändå får thrashing (och hade fått på Windows med), så kan jag se hur detta gör problemet värre.

Se för övrigt i länken ovan tips om hur du kan begränsa minnet på enskilda processer, t.ex. på firefox. Men det löser såklart inte ditt önskemål att linux på desktop ska bli bättre på "failing gracefully".

(Jag gillar ändå Linux's dedikation till att göra allt som går för att slippa döda program. )

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX

Permalänk
Medlem

Några fler tankar.

Skrivet av anon309108:

En idé som slagit mig är att kswapd går in för sent och för på tok för aggressivt.. den kickar in när det bara finns runt 128MB ram ledigt och när den börjar jobba så räcker det med något litet som får den att pika till 100% använd ram och där med fryser det sig, då i/o processen för kswapd har så hög prio att systemet fryser även att cpun är obelastad

Jag tror inte problemet är att Linux inte hinner swappa undan, utan problemet uppstår nog för att det som swappas undan behöver läsas in igen pga att det är aktivt. Jag kan dock som jag skrev tänka mig en psykologisk process, att om Windows swappar ut saker tidigare, kanske oftare och oftare ju mer minnet fylls, så märker användaren tidigare att systemet blir segare, och surfar "lite lungare"

Citat:

Så om man skulle kunna få en effektivare swap som tidigare föreslog som swap-fil eventuellt kan ha..

Jag tror inte att det finns någon prestandafördel med swapfil på mekanisk disk, snarare nackdelar om disken är fragmenterad. Dock spelar det förmodligen ingen roll vid installation av ett system, eftersom disken då är tom, och filen därför blir en sammanhängande rad sektorer. Samt på ssd spelar det inte heller någon roll, då de inte begränsas av någon mekanik. Fördelen är att en swapfil är lättare att ändra storlek på, eller ta bort om det visade sig att den inte behövdes.

Citat:

Jag har läst på flera ställen där folk även påpekar att Firefox är mer minneshungrigt Linux än i windows.. Vilket är lite intressant, för mozilla är väl mer "linux än windows" i koden? eller?

Jag vet inte varför Firefox skulle vara minneshungrigare på Linux, men om det stämmer så är det nog förklaringen till att du får problem med Linux och inte med Windows. Det krävs nog färre flikar för att working set ska gå i taket. Jag gissar att Javascript har en del i detta, då typ allt på webben bygger på det idag.

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX