From owner-freebsd-ports@FreeBSD.ORG Sun Sep 7 08:20:38 2003 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91D0A16A4BF; Sun, 7 Sep 2003 08:20:38 -0700 (PDT) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id F225743FA3; Sun, 7 Sep 2003 08:20:36 -0700 (PDT) (envelope-from anders@fix.no) Received: by totem.fix.no (Postfix, from userid 1000) id 95B702024A; Sun, 7 Sep 2003 17:20:51 +0200 (CEST) Date: Sun, 7 Sep 2003 17:20:51 +0200 From: Anders Nordby To: Mike Harding Message-ID: <20030907152051.GA44042@totem.fix.no> Mail-Followup-To: Anders Nordby , Mike Harding , stable@FreeBSD.org, ports@FreeBSD.org, adrian@freebsd.org, tjr@FreeBSD.org, phk@FreeBSD.org References: <20030906141108.GA13082@totem.fix.no> <20030906151719.A83B65350@netcom1.netcom.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <20030906151719.A83B65350@netcom1.netcom.com> X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 X-message-flag: Outlook : A program to spread viri, but it can do mail too. User-Agent: Mutt/1.5.1i cc: ports@FreeBSD.org cc: stable@FreeBSD.org cc: adrian@freebsd.org cc: tjr@FreeBSD.org cc: phk@FreeBSD.org Subject: Re: Squid memory leaks in -stable using libc malloc X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2003 15:20:38 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Sat, Sep 06, 2003 at 08:17:19AM -0700, Mike Harding wrote: > Squid uses more memory than you assign to cache_mem, this is > documented in the Squid FAQ, section 8. cache_mem is sort of a > 'suggested' value, it's normal for squid to use a lot more memory than > cache_mem. I know this, and I know the contents of the FAQ. However, there's a huge difference between what top reports as memory used (SIZE) and what cache manager reports as total allocated KB. In a running process I have just now, top says Squid uses 1235 MB of memory, while cache manager reports 663 MB allocated (contents of /proc//map attached). That's after running for around 10 hours. If I use dlmalloc (I do on one system), the numbers are 2291 MB according to top and 2221 MB according to cache manager after running for 30 hours. Do you see the difference? To me, there seems to be a leak, or at least very unfavourable results with phkmalloc and Squid. BTW, in the first example I gave here, I (still) use phkmalloc with H configured in malloc.conf, although H did not seem to make a difference. > If you are happy with dmalloc, though, go ahead and use it, just check > out the squid FAQ about memory usage. I don't think that there is > anything wrong with FreeBSD's malloc, it just has different > performance characteristics. I agree that there doesn't have to be something technically wrong with (phk)malloc. However, if there is, someone may have an interest in following this up (tjr@ seems to be - I talked to him on IRC about this). Cheers, -- Anders. --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=map 0x8048000 0x80d6000 125 0 0xf2d28b40 r-x 4 2 0x0 COW NC vnode 0x80d6000 0x80d7000 1 0 0xf2d28240 rw- 1 0 0x2180 COW NNC vnode 0x80d7000 0x81f6000 241 0 0xf2de6e40 rw- 1 0 0x2180 COW NNC default 0x81f6000 0x842b000 561 0 0xf2de6de0 rwx 1 0 0x2180 COW NNC default 0x842b000 0x8776000 843 0 0xf2de6d80 rwx 1 0 0x2180 COW NNC default 0x8776000 0x8777000 1 0 0xf2de6cc0 rwx 1 0 0x2180 COW NNC default 0x8777000 0x54f54000 313309 0 0xf2dd3c60 rwx 1 0 0x2180 NCOW NNC default 0xb70d6000 0xb70e8000 12 0 0xc044f680 r-x 53 26 0x0 COW NC vnode 0xb70e8000 0xb70e9000 1 0 0xf2d71300 rw- 1 0 0x2180 COW NC vnode 0xb70e9000 0xb70eb000 2 0 0xf2d7a1e0 rw- 1 0 0x2180 COW NNC default 0xb70eb000 0xb70f3000 6 0 0xf2d7a240 rwx 1 0 0x2180 COW NNC default 0xb70f3000 0xb70f9000 1 0 0xc044d040 r-x 20 12 0x0 COW NC vnode 0xb70f9000 0xb70fa000 1 0 0xf2d71c00 r-x 1 0 0x2180 COW NC vnode 0xb70fa000 0xb70fb000 1 0 0xf2d716c0 rwx 1 0 0x2180 COW NC vnode 0xb70fb000 0xb710c000 0 0 0 rwx 0 0 0x0 NCOW NNC none 0xb710c000 0xb7122000 9 0 0xf2cf9240 r-x 24 16 0x0 COW NC vnode 0xb7122000 0xb7123000 1 0 0xf2d715a0 r-x 1 0 0x2180 COW NC vnode 0xb7123000 0xb7127000 3 0 0xf2d717e0 rwx 1 0 0x2180 COW NNC vnode 0xb7127000 0xb71a7000 100 0 0xc044f980 r-x 77 50 0x0 COW NC vnode 0xb71a7000 0xb71a8000 1 0 0xf2d71420 r-x 1 0 0x2180 COW NC vnode 0xb71a8000 0xb71ad000 5 0 0xf2dc8c00 rwx 1 0 0x2180 COW NNC vnode 0xb71ad000 0xb71c0000 14 0 0xf2db6420 rwx 1 0 0x2180 COW NNC default 0xb71c0000 0xb72f4000 308 0 0xf6a34c00 rwx 1 0 0x2180 NCOW NNC default 0xbf048000 0xbf0a8000 68 0 0xf2d96f60 rwx 3 0 0x190 NCOW NNC default 0xbf0a8000 0xbf108000 68 0 0xf2d99240 rwx 3 0 0x190 NCOW NNC default 0xbf108000 0xbf168000 67 0 0xf2db6480 rwx 3 0 0x190 NCOW NNC default 0xbfbc0000 0xbfbe0000 8 0 0xf2dd46c0 rwx 1 0 0x2180 NCOW NNC default 0xbfbe0000 0xbfc00000 4 0 0xf2de6ea0 rwx 1 0 0x2180 COW NNC default --gBBFr7Ir9EOA20Yy--