search

cyoung / stratux

Aviation weather and traffic receiver based on RTL-SDR.
BSD 3-Clause "New" or "Revised" License
1.06k stars 365 forks source link

Potential memory leak over time #230

Closed cyoung closed 8 years ago

cyoung commented 8 years ago
  1. Stratux version: v0.6r1.
  2. Stratux config: dual SDR, GPS unknown, AHRS no, battery unknown, battery cable unknown.
  3. EFB app and version NA. EFB platform NA. EFB hardware NA.
  4. Description of your issue. "noticed the memory usage went from 43mb initially to over 73mb currently, in 2 days 1:37 minutes of uptime."

May just be the ever-growing traffic target list, but a 2+ day memprof should solve it.

Ergonomicmike commented 8 years ago

Here is some data from htop, from two days of testing for memory leaks. Mostly vanilla Stratux v0.6r1 with iposva's GlobalSat update and powersave governor. Two SDRs, listening inside the house. No towers. Peak 1090 = 2680, peak UAT = 108. (It's higher when the unit is outside.) GPS mostly WAAS.

(Power from a 2A wall wart. Pi red LED on solid. Never lost Wi-Fi.)

Here's the start of the test.

Mem showing 42/925.

At 4 hours.

46/925

At 17 hours.

50/925.

The memory stayed there for the rest of the test. It would toggle between 50 and 51.

48 hours.

Having said that the memory topped out at 50/51, I saw 60 MB after only two hours of flying with the same hardware but towers and a lot more UAT messages. I forgot to take a screenshot of the Stratux status page at the end of the flight, but here's a screen shot from about 1 hour into a 2.3 hour flight. We're near the Hector VOR about this time, where there wasn't much traffic. And then we flew thru R-2515 and then down low into the Southern Sierras. So we probably didn't see enough new traffic for the rest of the flight to move the peaks any higher.

Update: Notice that the memory in the VIRT column increases from start to finish.

If memprof is an easy apt-get thing, I'm willing to do the test again with that. (Outside the house this time.) Please let me know.

Ergonomicmike commented 8 years ago

I tried installing memprof. In addition to apt-get, I tried pip install and easy_install. No joy.

Ergonomicmike commented 8 years ago

I forgot to post a screen shot of htop from near the end of the flight. Here it is.

ghost commented 8 years ago

@cyoung -- While testing #249, I noticed that I have several DHCP leases that never expire, and that FIS-B data will be queued for port 4000 on those addresses:

2016/02/15 05:01:32 On  192.168.10.12:49002,  Queue length = 0 messages / 0 bytes
2016/02/15 05:01:32 On  192.168.10.13:4000,  Queue length = 20005 messages / 8806305 bytes
2016/02/15 05:01:32 On  192.168.10.13:49002,  Queue length = 0 messages / 0 bytes
2016/02/15 05:01:32 On  192.168.10.14:4000,  Queue length = 20005 messages / 8806305 bytes
2016/02/15 05:01:32 On  192.168.10.11:49002,  Queue length = 0 messages / 0 bytes
2016/02/15 05:01:32 On  192.168.10.10:4000,  Queue length = 0 messages / 0 bytes
2016/02/15 05:01:32 On  192.168.10.12:4000,  Queue length = 0 messages / 0 bytes
2016/02/15 05:01:32 On  192.168.10.14:49002,  Queue length = 0 messages / 0 bytes
2016/02/15 05:01:32 On  192.168.10.15:4000,  Queue length = 20005 messages / 8806305 bytes
2016/02/15 05:01:32 On  192.168.10.15:49002,  Queue length = 0 messages / 0 bytes
2016/02/15 05:01:32 On  192.168.10.11:4000,  Queue length = 20005 messages / 8806305 bytes
2016/02/15 05:01:32 On  192.168.10.10:49002,  Queue length = 0 messages / 0 bytes

Since the message queues autotrim to a length of 25000 messages (~10.3 MiB per port), that may explain why memory usage eventually tops out... at least until a new device connects.

cyoung commented 8 years ago

@AvSquirrel - /var/lib/dhcp/dhcpd.leases should have expired leases. Added code now that reads and parses the lease expire time. The max lease time is set to just over 3 hrs (and has been set there for a while).