Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
Persistent TCP Sync question
-
I re-synced a year of historical data from the ES to our cloud (about 4 million pointvalues) and although the sync finished several hours ago and the cloud does show the values synced in charts, the points to be written is still hovering > 200,000 and I am wondering how long to expect before this number returns to its normal level around 200 - 500. Shouldn't this be completed after a couple hours?
-
This likely points to a recent bug we found and have fixed in the NoSQL module where discarded samples could potentially make that count incorrect. If your 'Writes per second during database batches' is low and does not appear to be taking any out of the > 200,000 then this is the cause. Those values are not actually in memory, the counter is wrong.
The only way to reset the counter is to restart Mango. The fix for this bug will be in the 3.2.2 mangoNoSQLDatabase release next week.
The 200,000 values missing were discarded due to a problem writing to disk so you will likely need to re-run the sync. You will see the reasons for the discards in the log file.
-
OK that make more sense. Thanks for the quick response.
-
So how should I configure the NO SQL settings so these values are not lost? The heap is 10g so I wouldn't think memory limitation is the issue. When I rerun the sync over the same period the PointsTBW does not increase above 100 and the sync completes quickly.
-
You shouldn't need any configuration changes, the lost backdates were likely due to a corrupt shard that was repaired while the system was running and inserting data. This is a rare scenario and has been fixed in the next release.
