Virtuellt minne / win pagefile

Permalänk
Medlem

Virtuellt minne / win pagefile

Hej allihop

Sitter med en fundering om det är någon som kör virtuellt minne i windows till en helt dedikerad ssd?

Varför jag frågar är att senast jag (i Avid mediacomposer) exporterade en dnx-videofil så började det med ett par oförklarliga krasher. Till sist satte jag mig vid datorn samtidigt (lika kul som att titta på när målarfärg torkar ungefär) och såg att minne + möjligt virtuellt minne på C: blev fullt (128 ram, men inte mycket plats över på C:, typ 40-50 GB ). Nu är det en 9900k så arbetsminnet går inte utöka mer, men jag provade att byta plats på virtuella minnet till en annan SSD (850 evo med gott om plats) och voila, inga fler krasher. Men, efter ett tag ser jag att den SSDn ligger på ungefär 100% aktivitet, och stryper CPUn som då kanske kan arbeta på mellan 30-50% istället för 100 som normalt.

Är det någon med erfarenhet av en snabbare SSD som virtuellt minne? Hittade en halvgammal tråd om intel optane, men verkade inte komma till någon slutsats (i tråden).

Permalänk
Medlem

Inte helt bevandrad i hur just Avid använder virtuellt ram, antar att du kan ställa in hur mycket den ska använda? Skapar man ett virtuellt ram i andra applikationer t.ex för en virtuell server, sätter man det virtuella "dediskerat" på t.ex 16Gb då "bokas" 16GB (oavsett om det används) kan du konfigurera så Avids "virtuella ram är dynamiskt istället för dedikerat?

Känns inte som avid gjort rätt om man måste ha extremt stora virtuella ram, testa att stryp ner det virtuella till 32Gb eller nåt bara, kanske tillomed jobbar fortare.

Skyfflar du stora mängder data fram och tillbaka till en SSD lär ju livslängden inte vara jättelång på den heller.

Permalänk
Medlem

Låter så usel mjukvara om 128+GB RAM inte räcker.

Enda anledningen att virtuella minne finns är att systemet inte skall crasha när RAM tar slut. Det är en livrem, inget man kontinuerligt skall eftersträva att använda. På sikt skulle den bara skriva sönder SSDn om man låter den härja fritt.

Permalänk
Medlem
Skrivet av adfactory:

Inte helt bevandrad i hur just Avid använder virtuellt ram, antar att du kan ställa in hur mycket den ska använda? Skapar man ett virtuellt ram i andra applikationer t.ex för en virtuell server, sätter man det virtuella "dediskerat" på t.ex 16Gb då "bokas" 16GB (oavsett om det används) kan du konfigurera så Avids "virtuella ram är dynamiskt istället för dedikerat?

Känns inte som avid gjort rätt om man måste ha extremt stora virtuella ram, testa att stryp ner det virtuella till 32Gb eller nåt bara, kanske tillomed jobbar fortare.

Skyfflar du stora mängder data fram och tillbaka till en SSD lär ju livslängden inte vara jättelång på den heller.

Stämmer att man kan allokera ram för viss funktionalitet, men det är för vissa delar/funktioner (har bl.a. en egen disk-cache, så i detta fall skulle jag säga att allokeringen är nästan statisk per funktion). Tex export-funktionen verkar använda minne utöver det som allokerats. Det är ett minneshungrigt program, men å andra sidan är alla redigeringsprogram jag provat (davinci resolve, premiere pro) rätt minneshungriga om man börjar arbeta med 4K video. Därför min fråga om någon provat att använda en bättre vald ssd-sticka för virtuellt minne. Min första tanke var intels optane, men det verkar finnas väldigt lite skrivet eller testat om den på sistone...Notera att programmet flyter på rätt bra att arbeta med om man låter det använda allt minne (förallokering) men det vore skönt att slippa hoppa in och ändra inställningar för exempelvis exporter.

Permalänk
Medlem
Skrivet av Jimi84:

Låter så usel mjukvara om 128+GB RAM inte räcker.

Enda anledningen att virtuella minne finns är att systemet inte skall crasha när RAM tar slut. Det är en livrem, inget man kontinuerligt skall eftersträva att använda. På sikt skulle den bara skriva sönder SSDn om man låter den härja fritt.

Tja, när det gäller stabilitet skulle jag säga inte säga att det är sämre än någon konkurrent (obs, har aldrig använt mac så viss reservation finns för final cut). Min uppfattning är att dess huvudkonkurrenter är mer eller mindre lika krash-benägna, sen av lite olika anledningar. Jag skulle väl likna det mer som exempelvis en NAS-lösning, där många erbjuder SSD cache. Det betyder inte att man bör sätta i billigaste SSD-stickan utan satsa på någon variant som är mer utformad för den typen av användning (är det inte synology som till och med erbjuder egna SSD-stickor till vissa av sina NAS-modeller?).

