From owner-freebsd-hackers Fri Dec 6 1: 6:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EE8037B406; Fri, 6 Dec 2002 01:06:48 -0800 (PST) Received: from apache.metrocom.ru (www.metrocom.ru [195.5.128.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 971E043EBE; Fri, 6 Dec 2002 01:06:47 -0800 (PST) (envelope-from alex@metrocom.ru) Received: from apache.metrocom.ru (localhost [127.0.0.1]) by apache.metrocom.ru (8.12.6/8.12.6) with ESMTP id gB695cvE001353; Fri, 6 Dec 2002 12:06:40 +0300 (MSK) Received: from localhost (alex@localhost) by apache.metrocom.ru (8.12.3/8.12.3/Submit) with ESMTP id gB5Brk61008568; Thu, 5 Dec 2002 14:53:46 +0300 (MSK) X-Authentication-Warning: apache.metrocom.ru: alex owned process doing -bs Date: Thu, 5 Dec 2002 14:53:46 +0300 (MSK) From: Varshavchick Alexander To: Terry Lambert Cc: , Subject: Re: maxusers and random system freezes In-Reply-To: <3DEF37AF.182DD85@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 5 Dec 2002, Terry Lambert wrote: ... > > Are you talking primarily about SHMMAXPGS=262144 option here? Then may be > > it'll be oevrall better to reduce it and make KVA space 2G, to leave more > > room for user address space? > > That's the one I was referring to, yes, but you didn't post your > whole config (please do *NOT* post it; I can't spend the time on > going over it line by line). > All other config options are pretty much like the default ones. > Tuning is a skill; it can be plotted out as a cookbook recipe, > but it takes a lot of work to do that, and no one has volunteered. > > Basically, to write out a cookbook, you have to know where every > byte of memory is going in the kernel, and what tunables impact > each other, and how they are related. > > Once you know that, you could easily write a program to kick out > a configuration file for various usages, or even modify the code > to auto-tune itself (everything by KVA space, which impacts the > base address that the kernel gets linked to... unless you compile > the entire kernel PIC, which I do not recommend). But knowing > the information is hard. I know it for 4.3 and 4.4. > You're right, expecially for getting an _ideally_ tuned kernel. However in a real life, a specialist cannot have an absolute knowledge about _all_ server and other issues, so practical solutions are being looked for in items which can arise. Of cause, no one is arguing that a basic knowledge is needed and required. ... > If you are having system freeses at random, and you want to fix > them instead of living with them, some experimentation is going > to be inevitable. I don't know enough about your installation > to be able to give you a kernel config file to use that will > magically fix all your current issues for you, and prevent future > issues from coming up. That's going to have to be up to you. > > Surely, I'm just trying to reduce the experimental attempts as much as possible and to rise the chances of success for each new configuration version. ... > > No, the swap is very slightly used on this server, and the total swap > > size is 2G. > > It doesn't matter. The amount of swap the kernel allocates page > tables for is based on the amount of physical RAM in the machine. > You pay for the page tables whether you use them or not, for swap, > for the kernel, and for any memory which you permit to be allocated > at interrupt time, plus any allocations that occur after you are up > and running, until you run out of physical RAM. > > This is "one of those things" you just have to know about how > the kernel uses virtual memory, if you are going to be a skilled > kernel tuner. > > > As a rule, swap should be at least physical memory size + 64K on > any system that you need to be able to get a system dump from, > since it needs to dump physical RAM. If you are not worried about > the machine falling over, then you can ignore that. > > Note that "man tuning" suggests 2* physical RAM for swap. > > PS: I am going to be out of touch (able to download, but not > send email) for the next couple of days... up to a week. If you > have more questions, and they can't wait, you will need to ask > someone else. > Thank you for all your advices, they've already helped a bit. Have luck in your trip or elsewhere. ----- Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message