Vice,
The memory leaks are caused by the weewx reporting (currently weewx
4.0.0b17)
I have posted this in a seperate thread.
Luc
On Sunday, 29 March 2020 08:11:24 UTC-3, Lucas Heijst wrote:
>
> Vince,
>
> I found one source of a memory leak: the webcam cronjob.
> In the webcam.debian file a
Vince,
I found one source of a memory leak: the webcam cronjob.
In the webcam.debian file a number of variables were used like:
WEBCAM_ID=4
CAMERA=picamera$WEBCAM_ID
DATETIME=$(date +"%Y-%m-%d %H:%M:%S")
EPOCH=$(date +"%s")
...
The memory which is used by these variables is not automatically
Vince,
These are the steps I will do:
1. Stop mben, this will also stop cmon. Tfrc runs and the web photos are
taken starting at 06:00 tomorrow morning.
2. When they are stable I will move cmon to tfrc.
3. When tfrc, web photo and cmon are stable I will start the mben driver
but stop the mben
On Friday, March 27, 2020 at 12:45:22 PM UTC-7, Lucas Heijst wrote:
>
> Vince,
>
> As I stated earlier, I have no knowledge how to get program modbusenergy
> stable.
> I only can monitor the difference in memory leak with different settings.
> Restarting a program doesn't change the used memory.
Vince,
As I stated earlier, I have no knowledge how to get program modbusenergy
stable.
I only can monitor the difference in memory leak with different settings.
Restarting a program doesn't change the used memory.
Luc
On Friday, 27 March 2020 16:32:56 UTC-3, Vince Skahan wrote:
>
> On
On Friday, March 27, 2020 at 11:47:34 AM UTC-7, Lucas Heijst wrote
> Program modbusenergy has a memory leak of 80 KB per 24 h (nothing new), so
> the memory will be full after 7.5 days.
> It looks like the program starts and stops a program twice per second,
> because each time I perform 'ps
Gary,
The programs modbusenergy.py, tfrc.py and cmon.py are modified to use
module logging instead of syslog.
Everything still works OK.
Program modbusenergy has a memory leak of 80 KB per 24 h (nothing new), so
the memory will be full after 7.5 days.
It looks like the program starts and stops
On Thursday, 26 March 2020 13:21:55 UTC+10, Lucas Heijst wrote:
> I think the fact that weewx can't keep up in time to handle the 1-minute
> archive data is the reason that the memory is filled.
>
I think you are being a little harsh here Luc. From what i can read of the
log extracts you are
Vince,
I think the fact that weewx can't keep up in time to handle the 1-minute
archive data is the reason that the memory is filled..
Each archive record contains 90 real values (doubles) and these values are
stored in memory (I suppose) as long as they are not written to the
database.
One
On Wednesday, March 25, 2020 at 12:06:30 PM UTC-7, Lucas Heijst wrote:
>
> Not sure. See the attached cpu data graph.
> The empty parts in the graph are a result of the linux system looping
> (see: crash log)
>
>
>>
The log showed the oom_killer which is more likely your problem. You must
have
Sounds like something is blocking waiting for i/o to complete perhaps (???)
--
You received this message because you are subscribed to the Google Groups
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
11 matches
Mail list logo
