Date: Sat, 16 Nov 1996 00:26:46 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: iwanleo@usa.net (Iwan Leonardus) Cc: dwhite@resnet.uoregon.edu, questions@freebsd.org Subject: Re: Questions Message-ID: <199611160526.AAA00252@dyson.iquest.net> In-Reply-To: <328D40EB.41C67EA6@usa.net> from "Iwan Leonardus" at Nov 16, 96 11:19:55 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Thanks for the answer, but I was not asking about X windows > configurations. > What I want to know is: > Kernel memory configuration, so when I want the machine to function as > server, > what should I do to make the machince run as server with maximum speed. > It also goes when I want it to do desktop oriented, cache usage for this > and > that, like "configure" at SCO unix. > This is by no means complete -- so here are some opinions: FreeBSD V2.1.X and V2.2 dynamically allocates alot of the kernel memory items. We don't do a very good job of dynamically allocating the vnode usage (and there are some tunables to help there.) Also, memory above 64M won't be automatically detected. The buffer cache is almost totally dynamic. There are some tunables that can help alittle bit in strange situations, but it is best to leave them alone generally. Our buffer caching system limits the number of dirty buffers so that you won't swamp your hard drives as much as with other systems when sync time comes around. We are still considering various design tradeoffs in that arena, but suffice it to say that there isn't that much to be tuned in the buffer caching area -- simply because the system tunes it all of the time (and does a pretty good job of it.) Here is the LINT config file from something approaching -current, with some comments as to what to remove added by me with a JSD prefix. I am leading off first with some undocumented LINT items that should be added: # # JSD: these allow running larger procs # options "MAXDSIZ=200000000" options "DFLDSIZ=200000000" # # JSD: some server apps need lots of SHM, in -current there are now # almost no limitations to the size of SHM!!! # options "SHMMAXPGS=1000" ### JSD: the following are useful, documented options: # # JSD: size of memory: here is an alloc for 80MB total: # options "MAXMEM=81920" machine "i386" #JSD get rid of the I386_CPU if you can... #cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" # aka Pentium(tm) cpu "I686_CPU" # aka Pentium Pro(tm) #JSD increase maxusers, because it helps with certain caching/net params. # for servers, try 64 or larger. maxusers 10 #Certain server apps like more of these options CHILD_MAX=128 options OPEN_MAX=128 # # JSD: do this almost out of reflex: # # Under some circumstances it is useful to have an extra number of # vnode data structures allocated at boot time. In particular, # usenet news servers can benefit if there are enough vnodes to # cache the busiest newsgroup and overview directories. Beware that # this is an expensive option, it consumes physical non-pageable ram. # A busy news server may benefit from 10,000 extra vnodes or so. # options EXTRAVNODES=1 # # JSD: get rid of this option if you want higher perf (depending on # interfaces that you are using.) # # When this is set, be extra conservative in various parts of the kernel # and choose functionality over speed (on the widest variety of systems). #options FAILSAFE # JSD: these can help for Pentiums: # When this is set, bcopy() will use an unrolled loop using # floating point registers. It makes bcopy() run 30-100% # faster on Pentiums and makes no difference or slower on non-Pentium # (including P6) systems. # # However, even when this is set, there is a run-time check for CPU # type so the routine will never be invoked for a wrong architecture. # It will become the default after some testing period. options "I586_OPTIMIZED_BCOPY" # This is like I586_OPTIMIZED_BCOPY except it controls bzero(). options "I586_OPTIMIZED_BZERO" # JSD: Lots of SVR3/4 apps like to have these: # # These three options provide support for System V Interface # Definition-style interprocess communication, in the form of shared # memory, semaphores, and message queues, respectively. # options SYSVSHM options SYSVSEM options SYSVMSG #JSD: These make the kernel bigger, but can help us find probs for you # # Enable the kernel debugger. # options DDB # # Don't drop into DDB for a panic. Intended for unattended operation # where you may want to drop to DDB from the console, but still want # the machine to recover from a panic # options DDB_UNATTENDED # # JSD: for a server app -- this can hurt perf, get rid of it!!! # # # The DIAGNOSTIC option is used in a number of source files to enable # extra sanity checking of internal structures. This support is not # enabled by default because of the extra time it would take to check # for these conditions, which can only occur as a result of # programming errors. # #options DIAGNOSTIC # # JSD: certain servers need lots more pty's -- for example remote # shell servers: # pseudo-device pty 16 #Pseudo ttys - can go as high as 256
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611160526.AAA00252>