Date: Tue, 23 Apr 2002 09:44:50 -0300 (ADT) From: "Marc G. Fournier" <scrappy@hub.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-current@freebsd.org, <freebsd-stable@freebsd.org> Subject: Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ? Message-ID: <20020423092909.N1721-100000@mail1.hub.org> In-Reply-To: <3CC4C683.F9AEF14E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Apr 2002, Terry Lambert wrote: > "Marc G. Fournier" wrote: > > First, alot of this stuff is slowly sinking in ... after repeatedly > > reading it and waiting for the headache to disapate:) > > > > But, one thing that I'm still not clear on ... > > > > If I have 4Gig of RAM in a server, does it make any sense to have swap > > space on that server also? > > Yes. But it (mostly) does not apply to KVA, only to UVA data, > and there are much larger KVA requirements, so the more RAM you > have, the bigger the bottleneck to user space for anything you > swap. Okay ... to me, a bottleneck generally means slowdown ... so the more RAM I have, the slower the system will perform? > > Again, from what I'm reading, I have a total of 4Gig *aggregate* to > > work with, between RAM and swap, but its right here that I'm confused > > right now ... basically, the closer to 4Gig of RAM you get, the closer > > to 0 of swap you can have? > > No. > > I think you are getting confused on cardinality. You get one KVA, but > you get an arbitrary number of UVA's, until you run out of physical RAM > to make new ones. > > You have 4G aggregate KVA + UVA. > > So if your KVA is 3G, and your UVA is 1G, then you can have 1 3G > KVA, and 1000 1G UVA's. Okay, first question here ... above you say 'arbitrary number of UVAs', but here you state 1000 ... just a number picked out of the air, or is this some fixed limit? > Certain aspects of KVA are non-swappable. Some parts of UVA are > swappable in theory, but never swapped in practice (the page > tables and descriptors for each user process). > > The closer to 4G you have, the more physical RAM you have to spend > on managing the physical RAM. > > The total amount of physical RAM you have to spend on managing > memory is based on the total physical RAM plus the total swap. Okay, this makes sense ... I notice in 4.5-STABLE that if maxusers is set to 0, then the system will auto-tune based on memory ... is this something that also is auto-tuned? > As soon as that number exceeds ~2.5G, you can't do it on a 32 > bit processor any more, unless you hack FreeBSD to swap the > VM housekeeping data it uses for swapping UVA contents. Okay, now here you lost me ... which number exceeds ~2.5G? The "total amount of physical RAM you have to spend"? > Think of physical RAM as a resource. It's seperate from the > KVA and UVA, but the KVA has to have physical references to > do paged memory management. You are limited by how many of > these you can have in physical RAM, total. Okay ... alot of lights came on simultaneously with this email ... some of those lights, mind you, might be false, but its a start ... If I'm understanding this at all ... the KVA (among other things) is a pre-allocated/reserved section of RAM for managing the UVAs ... simplistically, it maintains the "process list" and all resources associated with it ... I realize it does do alot of other things, but this is what I'm more focused on right now ... Now, what exactly is a UVA? You state above '1000 1G UVAs' ... is one process == 1 UVA? Or is one user (with all its associated processes) == 1 UVA? Next, again, if I'm reading this right ... if I set my KVA to 3G, when the system boots, it will reserve 3G of *physical* RAM for the kernel itself, correct? So on a 4G machine, 1G of *physical* RAM will be available for UVAs ... so, if I run >1G worth of processes, that is where swapping to disk comes in, right? Other then the massive performance hit, and the limit you mention about some parts of UVA not being swappable, I could theoretically have >4G of swap to page out to? Is there a reason why this stuff isn't auto-scaled based on RAM as it is? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020423092909.N1721-100000>