Permalänk
Medlem

Efter att ha provat bcache så skulle jag säga att man måste välja sina SSD/NVMe-lagring för cache-användning med stor omsorg och prova ordentligt med tortyrliknande användning - 3 olika tillverkar har jag provat och alla har slutat med att vara väldigt långsamma i skrivning och ett par av dem faktiskt totalt hängt sig så att de blev utkickade för att de inte svarade alls inom stipulerad tid... - och i kapacitet så långsam att en mekanisk 2.5" kan köra cirklar kring dem då man med svårighet kommer över 20 MB/s skrivning på SSD vid tester efteråt - man måste skriva hela disken med '0' eller göra security erase på dem innan de närma sig sina fornstora dagar i hastighet igen...

- mitt förtroende för SSD/NVMe har faktiskt blivit rätt tilltufsad efter detta... en SSD, ja shit happen, men 3 olika med samma slut indikerar något grundläggande problem...

Nu skall jag säga att jag testade bcache ordentligt med att köra deduplicering på BTRFS-filsystem med 'bees' - vilket inte är normal användning utan det bokstavligen torterar bcache med småskrivningar - och kort sagt SSD (64 och 128 GB av MLC-klass) höll inte måtte för kontinuerlig och random-mässigt småsektorskrivande...

Använd write-trough endast och inte write-back om du inte är väldigt säker på att SSD/NVMe är av serverkvalitet och överlevt tortyr-tester - För när den kraschar/kickas ut för att de inte svarar längre i write-back mode så är det adjöss med din filsystem på icke räddningsbar nivå...

Permalänk
Medlem
Skrivet av xxargs:

Efter att ha provat bcache så skulle jag säga att man måste välja sina SSD/NVMe-lagring för cache-användning med stor omsorg och prova ordentligt med tortyrliknande användning - 3 olika tillverkar har jag provat och alla har slutat med att vara väldigt långsamma i skrivning och ett par av dem faktiskt totalt hängt sig så att de blev utkickade för att de inte svarade alls inom stipulerad tid... - och i kapacitet så långsam att en mekanisk 2.5" kan köra cirklar kring dem då man med svårighet kommer över 20 MB/s skrivning på SSD vid tester efteråt - man måste skriva hela disken med '0' eller göra security erase på dem innan de närma sig sina fornstora dagar i hastighet igen...

- mitt förtroende för SSD/NVMe har faktiskt blivit rätt tilltufsad efter detta... en SSD, ja shit happen, men 3 olika med samma slut indikerar något grundläggande problem...

Nu skall jag säga att jag testade bcache ordentligt med att köra deduplicering på BTRFS-filsystem med 'bees' - vilket inte är normal användning utan det bokstavligen torterar bcache med småskrivningar - och kort sagt SSD (64 och 128 GB av MLC-klass) höll inte måtte för kontinuerlig och random-mässigt småsektorskrivande...

Använd write-trough endast och inte write-back om du inte är väldigt säker på att SSD/NVMe är av serverkvalitet och överlevt tortyr-tester - För när den kraschar/kickas ut för att de inte svarar längre i write-back mode så är det adjöss med din filsystem på icke räddningsbar nivå...

Intressant, nu har jag lyckats ”skruva ned” minnesanvändningen så att ssdn används i undantagsfall. Men av kuriosa, vilka ssd-er testade du som inte höll måttet? Och för att vara tydlig, den ssdn jag använder är primärt som cache av olika slag, tex för davinci resolve. Om den ger upp så är det trist men absolut ingen katastrofsituation...

Permalänk
Medlem

