Community discussions

MikroTik App
 
User avatar
znet
Member Candidate
Member Candidate
Topic Author
Posts: 134
Joined: Mon Jul 24, 2006 8:07 pm
Location: Houston, Texas

Dude4.beta2 Export crashes Dude instance on x86 RouterOS

Sun Oct 10, 2010 1:48 am

Made a couple backups (exports) when starting to use new v4b2 Dude. After manipulating a few chart parameters, especially raw data keep time, every time I try to perform export, it puts x86 machine to 100% utilization, presumably subsequent to a crash of the Dude. Since its running within RouterOS on x86, no way to determine file size of .db file. Dont believe its as large as 2GB, but it could be a couple hundred MBs.

Have tried booting x86 machine and/or just a regular system/reboot. Doesnt help, but notice it takes long time to 'rebuild' before Dude becomes accessible again. Suspect its re-indexing .db file.

Whatever will I do? 8)

Hint: Need visibility and access to dude.db data store on RouterOS...
Request: How about adding the old style xml export again?
 
lebowski
Forum Guru
Forum Guru
Posts: 1618
Joined: Wed Aug 27, 2008 5:17 pm

Re: Dude4.beta2 Export crashes Dude instance on x86 RouterOS

Mon Oct 11, 2010 8:30 pm

Add an XML export would be a nice step, then folks could downgrade if they want. I believe the real issue is how the code for polling and the code for exporting are somehow crossing their streams :)

I have a W2k3 server and when I do an export of my configuration using 4.0 beta 2 the larger the file the more likely it is going to disconnect and fail. We could not make these huge files with out being able to modify the raw keep time. The more interesting part is while it is creating the export some of the probes I have start failing as if the export function shares the thread with the polling process. This has me worried.

Also when I set a map to export at a timed interval I have more false positives. Once again polling process and disk process...

It seems that once the db hits about 300MB or 400MB there is just too much data for an export to work. (Some internal process times out? The client disconnects, have not tried it directly on the server.) I no longer have a modified raw keep time because of this.

My server is a little old but still a very fast machine with 200 probes only using 17% of one core, quad core server. The dude service is running "real time priority" to reduce false positives.
 
User avatar
znet
Member Candidate
Member Candidate
Topic Author
Posts: 134
Joined: Mon Jul 24, 2006 8:07 pm
Location: Houston, Texas

Re: Dude4.beta2 Export crashes Dude instance on x86 RouterOS

Tue Oct 12, 2010 3:21 am

:(
Add an XML export would be a nice step, then folks could downgrade if they want. I believe the real issue is how the code for polling and the code for exporting are somehow crossing their streams :)

I have a W2k3 server and when I do an export of my configuration using 4.0 beta 2 the larger the file the more likely it is going to disconnect and fail. We could not make these huge files with out being able to modify the raw keep time. The more interesting part is while it is creating the export some of the probes I have start failing as if the export function shares the thread with the polling process. This has me worried.

Also when I set a map to export at a timed interval I have more false positives. Once again polling process and disk process...

It seems that once the db hits about 300MB or 400MB there is just too much data for an export to work. (Some internal process times out? The client disconnects, have not tried it directly on the server. I no longer have a modified raw keep time because of this.

My server is a little old but still a very fast machine with 200 probes only using 17% of one core, quad core server. The dude service is running "real time priority" to reduce false positives.
'Lebowski' ( 8) !)--Your reply corroborates much of what I have been seeing, and adds a couple new concerns...I am going to try exporting to a server on the same network, in the same switch as the Dude server and see if gigabit network speed will let the export complete.

Im glad you agree with the XML output feature returning. That could help re-creation of a Dude instance.

You are fortunate to be able to determine the size of your .db file since you are on Win2K. In RouterOS you are essentially 'running blind' regarding any Dude core files. This is one of the few disadvantages I have ascertained running on the native RouterOS platform. Otherwise, over the last years, Dude has been very stable on ROS. I had run on Win2K for a long time, but experienced many more crashes and anomalies on Win2K. I wonder if some of what you are experiencing is OS related?

How about a 'Dude' menu item in 'Tools' in RouterOS? You could:
Kill, or just shutdown the process, without going through some dangerous methods.
Show file size of .db file
Show percentage of processor Dude process is eating up (Win2k can)
Backup/Export Dude instance to the Files menu for drag and drop to a location of your choice.
I could go on for quite a while, but would never send this reply....

Without a clean backup of my instance, I cant do anything (again, without getting dangerous)! Afterall, there is a 'Dude' tab in the device icon for a Dude server...
I wonder if I back off the raw data keep time if it will recreate a smaller file? I have noticed a marked sluggishness on many of my charts, especially the ones with a lot of history. Of course, this takes all the fun out of having all that realtime history that goes back as far as you dare...

Thanks for the reply Lebowski. Its giving me a whole bunch of new ideas, i.e. 'requests'......
 
lebowski
Forum Guru
Forum Guru
Posts: 1618
Joined: Wed Aug 27, 2008 5:17 pm

Re: Dude4.beta2 Export crashes Dude instance on x86 RouterOS

Tue Oct 12, 2010 4:44 pm

