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
> 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.
> 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 <madpi...@freebsd.org>
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"