From owner-freebsd-current@freebsd.org Tue Sep 26 13:06:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2568E0A3E2 for ; Tue, 26 Sep 2017 13:06:32 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 96B296527B for ; Tue, 26 Sep 2017 13:06:32 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3y1h6Y6SCjzZrT; Tue, 26 Sep 2017 15:06:29 +0200 (CEST) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id 8SrtYKeFCaiv; Tue, 26 Sep 2017 15:06:24 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Tue, 26 Sep 2017 15:06:24 +0200 (CEST) Subject: Re: net/asterisk13: memory leak under 12-CURRENT? To: "O. Hartmann" , freebsd-current References: <20170926144522.21e59cfe@freyja.zeit4.iv.bundesimmobilien.de> From: Guido Falsi Message-ID: <979b6cfe-0e38-5df3-7bb5-cdb8de6677bf@FreeBSD.org> Date: Tue, 26 Sep 2017 15:06:23 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170926144522.21e59cfe@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 13:06:32 -0000 On 09/26/2017 14:45, O. Hartmann wrote: > Befor starting a PR I'd liek to ask for some advice to document a supposedly > existent memory leak in net/asterisk13 and 12-CURRENT. > > Background: > > Running recent 12-CURRENT (FreeBSD 12.0-CURRENT #58 r323999: Tue Sep 26 > 06:18:27 CEST 2017 amd64) on a PCengine APU 2C4, equipted with 4GB of RAM and > 4080 KB free after the most recent SeaBIOS has been started, I try to utilise a > net/asterisk13 as PBX on that platform. Asterisk13 has been build via poudriere > and is compiled with CLANG/LLVM, not GCC! > I'm running asterisk on similar hardware and also building with clang, and have it going for months without any problems. I have disabled many modules in that build though. Problem could be caused by some ancillary library pulled in by some module. > When FreeBSD (NanoBSD) has been started, depending on the recent revision of the > OS/Kernel, top shows ~3680 - 3705 MBytes of free memory. Starting > net/asterisk13 via "service asterisk onestart" indicates an overall usage of up > to 100 MBytes of memory. After having now run the Asterisk 13.17.2 daemon for > two days resulted in ~ 3100 MBytes of free memory, while the asterisk daemon > was still running and doing nothing. But performing several restarts on a > freshly started box gives the same result after ~ 10 restarts - and even after > stopping asterisk and let the system run for a couple of days doesn't free the > memory. I stopped after 15 restarts or so watching the loss of memory after > each restart of asterisk, so i came to the conclusion that there must be a > memory leak somewhere. now i try to provide more informations as needed for a > PR. > > Can someone help? Not sure, restarting the daemon should free any leaked memory the daemon has. If a killed process leaves memory locked at the system level there should be some other cause. Have you tried diagnosing this memory with more tools? Depending on how deep you want to investigate ps, top and vmstat are simple to use and give you some indication. To go deeper you'll need to use more complicated tools. Others are better suited than me for suggesting those. DTrace could be a powerful but not easy to use instrument. Looking just at free memory (which under a UNIX OS can have various valid definitions, depending on how you account for inactive memory, buffers and laundry RAM) is definitely not enough. Have you seen asterisk process allocate more and more memory? You should check also what other processes in the system are doing. A computer software when running never really does "nothing"(except, maybe, when swapped out) and some memory usage can accumulate in many parts of the system. -- Guido Falsi