From owner-freebsd-stable@FreeBSD.ORG Mon Nov 29 15:55:10 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D80F216A4CE for ; Mon, 29 Nov 2004 15:55:10 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F85B43D1F for ; Mon, 29 Nov 2004 15:55:10 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.250] (pool-68-161-115-118.ny325.east.verizon.net [68.161.115.118]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id iATFsnoc042983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Nov 2004 10:54:51 -0500 (EST) Message-ID: <41AB4643.90807@mac.com> Date: Mon, 29 Nov 2004 10:54:43 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan Voras References: <41A60264.30109@fer.hr> <41AA6F6E.1080809@mac.com> <20041129004546.GA1541@k7.mavetju> <41AAF2BE.7030800@fer.hr> In-Reply-To: <41AAF2BE.7030800@fer.hr> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.6 required=5.5 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on pi.codefab.com cc: Edwin Groothuis cc: stable@freebsd.org Subject: Re: Huge slapd? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 29 Nov 2004 15:55:11 -0000 Ivan Voras wrote: > Edwin Groothuis wrote: >> On Sun, Nov 28, 2004 at 07:38:06PM -0500, Chuck Swiger wrote: [ ... ] >>>> I know that the actually used memory size is the 6MB figure above, >>>> but why does it allocate almost 150MB? Is it normal? >>> >>> This sounds like a classic example of a memory leak. >> >> Had the same before I moved to openldap 2.2 > > I should have said - this *is* openldap 2.2, from a week ago, on 5-stable. You can work around the problem to some extent by making sure the system has plenty of swap space available, and/or by restarting slapd on a regular basis (weekly or even nightly). However, the real solution involves identifying what is leaking and having the authors of LDAP fix that problem. You can use gdb to attach to the process and examine memory in order to get some clues as to what is going on. You can link slapd against a malloc debuuging tool like Purify or dmalloc, however, I would really like to see a tool for FreeBSD which resembles "leaks" under MacOS X: 1-base# leaks syntax: leaks 1 ... n {-exclude }* to exclude specific symbols With -nocontext, the hex dump of leaked memory is supressed. If the target ran with 'setenv MallocStackLogging 1, then the call stack leading to the allocation is shown. With -nostacks, the call stack for the allocation is supressed. 2-base# psg zsh root 9474 0.0 0.2 28172 1236 std Ss 10:45AM 0:00.30 zsh 3-base# leaks 9474 Process 9474: 3703 nodes malloced for 125 KB Process 9474: 0 leaks for 0 total leaked bytes. 4-base# psg syslogd root 78 0.0 0.0 18092 188 ?? Ss 19Aug04 18:42.23 /usr/sbin/syslogd -s -m 0 5-base# leaks 78 Process 78: 284 nodes malloced for 38 KB Process 78: 232 leaks for 5568 total leaked bytes. Leak: 0x001018f0 size=32 0x00000000 0x00000002 0x00000002 0x00000011 0x00000010 0x00000000 0x001018b0 0x00000000 Leak: 0x001018c0 size=32 0x00000000 0x00000002 0x00000002 0x00000011 0x00000010 0x00000000 0x00101880 0x00000000 [ ... ] Is there anything like this available for FreeBSD? -- -Chuck