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 <madpilot_at_FreeBSD.org>Received on Thu Sep 28 2017 - 05:29:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:13 UTC