MB Pro Red hanging about once amonth
Moderator: Mattk
Re: MB Pro Red hanging about once amonth
More an more features were added over time, so RAM might go a bit low on certain conditions. SMB takes a lot of RAM, so disabling it might help. If not, we know at least that this is not the reason
-
WS Heinenoord
- Senior Boarder
- Posts: 46
- Joined: Sun Dec 22, 2019 2:08 pm
Re: MB Pro Red hanging about once amonth
End of May the frequency of the hang-up trouble went up and getting sick of weather services reporting my station was offline and instead of doing a full erase and a clean build of the MB-Red, I took a bold step and ordered a new MB-Black. Yes that did hurt, but was on my long-term wish list anyway since the MB-Red display has developed serious burn spots and I always disliked its inside temperature going 50 - 63 degree C in summer.
I now have the two running in parallel at same location in my attack and this setup allows to have a close look at the issue without risk of any further data loss and misfiring in the weather services updates.
The MB-Black was simply loaded with the MB-Red configuration file and a copy of the database from the MB Red. And it ran without any issue and no spikes in CPU-% at the hour !
I did the transition in small steps, switching off things in the MB-Red and simultaneously switching same service on in the MB-Black. And checking CPU-% for multiple hours.
1 Stopped all events
2 Erased all events
3 Stopped uploads to weather services
So far, the CPU-% spiking remained for the MB-Red while no spiking in the MB-Black.
Then I erased the database in the MB-Red and to my surprise the spiking had stopped !
Loading the database again resulted in return of the CPU spiking at the hour.
Reconstruction of that database did not change the problem.
In order to produce some Prohealth graphs to show the effect on this forum I tried to reproduce above sequence, but when loading the database the MB-Red returned a stubborn error: “cannot prepare create table (after 0 tries in 1ms): database disk image is malformed (11) dbase (06.06.2026 21:29:45): RAM database purged.”
I tried older versions of its back-up database and configuration file, did multiple restarts, factory resets, nothing helped to accept a database back-up file. Suspecting the internal memory stick was the problem, I had the MB-Red running with an external USB stick as database store. And tried to get the database loaded in again via the second USB port. Still no success, same error: “database disk image is malformed (11)”. As a last option I tried to load a fresh database back-up file from the MB-Black and using the internal USB memory again to store it. And that step made the MB-Red run without issues, no errors and no CPU spikes over 100% at the hour! Weird that the MB-Red did not accept it’s own back-up file, but did accept the MB-Black database.
Maybe Boris can get some clues out my excursions.
For the moment the MB-Black is running fine for a month. While the MB-Red has developed a new issue: it loses connection to all my Davis stations while sitting next to the MB-Black. RF-signal strength was a typical -69 dB at time of disconnection, so cannot be an issue, I would say. Simply restarting the MB-Red make it go again, but unfortunately not for long. RAM usage is usually around 80%, sometimes 91% max. He're some typical lines from the logfile:
logger (30.06.2026 18:54:08): station 0 (RF Vantage), no synchronization for 2700 seconds, data logger will be restarted.
logger (30.06.2026 18:54:08): disconnect station 0 (RF Vantage): timeout
logger (30.06.2026 18:54:38): connect station 0 (RF Vantage via USB serial).
logger (30.06.2026 19:39:09): station 0 (RF Vantage), no synchronization for 2700 seconds, data logger will be restarted.
logger (30.06.2026 19:39:09): disconnect station 0 (RF Vantage): timeout
logger (30.06.2026 19:39:39): connect station 0 (RF Vantage via USB serial).
For those having a similar CPU spike issue, if you are in a position to try running with an empty database, pls check about spikes disappearing like in my case.
I now have the two running in parallel at same location in my attack and this setup allows to have a close look at the issue without risk of any further data loss and misfiring in the weather services updates.
The MB-Black was simply loaded with the MB-Red configuration file and a copy of the database from the MB Red. And it ran without any issue and no spikes in CPU-% at the hour !
I did the transition in small steps, switching off things in the MB-Red and simultaneously switching same service on in the MB-Black. And checking CPU-% for multiple hours.
1 Stopped all events
2 Erased all events
3 Stopped uploads to weather services
So far, the CPU-% spiking remained for the MB-Red while no spiking in the MB-Black.
Then I erased the database in the MB-Red and to my surprise the spiking had stopped !
Loading the database again resulted in return of the CPU spiking at the hour.
Reconstruction of that database did not change the problem.
In order to produce some Prohealth graphs to show the effect on this forum I tried to reproduce above sequence, but when loading the database the MB-Red returned a stubborn error: “cannot prepare create table (after 0 tries in 1ms): database disk image is malformed (11) dbase (06.06.2026 21:29:45): RAM database purged.”
I tried older versions of its back-up database and configuration file, did multiple restarts, factory resets, nothing helped to accept a database back-up file. Suspecting the internal memory stick was the problem, I had the MB-Red running with an external USB stick as database store. And tried to get the database loaded in again via the second USB port. Still no success, same error: “database disk image is malformed (11)”. As a last option I tried to load a fresh database back-up file from the MB-Black and using the internal USB memory again to store it. And that step made the MB-Red run without issues, no errors and no CPU spikes over 100% at the hour! Weird that the MB-Red did not accept it’s own back-up file, but did accept the MB-Black database.
Maybe Boris can get some clues out my excursions.
For the moment the MB-Black is running fine for a month. While the MB-Red has developed a new issue: it loses connection to all my Davis stations while sitting next to the MB-Black. RF-signal strength was a typical -69 dB at time of disconnection, so cannot be an issue, I would say. Simply restarting the MB-Red make it go again, but unfortunately not for long. RAM usage is usually around 80%, sometimes 91% max. He're some typical lines from the logfile:
logger (30.06.2026 18:54:08): station 0 (RF Vantage), no synchronization for 2700 seconds, data logger will be restarted.
logger (30.06.2026 18:54:08): disconnect station 0 (RF Vantage): timeout
logger (30.06.2026 18:54:38): connect station 0 (RF Vantage via USB serial).
logger (30.06.2026 19:39:09): station 0 (RF Vantage), no synchronization for 2700 seconds, data logger will be restarted.
logger (30.06.2026 19:39:09): disconnect station 0 (RF Vantage): timeout
logger (30.06.2026 19:39:39): connect station 0 (RF Vantage via USB serial).
For those having a similar CPU spike issue, if you are in a position to try running with an empty database, pls check about spikes disappearing like in my case.