On 30/03/2020, Lucas Heijst <[email protected]> wrote: [...] > 2. With weewx reports (mben with 84+ generated graphs each run). > > Luc
I have a fairly complex set of graphs ( multiple plots, large size, anti-alias turned on) and I have a persistent and steady climb until the OOM killer takes over. If I simplify the graphing then it holds up very well, but there's no fun in that! Rather than a Cronjob to force a set restart, I've turned off StdReport report_services = weewx.engine.StdPrint # , weewx.engine.StdReport and then once engine.py has finished its post_loop(self, _event): function, it writes a log message to loginfo (rsyslog). syslog picks up that message and then fires off an instance of wee_reports. The advantage of this is that... 1. The Reports are called at the correct point in the weewx cycle. 2. Once wee_reports finishes it closes completely (assuming another problem isn't holding it open) and completely frees the memory it's used. 3. Weewx stays up and I don't waste anymore time looking for a memory leak that I can do nothing about, or is way above my skill set. I've chased PIL versions and run memory profilers but never had a suitable Eureka moment. The disadvantage is that... 1. weeWX uptime is reported as zero 2. engine.py needs a one line patch (a suitable loginfo message) 3. rsyslog is easy but a set procedure needs following. One that's simple in hindsight. now, in a week, weewx might use 2 Meg. It basically flatlines with this action. If you want I'll track down the scripts, post them and outline the full logic. -- Cheers Glenn rorpi - read only raspberry pi & various weewx addons https://github.com/glennmckechnie -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/CAAraAzg658koiMMOyy7-m4zrjUBg6XCLxR8sbzBgrgbA%2BLm72Q%40mail.gmail.com.
