What I did was install a clean beta via pip, then overwrite extension.py down buried in the venv from the later one you'd uploaded to github. I 'think' that I hand-edited in one patch as you'd previously updated multiple things after the beta was released, but my memory is a little hazy there.
In thinking about it after the fact, I wish I had stopped weewx and deleted all the __pycache__ trees in the venv, then restarted weewx and retried the same command to see if the issue went away. A clean install worked. A later try where I was more careful hand-editing the diff in worked. On Tuesday, December 26, 2023 at 1:23:34 PM UTC-8 Tom Keffer wrote: > I am trying to reproduce the result that Vince and Cameron have reported, > but am unable to do so. More details would be helpful. > > Did you both do an upgrade from v4.10.2 to v5.0.0rc1? > > Did you have any extensions installed? > > Vince, I know you were running "weectl report run" using Python 3.11, but, > Cameron, what were you running? > > Cameron, do you have a stack trace? > > It's hard to debug because the snippet that Vince has does not show the > type of the underlying exception. > > -tk > > On Tue, Dec 26, 2023 at 9:02 AM Vince Skahan <[email protected]> wrote: > >> If you're running a throwaway vm, try running the benchmarks at >> https://github.com/weewx/weewx/wiki/Benchmarks-of-file-and-image-generation >> and see what your numbers look like. You should see numbers well under 3 >> seconds on that kind of gear. >> >> On Tuesday, December 26, 2023 at 6:52:42 AM UTC-8 Cameron D wrote: >> >>> I ran some more tests with my main DB converted to sqlite, using weectl >>> to run repots using the default Seasons skin. >>> >>> The times remained basically constant at about 4.5 minutes user+sys >>> CPU as I kept deleting old records. >>> As I got below 500k records the times dropped proportionally to the >>> number of archive records, extrapolating back to about 20 seconds for no >>> records (which is still a crazy long time. >>> >>> In addition the various gaps between the file creation times also >>> dropped in proportion. >>> >>> The bit I wrote in the previous post about memory use did not apply to >>> this set of tests, as the value just stuck steadily to 120MB. I think I >>> have lost track of some of the tests I was doing. >>> >>> On Tuesday 26 December 2023 at 6:04:05 pm UTC+10 Cameron D wrote: >>> >>>> The wmr300 DB has 3.7million records, and the ecowitt DB has only >>>> 530k. The system is a VM running on an i5 - the VM is allocated 8GB ram >>>> and 4 cores. It was not stressed at all by weewx V4. >>>> >>>> The CPU usage is all in the python, not in the mariadb server. >>>> >>>> While the python code is thrashing around achieving nothing, the memory >>>> allocation for the report script is oscillating from under 200MB to 780M - >>>> no swapping, the machine still has 4GB free. >>>> >>>> On Tuesday 26 December 2023 at 4:11:59 pm UTC+10 Vince Skahan wrote: >>>> >>>>> Cameron several of us have run v5 with very large db of over 10 years >>>>> data on pi4 or lesser boxes without such issue, so a bit more data from >>>>> you >>>>> would be helpful. How big a size are you running ? On what hardware ? >>>>> >>>>> -- >> > 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/c5270d4d-0008-4b23-ac1b-5ab4647e2e8bn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-development/c5270d4d-0008-4b23-ac1b-5ab4647e2e8bn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/f24957bc-b805-4507-9fcb-794492cfe8dbn%40googlegroups.com.
