Yeah, I don't understand it either. I saw the caching of fonts. The data
seems to point to something that the Plot render method uses in the
library. I did see that the default font is actually embedded in the
imaging library code (not loaded from a file). I also used a true type font
when I sp
Good information, although I don't understand it.
The 'weeplot' image generator actually caches fonts, exactly for this
reason. Many years ago, we experienced memory leaks, due to PIL not
properly recycling font handles. So, in revision 8615d0f3, added over 7
years ago, we introduced the cache. So
Not sure what happened to the plots... Hopefully this works.
-rich
On Sun, Dec 1, 2019 at 3:43 PM Rich Bell wrote:
> This is not new information, but I thought it might help others seeing a
> steady increase in memory consumption.
> TL;DR
> I am seeing a memory leak when the imaging library def
This is not new information, but I thought it might help others seeing a
steady increase in memory consumption.
TL;DR
I am seeing a memory leak when the imaging library default font is used.
Ensuring that a font is specified for each label (top_label_font_path,
unit_label_font_path, bottom_labe
TK,
Thanks for confirming I am not totally crazy. In my case it is aggressive
enough to bring the pi down in about a week. When I get a chance I’ll fire
up my ubuntu machine and see what I see. I’m curious enough to keep
looking, but doubt I will find anything more.
And again, thanks for all yo
I have experienced memory leak issues as well, but only under 32-bit Debian
systems.
About 6 months ago, I tried to isolate the problem, and, like you, came to
the conclusion that it was in the sqlite3 "wrappers." In fact, I came up
with a memory test program that looks very similar to your amemte
Rich,
You're not the only one seeing memory leaks, but so far yours is among the more
complete reports, helping to narrow it down. Thanks for this!
I know of several of the extended development team who have been trying to
reproduce and instrument to zero in on it. I am sure they will be appre
I'm running on: raspbian stretch, python 2.7.13, and WeeWX 3.9.1.
I was noticing a steady increase in memory usage. I narrowed it down to one
service I had installed. This service binds to the loop event and makes
over 10 calls to getSql. I updated the service to open and close the
connection o
Sort of related but for sometime I had a memory leak that causing weewx
repeport generation to halt after about 3 to 4 weeks. I was using the forecast
extension to produce 2 different outputs; one for my Saratoga format page and
the other for my native weewx page. One of them was the culprit, my
I run weewx on a 128 MB RAM system, so perhaps this is a bit unusual, but
in loading the current forecast extension it 'seems' that it has really
high memory usage in VSZ. I'm wondering how much this might matter (or not):
Symptoms I saw:
- added forecast 3.2.4 on my weewx 3.6.1 Dockstar, go
10 matches
Mail list logo