Yes, just back off the raw keep time and wait (a few days at least). The raw values will be replaced as the background tasking will eliminate the extra data. I don't believe anyone has a system that is fast enough to keep 20 days of raw values (10 might be reasonable?). I tried 20 and the system just got silly slow at viewing graphs after a couple weeks.

I am not certain why on w2k seems like everyone gets different issues. Maybe most are the same but everyone communicates it different? I have not had any game stoppers and it is working very predictable now. The false positives are the only issue I have at this point and they are few so it is not worth complaining about. Although I do think that they will go away if they find an issue with the IO routines. And please even though I claim something is up with the two no one should take it as gospel, the problem could lie in the way w2k3 writes to disk or drivers or the SCSI controller in my machine. I should be getting a new server in the next few months so I will have more experience then. But this is fairly easy to recreate and seems to be a common issue maybe we can get some traction on getting it looked into.

It seems that there was a change maybe in 3.5 where false positives and other things like labels not being updated started happening. It might be associated to a change they made to the IO routines. There was an increase of posters complaining about the labels not being updated and that they worked great under 2.2. http://forum.mikrotik.com/search.php?ke ... mit=Search Just search for "labels not" and you can find others with this issue. It might be related.

Normis, will you do a test for us, set your raw keep time to 30 days and try to export your configuration once your db gets big?
Also let it keep growing till it hits 2GB and see what happens?

Thanks,
Lebowski
 
User avatar
znet
Member Candidate
Member Candidate
Topic Author
Posts: 134
Joined: Mon Jul 24, 2006 8:07 pm
Location: Houston, Texas

Re: Dude4.beta2 Export crashes Dude instance on x86 RouterOS

Fri Oct 15, 2010 9:56 pm

Yes, just back off the raw keep time and wait (a few days at least). The raw values will be replaced as the background tasking will eliminate the extra data. I don't believe anyone has a system that is fast enough to keep 20 days of raw values (10 might be reasonable?). I tried 20 and the system just got silly slow at viewing graphs after a couple weeks...........
Lebowski
Seem to have found an ugly workaround. After using a local network machine to the Dude server, I started noticing that sometimes the save file dialog box for the export flashes on the screen for about ~1sec in some cases. I also noticed that if you attempt export repeatedly, I told you it was ugly, eventually you will see it flash by. If you stuff the keyboard with 'enters', that will force the save to wherever the default directory is set, usually 'Desktop'. OK by me as long as I see a new file on my desktop. However this ugly method is crashing the Dude instance most of the time. If you see the 'server tx/rx' stats to the right of the client stats, make sure you are stuffing that keyboard buffer, as thats when it works.

BTW, I did have a large keep time set on my Dude instance, but since I hadnt even gotten close to the 30 day keep time, the file really hadnt grown that large. At the time I stumbled on this workaround, the dude.db file was only 30MB, so that kinda busts the 'file too large' theory. I could only find out this file size with a successful export since I am running on Routeros on x86. Never-the-less, I have backed off the keep time to about a couple days. Logic there is if I saw it today, and it needed attention, it would likely be within the next couple days I would want to review an exact 'raw' picture of my bandwidth.

On another thread you suggested the correct way to cut and paste the XML into a new map by quitting the client, and reconnecting. To my surprise it worked! However, use with great care when duplicating links within the same Dude instance, or another Dude instance with identical links. Seems like the duplication 'restarts' the data collection for both the original, and new link data. :shock: No way to retrieve history data when that happens. Must revert to a backup....Glad I found out how to accomplish the backup before I wiped out some data on my development machine. Imported .tgz file, and was glad to see only a small gap in my data subsequent to wiping out my data. Also, its nice to be able to go across Dude instances with this method. You can move large sets of objects to another instance---just as long as you dont replicate any links! I would check the integrity of whats in the clipboard before doing a 'cross-Dude' paste by pasting it manually into notepad to make sure that whats in the clipboard is what you expect, i.e. not a piece of text in an email you just copied but forgot! Bottom line is that with care, moving individual maps to empty or different Dude instances can be accomplished with the understanding that the xml cut and paste doesnt carry all that raw link data you are keeping!

To make sure I wasnt tricking myself, I tried it again with full knowledge of the predicted outcome. Yes, it works--wipes out all link data as expected. I will try creating a new test link and see if the pasted 'brand new' link on another Dude instance, collects data as expected. Dangerous business....

As you have 'disclaimed': These are forward looking statements that in no way are guaranteed to be suitable or correct for any particular purpose! ......Znet
 
chrisd13
Frequent Visitor
Frequent Visitor
Posts: 68
Joined: Mon Feb 20, 2006 4:05 pm
Location: UK

Re: Dude4.beta2 Export crashes Dude instance on x86 RouterOS

Mon Oct 18, 2010 7:08 pm

I experienced a strange ocurrence when I performed an export from a client and then from the w2k server The Dude server is running from. See the attached file for the blips that coincided with the two exports I ran. The links which graphed the blips are external links which the traffic would not have been passing along. So I was just wondering if anyone else has seen this behaviour when doing an export.
Backup_blips.jpg
You do not have the required permissions to view the files attached to this post.

Who is online

Users browsing this forum: No registered users and 10 guests