From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 16:43:50 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9861616A41A for ; Mon, 15 Oct 2007 16:43:50 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from atl04.ws-e.com (vh00.ws-e.com [69.61.31.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5CC13C45A for ; Mon, 15 Oct 2007 16:43:50 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from lilburn.lefebvre.org (ocee.groupsys.com [66.149.10.161]) by atl04.ws-e.com (8.13.8/8.13.8) with ESMTP id l9FGhnGk072787 for ; Mon, 15 Oct 2007 12:43:49 -0400 (EDT) (envelope-from bill@lefebvre.org) Received: from [10.88.88.6] (milton.lefebvre.org [10.88.88.6]) by lilburn.lefebvre.org (8.13.8/8.13.8) with ESMTP id l9FGhleg061784 for ; Mon, 15 Oct 2007 12:43:47 -0400 (EDT) (envelope-from bill@lefebvre.org) Message-ID: <471398BB.30405@lefebvre.org> Date: Mon, 15 Oct 2007 12:43:39 -0400 From: William LeFebvre User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <008801c80e66$7be49490$0c00a8c0@Artem> <471367F2.7050303@lefebvre.org> <037501c80f3d$69120730$0c00a8c0@Artem> In-Reply-To: <037501c80f3d$69120730$0c00a8c0@Artem> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on lilburn.lefebvre.org X-Scanned-By: MIMEDefang 2.57 on 192.168.0.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (atl04.ws-e.com [69.61.31.90]); Mon, 15 Oct 2007 12:43:49 -0400 (EDT) Subject: Re: Question about 'top' values on memory usage, now threads X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 16:43:50 -0000 Artem Kuchin wrote: > CPU is more than just enough in my case. There will a a lot https > sitting there but load, i am sure, will be low. If the load is low then you may not need very many processes. > Swapping is simply unacceptable, so i am counting only real physical ram. Whether there is actual swapping going on or not, processes will still need swap space. There needs to be a backing store for every page that's in physical memory. For text pages and untouched data pages, the backing store is the executable file itself. For modified data pages there needs to be some place on disk to put a page when the virtual memory system decides it needs more physical pages. This isn't really swapping: its reclaiming infrequently used physical pages when there is something else with a more immediate need, usually called a "page out". When a modified data page is paged out it has to be written somewhere. That somewhere is the swap area. You can say "swapping is unacceptable" and that's fine. But most systems will have page outs: its just a fact of life with virtual memory systems. You can keep adding physical memory to minimize the number of page outs, and that sounds like what you want to do. And its even possible to have sufficient physical memory to ensure all processes remain memory resident. But without knowing the amount of shared virtual memory there is no easy way to determine the amount of physical memory you will need. > > However, noone mentioned anything about threads. DO they give any memory > advantage on freebsd? Yes, threading within httpd should provide a big advantage. The top output snippet you first posted indicates that you are not using threading yet (THR column is 1). Multiple threads in the same process will share the same text and data pages, but will have their own stacks. There may be some data memory overhead in the pthreads library (and within the program itself) to track all the threads, but I believe it will be small compared to the extra memory that additional processes would use. Of course there will be additional stack space required. Finding this overhead is actually easy. Just compare a process's SIZE when running with one thread and again when running multiple threads. Bill LeFebvre