De jag har provat är LITEONIT LCS-128M6S, ADATA SP900 64 GB, Sandisk X300s 128GB (skräpdiskar jag hade liggande och inte gråter om de blir utslitna) och sist Samsung 830 256GB som aldrig har blivit sig riktigt lik efter detta (och i 830:s fall det finns bekymmersamma poster "SATA Phy Event Counters (GP Log 0x11)" med höga uppräkningar i antal event (jag menar inte 10-tal event - jag menar 5-siffrigt i antal...) om man tittar i slutet av dataflödet när man kikar med smartctrl -x (som ger mer och vendorspecifik information som normalt inte syns i standard SMART) med misslyckade kommandon, com-reset etc.

Alla utom möjligen Sandisk X300s är av MLC-typ och ingen av dem klarade sig särskilt väl. sandisk och liteon hängde sig så hårt efter ett tag att de blev utkickade och bcache körde plötsligt utan SSD aktivt (i writethrough-mode), Adata gick bara fruktansvärd långsamt med typ 2 MB/s i skrivtest sedan och så Samsung 830 - som jag förväntade mig mer på, har aldrig riktigt återhämtat sig efter totalhängning trots skrivning med '0' hela disken, blkdiscard och håller på med bussblockeringar och skit även efteråt i 'vanlig' filsystem-användning...

Obs detta var inget som syntes vid 'normal användning' utan först vid när jag började deduplicera BTRFS-filsystem med 'bees' som tortyr-test. Och det jag började med först var en präktig filsystemhaveri efter ca 1 dygn när jag körde "writeback", med writethrough fungerar det hyfsat men fick finna sig i att SSD:erna var utkickade plötsligt och utan förvarning inom 1 dygn med deduplicering igång - testet gjordes mot en 2TB WD-green-disk som backend då jag tänkte att SSD-cache skulle hjälpa upp den till närmast frusna sirapen långsamma söktiden (> 20 ms) på dessa diskar...

- Med Bcache i Writeback-mode som syndare var för mig den första BTRFS-filsystemet som inte gick att reparera eller rädda filer ur efter haveri och efter analys förstod jag varför - metadata för filsystemet hade i princip inte lämnat SSD:n som kraschade (och ej kunde identifieras efteråt av bcache-systemet) då default så görs det inte någon intervallbaserad synkning alls av data mellan SSD och bakomliggande snurrdisken i bcache.

Writeback är det som är det mest attraktiva med SSD-cache när man jagar prestandaökning - men här visade sig också vara den farligaste tillämpningen den dagen när det skiter sig i SSD:n och man förlorar precis allt!!

Man såg under körning med 'bees' med dmesg att svartiderna från SSD blev hela tiden långsammare och långsammare, börjar med busreset och till sist kickade ut för att det inte svarade alls inom ganska lång tid (> 8 sekunder) - ungefär i beteende som en SMR-disk som fått sin PMR-del knökfull av icke sammanhängande sektorer som den aldrig får tid för att städa ur... och jag skulle tro att det är samma sak med en TRIM-tabell i SSD som blivit fullständig spagetti av kedjereferenser till varandra och GC hinner aldrig reda ut dessa igen för att få 8-64 MB frigjorda och raderbara block i flashen då det fylls på mer än det hinner tömma.

Det jag skall prova med på Samsung 830 är att göra en security erase och se om den blir människa igen - då nollställs alla trimtabeller etc. olika logiska nystan och börja på samma nivå som ny direkt ur förpackningen. Dock är det en smula bökigt då det måste går via SATA och man skall bränna specifik USB-bootsticka för jobbet om man gör det via samsungs magican ... (det går också via hdparm också, men där måste man fan hålla tungan rätt i munnen för att inte riskera en permanentlåst-disk då ATA-password är involverat)

---

bcache skall inte bry sig om vad som hanteras ovanpå imagen med filsystemet mer än att det cachar när läs och skrivstorlekar av sektorföljder är under en viss (och ställbar) nivå mot disken eller läser från disken då man avsiktligt inte cachar stora sekventiella skrivningar/läsningar då hastighetsvinsten är liten och skulle ge stor slitage på SSD - och med moderna SSD med SLC-cache i begränsad storlek för TLC och QLC-SSD/NVMe så finns risken att de blir fullskrivna fort vid stora filskrivningar/läsningar och då blir SSD väldigt långsamma, långsammare än snurrdiskar...

---

Om jag skall vara ärlig så blev jag lite besviken på bcache och framförallt hur illa SSD klarade sig i situationer där de borde excellera i prestanda men i själva verket havererade istället (och med katastrof i vissa cache-moder) vid tung kontinuerlig last som aldrig släpper i dygns perioder. Och också hur farligt det kan vara med risk för förlorade filsystem vid tunga läs och skrivlaster med writeback som scrub, resynkningar av diskar i RAID och mycket uppenbart - deduplikation på 4k-block och sektornivå då det kan hålla på i många dygn i rad utan uppehåll.

Det är samma effekter som SMR-diskar i samband med resynkning av RAID - vilotiderna som man räknar med finns för 'housekeeping' internt så att det kan tömma PMR-delen på disken, inträffar inte och för vissa RAID-system som ZFS blir en katastrof när diskar blir utkickade som knatterband efter en ganska bestämd tid när diskarna inte längre svarar inom 8 sekunder.

samma effekter tycker jag mig se efter övningen med bcache - även finns i SSD-diskar för diskaktiviteter med småsektorskrivningar som aldrig slutar utan bara håller på timme efter timme...