Open GoogleCodeExporter opened 9 years ago
I would say the expected output for the memory usage over the period of 1 day
is an increasing memory usage. All the sensor values are recorded over the
period of 1 day (which of course comsumes memory). The additional memory usage
should be about
(12 bytes per sensor value) * (15 * 60 * 24 recorded values per day and sensor)
* (19 sensors) = 4.7MB
There is some compression applied to the storage of values, but there is
overhead from the dynamic memory structure as well. While this can explain some
of the memory usage, it does not explain the increase in "# Bytes in all
Heaps". If I understand the values in this plot right, then the largest portion
would have to be on the LOH (large objects heap). Either this problem is caused
by some nasty LOH fragmentation effect (or the like), or there is some other
leaking going on somewhere.
To do anything on this issue the source of the leaking has to be identified (if
there is any).
Original comment by moel.mich
on 9 Aug 2013 at 4:16
I will investigate it more . Thank you for your reply.
Original comment by husam.el...@gmail.com
on 9 Aug 2013 at 5:00
I just realized that the scale on the left is not MB but 0.1 MB (except
"Private Bytes"). So the "# Bytes in all Heaps" (on my system this is actually
Gen 1 + Gen 2 + LOH but without Gen 0) increases from about 2MB to 8MB. The
"Private Bytes" from 32MB to 38MB. This would still be within the expected
increase in memory usage due the recording of sensor values. Of course if it
continues to increase with each day, then there is really a leaking issue (the
OHM starts dropping recorded sensor values after 24h).
Original comment by moel.mich
on 9 Aug 2013 at 6:39
Original issue reported on code.google.com by
husam.el...@gmail.com
on 9 Aug 2013 at 3:34Attachments: