Dude causing CCR Reboots "out of memory" condition

So I have been battling the dude for over 6 months trying to find the right combination of hardware and settings to prevent our core router from randomly rebooting. After many tests and logs, we were able to determine that the dude seemed to consume all the available memory of our CCR1016 which would cause the kernel to crash and reboot the router which would drop the 600+ ospf routes we have thus causing many problems on the network for a few minutes until the routes come back up.

Not much would hit the log file, but while consoled in, we were able to view some messages like so: “aug/21/2017 06:16:12 dude,critical queued 134265830 bytes for write to db. Please consider faster storage otherwise memory condition or data loss can occur”

So that led us to believe it was the 8GB SD card installed on the front of the router formatted for FAT32. We then ordered a faster card “SanDisk SDXC 10 64GB”. We formatted to FAT, installed the backup and ran it for about a week and it started again. After talking to a few tech support companies and several other users who seemingly have no issues with this, we thought maybe most people use a usb stick hanging off the dongle. So again we moved the db to the usb drive and within two weeks, were experiencing the same issues. So I thought well maybe most run it on ext format so we formatted the 64GB SD card and reinstalled the database and within a few weeks…same thing.

I am at a loss. The only other option I can come up with is to run it in a virtual machine but I thought the CCR would be more than sufficient to run the application. Does anyone have any thoughts or best practices on how to set this up correctly? Currently running 6.39.2, the dude db backup size is just over 21MB, CPU averages 10-15%, around 400 devices.

Please, upgrade to the latest current version, then generate new supout.rif file after ~1 minute.

Now wait until RAM is almost full (before router reboots itself) and generate another file.

Download both of these files and send them to support@mikrotik.com. One will represent situation when everything is fine and other when it is not. We will try to trace what fills up RAM between these two moments when files are generated.