|
| Kan ikke bruge al min ram Fra : Kim Ludvigsen |
Dato : 13-04-03 17:03 |
|
Ja, jeg ved godt at emnelinjen er lidt speciel, for det er generelt
svært at bruge al rammen med OS/2 på en nyere maskine. Det hjælper dog,
hvis man har installeret VPC og kører en eller flere sessioner med
Windows.
Mit problem er, at jeg har 1024 MB ram i dyret, men når jeg kommer ned
på kun at have 300-400 MB fri ram, så får jeg en meddelelse om, at der
ikke er nok hukommelse. Indtil i dag er fejlen kun opstået, når jeg har
kørt flere Windows'er, hvor VPC så sætter alle undtagen den aktive på
pause. Men nu har jeg lige været ude for, at jeg ikke kan starte flere
OS/2-programmer, fordi der ikke er nok ledig hukommelse.
Hvad sker der? Og hvordan kan jeg undgå den fejl? Jeg havde lidt over
300 MB fri ram og mange GB fri plads til swapfilen.
--
Mvh. Kim Ludvigsen
| |
Mads Orbesen Troest (13-04-2003)
| Kommentar Fra : Mads Orbesen Troest |
Dato : 13-04-03 17:17 |
|
On Sun, 13 Apr 2003 18:03:29 +0200, Kim Ludvigsen wrote:
> Hvad sker der? Og hvordan kan jeg undgå den fejl? Jeg havde lidt over
> 300 MB fri ram og mange GB fri plads til swapfilen.
OS/2, i sin oprindelige form, har en per-process allokeringsbegrænsning på
512 megabytes, uanset mængden af RAM i maskinen. Selv om du har 1 GB RAM
kan en enkelt process maksimalt allokere 512 MB.
Det var riiiiiiiiiigeligt dengang OS/2 blev designet, men nu om dage ser
verden anderledes ud. Heldigvis giver det nye Kernel32 Execution
Environment (som er standard i WSEB og ECS, og som man får på Warp 4 med
nogle af de "nyere" fixpacks, kan ikke huske præcis fra hvornår det blev
indført) mulighed for, via Config.sys argumentet "VIRTUALADDRESSLIMIT",
mulighed for at hæve dette. Sæt det fx til 3072 (3 GB). Det er ikke slået
til som default af overkill kompatibilitetshensyn (IBM er jo nødt til at
gøre sligt for at store erhvervskunder ikke pludselig skal komme og dunke
dem i hovedet) - men du kan roligt gøre det, jeg har aldrig oplevet noget
der kolliderede med dette.
/\/\\ads Orbesen Troest
| |
Kim Ludvigsen (13-04-2003)
| Kommentar Fra : Kim Ludvigsen |
Dato : 13-04-03 18:00 |
|
Mads Orbesen Troest wrote:
>
> On Sun, 13 Apr 2003 18:03:29 +0200, Kim Ludvigsen wrote:
>
> > Hvad sker der? Og hvordan kan jeg undgå den fejl? Jeg havde lidt over
> > 300 MB fri ram og mange GB fri plads til swapfilen.
>
> OS/2, i sin oprindelige form, har en per-process allokeringsbegrænsning på
> 512 megabytes, uanset mængden af RAM i maskinen. Selv om du har 1 GB RAM
> kan en enkelt process maksimalt allokere 512 MB.
>
> indført) mulighed for, via Config.sys argumentet "VIRTUALADDRESSLIMIT",
Jeg havde allerede tilføjet den i Config.sys, men dog kun med 1024. Jeg
prøver lige, om det gør en forskel at sætte den op til 3072.
Kan fejlen skyldes noget andet, når nu den opstår længe før de 1024 er
brugt?
Jeg har forøvrigt WSeB med fixpack 2 (eller 3).
--
Mvh. Kim Ludvigsen
| |
Allan (16-04-2003)
| Kommentar Fra : Allan |
Dato : 16-04-03 00:19 |
|
On Sun, 13 Apr 2003 16:17:01 UTC, Mads Orbesen Troest <mads@troest.NEVERMORE.dk> wrote:
> On Sun, 13 Apr 2003 18:03:29 +0200, Kim Ludvigsen wrote:
>
> > Hvad sker der? Og hvordan kan jeg undgå den fejl? Jeg havde lidt over
> > 300 MB fri ram og mange GB fri plads til swapfilen.
>
> OS/2, i sin oprindelige form, har en per-process allokeringsbegrænsning på
> 512 megabytes, uanset mængden af RAM i maskinen. Selv om du har 1 GB RAM
> kan en enkelt process maksimalt allokere 512 MB.
Det er lidt af en tilsnigelse. OS/2 kan faktisk kun allokere omkring 230MB pr process,
> Det var riiiiiiiiiigeligt dengang OS/2 blev designet, men nu om dage ser
> verden anderledes ud. Heldigvis giver det nye Kernel32 Execution
> Environment (som er standard i WSEB og ECS, og som man får på Warp 4 med
> nogle af de "nyere" fixpacks, kan ikke huske præcis fra hvornår det blev
> indført) mulighed for, via Config.sys argumentet "VIRTUALADDRESSLIMIT",
> mulighed for at hæve dette. Sæt det fx til 3072 (3 GB). Det er ikke slået
> til som default af overkill kompatibilitetshensyn (IBM er jo nødt til at
> gøre sligt for at store erhvervskunder ikke pludselig skal komme og dunke
> dem i hovedet) - men du kan roligt gøre det, jeg har aldrig oplevet noget
> der kolliderede med dette.
Nu hjælper det ikke det store på "gamle" programmer, for der kan OS/2 stadig
kun allokere 230MB pr process. Det kræver at programmet selv udnytter de
nye features, for at det hjælper noget.
Ofte er problemet dog, at programmerne bruger den mængde shared ram op,
som der er til rådighed. En ting der kan hjælpe lidt på dette, og i øvrigt sætter
pr process grænsen lidt op, er at tilføje denne til config.sys:
DLLBASING=OFF
og i samme sammenhæng kan det (hvis du bruge JAVA) hjælpe med denne:
SET JAVA_HIGH_MEMORY=1
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
| |
Mads Orbesen Troest (22-04-2003)
| Kommentar Fra : Mads Orbesen Troest |
Dato : 22-04-03 17:33 |
|
Hej;
> Det er lidt af en tilsnigelse. OS/2 kan faktisk kun allokere omkring 230MB pr process,
Hvor har du det tal fra? Ifølge Deitel og Kogans "The Design of OS/2" i
afsnittet om Memory Management (p.164):
"The process virtual address space is mapped by a pair of GDT code and data
descriptors with limit fields of 512MB. The 512 limit is due to the
implementation of 16-bit OS/2 compatibility [altså "thunking"] and will be
removed in the future [hvilket det så også blev - efter MEGET lang tid ;)]"
.... "The system provides an independent 512MB linear address space to each
process [...]"
Almindelig "private" hukommelse allokeres så fra bunden og op inden for
adresserummet, mens "shared" hukommelse allokeres fra den anden ende (samme
kilde som ovenstående citat). Det vil så i praksis sige, at det nok er
mindre end 512MB du rent faktisk kan allokere, afhængig af hvor meget delt
hukommelse der anvendes, men hvordan det fast skulle sætte en grænse på det
tal du giver har jeg svært ved at se. Kan du henvise til noget?
> Nu hjælper det ikke det store på "gamle" programmer, for der kan OS/2 stadig
> kun allokere 230MB pr process. Det kræver at programmet selv udnytter de
> nye features, for at det hjælper noget.
I øvrigt en interessant tråd om dette emne her:
http://groups.google.com/groups?q=OBJ_ANY&hl=da&lr=&ie=UTF-8&oe=UTF-8&selm
=b7o5d9%24pch%241%40news.hawaii.edu&rnum=1
Med venlig hilsen,
/\/\\ads Orbesen Troest
| |
Allan (27-04-2003)
| Kommentar Fra : Allan |
Dato : 27-04-03 20:33 |
|
On Tue, 22 Apr 2003 16:33:02 UTC, Mads Orbesen Troest <mads@troest.NEVERMORE.dk> wrote:
> Hej;
>
> > Det er lidt af en tilsnigelse. OS/2 kan faktisk kun allokere omkring 230MB pr process,
>
> Hvor har du det tal fra? Ifølge Deitel og Kogans "The Design of OS/2" i
> afsnittet om Memory Management (p.164):
>
> "The process virtual address space is mapped by a pair of GDT code and data
> descriptors with limit fields of 512MB. The 512 limit is due to the
> implementation of 16-bit OS/2 compatibility [altså "thunking"] and will be
> removed in the future [hvilket det så også blev - efter MEGET lang tid ;)]"
> ... "The system provides an independent 512MB linear address space to each
> process [...]"
>
> Almindelig "private" hukommelse allokeres så fra bunden og op inden for
> adresserummet, mens "shared" hukommelse allokeres fra den anden ende (samme
> kilde som ovenstående citat). Det vil så i praksis sige, at det nok er
> mindre end 512MB du rent faktisk kan allokere, afhængig af hvor meget delt
> hukommelse der anvendes, men hvordan det fast skulle sætte en grænse på det
> tal du giver har jeg svært ved at se. Kan du henvise til noget?
Det er tal, som forskellige personer har nævnt ved forskellige lejligheder i nyhedsgrupperne.
Jeg mener at have set dem fra Scott G tidligere; men jeg har osse selv haft en del snak
med Trevor Hemsley omkring det, fordi Pronews netop lider under dette problem, efter-
hånden som nyhedsgrupperne kan blive rigtigt store.
Jeg faldt lige over dette citat fra Herbert Rosenau idag:
-----
In the standard way OS/2 allows an application only to access up to
512 MB. Since FP13 it is possible that an application can allocate
more than that. It means not that all applications gets that new limit
by default. But it means that an application needing a higher amout of
dynamic allocated memory can use it now.
One of the most popular applications that would only work best is
java. Java is extremely memory hungry, so the amount it gets by
default is (512 - 250(the cost for code and static data)) == circa 250
MB is too low to fullyfy all memory requests it needs to handle bigger
..ja* files. So with VIRTUALADDRESSLIMIT=2048 it will have enough
freedom to handle the requests.
-----
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
| |
Kim Ludvigsen (27-04-2003)
| Kommentar Fra : Kim Ludvigsen |
Dato : 27-04-03 19:50 |
|
Jeg kan ikke helt følge med i jeres diskussion, men vil lige følge op på
mit oprindelige indlæg.
Det kan godt passe med, at jeg er stødt ind i et loft, hvor Virtual PC
(VPC) ikke har kunnet bruge mere end 512 MB RAM. Jeg har ikke lagt mærke
til, hvornår mine problemer helt præcis opstod, og hvor meget RAM VPC
havde brugt på det tidspunkt, men det har været omkring de 500 MB.
Efter jeg har ændret config.sys med VIRTUALADDRESSLIMIT=3072 (tak for
tippet) opstår problemet ikke længere. VPC løber dog stadig ind i et
problem i form af manglende hukommelse, når den fysiske RAM er opbrugt,
men jeg kan forestille mig, at det er et problem i VPC. Problemet viser
sig ved, at VPC-sessioner i baggrunden sættes på pause, så kun én
VPC-session er aktiv - lidt irriterende, når der er masser af
swapper-plads.
Jeg bruger forøvrigt WSeB med fixpack 2 eller 3.
--
Mvh. Kim Ludvigsen
| |
Mikkel C. Simonsen (02-05-2003)
| Kommentar Fra : Mikkel C. Simonsen |
Dato : 02-05-03 00:52 |
|
Kim Ludvigsen wrote:
>
> Efter jeg har ændret config.sys med VIRTUALADDRESSLIMIT=3072 (tak for
> tippet) opstår problemet ikke længere. VPC løber dog stadig ind i et
> problem i form af manglende hukommelse, når den fysiske RAM er opbrugt,
> men jeg kan forestille mig, at det er et problem i VPC. Problemet viser
> sig ved, at VPC-sessioner i baggrunden sættes på pause, så kun én
> VPC-session er aktiv - lidt irriterende, når der er masser af
> swapper-plads.
Så vidt jeg har forstået bruger VirtualPC ikke virtuel hukommelse men
fysisk hukommelse, så din swap-fil er helt irellevant. Derfor skal man,
hvis man bruger VirtualPC, have rigtig meget RAM...
Venlig hilsen
Mikkel C. Simonsen
> Jeg bruger forøvrigt WSeB med fixpack 2 eller 3.
Og jeg bruger Warp4 fp9!
| |
Bent Nielsen (14-04-2003)
| Kommentar Fra : Bent Nielsen |
Dato : 14-04-03 21:58 |
|
Kim Ludvigsen wrote:
> Ja, jeg ved godt at emnelinjen er lidt speciel, for det er generelt
> svært at bruge al rammen med OS/2 på en nyere maskine. Det hjælper dog,
> hvis man har installeret VPC og kører en eller flere sessioner med
> Windows.
>
> Mit problem er, at jeg har 1024 MB ram i dyret, men når jeg kommer ned
> på kun at have 300-400 MB fri ram, så får jeg en meddelelse om, at der
> ikke er nok hukommelse. Indtil i dag er fejlen kun opstået, når jeg har
> kørt flere Windows'er, hvor VPC så sætter alle undtagen den aktive på
> pause. Men nu har jeg lige været ude for, at jeg ikke kan starte flere
> OS/2-programmer, fordi der ikke er nok ledig hukommelse.
>
> Hvad sker der? Og hvordan kan jeg undgå den fejl? Jeg havde lidt over
> 300 MB fri ram og mange GB fri plads til swapfilen.
>
defaults to 1GB, but can be tuned via the Config.Sys
variable "VIRTUALADDRESSLIMIT=3072
It appears to also work from a command prompt:
set VIRTUALADDRESSLIMIT will give you set VIRTUALADDRESSLIMIT=(null), and
set VIRTUALADDRESSLIMIT=3072 appears to be a supported command.
| |
|
|