Date: Fri, 07 Jul 2006 12:16:33 -0500 From: Kevin Kinsey <kdk@daleco.biz> To: Worth Bishop <wbishop@twosensemedia.com> Cc: questions@freebsd.org Subject: Re: Unable to boost maxusers in custom kernel. Message-ID: <44AE96F1.7020005@daleco.biz> In-Reply-To: <017501c6a1dc$ef59e1c0$0801000a@S0030153310> References: <009201c6a14d$60ffac00$0801000a@S0030153310> <44AE1721.2010000@daleco.biz> <017501c6a1dc$ef59e1c0$0801000a@S0030153310>
next in thread | previous in thread | raw e-mail | index | archive | help
Worth Bishop wrote: > Thanks Kevin - > >> First, I guess, be sure that it's using the file >> you're specifying. > > I've sure wondered about this. As I've compiled & installed the custom > kernels, I've watched the changes in the size & date/time stamp to the > /kernel binary file. It's definitely changing, and I think I've done > everything I'm supposed to to tell the system what kernel file to use. > I've gone so far as to copy the /kernel file into /kernel.GENERIC > (keeping a backup kernel.GENERIC) with the same results. > > What troubles me is that every time I reboot I see: FreeBSD 4.3-RELEASE > #0: Sat Apr 21 10:54:49 GMT 2001 > jkh@narf.osd.bsdi.com:/usr/src/sys/compile/GENERIC in the messages. I > don't see :/usr/src/sys/compile/MYKERNEL, even though I've changed the > ident line and every other reference to GENERIC I can find in the > configuration file to MYKERNEL. > This is the output of "uname -a", I'm quite sure, and therefore is a reference to the userland, and the kernel that was in place when it was built. If the kernel has a different date/time, etc., then you've built it just fine...question is, what's up with the MAXUSERS thing. > What else can I do to ensure that the system is using the kernel I > intend it to use? > That's about it. > I've not tried setting maxusers to "0" but will. And as for > patches...well, I kind of inherited this system and am guessing patches > have been sporadically applied if at all. My own expertise is all OJT > and what I've gleaned from manuals, online help, folks like you, etc. My > inclination is to upgrade ASAP to newest release, but as this is a > production system with no hot spare and those who control it are > fanatically opposed to any downtime...it may need to reach crisis point > before that can be done. > > Thanks again for any suggestions! > > Worth Bishop > I'm not sure I've any further suggestions. I've pretty much decided to keep close to updated; however, and somewhat unfortunately perhaps, I've no boxes so "busy" and "mission-critical" that they can't be rebooted now and again..... Kevin Kinsey > ----- Original Message ----- From: "Kevin Kinsey" <kdk@daleco.biz> > To: "Worth Bishop" <wbishop@twosensemedia.com> > Cc: <freebsd-questions@freebsd.org> > Sent: Friday, July 07, 2006 4:11 AM > Subject: Re: Unable to boost maxusers in custom kernel. > > >> Worth Bishop wrote: >>> Running FreeBSD 4.3 (I know - upgrade on the way, but would like to >>> know what's going on here for future ref), on AMD Athlon MP 1600 >>> (1393.79-MHz 686-class CPU) with 1.5 Gb RAM. Ran up against 'too many >>> files' problem, dropped packets, maxing out mbuf's, proc files, etc. >>> >>> Attempted to compile custom kernel based on GENERIC only by changing >>> maxusers from 32 to (first) 512, then 256, then 128. No matter what, >>> system rebooted with 32 maxusers, 4096 mbugs, 1024 max mbuf clusters, >>> 1024 maxfiles. Can reset maxfiles via sysctl, but why won't maxusers >>> stick? >>> >>> Have tried building both with: >>> >>> # /usr/sbin/config MYKERNEL >>> # cd ../../comple/MYKERNEL >>> # make depend >>> # make >>> # make install >>> # reboot >>> >>> and with >>> >>> # cd /usr/src >>> # make buildkernel KERNCONF=MYKERNEL >>> # make installkernel KERNCONF=MYKERNEL >>> # reboot >>> >>> No discernable error messages. >>> >>> What am I missing? >>> >> >> First, I guess, be sure that it's using the file >> you're specifying. >> >> Next, hmm, per the Handbook, have you tried "0" (to let >> the system "auto-tune" itself?) >> >> That said, after 4.5*, you can set this variable in >> /boot/loader.conf ... I've no idea ATM whether or not >> this behavior was "MFC'ed" back into your code stream >> or not ... (surely you're not running 4.3 UNPATCHED<?!!>) >> you may wish to check /boot/defaults/loader.conf for >> evidence of this theory, and, if you find it, give that >> a try as well. >> >> >> HTH, >> >> Kevin Kinsey >> >> *This information isn't in the handbook (I don't think ... >> I sent a doc PR a day or two ago on it due to a post >> here by someone who was having troubles in the same >> area, I guess...). > > > > -- No problem is insoluble in all conceivable circumstances.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44AE96F1.7020005>