From owner-freebsd-current@freebsd.org Thu Sep 28 07:29:34 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 37A7CE2B2DE for ; Thu, 28 Sep 2017 07:29:34 +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 EE45173442 for ; Thu, 28 Sep 2017 07:29:32 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3y2mXp39MszZrX; Thu, 28 Sep 2017 09:29:30 +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 JMYGfTdVJLnK; Thu, 28 Sep 2017 09:29:27 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Thu, 28 Sep 2017 09:29:27 +0200 (CEST) Subject: 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> <20170927112706.436500ec@freyja.zeit4.iv.bundesimmobilien.de> <40903499-6cbb-53b7-e25a-1d7d96c47a75@FreeBSD.org> <20170928080136.6a19fd7d@freyja.zeit4.iv.bundesimmobilien.de> From: Guido Falsi Message-ID: <6d582286-d5ce-11ac-a8d4-391d79691d2c@FreeBSD.org> Date: Thu, 28 Sep 2017 09:29:26 +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: <20170928080136.6a19fd7d@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: Thu, 28 Sep 2017 07:29:34 -0000 On 09/28/2017 08:01, O. Hartmann wrote: >> These numbers really don't tell us anything. The system has anyway been >> running for days, depending on configuration daemons like cron and ntp >> are running and performing tasks, things are being cached and so on, so >> that difference after three days could be perfectly normal overhead. > > I think they do, but not in a scientific way. I am unable to work with such data anyway. > > The system in question has to do always the same task and is running for months > with never dropping below a certain memory boundary. > > Then, when asterisk started/stopped/started, memory begins to fade away and is > never getting back to "free", even with asterisk off for days, twoo weeks. Does > this really tell me nothing? > It tells you the OS is caching some data. Which is normal. You should discover what the OS is doing with that memory. The fact that it is in some way allocated does not indicate anything. Maybe the memory used by asterisk is simply going in the inactive pool and never reclaimed by the OS because it's not required, having still lots of Free memory. There are many possibilities, and exact data is needed to investigate. I'm also not an expert about VM systems. Asterisk, even with few modules tends to use a big chunk of memory and after stopping a software which uses much RAM it's normal for the OS to not immediately reclaim that to the Free pool. In fact such reclaiming happens only if there actually is memory pressure. There are so many factors playing into this that just looking at Free RAM answers no question. What problem are you trying to solve? Are you running out of memory? >> Whatever you prefer, but trying a few days uptime with all modules >> enabled is zero cost and east to do. Also you started this report with >> THIS configuration, changing configuration would prevent from comparing >> results. Let's test one thing at a time. >> > > I will. > Now as we have a indication that there is porbably something, I'll go for > deeper investiagtions with a static config. > I disagree with the indication buyt to investigate such a problem you need to use better tools than just looking at the free ram reported in top. Please at least give us the other ram numbers (Used, inactive, laundry, wired, buffers...) -- Guido Falsi