Hey, Steve,

I must have missed the context, but if you are looking at overall system memory 
growth, well, it's a normal / healthy thing for a Linux kernel to try to use as 
much memory as possible at all times, to keep from having to go back to disk 
for code pages as different processes context switch in/out of the scheduler.   
Even as memory is freed by a program, the kernel won't bother to go back and 
re-use free'd pages unless/until there are no more previously unused memory 
pages available.
At that point the kernel will run the free memory "scanner" to go through the 
list of freed pages to find some to allocate to some other program requesting 
memory.

In a healthy system with plenty of RAM the free memory scanner should rarely 
run.
If the scanner runs a lot, then that means memory pressure is high and so THERE 
would be your indication that you're running low on memory, not "free -m" 
indicating a high number (because a high number is a good/normal thing in 
Linux).

What you should be most concerned about is if the system is starting to 
actually use swap, because then that means that not only is the physical RAM 
full, and freed pages are constantly being turned over / re-used, but the 
kernel is ALSO having to dip into virtual memory by swapping out (to disk) 
things not currently running, and then swapping those things back in when the 
associated processes are brought back to the running state by the process 
scheduler.

I like to use "top" to see what's going on with swap usage, but you can also 
get the info via other ways, such as:

$ cat /proc/meminfo
$ vmstat

(Etc etc)...

As for how to track the *real* indicator of memory pressure, that being the 
free memory scanner running too frequently, I'd look to "sar" for that.

I didn't see mention of what platform you are on, but for me on RPI, I get sar 
via:

$ sudo apt-get install sysstat
(And enable it in "/etc/default/sysstat").

And then these go in root's cron, a la "sudo crontab -e"

# Enable SAR:
# Collect measurements at 10-minute intervals
0,10,20,30,40,50   * * * *   /usr/lib/sysstat/sa1
# Create daily reports and purge old files
0                  0 * * *   /usr/lib/sysstat/sa2 -A



After sa1 has been running a few times (say, give it an hour) then you can use 
"sar -B" to see the "pgscand/s" statistics (and related).

Of course check "man sar" for more details.


Like I said I missed the context, but did you previously capture some data to 
suggest that weewxd is growing and growing in its memory consumption?

Here is a handy command you can use to check it:

$ ps -C weewxd -o comm,size,rss,vsize,%mem
COMMAND          SIZE   RSS    VSZ %MEM
weewxd          88616 71816 102640 16.1

You can use "man ps" to understand what size and RSS is, but if those grow and 
grow and grow, then that's usually an indicator of a memory leak in the code.

If you run that ps command in a loop, checking it say once every 10 minutes you 
can do some math to gauge how much it is growing.

A la:

$ while [ 1 ] ; do
ps -C weewxd -o comm,size,rss,vsize,%mem
sleep 600
done | tee -a /var/tmp/weewxd_size.txt

Wouldn't be too hard to just show the delta in the numbers.
Lemme know if you're still reading this far and I'll take a few seconds to show 
such an example.  ;-)

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 22, 2019, at 12:14 PM, Steve2Q <[email protected]> wrote:
> 
> A little follow up. As the memory growth is still happening, I implemented a 
> script which runs the program free -m and does a little calculation to 
> determine if memory use is over 80% (or any % I want to use). If mem >80% 
> weewx is restarted. So at least it now will run unattended.
> 
> A new question with Steel Gauges. I did the re-installation of RTG on April 
> 9. I just noticed that the gauges themselves are working perfectly, the pop 
> up charts are showing April 9; they have not updated. I probably have the 
> wrong syntax somewhere?
> 
> Steve
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/aa2ae09d-6a65-4c1d-aff5-46332084ade7%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/170C7D38-46B5-4285-BFC4-C82807F8DB7B%40isylum.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to