From owner-freebsd-current@freebsd.org Thu Sep 28 06:01:40 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 0A679E29C68 for ; Thu, 28 Sep 2017 06:01:40 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D6BC71084; Thu, 28 Sep 2017 06:01:39 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MJSuF-1dw5Nb3xDH-0039f7; Thu, 28 Sep 2017 08:01:37 +0200 Date: Thu, 28 Sep 2017 08:01:36 +0200 From: "O. Hartmann" To: Guido Falsi Cc: "O. Hartmann" , freebsd-current Subject: Re: net/asterisk13: memory leak under 12-CURRENT? Message-ID: <20170928080136.6a19fd7d@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <40903499-6cbb-53b7-e25a-1d7d96c47a75@FreeBSD.org> 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> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:p3Mejpjnk049Im7TmbAF7vJreDv1PEAPa3ajBKM8h51oMWGV3EX YRbjHQgbzaF73OL/1iBMiafGY7zZ2hi79WOUhh6etdDeqNdmrYbmIksb8OxGFfxWhAfwia+ xInCrO0V+b+ajB5fC+hN2Evy6tDU+7wmatF86basLeOsbV85sGRdUCy6/oMVqSY8zSxf85g XeNlvvfwg5Mcm+AgZlonA== X-UI-Out-Filterresults: notjunk:1;V01:K0:3fXE7jnwv5o=:qlb2GE4fQfBORAKZeHL//k VmdwIx4EgLmLzbs2E8cc1axchdw9FEwZcI22T+blKbIkG8nVfRWFvdIaY0xNAN5X1SBx+RwY0 FaumEwwoh0bgFYlLUzDVx+Oq5JnJd1jvafrwoACo5GvVPxndL3WL+CKSgvuvTqS4d5Hu2OGDs cEamNi+PqVcMDFSQkOBYFgLycAJLv9Vf4GqxkZ5KcpvYO5hWZmsYIApBJZDLHedvJI0TXPXm+ F0o1nZPtREOcPoBm5xu6TDYm5KNxeXKMwuU5fAJSUnNxQw1G4T0opfkyKPhDCZlFlurJbotl4 bxPFONNkKfR6rFH/gdTA9ZVJbyMJ13OmU3HaOV2l0Y9D9gIZJ0gu0gfvC5w4xx3qh1GNNIEzb ymknejRD11qMJRiQ3I8wNj4JMCy9NoWPARBEwIHiUnlxpGDpvqOiXC6EU5RyJdWXkmOJjvWCO XJ7eE4DByWCDfGegvl29Lz903iBZU08tGkM/ttT9DRCx6BLa40pKckXncDv+ksgUoJ8bI0Sbz z1TbLCTYEmkdrcJGZb4HEkOlYNMc67UtphAGx1Icw3diyl8N5Er9Jghg0ywgVYTSzxbG47Nxs StvaHrj/0GzlbTSB5duce7KWaZc+1gfQa55ZgOjM4AEa1tgvgVuGx3spxE5bTN+MLFcZ35eIy 3lpyjnmpPyOZ6EKOd3lbTE+kRagyZkzLCMNTLzFwqNXHc9BCiHRxOnHmlB+twF4ArP49or+GL twj6DqI2n5uFoEX7tp8gwkyVyQYZTLqwy0npw6aIwnH1oug5wR61/UyFHQKmNGtKZkUxQqDly Vge7haiAfe9U6tS4JLNb2N7YBkzQgHuXFR3zILitkd2ehGpD4o= 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 06:01:40 -0000 On Wed, 27 Sep 2017 12:23:20 +0200 Guido Falsi wrote: > On 09/27/2017 11:27, O. Hartmann wrote: > > On Wed, 27 Sep 2017 09:05:42 +0200 > > Guido Falsi wrote: > >> But while asterisk is running does the memory usage increase unbounded > >> till filling all available memory or does it stabilize at some point? > > > > As far as I could observe, a three day test run of the > > router/firewall/asterisk box drained around 500 MB of memory: starting at > > boot time with ~3700 MB, asterisk leaves the box with ~3640 MB after bein > > started and after three days the system reached ~3150 MB. Stopping asterisk > > gave back some memory, so ~3300 MB then was for days the final result - not > > recovering anything further. I use TEMPFS, if it matters, but I > > checked /tmp and /var/, there were no remnant files so far. TMPVAR is only > > allowed to have 256 MB. > > 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. 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? > > You need to investigate the amount of memory allocated to asterisk with > ps and top and check if that stabilizes. A few days, at most a week > would be enough. After that, if it's not stabilizing you can start > thinking on a leak, but still can't assume where the leak is happening. > > > > Can't say whether it is stabilising or not - I think the runtime is too > > short. I'll check first to disable some modules in the first place and then > > try to perform a test with several days of asterisk enabled. > > > > 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.