Re: Default mfs/md fs on /tmp (Was: adding more ram
On Fri, Dec 12, 2003 at 12:00:46PM -0800, [EMAIL PROTECTED] wrote: > Date: Thu, 11 Dec 2003 17:30:32 -0500 > From: Andrew J Caines <[EMAIL PROTECTED]> > > Charles Swiger opined: > > By the time Solaris transitioned from 2.6 to 2.7 (aka Solaris 7), > > having /tmp be memory-based was the default system configuration, and I > > would like to see FreeBSD pursue the same course. > > Seconded. > > I've been using mfs for /tmp since way back (3.x? 2.x?) and on 5.x (which > is configured the same way, but implimented differently) in recent times > and have found it to be nothing but useful and stable, speeding up > numerous things while never obviously significantly impacting overall > performance. I agree with the idea. The late lamented BSD/OS also did this on the default install, from version 1.1 or thereabouts, and it worked very well for typical use. I think it would work well for the typical new FreeBSD user. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Default mfs/md fs on /tmp (Was: adding more ram
Charles Swiger opined: > By the time Solaris transitioned from 2.6 to 2.7 (aka Solaris 7), > having /tmp be memory-based was the default system configuration, and I > would like to see FreeBSD pursue the same course. Seconded. I've been using mfs for /tmp since way back (3.x? 2.x?) and on 5.x (which is configured the same way, but implimented differently) in recent times and have found it to be nothing but useful and stable, speeding up numerous things while never obviously significantly impacting overall performance. One reason for this is that unlike the default all-users-may-swamp-the-vm on Solaris, I limit the size of the mfs to a "small" (relative to RAM) one. If implimented, please default to a sensible size, preferably a small fraction of RAM down to a sane minimum (1 MB). It also avoids the newbie /tmp-on-/ problem. -Andrew- -- ___ | -Andrew J. Caines- Unix Systems Engineer [EMAIL PROTECTED] | | "They that can give up essential liberty to obtain a little temporary | | safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding more ram
On Dec 11, 2003, at 12:01 AM, Robert Watson wrote: [ ... ] Actually, the thing I use swap for most now is to make sure I can allocate large temporary file systems without consuming excessive kernel address space. I.e., I'll often create a 512mb swap-backed md device for /tmp, and make sure I have enough swap to fully back it and everything else, even though the chances are I won't touch it in normal operation. I just don't want to run out in the event something does need it... I first saw this implemented under Solaris via the "tmpfs" filesystem mount type, and I agree with you that it tends to function quite well. By the time Solaris transitioned from 2.6 to 2.7 (aka Solaris 7), having /tmp be memory-based was the default system configuration, and I would like to see FreeBSD pursue the same course. I seem to recall that Solaris sets the paging priority of processes higher than tmpfs so that the system will write out of the contents of the memory-based filesystem rather than reducing process working sets if the system encounters memory pressure. I'm not sure to what extent this is applicable to FreeBSD's md device. Also, will FreeBSD double-buffer md based devices if it does need to scribble their contents to disk, or is something like what Mach calls a "unified buffer cache" available? -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding more ram
On Wed, Dec 10, 2003, Mike Silbersack wrote: > > On Wed, 10 Dec 2003 [EMAIL PROTECTED] wrote: > > > Hi all. > > > > I have a server with 1GB of RAM and a swap partition of 2GB i will upgrade > > the memory server to 2GB so my questions are: > > > > should i fix the swap partition to have now 4GB of space ? > > > > what other changes do i have to make to my system after adding more ram ? > > > > regards. > > Dan's advice seems good; swapping more than a gig of data would be awful. > > I'm replying because I want to answer your real question. The notion > of swap = 2 x ram is an old one, and is no longer applicable. The real reason that 2 * sizeof(RAM) is often an overestimate on FreeBSD is that FreeBSD overcommits swap (as others have pointed out.) Many (most?) other systems do not overcommit, including Solaris. Some systems, such as Tru64 (and Linux???) support both. For these systems, 2 * sizeof(RAM) is sometimes even an underestimate. These days overcommit is actually not very sensible. Even though it tends to overestimate space requirements, disk capacity has outstripped RAM capacity to such an extent that the cost is nominal. The advantage of being more conservative is that you never have to kill processes to save the kernel from deadlock. (Wes recently added a simple feature that improved the situation, but randomly killing processes is still a kludge.) Unfortunately, getting non-overcommit right is hard. In addition to checking available space every time you allocate pageable memory (including things like lazily copied map entries), you also need to be careful to reserve enough space for stacks for each application thread, etc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding more ram
On Wed, 10 Dec 2003, Dan Nelson wrote: > In the last episode (Dec 10), [EMAIL PROTECTED] said: > > I have a server with 1GB of RAM and a swap partition of 2GB i will > > upgrade the memory server to 2GB so my questions are: > > > > should i fix the swap partition to have now 4GB of space ? > > Depends. Have you ever used up that 2gb of swap? If not, you'll > probably never consume 4gb either :) If this is a database server, or > something similar where a few processes allocate large amounts of > memory, you don't need much swap anyway, since if any of those processes > actually has to swap, you end up thrashing the system as it tries to > swap 500mb processes in and out of memory. I really can't think of a > system that would still perform well with 2 or 3GB of process space in > swap. At the 2gb RAM point, you usually have a system where any > swapping == bad news. Actually, the thing I use swap for most now is to make sure I can allocate large temporary file systems without consuming excessive kernel address space. I.e., I'll often create a 512mb swap-backed md device for /tmp, and make sure I have enough swap to fully back it and everything else, even though the chances are I won't touch it in normal operation. I just don't want to run out in the event something does need it... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding more ram
In a message written on Thu, Dec 11, 2003 at 02:42:12AM -, Sparrevohn, Thomas wrote: > The /var size should properly stay as recommended. But a sanity > check on the available space when enabling crash dumps might be a > good idea Right, I didn't want to change the default suggestion, just put near that recomendation that crash dumps may greatly increase /var need, and also mention that in the swap sizing section as to why swap == ram should probably be a minimum (otherwize you can't turn on crash dumps without repartitioning). -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
RE: adding more ram
The /var size should properly stay as recommended. But a sanity check on the available space when enabling crash dumps might be a good idea -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leo Bicknell Sent: 11 December 2003 02:27 To: [EMAIL PROTECTED] Subject: Re: adding more ram Speaking of tuning, it should probably mention a swap partition must be larger than RAM to support crash dumps, and /var needs to have space for nxRAM dumps, where n is how many you want to keep. I've seen too many people with 2G RAM and 1G swap, or a 1G machine with crash dumps enabled and a 128M /var, as recomended. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding more ram
Speaking of tuning, it should probably mention a swap partition must be larger than RAM to support crash dumps, and /var needs to have space for nxRAM dumps, where n is how many you want to keep. I've seen too many people with 2G RAM and 1G swap, or a 1G machine with crash dumps enabled and a 128M /var, as recomended. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: adding more ram
> The same was true for 10.20 and 11 Versions of HPUX - I believe there once > was I very long going debate when the "new" FreeBSD vm was made on the > issue. The fundamental question at the time was what to do when you run out > of swap/vm space. The 1-1 backing of swap space was seen as a way to avoid > that you have resort to kill random processes in order to free up space and > the tradition with the 2-1 swap ratio used to have "a performance reason" > in the initial Unix Swap and paging implementations. I can't seem to recall > the actual reason While we're at this topic, can somebody plz briefly explain how does swap performance depend on swap size? From `man 7 tuning` (May 25, 2001): The kernel's VM paging algorithms are tuned to perform best when there is at least 2x swap versus main mem- ory. Configuring too little swap can lead to inefficiencies in the VM page scanning code as well as create issues later on if you add more mem- ory to your machine. Is this still true? For -CURRENT also? 10.12.2003; 18:42:17 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: adding more ram
The same was true for 10.20 and 11 Versions of HPUX - I believe there once was I very long going debate when the "new" FreeBSD vm was made on the issue. The fundamental question at the time was what to do when you run out of swap/vm space. The 1-1 backing of swap space was seen as a way to avoid that you have resort to kill random processes in order to free up space and the tradition with the 2-1 swap ratio used to have "a performance reason" in the initial Unix Swap and paging implementations. I can't seem to recall the actual reason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Vermillion Sent: 10 December 2003 14:41 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: adding more ram While normally not able to pour water out of a boot with instructions on the heel, on Wed, Dec 10, 2003 at 02:41 our dear friend Mike Silbersack uttered this load of codswallop: Just one slight addendum here. > I'm replying because I want to answer your real question. > The notion of swap = 2 x ram is an old one, and is no longer > applicable. (Some) older VM systems used very simplistic swapping > mechanisms, which required entire processes to be swapped, thereby > requiring large amounts of swap space. FreeBSD (and other modern OSes) > page out to the swap file in increments of 4K pages, and do so in a > flexible manner. As a result, you should always have *some* swap space > to handle overload cases, but it's not necessary to keep any specific > ram to swap ratio. Systems such as the Irix I used before moving the servers to FBSD around 1996 - reserverd swap space for applications when the application started up so those needed large swap space. Often it was never used, but the design allocated it anyway. Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding more ram
On Wed, Dec 10, 2003 at 09:41:11AM -0500, Bill Vermillion wrote: > Systems such as the Irix I used before moving the servers to FBSD > around 1996 - reserverd swap space for applications when the > application started up so those needed large swap space. Often it > was never used, but the design allocated it anyway. I also remember what fun could be had on an IRIX 5.3 machine with leaky X11 servers. SGI's Xsgi memory leaks on that IRIX release were particularly noticeable when using it on a 24-bit Indy and viewing lots of porn^Wgraphics. This seemed to be down to Xsgi reserving lots of swap in lieu of a heavy backing store workload, which it didn't actually use. And this often brought Xsgi crashing to a halt anyway. So I would have mixed feelings about adopting such a scheme in future. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding more ram
While normally not able to pour water out of a boot with instructions on the heel, on Wed, Dec 10, 2003 at 02:41 our dear friend Mike Silbersack uttered this load of codswallop: Just one slight addendum here. > I'm replying because I want to answer your real question. > The notion of swap = 2 x ram is an old one, and is no > longer applicable. (Some) older VM systems used very simplistic > swapping mechanisms, which required entire processes to be > swapped, thereby requiring large amounts of swap space. FreeBSD > (and other modern OSes) page out to the swap file in increments > of 4K pages, and do so in a flexible manner. As a result, you > should always have *some* swap space to handle overload cases, > but it's not necessary to keep any specific ram to swap ratio. Systems such as the Irix I used before moving the servers to FBSD around 1996 - reserverd swap space for applications when the application started up so those needed large swap space. Often it was never used, but the design allocated it anyway. Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding more ram
On Wed, 10 Dec 2003 [EMAIL PROTECTED] wrote: > Hi all. > > I have a server with 1GB of RAM and a swap partition of 2GB i will upgrade > the memory server to 2GB so my questions are: > > should i fix the swap partition to have now 4GB of space ? > > what other changes do i have to make to my system after adding more ram ? > > regards. Dan's advice seems good; swapping more than a gig of data would be awful. I'm replying because I want to answer your real question. The notion of swap = 2 x ram is an old one, and is no longer applicable. (Some) older VM systems used very simplistic swapping mechanisms, which required entire processes to be swapped, thereby requiring large amounts of swap space. FreeBSD (and other modern OSes) page out to the swap file in increments of 4K pages, and do so in a flexible manner. As a result, you should always have *some* swap space to handle overload cases, but it's not necessary to keep any specific ram to swap ratio. (Actually, the term "swapping" is still used inside the FreeBSD kernel, but it only applies to paging out the last 20K or so of a process's memory.) Now, to contradict myself, there *is* a reason that you might wish to have a larger swapfile. Taking a crashdump requires that the swap file must be of the size RAM + 64K or so. Hence, your present swap file might be slightly too small to take a crashdump once you upgrade to 2G ram. Whether this is an issue for you or not depends on how often your machine crashes and whether you wish to debug it. :) Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding more ram
In the last episode (Dec 10), [EMAIL PROTECTED] said: > I have a server with 1GB of RAM and a swap partition of 2GB i will > upgrade the memory server to 2GB so my questions are: > > should i fix the swap partition to have now 4GB of space ? Depends. Have you ever used up that 2gb of swap? If not, you'll probably never consume 4gb either :) If this is a database server, or something similar where a few processes allocate large amounts of memory, you don't need much swap anyway, since if any of those processes actually has to swap, you end up thrashing the system as it tries to swap 500mb processes in and out of memory. I really can't think of a system that would still perform well with 2 or 3GB of process space in swap. At the 2gb RAM point, you usually have a system where any swapping == bad news. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
adding more ram
Hi all. I have a server with 1GB of RAM and a swap partition of 2GB i will upgrade the memory server to 2GB so my questions are: should i fix the swap partition to have now 4GB of space ? what other changes do i have to make to my system after adding more ram ? regards. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
