Date: 08 Oct 2002 23:39:52 +0400 From: "Vladimir B. " Grebenschikov <vova@sw.ru> To: Nate Lawson <nate@root.org> Cc: arch@FreeBSD.org Subject: Re: using mem above 4Gb was: swapon some regular file Message-ID: <1034105993.913.1.camel@vbook.express.ru> In-Reply-To: <Pine.BSF.4.21.0210081209010.11243-100000@root.org> References: <Pine.BSF.4.21.0210081209010.11243-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=F7 Tue, 08.10.2002, =D7 23:10, Nate Lawson =CE=C1=D0=C9=D3=C1=CC: > On 8 Oct 2002, Vladimir B. Grebenschikov wrote: > > =F7 Tue, 08.10.2002, =D7 19:50, Mikhail Teterin =CE=C1=D0=C9=D3=C1=CC: > > > On Tuesday 08 October 2002 11:41 am, Terry Lambert wrote: > > > =3D Terry Lambert wrote: > > > =3D > So whatever connections you are getting now... halve that, or l= ess, > > > =3D > to get a window for your RAM disk (you will need KVA for mappin= gs > > > =3D > for all the memory that *can* be in the window, etc.). > > > =3D=20 > > > =3D To emphasize this: if you are using 4K pages, you will need: > > > =3D=20 > > > =3D 4K/1M * 64G =3D 256M > > > =3D=20 > > > =3D ...1/4 of 1G of memory outside the window, just for page tables. > > > =3D=20 > > > =3D Also, if we still were using an mbuf per connection for the > > > =3D template, for 1,000,000 connections, that's 256M of RAM -- anothe= r > > > =3D 1/4 gig. > > > =20 > > > =3D Yeah, most people don't think in these terms; personally, I like > > > =3D to call it "Extreme BSD". 8-). > > >=20 > > > Although this is fascinating read -- it getting further and further a= way > > > from the original subject. And from the modified one too -- I don't > > > believe Vladimir said anything about networking... > >=20 > > Exactly, Terry is right about large number of relative-small > > network-access processes (say apaches). But there are some other cases, > > say you have some DB server with huge index, say 10Gb, I think keep > > index in RAM effective than on disk. >=20 > It's often surprisingly effective to just access the index on disk and > tune your VM cache instead. You can lose performance by double-caching > data. I don't want cache disk data in extra memory - simply store index in RAM (no disk access at all) - I think it must be faster. > -Nate --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1034105993.913.1.camel>