Nytt SSD och RAM-minne på min 10 år gamla dator

2400MHz är riktigt högt för DDR3, och vissa processorer och moderkort kan få det svårt att klara av sådana höga hastigheter, speciellt om det är 4st moduler. I värsta fall så får du nog klocka ner dem till ~1600MHz på 1.5V.

Men om du bara har 55GB dedikerat till C: och den blir full, så låter det som problemet - inte minnena.

Jag hade nog valt att enbart köpa 2st 4 GB moduler och komplettera de du redan har (under förutsättning att du idag har 2 st 4 GB moduler. Men du kan inte gå fel med det där 4x4 kittet

Som Decster säger så är det troligtvis din systemdisk som är överfull. Testa först att ta bort temp-filer och liknande.

Alternativt installera om Windows från scratch. Det kan nog ge dig ett prestandalyft.

Edit: Du kan dubbelkolla ifall det är ditt RAM som tar slut genom att kontrollera över tid hur mycket du använder av det, samt ifall du utnyttjar hårddisk-swapping något (väldigt långsamt).

En 55 Gbyte stor systemenhet är otroligt litet idag om du kör win, den kommer att bli full direkt.
En fördel vad gäller utymmet är att du har win 7 som inte längre får uppdateringar men att det inte får uppdateringar är å andra sidan en nackdel

Man bör minst ha en systemenhet i 500 Gbyte klassen om det ska gå att installera ett par program på den utöver win, har man enbart win på den kan man klaras sig med en i 250 Gbyte klassen.

16 Gbyte ram är normalstorlek idag men välj inget supersnabbt ddr3 minne om det är dyrt om du inte ska toköverklocka för ddr3 är mer retro än moderna minnen nu när ddr5 precis ska börja introduceras på allvar.
Du kan inte återanvända minnena om du skaffar en modern plattform så tänk på priset och kolla även på beg minnen.

Leta begagnat ram för ddr3 är inte prisvärt nytt idag då det är en gammal teknik och nypriserna börjar gå upp på det för det inte längre används i nya prylar.

Oavsett hur snabbt minne du väljer så är grundinställningen högst 1600 Mhz, högre än det räknas som överklockning och har ingen garanti att fungera eller vara stabilt.

Jag tycker alltid att det känns hårt att betala mycket för att uppgradera en dator som blivit så gammal. DDR3 kostar fortfarande mycket för högre minnesmängder och hastigheter. Förmodligen kan du få tag på 2x2GB mycket billigare, 1GB-stickor brukar också gå att finna för en spottstyver.

Ditt största problem är att du har för trångt på system-hårddisken och för sådant hjälper inte mer RAM

55 GB SSD på OS-systemdrivern är _ingenting_ idag och handikappar ditt OS mycket när disken är mer än 80% fyllt och mindre än 20 GB ledigt utrymme på disken

Lägger du inte mer än enstaka mindre spel på disken så bör den nya SSD vara minst 240 GB om du uppgraderar befintlig dator om du inte hela tiden måste rensa och idag när man köper ny dator är 500 GB absolut minimum, helst 1 TB SSD/NVMe.

Ett filsystem som är fylld mer än 80% blir mer trög oavsett på SSD eller mekanisk disk då filer som skrivs inte kan hitta sammanhängande områden för sekventiell skrivning (och läsning) utan fylls i lediga platser här och där och väldigt många små paket av filer-delar som skall skrivas/läsas spritt över diskytan med väldigt mycket läsande i filsystemets metadata [$MFT] [1] och väldigt många anrop mot disken som även på SSD köar upp och det blir trögare i jämförelse med färre och större paket som kan skrivas sekventiellt.

TRIM-kommando som windows skickar efter filers radering kan heller inte göra nytta när SSD-disken är nära smockfull då för-radering för att skrivning skall gå snabbare senare kräver ganska stora sammanhängande block frigörs när du raderar filer och det blir ingen sammanhängande område om en starkt fragmenterad fil raderas då det blir bara små delar som förklaras ledigt över diskytan när TRIM-kommandot körs efter raderingen, ungefär som småhålen utspridda över diskytan efter liknande ett hagelskott på en papptavla.

Det tar tid att skriva och att läsa filer på en disk som är fylld över 80% och det drabbar hårdast på just systemdiskar men mindre på lagringsdiskar där man skriver filer en gång med tex. spel-binärer och hackas inte upp i småbitar på samma sätt som en systemdisk som hela tiden skriver och raderar filer och det blir hårt fragmenterat när systemdisken arbetar när den är konstant nära full.

Om disken var större med mer ledig utrymme än under 10-20 GB ledigt, så skulle jag rekommendera att köra ett varv med defraggler eller motsvarande defragmenteringsprogram[2] och även på SSD så kommer det ta många timmar när man kör första gången på mycket länge då väldigt mycket av filerna är fragmenterade och därmed hanteras långsamt av filsystemet

- men på en 55 GB SSD och knappt någon ledig diskutrymme så vete fasen om man vågar och förmodligen kommer defragmenteringsprogrammet inte vilja köra för att disken är för full...

[1]
Många modernare filsystem försöker hela tiden passa in filens data i lediga block som stämmer exakt i storlek och skriver samma fil sekventiellt om möjligt utan att hacka upp dem i för små block, men NTFS är inte en av dem och dessutom flätar in skrivningarna i varandra om det har flera parallella skrivningar gående hela tiden och det hela blev väldigt uppenbart hur illa det fungerade när folk började tanka ned torrent-filer på mekaniska diskar (ingen hade råd att lägga sådant på SSD)

- att för-allokera filerna hjälpte heller inte till mer än viss del då skrivordningen är samma inom filen som torrent-blocken laddades ned och med torrent-nedladdningens natur kunde alltså hoppa fram och tillbaka slumpmässigt (och det flätades in på samma sätt i $MFT men där också med alla filer som är aktiva samtidigt) och mönstret upprepades när man senare läste ut filen vilket gjorde att på mekaniska diskar gick det väldigt långsamt att läsa ut filerna igen då läshuvudena fick hoppa fram och tillbaka över skivytan som ett skållat troll i att samla bitarna här och där samt ideligen läsa och sila i $MFT inflätade data för att veta var blocken ligger för att det skulle bli sekventiell dataflöde läst. Detta märks inte lika mycket på SSD/NVMe men med 0.01-0.5 ms per sökning i SSD så kommer det ändå bli märkbar seghet när 4K-block per diskkommando måste letas över hela diskytan i jämförelse med 64K-block i långa i serie efter varandra per diskkommando.

Inom Linux-världen skapades filsystemen ext3 och senare ext4 för att _inte_ upprepa misstagen som man gjorde i samband med NTFS när den designades och därmed skapade en filsystem som fragmenterar väldigt lite trots många parallella dataströmmar med slumpmässig skrivordning inom respektive fil och behåller att det är sekventiellt senare när filen senare läses - dvs. klarar torrent-nedladdning utan att det fragmenterar filer.

[2]
Alla tjatar om att man inte skall köra defragmentering på SSD/NVMe i rädsla för flash-slitage - men även SSD behöver defragmenteras då och då när man har NTFS som filsystem - men inte så ofta utan 1 gång per halvår räcker i de flesta fallen om defragmenteringstiden (efter den första...) ligger under en halvtimme - tar det längre tid får man köra lite mer ofta. Om man som jag har förbrukat inte mer än 1/4-del av SSD totala skrivkapacitet efter 70000 timmar så är en defragmentering per 6 månader inte ett problem även om hela disken skulle skrivas om 2 gånger per session, vilket i stort sett bara görs första gången när det måste möblera om i princip alla filer - medans efterföljande defragmentering bara kanske handlar om 10-20% av diskvolymen per körning. Att tanka ned en spelbinär eller några mediafiler eller köra på netflix eller annan strömmande media med buffrande av krypterad data hela tiden skriver mer på SSD/NVMe i jämförelse i dessa fall.

Är inte målet med defrag att när datorn ska hitta en fil ska den inte behöva leta på massor av olika ställen - vilket på en snurrdisk såklart kan ta väldigt lång tid? Men på en SSD som läser lika snabbt från 10 olika ställen som 1 stort ställe som hänger ihop, tjänar man då något på en defrag?
Är ärligt nyfiken vad det är alla missar när du låter så säker på din sak att det är positivt att köra defrag.

Att det sliter tar jag inte som nått allvarligare argument, så länge man inte gör det i tid och otid

Det faktum att windows stänger av defrag automatiskt på en SSD känns ändå som det är rätt väg att gå

Men motbevisa mig gärna, jag är öppen för att lära mig nått nytt.

Win kör automatiskt defrag även på ssder men inte lika ofta som på hdd, defrag ingår i optimering. Ntfs har också ett begränsat antal maximala fragment per fil så även om fragmentering inte påverkar läshastigheten på en ssd kommer filsystemet att kunna bli korrupt.

Så i praktiken innebär det att man inte behöver göra nått manuellt utan låta windows göra sitt? I så fall förstår jag ju att rekommendationen brukar vara att inte defragmentera manuellt.

Ja nyare versioner av win sköter om trim och defrag (och kallar det optimera) själv på ssder om man inte ändrar inställningarna, det kan däremot fungera dåligt om enheten är väldigt full och är man inte expert eller har nån särskild anledning att ändra på det så bör man nog låta win sköta om det själv.

du kan köra 2400Mhz minnen men de ska vara specade isf med 1.5V med 2400Mhz profilen 1600-1800Mhz är väl vanligast och snabbaste som brukar va specat till 1.5V dock

edit: 1866Mhz

men som sagt borde gå att hitta begagnat för typ <600:- för 16GB 1600-1866Mhz minnen hälst 2x 8Gb stickor istället för 4x 4Gb då vissa moderkort kan bli lite kinkiga med 4 stickor installerade.

rekommenderat att ha iaf runt 10-20Gb ledigt på C: inte värt att gå under typ 200Gb partition för C: om man vill ha lite program och grejor på c: också då win 10 lätt når upp till 50-75Gb bara för operativsystemet efter att win update körts ett par gånger.

och har du win update på att automatiskt ladda ner uppdateringar så kan själva uppdateringsmappen lätt ta en 10-20Gb innan den installerats och tagits bort.

du kan troligen köra minnena i 1600 eller 1866Mhz med 1.5V om du tweakar inställningarna lite i bios dvs överklockar dem manuellt (allt över 1600Mhz är klassat som överklockning då intel bara testat sin minneskontroller upp till att garanterat klara det).

troligen kommer de köras i 1600Mhz (default) med 1.5V om du struntar i att ladda XMP profilen från minnena.

beroende på vad du gav för minnena så kanske.

över 700:- så njae kolla begagnat istället men va beredd på att de kan ta en stund minnen åker sällan upp begagnat speciellt inte något som varit omodernt och inte använts senaste typ 4-5 åren.

och ditt problem är mer troligt beroende på att din c: är full och den inte alltid får plats med allt den behöver få plats med.

typ alla program brukar ju använda sig av div tempfiler medan de körs i varierande storlekar och får tempfilen inte längre plats så blir det problem.

Att hämta från 10 olika platser är inte lika snabbt som att hämta alla delar sekventiellt efter varandra i en enda anrop ens på SSD - visst det handlar om delar av millisekunder per anrop istället för > 10 ms för ny sökning på snurrdisk men det är ändå tid och kan bli stora om det är tusen och tiotusen sådana anrop i rad som skall ske för att filen är kraftigt fragmenterad - du har overhead-tid för varje diskanrop och handlar det om 1-10 anrop för en fil så tar det mindre tid än att jaga 1000 - 10000 olika fragment (vilket det lätt kan nå upp till på en större icke defragmenterad fil i NTFS som en torrent-nedladdad fil)

Och som redan skrivet kan inte NTFS ha hur många fil-fragment som helst och det kan bli konstiga och svårsökta fel om man ändå kör in i gränsen, och det är också en av anledningarna att NTFS inte skalar väl när filsystemen blir TB-stora (man skall komma ihåg att NTFS designades i en tid där 100 MB stor disk var 'stor disk' och en disk på 4 GB var 'enormt stor' och OS-mijöer där man skrev en fil i taget och inte som idag med kanske 100-tals filer öppna samtidigt och skrivs mer eller mindre parallellt - klart att man springer på begränsningar när man >25 år senare bollar med TB-stora diskar) och gissar att ReFS var ett av försöken att adressera problemet för riktigt stora lagringar även om resultatet blev bara halvdan och inte tillräckligt komplett för att kunna användas som OS-filsystem som windows väl så behöver för att kasta ut NTFS, för att man 'glömde' några viktiga funktioner som windows själv är mycket tung användare av (hårda länkar - som stöds av alla posix-kompatibla filsystem - men inte ReFs...)

Eller om man vill - resultatet är väldigt typisk när stort bolag som 'beställde' en filsystem av grupp inte så entusiastiska programmerare utan arbetsuppgift, fast budget och hård tidsram. Sådan kräver filsystemsnördar, stor frihet, många misslyckande och långsiktighet och att utvecklingsjobbet egentligen aldrig tar slut och som det ser ut idag är det i stort sett bara open source-community som orka med den långsiktigheten även om grunderna i många fall är kommersiellt skapade filsystem som sedan öppnats till opensource.

Den andra delen som gör att jag förordar att köra defragmentering typ en gång per halvår är att få upp större lediga sammanhängande ytor som hjälper SSD och även NTFS-filsystemet själv att göra sitt jobb bättre med trimkommandot på raderad och lediga utrymmen som körs av windows då och då och att du får mer flashminne som för-raderas i dynamisk överprovisionering och användning som SLC-cache för diskar som använder sådant och ändå är utrymme du kan använda för fillagring när det behövs.

För att för-raderingen av flash-blocken skall kunna göras så måste man frigöra ett antal MByte data i sammanhängande block och TRIM kan inget göra om de friställda sektorerna är spridda slumpmässigt som 4k-block över hela diskytan för att filen man raderade var väldigt fragmenterad. Med stora lediga sammanhängande ytor så är det också lättare för NTFS själv att placera ut filer så att de inte blir allt för upphackade i småblock och 'trim' kan göra något vettigt av frigjorda utrymmet när filen senare raderas

Alternativet är statisk överprovisionering som gör med diskens manager-program (som magician för Samsungdiskar) men då förlorar du sammanhängande diskyta som reserveras för överprovisioneringen och du inte kan använda för att lagra data på[1].

För det 3' - prova att köra Defraggler (gratisprogram från samma företag som crapcleaner (Ccleaner)) - om den inte är klar inom 1 timme så bör man ställa fråga om windows egna defragmentering verkligen gör jobbet särskilt väl... det brukar se för hemskt ut i för-visningen i Defraggler innan man kör igång första gången och det brukar ta flera timmar, ja hela natten typ i första körningen innan det är färdig på en till 70% fylld och gammal välanvänd windows systemdisk på 256 GB SSD med många uppdateringar bakom sig.

Körningarna därefter typ en gång per halvår brukar vara klara inom timmen och ofta mycket mindre än så.

[1] görs genom att programmet minskar den befintliga NTFS-filsystemet och skriver om partitionstabellen så att en bit av slutet på disken inte används - kör trim/blkdiscard på området utanför filsystemet så att LBA-nummerområdet i slutet av disken inte längre är kopplade mot några flash-block och kommer att leverera '0' om man läser sagda sektorer.

Jo, att NTFS är långt ifrån optimalt är det nog ingen som säger emot

Finns det mätbara data som pekar på att SSDn blir snabbare efter att defraggler kört än innan? Nån som kört lite benchmarks innan och efter t.ex.? Och vilken nivå av förbättring kan man förvänta sig i så fall (om man haft den flera år och aldrig gjort nått)? För om nivån av förbättring är inom felmarginal så är det ju inget som behöver göras. Om vi däremot snackar rejält märkbar förbättring, då har ju Microsoft lite att förbättra i sin egen defragmentering som sker automatiskt i windows.