Varför utnyttjas inte internminnet

Megabyte ? Unge gosse...

Jag har även expanderat en Casio med 2kbyte, det kostade ca 1kr/byte på den tiden....

Dagens winmaskiner behöver däremot minst 8Gbyte för att uppföra sig trevligt men 16 skadar inte direkt, sitter på relativt nystartad dator (pga 15h strömavbrott) och slösurfar lite lätt och det drar runt 8 Gbyte just nu.

Det var därför jag skrev som jag gjorde. Ram tog inte slut. Men spärrar vid rund 5Gb och vindows går till basic läge. Spelet hade nått gränsen vid 4Gb eller nått. Weblässaren ligger ändå i bakgrunden och tar ram.vissa spel fungerar inte eller funkar dåligt om webbläsaren är igång. Vet dock inte vad det beror på.

Det kanske beror på Flash, webbläsarna lämpar över det på gpun om man har acceleration på.

Mitt 280X lägger sig i en annan energinivå med flash igång. Standardfrekvens är 1030MHz, den vägrar röra sig över 800MHz om Flash är igång, grymt irriterande xD

Kan du ha rätt i

Du drar nytta av 8->16 GB, du har 7,7 GB cachelagrat minne, alltså minne som cachar innehållet på hårddisken.
5,3GB+7,7GB av ditt arbetsminne används i detta fall, alltså ca 13 GB av 16GB.

Låt som sagt windows bestämma swapens storlek, men du kan med fördel flytta den från din SSD till en hårddisk om du behöver mer plats på SSD:n.
Swapen kan tex. användas till att säkerställa minne som reservats men inte använts.
Om ett program reserverar 2 GB minne men bara använder 1 GB av dessa kan det oanvända minnet läggas på swapen i stället för att ta värdefull plats i arbetsminnet.
Även om denna 1GB tar upp plats i swapen skriver eller läser inte windows det, det är ju som sagt oanvänt minne.

Nej, jag är nästan säker på att alla 32 bitars program inte behöver samsas om samma 4GB, programmen adresserar varsin virtuell minnesarea (0-4GB) som sen windows mappar mot det riktiga minnet.

edit Tycker att det visas en konstig storlek på swapen i första bilden, enligt andra borde den vara 18,8-15,9 = 2,9 GB.

Trevlig beskrivning.

Okej då hade jag fel

Nå, synd att spel oftast inte görs i 64 bitars, vissa behöver det (behöver vara jätte krävande spel som man får problem med).

Den här bilden visar att du i detta läge överhuvudtaget inte behöver mer än 6.8GB för det är totala mängden RAM som vid detta tillfälle överhuvudtaget mappas upp till applikationer, rent fysiskt är det ca 1.5GB av det minne som allokerats i systemet som aldrig används och därför inte tar fysisk minne (5.3GB används men 6.8GB är garanterat av OS att det skulle kunna användas).

Så i ditt fall var det rätt onödigt att utöka från 8GB om målet var att optimera just det användarfall du visade här. Du har köpt dig en rätt dyr diskcache
Men nu har du i alla fall lite utrymme att växa om framtida program blir mer minneshungriga.

Vad ser du att pagefilen skulle använda 9-10GB? Den kanske är så stor på disk, men i ditt system så är det för tillfället bara 18.8-16.0 = 2.8GB av page-filen som överhuvudtaget är uppmappad av OSet.

Fast en rejäl diskcache är ju inte fel det heller, mindre och läsning till disk och snabbare tillgång till filer.

Passar på att fråga lite om det inte är för stort besvär.

1. Har jag uppfattat det rätt i att om det saknades swaparea, så skulle detta oanvända 1.5 GB allokerade minne, tvingas reserveras i RAM och inte på pagefilen?

2. Vet du om detta 18.8 GB virtuella minne, är inklusive maskinreserverat minne?

3. Funderar också lite på vad som reserverar maskinreserverat minne, när det gäller inbyggd grafik är det ju självklart, är det grafiken även i detta fall, som en sorts gemensam minnesarea?

Angående din fråga lade lasse upp även denna bild.
http://eklunda.se/lasse/grafik/k2.jpg
Den verkar lite lurig, detta som benämns page file usage, skulle kunna vara dedikerat minne.

edit Sorry för mina sena editeringer som kom efter det att du börjat svara.

