having some issues of late with the Dude, we keep getting this message pop up in the terminal,
sep/19/2016 23:05:19 dude,critical queued 33615129 bytes for write to db. Please
consider faster storage otherwise out of memory condition or data loss can occur
sep/20/2016 03:01:09 dude,critical queued 67279316 bytes for write to db. Please
consider faster storage otherwise out of memory condition or data loss can occur
Setup
CCR1036 8Gb ram, with SSD 200GB HDD plugged into USB port.
Currently testing 6.37rc12
my thoughts are the USB->HDD may be too slow?
we have well over 1200 devices, and I have turned off link monitoring and graphing.
MikroTik RouterOS 6.37rc40
still having same issue.
as you can see it gets worse and worse over time,
sep/22/2016 22:32:52 dude,critical queued 33558295 bytes for write to db. Please
consider faster storage otherwise out of memory condition or data loss can occur
sep/22/2016 23:40:12 dude,critical queued 67254888 bytes for write to db. Please
consider faster storage otherwise out of memory condition or data loss can occur
sep/23/2016 02:43:22 dude,critical queued 134606540 bytes for write to db. Please
consider faster storage otherwise out of memory condition or data loss can occur
sep/23/2016 09:36:32 dude,critical queued 269276833 bytes for write to db. Please
consider faster storage otherwise out of memory condition or data loss can occur
sep/24/2016 00:12:03 dude,critical queued 538618337 bytes for write to db. Please
consider faster storage otherwise out of memory condition or data loss can occur
So, I had this issue when I deployed a CHR and use VMware to grow the disk. RouterOS detected the disk change, but the performance on it was dismal with SQL Lite. Ended up having to mount a 2nd volume to the VM, format it with Router OS and have the Dude use the new volume’s path for it’s DB and files. Much better now. I never see the queued writes error.
disk path of dude store or anything else?
i get this error to, when i disable enable dude or create backup file dude database, it always show some queued bytes, and it take long time for dude to be able to enabled again
enabled: yes
data-directory: dude
status: disabling before export: waiting for config changes to flush (54514930 bytes in queue)
same situation with 6.37.1 on x86 vm in esxi, tried mounting a second disk as suggested but problem remains. Also tried moving the vm to an empty RAID10 datastore but the issue still persists.
it will show a increasing number in queued bytes until ROS goes on kernel failure and reboot.
Already submitted supout to support, but no luck yet :c
Every 13s or so the db-wal file flushes data into main db. like scubyx said, it takes a long time because actually if you keep printing in terminal the status of dude, it only “flushes” around 200KB every 13s
CCR1036 v6.39rc25
Storage: USB Flash 80/80Mb write/read speed
Running only dude - the same problem + loss of information
x86 v6.39rc37 - running on SSD
The same problem
x86 - 2 hours of work
11:03:32 echo: dude,critical queued 33576606 bytes for write to db. Please conside
r faster storage otherwise out of memory condition or data loss can occur
12:06:52 echo: dude,critical queued 67180517 bytes for write to db. Please conside
r faster storage otherwise out of memory condition or data loss can occur
CCR1036
00:41:54 dude,critical queued 33615689 bytes for write to db. Please consider faster storage otherwise out of memory condition or data loss can occur
01:52:15 dude,critical queued 67337353 bytes for write to db. Please consider faster storage otherwise out of memory condition or data loss can occur
05:45:42 dude,critical queued 134754953 bytes for write to db. Please consider faster storage otherwise out of memory condition or data loss can occur
…
13:48:48 dude,critical queued 269573459 bytes for write to db. Please consider faster storage otherwise out of memory condition or data loss can occur
is really scared to add some new devices or maps
After 1-2 days dude is back to default-backup settings
I write many times to support and every time i get answer get better storage…
x86 on vmware
2Gb ram
SSD - 50Gb space
CPU 2x4 2.6Ghz
When disable dude >
applying settings: disabling: waiting for config changes to flush (77351175 bytes in queue)
Every 37 Seconds he write around 120 000 bytes
What is very low
So i am running Dude 6.38.3 I spend 12 hours building out our entire network to wake up the next morning and having it all Gone. So I rebuilt it again. about 200 Devices running on a CCR1016. after I got the network completely done I went to back it up so that if i lost the data again i could restore. I started the backup 16 hours ago. 16 Hours ago. again for dramatic effect 16 HOURS AGO.
currently it is stating this:
/dude print
enabled: yes
data-directory: SSD
status: disabling before export: waiting for config changes to flush (3910678 bytes in queue)
After 16 Hours it has yet to backup a 45 Meg file. WTH. I am more then pleased that the DUDE was resurrected. However, I do not understand why a simple backup takes this long. It should take minute. I have backup my entire cloud platform 1.5 TBs twice during this simple database backup.
Can someone please give me and idea what the problem is.
I am running a CCR1016-12s-1S+ with an SSD dedicated for just the DUDE.
I am having the same issue on a CHR. I has drives that should easily be able to write to the database. Running 6.39.1. It starts compounding. it started complaining about not being able to write about 20 megs. Now it is complaining about 131 megs it can not write. Any disk should be able to handle a few megs of data.
I got a CHR on AWS that is giving the same error. Yesterday I had almost a gig of data that hadn’t been written. Eventually had to just reboot it and redo everything I had done.
I am running 6.39.1 on a t2.medium (2 cores, 4gb ram) using general SSD storage. This should be plenty capable of running the dude services when I look at resources I am using at most 10%.
Any suggestions on how to fix this? Also have a issue with outages not showing up also…