Another update
I was seeing the same inexorable memory usage creep whether I used the
default wmr300 driver, or my version using libusb1. Also after removing
weather underground updates.
Between 22 days after restart and 32 days I had gained nearly 100MB VMdata
allocation.
But it did not happ
thanks for the updates, good to see a community thrive. the issue i have isn't
(doesn't) appear to be a memory leak, more of a call going wrong.
i am using the fousb / wh1080, so it maynot be down to a driver issue, for me
anyhoo.
i tried rolling back to Stretch, but same issues reappeared. J
Here is a plot overnight tracking the various memory values in
/proc/pid/status at sampling interval 20 sec.
My system is a wmr300, weewx 3.9.2, archive interval 1 minute to mysql,
posting to WU, not usng rapidfire.
I don't understand what I am talking about here, but just reporting what I
see:
If there is a memory leak in the wmr300 driver, it might be my fault, so I
suppose I should look into it.
There is a thread from maybe a year ago where WRM300s and 200s were
reportedly hanging Pi's but it seemed to be related to kernel version, so I
had assumed it was a kernel driver issue that
TK,
If it helps, I don't use any reporting stuff.
I'm strictly using WMR300 with rapid fire and archive simultaneously.
No other features.
Unfortunately, I've restarted weewxd several times today making the attempt to
debug it, so I can't share the latest memory usage snapshot. But as a data
po
While the tools work well in smaller projects where you can identify and
track every object, in a larger, real-time, project like weewx, there is
just too much going on to make sense of the huge memory trees the tools
produce.
They also suffer from a Heisenberg uncertainty principle: the very act
Hey, TK. WMR300. I'll see if I can track it down.
Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad)
> On Aug 11, 2019, at 12:45 PM, Thomas Keffer wrote:
>
>
> If memory increases every couple of seconds, which suggests that the leak is
> in the part of device driver that deals wit
If memory increases every couple of seconds, which suggests that the leak
is in the part of device driver that deals with LOOP packets. But, you're
on an WMR300, right? As I recall, their LOOP packets are more like 10-20
seconds apart --- too long to correlate with what you're seeing. Or, are
you o
On Saturday, 10 August 2019 14:01:11 UTC+1, Leon Shaner wrote:
>
> It isn't the weewx version, it's the pi kernel / usb module version. The
> usb stack hangs. I wrote a watchdog to detect it and reboot the pi,
> because so far there has been no fix to the issue. I am not able to
> correlate
It isn't the weewx version, it's the pi kernel / usb module version. The usb
stack hangs. I wrote a watchdog to detect it and reboot the pi, because so far
there has been no fix to the issue. I am not able to correlate this to a
memory leak. What are you seeing re: memory?
Regards,
\Leon
--
Hi all,
I have been runnin Weewx on a Raspberry Pi (model a) for a couple of years with
a Maplin NG96Y, without any issues.
I recently upgraded to a Pi3, running Stetch, and Lighttpd. the old Pi was
starting to struggle and sat at 100% cpu for most of the time.
All worked well for a month or
11 matches
Mail list logo
