From owner-freebsd-questions@FreeBSD.ORG Thu May 28 08:06:27 2015 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C86283E9 for ; Thu, 28 May 2015 08:06:27 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id 9E0E278B for ; Thu, 28 May 2015 08:06:27 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from [10.0.1.2] (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) (authenticated bits=0) by zoom.lafn.org (8.14.7/8.14.9) with ESMTP id t4S86O76095935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2015 01:06:24 -0700 (PDT) (envelope-from bc979@lafn.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Swap exhaustion From: Doug Hardie In-Reply-To: Date: Thu, 28 May 2015 01:06:23 -0700 Cc: kpneal@pobox.com, FreeBSD - Content-Transfer-Encoding: quoted-printable Message-Id: References: <1CD13C1C-5344-4909-A061-F25FBB86AFF9@lafn.org> <20150528000655.GA15385@neutralgood.org> <6F843A4D-8D2D-4DE2-B90E-A8033BEC1500@lafn.org> To: Michael Schuster X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98 at zoom.lafn.org X-Virus-Status: Clean X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 08:06:27 -0000 > On 27 May 2015, at 22:25, Michael Schuster = wrote: >=20 > Hi, >=20 > On Thu, May 28, 2015 at 7:09 AM, Doug Hardie wrote: > If I am understanding correctly, then it appears that a process can = actually allocate enough memory to eat up the swap space. Then I need = to find out why that process is allocating so much memory. Thanks. >=20 > one scenario that comes to mind is memory leak - I'd guess at a code = path where a previously allocated chunk or memory isn't properly = free()d. I'd start debugging using the information in malloc(3). The developer says that valgrind has been run on it extensively and no = leaks have been found. I suspect this is a =E2=80=9Cfeature=E2=80=9D = that is being used in a way that was not expected and is using way more = memory than one would expect.