From owner-freebsd-current@freebsd.org Fri Sep 29 09:58:54 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 475E8E28B52 for ; Fri, 29 Sep 2017 09:58:54 +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 E68C89D5 for ; Fri, 29 Sep 2017 09:58:52 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3y3RpX2yPBzZr7; Fri, 29 Sep 2017 11:58:44 +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 IkYDDNp8EO3n; Fri, 29 Sep 2017 11:58:42 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Fri, 29 Sep 2017 11:58:42 +0200 (CEST) Subject: Re: [SOLVED] Re: net/asterisk13: memory leak under 12-CURRENT? To: "O. Hartmann" Cc: freebsd-current References: <20170926144522.21e59cfe@freyja.zeit4.iv.bundesimmobilien.de> <979b6cfe-0e38-5df3-7bb5-cdb8de6677bf@FreeBSD.org> <20170926154155.28deb2e1@freyja.zeit4.iv.bundesimmobilien.de> <20170928081152.1b2f039c@freyja.zeit4.iv.bundesimmobilien.de> <20170929105856.5dbecae7@freyja.zeit4.iv.bundesimmobilien.de> From: Guido Falsi Message-ID: Date: Fri, 29 Sep 2017 11:58:42 +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: <20170929105856.5dbecae7@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: text/plain; charset=utf-8 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: Fri, 29 Sep 2017 09:58:54 -0000 On 09/29/2017 10:59, O. Hartmann wrote: > On Thu, 28 Sep 2017 09:38:58 +0200 > Guido Falsi wrote: > >> On 09/28/2017 08:11, O. Hartmann wrote: >>> On Wed, 27 Sep 2017 09:05:42 +0200 >>> Guido Falsi wrote: >>> >>>> On 09/26/2017 15:41, O. Hartmann wrote: >>>>> On Tue, 26 Sep 2017 15:06:23 +0200 >>>>> Guido Falsi wrote: >>>> >>>>> Since I run net/asterisk with automatic module loading (I'm new to >>>>> asterisk), this is very likely and might cause the problem somehow. >>>>> >>>> >>>> You can exclude single modules from autoloading via modules.conf. >>>> >>>>>> 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. >>>>> >>>>> Even with no runnidng asterisk, memory level drops after the last shutdown >>>>> of asterisk and keeps that low. Even for weeks! My router never shows that >>>>> high memory consumption, even under load. >>>> >>>> But while asterisk is running does the memory usage increase unbounded >>>> till filling all available memory or does it stabilize at some point? >>> >>> While Asterisk is running, it doesn't consume much memory, but stopping >>> Asterisk, I would expect that the claimed memory is freed again. It isn't, >>> not all memory is freed. Starting Asterisk then again from this reduced >>> memory level, it claims its memory, "stabilzes" at a certain point while >>> running and again, stopping Asterisk leaves the free memory now at a much >>> lower level never been leveld out - as I said. >>> >>> I played this game last night ~ 20 times until the free memory dropped >>> beneath 3 GB after asterisk has been shut down. This morning, the level was >>> at the same low level as I left it. The router has nothing special to do, >>> the workload is not memory consuming even for weeks! And if there is load, >>> after the load went away, the memory consumption always leveld out and >>> freed memory. >>>> >>>> Asterisk is relatively memory hungry, especially with all modules >>>> enabled. It also caches and logs various information in RAM, even doing >>>> "nothing" it will cache and log that "nothing" activity. If memory does >>>> stabilize after some point it's not really a leak but it's standard >>>> memory usage. To reduce it you should disable all unused modules. >>> >>> I don't understand here. Even if Asterisk is memory hungry - it has ~ 3 GB >>> to use. But after stopping it, it should free the memory. BUT the system is >>> then after the stop with less memory! that is the point. Not the running >>> asterisk's memory consumption bothers me, but the fact, that after 20 start >>> and stops and waiting for days the memory once gone is never put back. > > First of all, my questions weren't ment as an offense, more a question of > interest by asking thing that I whitnessed. If I sounded harsh or not polite, sorry, I did not mean to do that! I was trying to get a message through, but did not feel like I was succeeding and that was frustrating me. So sorry for any lack of respect I could have shown. > >> >> VM system is not composed only of "free" and "used" ram, there ar3e >> other categories. Depending on how a program allocates and uses memory >> it's not automatically sent to the "free" pool after being reclaimed. >> >> Allocated memory can be dirty buffers which are reclaimed after time, or >> other types of buffered data which is never reclaimed until there is >> memor7y pressure. How do you know the game you were playing has a >> similar memory usage as asterisk, which, I assure you, has some complex >> memory usage patterns in it's source. >> >> Also asterisk leverages many parts of the kernel which a game does not >> leverage. I'm quite sure after quitting asterisk you have an higher >> "wired" memory than before starting it. That memory was not allocated by >> asterisk itself, but by the kernel while "serving" asterisk requests. >> The kernel keeps running and does not free that memory right away. in >> fact will not free it until forced by VM pressure AFAIK. > > After a couple of other starts and stops yesterday, it seems, 12-Current and > Asterisk 13.17.2 have a barrier at ~ 3 GB of "free" memory - always having in > mind that this is within the very specific parameters of my setup. It's quite possible that on a system with less RAM (for example an older ALIX board) these extra buffers allocated while asterisk was running get freed earlier because memory pressure is felt sooner. > I expect "in circumstantial occurences of some phenomena" nothing. But my > observations triggered this explanation - and I'm glad I did and I'm glad you > explained! I'm glad I was useful! -- Guido Falsi