(Illustration by Gaich Muramatsu)
It's also worth pointing out that some database servers statically link their binaries to remove shared libraries from the "middle" of the address space. This should give you considerably more. - Peter - On Tue, 18 Jan 2000, Jan Harkes wrote: > On Tue, Jan 18, 2000 at 10:37:40AM -0800, Phil Nelson wrote: > > > > >I just wish to know what is the optimum configuration I can have on a > > >42G Raid drive. I have 256M of RAM and a local SCSI drive of 9G and > > >an external RAID of 42 GBHDD. Its a PIII500MMX IBM Box. /vicepa will > > >be on the external raid while the rest on the local drive. > > > For a 42GHDD , I need about 1.7G of RVM according to the 4% rule and what > > >about the Log size? Does my swap partition plays a part here for the RVM?? > > >How much space should I allocate? > > > > > >With 1.7G of RVM , do I need to run rdsinit instead of vice-setup-rvm?? > > > > I haven't heard of a server of this size yet. Since is is not one of > > the standard setups in vice-setup-rvm, you would have to init RVM yourself. > > I did it for a 6G server (also not one of the standard sizes.) > > > > A big problem you may have is the startup time with such a large RVM, IF > > you have enough VM space to map it in the first place. This can be helped > > by using a relatively new flag, "-mapprivate", for the server. I believe > > it is in coda 5.3.4, but I'm not sure. > > Yes mapprivate is available in the 5.3.4 release. One caveat, it only > works when RVM is stored in a file. > > You actually need to play with the address where rvm is mapped. We > currently map it at 0x20000000. Linux places shared libraries and other > memory mapped files at 0x40000000, which limits the usable area for RVM > to about 512MB. > > By moving the address where RVM is mapped to 0x41000000, you'll put it > above the libraries where there is room to 0xbff00000 before you hit the > stack. That gives about 2031MB of available space. > > Check /proc/`pidof codasrv`/maps to see how the memory map is layed out. > > Jan >Received on 2000-01-19 12:58:08