Maskinreserverat minne ligger på specifika fysiska adresser men en CPU med MMU-påslaget jobbar enbart med virtuella adresser. Av den anledningen är frågan om 18.8GB virtuell minne inkluderar maskinreserverat minne inte något man direkt kan svara ja/nej på. Om/när OSet vill läsa/skriva till maskinreserverat minne måste den ta en eller flera "pages" för att göra en mappning mellan någon virtuell adress till den fysiska adress där maskinvaran ligger, rent teoretiskt går det att göra en temporär mappning som man tar bort när man läst/skrivit klart.

18.8GB är storleken på den adressrymd som just denna Windows-maskin maximalt kan använda, typiskt kommer en del av detta användas för att komma åt maskinreserverat minne (i praktiken är det med stor sannolikhet så att det maskinreserverade minnet är permanent mappat).

Naturligtvis inte fel med mycket diskcache, tyvärr lämnar Windows diskcache en hel del att önska i form av hur effektiv den är. Hoppet från mekanisk disk till SSD är enormt på Windows oavsett hur mycket RAM man har, i ett Linux-system med rejält med RAM så är det inte alls lika dramatisk skillnad då den diskcachen är ruggigt effektiv.

Låter sannolikt att det är permanent mappat, tack för svaret.

En ordvrängare skulle alltså kunna säga att "Windows diskcache har stor förbättringspotential".
Något vi får lägga till i önskelistan för Windows.

Du svarade så snabbt så jag hann inte få in en fråga till.

Passar på att fråga lite om det inte är för stort besvär.
Har jag uppfattat det rätt i att om det saknades swaparea, så skulle detta oanvända 1.5 GB allokerade minne, tvingas reserveras i RAM och inte på pagefilen?

Angående din fråga lade lasse upp även denna bild.
http://eklunda.se/lasse/grafik/k2.jpg
Den verkar lite lurig, detta som benämns page file usage, skulle kunna vara dedikerat minne.

edit Hoppas att mina editeringar inte krånglat till det igen.

Om det saknades swap-area så skulle inget dynamiskt allokerat minne någonsin hamna på disk, men moderna OS är "smarta" vad det gäller kodsegmentet. Om man tänker på vad själva koden kommer ifrån så ligger den i .exe/.dll (eller motsvarande i andra OS) filer, så det finns ju ingen poäng med att skriva deras innehåll till swap då det redan ligger på disk!

Ett program som inte används på länge kommer får sitt dynamiska minne skrivet till swap (om det finns någon) men kodsegmentet kommer man bara markera som "för tillfället inte backat av fysisk RAM" med en referens till .exe/.dll filen som man måste läsa om/när den koden måste köras av CPU-delen igen. Inte helt 100% på hur Windows presenterar detta, men rimligen borde swap vara summan av det som används av swapfilen + all kod som rent teoretisk kan "swapas" ut när som helst då det redan ligger på disk.

Noter att även minne som ligger på swap har en beskrivning i form av en "page" och tar därmed också upp utrymme i virtuella adressrymden. Informationen i varje "page" talar om vilket fysiskt minne det motsvarar eller, om det är swappat, finns en referens vart innehållet är lagrat. CPU-delen kan däremot inte använda innehållet som en "page" refererar till med mindre än att den faktiskt pekar på RAM (fysiskt minne).

Edit: angående bilden. Vet faktiskt inte varför så mycket swap anses vara använt. En gissning är att OSet reserverat utrymme i swap utifall det skulle behöva skrivas ut senare, men det lär knappast behövas i ett system med 16GB RAM som för tillfället använder 5-6GB. I vissa lägen kan ändå saker skrivas ut, t.ex. om de inte används på länge, så det är en annan möjlighet. I detta fall kommer det finns både i RAM och på swap, fördelen med detta är att om man måste kasta ut saker från RAM så ligger det redan på disk vilket gör att swap-processen upplevs mycket snabbare.

Vet inte exakt hur Windows policy ser ut for detta, i Linux kan man styra hur aggressiv kärnan ska vara med att skriva ut saker till swap bara för den inte används på länge (är möjligt att sätta konfigurationen så det aldrig skrivs innan det absolut måste).

Det är onödigt om du inte ökar till > 4Gbyte och har 32 bit os.

Jag har 2x8 GB i min dator (Windows 8.1) och när jag kör stresstest i AIDA64 och bockar i CPU, FSU och RAM så fylls alla 16 GB...