mdh@srhqla.SR.COM (Matt Hardin) (07/26/89)
In article <1335@esquire> writes: >What is a reasonable amount of swap space to allocate for a machine >with a fair amount of memory? > >I used to feel (for reasons unknown) that twice as much swap space as >real memory was reasonable--but does that make any sense when you have >256 megabytes of memory? I heard the same story from RTOC (about swap to memory ratio), which was later strongly refuted. I guess there's no real foundation for that "rule of thumb". I was told to allocate enough swap so that all processes that would be active at once could be swapped out. It worked out to about twice the amount of physical memory (grin!). >I'm asking because the standard 'b' partition on Pyramid's layout for >the 1 gigabyte NEC 2363 drive is 30 megabytes. That seems a bit stingy >and I'm wondering what to do about it. Should I create my own (larger) >partitions (which I'm doing anyhow for other disks)? Don't change the partitioning for your system drive. The guy who installed our system (from Pyramid, no less) did that and it caused me nothing but grief when the first PTF tape came along and replaced conf.c. Blooey! There went our modified partitions! It also replaced /etc/disktab (I found out later), causing disktab's version of the partitioning to revert back to normal. What I am doing now is using both the b and c partitions as swap by issuing a swapon command for each partition (really I just defined partitions b and c as swap in /etc/fstab, but it works out the same way). This gives us ample swap space for our machine. What took me by surprise was that you could issue two or more swapon commands! I get to keep my standard partitions and have as much swap space as I need! >If it matters at all, this is for OSx5.0 on a MIServer. The folks at Pyramid may have something to say about the performance of this type of configuration. I know I'd like to hear how it compares to using just one big swap partition... Matt Hardin mdh@SR.COM
rick@uunet.UU.NET (Rick Adams) (07/26/89)
The amount of swap space that you need is totally dependant on your job load. E.g. I have 64 megbytes of main memory (on A Sequent S81) and can't even conceive of keeping the system running with 128 meg of swap. I have over 600 megabytes of swap space. The only rule that makes any sense at all is main memory + swap space must be greater than the sum of the memory use of all the processes on your system at peak load. (This is obvious if you think about it.) If by coincidence, that makes swap space be twice your main memory, fine. However, it IS a coincidence and is a bad "rule of thumb" to go by. ---rick
csg@pyramid.pyramid.com (Carl S. Gutekunst) (07/26/89)
In article <61633@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >The amount of swap space that you need is totally dependant on your job >load.... The only rule that makes any sense at all is main memory + swap >space must be greater than the sum of the memory use of all the processes >on your system at peak load. (This is obvious if you think about it.) Almost. Swap space and main memory do *not* add together on a demand-paged virtual memory system; swap space alone must be greater than the sum of all processes running on the system. The general rule back in ye olden days was that you allocated enough swap space to cover all your concurrently running processes, then bought as much RAM as you could afford. This meant a lot of paging (or swapping, back in those days). If the system thrashed too much, you tightened your belt and bought more RAM. These days in commercial installations, the goal seems to be to have enough RAM so that you don't page, and/or so response time is minimized. A trans- action processing system with 100 users that does one database query per user every 15 seconds would probably want at least 100MB of swap space, but might see no difference between 16MB RAM and 32MB RAM. My rule of thumb: 1MB of swap space per login user. 1MB of RAM per *active* user, plus 4MB for the kernel. Remember that users with windowing terminals (AT&T 630 or X Server) count as several users. And make adjustments for mongo sized applications that eat a horrific amount of memory, like FrameMaker. And as the folks at Silent Radio pointed out, please do not fiddle with the default disk partitions. It is easy to do, but a big headache for the service techs. Far better is to just use different or multiple partitions. When using multiple swap partitions, putting then on different drives is a big win. <csg>
steve@polyslo.CalPoly.EDU (Steve DeJarnett) (07/27/89)
In article <1115@srhqla.SR.COM> mdh@srhqla.UUCP (Matt Hardin) writes: >In article <1335@esquire> writes: >>I used to feel (for reasons unknown) that twice as much swap space as >>real memory was reasonable--but does that make any sense when you have >>256 megabytes of memory? >>I'm asking because the standard 'b' partition on Pyramid's layout for >>the 1 gigabyte NEC 2363 drive is 30 megabytes. That seems a bit stingy >>and I'm wondering what to do about it. Should I create my own (larger) >>partitions (which I'm doing anyhow for other disks)? > >Don't change the partitioning for your system drive. The guy who installed >our system (from Pyramid, no less) did that and it caused me nothing but grief >when the first PTF tape came along and replaced conf.c. Blooey! There went our >modified partitions! It also replaced /etc/disktab (I found out later), >causing disktab's version of the partitioning to revert back to normal. You can change your partitioning, but that's one more thing you have to check every time you install a PTF or an upgrade. Having been burned by PTF's once (/dev/null was recreated as a 2 byte long file -- needless to say, it grew rapidly :-( Therefore, the moral is: ALWAYS check what the PTF does before installing it. Look at all of the files it changes. If it's changing something that you think it has no business changing, stop and make a backup copy of that file (they've also been known to replace /etc/rc.local :-( >What I am doing now is using both the b and c partitions as swap by >issuing a swapon command for each partition (really I just defined partitions >b and c as swap in /etc/fstab, but it works out the same way). This gives us >ample swap space for our machine. What took me by surprise was that you could >issue two or more swapon commands! I get to keep my standard partitions and >have as much swap space as I need! If you have multiple drives, you also should spread the swap partitions across the drives. We have three Eagles with 3 b partitions used for swap (on a 98x with 26 Meg of physical memory -- so much for 2x physical -- our swap is closer to 3x physical). What it all boils down to is you need enough swap space to hold every job you might conceivably have running at any time (well, that's a bit of an overstatement, but you get the idea). If all you do is compile-edit-run, you can probably make do with 30 or 40 Meg of swap, provided you don't have 200 people doing these compile-edit-run jobs simultaneously. On our system, it usually works out to about 3 Meg of swap per user on the system. Your mileage will vary. > Matt Hardin > mdh@SR.COM ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | -------------------------------------------------------------------------------
) (07/27/89)
In article <78696@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >Swap space and main memory do *not* add together on a demand-paged >virtual memory system; swap space alone must be greater than the sum of all >processes running on the system. This is true for the 4BSD VM system, but not VM systems in general. In SunOS 4.x (and SVR4) it's perfectly reasonable for swap space to be smaller than physical memory. -- David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@sun.com
eric@pyramid.pyramid.com (Eric Bergan) (07/27/89)
In article <78696@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >In article <61633@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >>The only rule that makes any sense at all is main memory + swap >>space must be greater than the sum of the memory use of all the processes >>on your system at peak load. (This is obvious if you think about it.) > >Almost. Swap space and main memory do *not* add together on a demand-paged >virtual memory system; swap space alone must be greater than the sum of all >processes running on the system. Since the original posting asked about an OSx 5.0 system, this is not correct. In OSx 5.0, main memory and swap space are concatenated together as storage for processes. It is possible to run a machine with less swap space than memory. So even though you might have 256Mbytes of memory (or 1Gbyte after the 4Meg chips come out), you could still stick with a single b partition (~30Mbytes) if you wanted to. >These days in commercial installations, the goal seems to be to have enough >RAM so that you don't page, and/or so response time is minimized. A trans- >action processing system with 100 users that does one database query per user >every 15 seconds would probably want at least 100MB of swap space, but might >see no difference between 16MB RAM and 32MB RAM. > >My rule of thumb: 1MB of swap space per login user. 1MB of RAM per *active* >user, plus 4MB for the kernel. Remember that users with windowing terminals >(AT&T 630 or X Server) count as several users. And make adjustments for mongo >sized applications that eat a horrific amount of memory, like FrameMaker. For database applications, I would use a slightly different formula for RAM computations. Start with 4M for the kernel (remember the good old days of 64K machines? Oh, well). Add a fixed amount of memory equal to about two times the size of the frequently used database indices. Add a per user memory usage that depends on the DBMS being used, and on the front end application. (This can be anything from as little as ~40K per user, to as large as 2-3M bytes.) Stir gently... The fixed amount can be varied - if the indices are too large to all fit in memory, calculate the size of the index minus the bottom level (assuming Btree or variant), and use that instead. Or, if disk IO is a real bottleneck, and the frequently accessed data is small, add more memory and try to get the data itself into memory. One other frequently asked question - unlike some other machines, Pyramid does not store multiple copies of a shared memory segment in swap space. Just one copy is stored, not one per process linked to the segment. (In OSx 5.0, no copy is necessarily stored in swap.) -- eric ...!pyramid!eric
billd@pyrnova (Bill Dana) (07/28/89)
In article <1115@srhqla.SR.COM>, mdh@srhqla.SR.COM (Matt Hardin) writes: > In article <1335@esquire> writes: > >What is a reasonable amount of swap space to allocate for a machine > > What I am doing now is using both the b and c partitions as swap by > issuing a swapon command for each partition (really I just defined partitions > b and c as swap in /etc/fstab, but it works out the same way). This gives us > ample swap space for our machine. What took me by surprise was that you could > issue two or more swapon commands! I get to keep my standard partitions and > have as much swap space as I need! > > The folks at Pyramid may have something to say about the performance of this > type of configuration. I know I'd like to hear how it compares to using just > one big swap partition... > a few notes: #1: If you are swapping, call your pyramid sales rep and buy more memory! $-) #2: If swapping occures, the I/O will be interleaved accross the swap partions in /etc/fstab allocated at boot time. Thus, it is a good idea to use partions on different drives. Using (for example) an 'a' and an 'e' partition on the same drive would be a good exercise in seeking. If you only have one drive, use a single partition. #3: If /etc/swapon is used to add additional swap partitions by hand, interleaving will not be done on the additional drives. IE: swapping would occur on the initial partitions allocated at boot time (interleaved), then on the subsuqent drives configured latter with /etc/swapon. #4: see #1. #5: I have been told this is how swap allocation works; I have not verified it by checking out source, or by observation (I have lots of memory!) #6: see #4. -m------- Bill Dana Performance Analyst ---mmm----- Pyramid Technology Corporation -----mmmmm--- Mountain View, CA whatever!pyramid!billd -------mmmmmmm- U.S.A. billd@pyramid.com
cal@pyrtech (Craig Alan Levin) (07/29/89)
In article <1115@srhqla.SR.COM> mdh@srhqla.UUCP (Matt Hardin) writes: >Don't change the partitioning for your system drive. The guy who installed >our system (from Pyramid, no less) did that and it caused me nothing but grief >when the first PTF tape came along and replaced conf.c. Blooey! There went our >modified partitions! It also replaced /etc/disktab (I found out later), >causing disktab's version of the partitioning to revert back to normal. Aren't we glad that SE for LA is no longer with Pyramid?
mdh@srhqla.SR.COM (Matt Hardin) (08/04/89)
In article <79000@pyramid.pyramid.com> cal@pyrtech.pyramid.com (Craig Alan Levin) writes: >In article <1115@srhqla.SR.COM> mdh@srhqla.UUCP (Matt Hardin) writes: >>[Horror story about changing disk drive partition tables and receiving PTF's] >Aren't we glad that SE for LA is no longer with Pyramid? In all fairness to the LA SE, it was one of Pyramid's own GURUs from Mountain View who set the sytem up for us. The SE here in LA was horrified when she found out what had been done... Matt Hardin mdh@SR.COM