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.

Hi Greg,

The most important thing is to pick an explicit memory allocation that is appropriate to the machine but as large as possible. On your machine, you could probably allocate 650 or 700 MB to Mango before the operating system starts waking up the oom-killer to take it back.

There were some memory leaks in the past, true, but there's nothing to do in preparation for the bugs that have already been fixed.

There are other things, but they are sometimes subtle and certainly numerous. For instance, the persistent's minimum overlap when synchronizing blocks of data setting can speed up synchronizations significantly (the receiver must be using NoSQL though) which will make the memory in use there available to other uses faster.

Or, scheduling a bunch of meta points on the same cron pattern with a statistics call ( .past(DAY) for instance) would be a bad idea faster when memory is less available. The same could be said for a bunch of reports scheduled for the same instant.

Usually for memory I find it's easier to unwind the problem than presage where it could go wrong. This way, if there is no problem, there is no unwinding necessary.

With some of the ways users can cause massive memory usage in short order by certain large requests (which should have seen improvement in 3.6.3, much larger REST requests should be possible with much smaller memory footprints, and 3.6.4 should improve this some more), an important variable is the access control.

I would not expect a history generation to cause the issue again with the settings changed.

I see your point about the delay in shutdown. You can wait in the shutdown until it is reporting that it is waiting for batch write behind tasks to finish, and then use a kill -9 to stop Mango, this should not cause issues. It is possible to reflect out the counter and manually set it to something, but I think it would be better to restart Mango.

Hi Rick,

Are you polling these devices or using a COV subscription?

Does the data acquisition stop at the same time each day? Are there any related events or log messages?

You could use one of the data source's events to restart the data source, or you could try to broadcast a whois request periodically from a script.

It should, but it doesn't look like it does in all cases. For instance, scripting appears to, but meta data points don't. I will bring this up, thanks for bringing it to our attention.

@Tomi The adminTemplate has been removed, we highly recommend creating a custom page using "Edit pages" or "Dashboard designer" (you will find these in the menu). You can set them up so they are full screen pages, i.e. have no left menu or toolbar at the top.

If you do want to create your own custom AngularJS project and serve it from the Mango web server you can still do so. However the onus is on you to maintain it. The old adminTemplate is located here as a starting point - https://github.com/infiniteautomation/ma-dashboards/tree/3.3.x/UI/web/adminTemplate

@support-jo said in AC data point:

I press the green refresh arrow but when I select "present value " then save the work , the green refresh arrow return to appear

That is the the expected behavior in the old UI. If you were on the latest Mango you could create this BACnet data source in the new UI, which does not have the refresh arrows on data type and property identifier.

Speaking of version numbers, what Mango version are you on? It looks like there was a bug fixed with the relinquish tag, which is what the screenshot of the error seems to be about: https://github.com/infiniteautomation/ma-core-public/commit/a6c2a0f8714368c61a0e167bc1cc73328fa48e30

The stack trace would be in the Mango/logs/ma.log file, accessible through the logging console page or the logging console within Administration --> System Status

Glad to hear it, I mostly took it from this thread: https://forum.infiniteautomation.com/topic/3590/ma-date-range-picker

Hi Tomi,

There are a ton of ways to do this.

Here's a video on using CSV to create large numbers of points: https://help.infiniteautomation.com/bulk-importing-data-points

Here's a thread about using the template configuration module to do it: https://forum.infiniteautomation.com/topic/3216/template-import-json-markup-example

Here's a thread using a script to import event detectors onto points: https://forum.infiniteautomation.com/topic/3708/a-script-jsonemport-example

The second two are based off JSON, which is also what it would be used for the API, as in this thread: https://forum.infiniteautomation.com/topic/3060/mango-rest-api-how-to-create-data-sources-data-points

There's also a copy button on data sources in the old UI (use the link from the data sources page to the legacy data sources page, or navigate to /data_sources.shtm). I suspect it will appear in the new UI fairly soon:
0_1563212508109_old-ui-copy-button.png

I probably overlooked a few options...

Correct, although it should continue to work even in subsequent releases. But, once 3.6.2 is released the concerns raised in this thread will have been fixed,

points list not available via .points JavaScript help says type not typeName while .typeName is correct

OK Thank you for the quick response Phil.

Cheers

Brian

Hi fishfacs, no problem at all!

You can use

Mango/overrides/web/modules/excelReports/web/ftl/

which will persist upgrades.

Yes that should be possible too. Simply have mostly the same configuration on two Mango instances on the same network, with one asymmetry being one is publishing its heartbeat to the other (publish system uptime or a random number, whatever) and have a no-update detector on the received point, which has a script to start all the data sources, and then stop them once the first machine is updating that point again. As far as merging after the fact, the easiest way would be to do a NoSQL "Migrate Mango NoSQL Data into Mango" on the second Mango/databases/mangoTSDB and Mango/databases/mah2 after any outage. There may be some issue with the changeover, but that's likely to do with the specifics of your system (i.e. some other host on the network refused the first connection, etc).

Currently no, but that is possibly a good suggestion. Currently the solution is to use individual directories for individual importers.

I'm surprised you report that to be the issue! I took a quick look at the code and it's checking if a listed file in the directory and shouldn't import in that case. I'll take a deeper look next week. You can have other files in the directory and have them be ignored, but only if they're named to begin with the imported prefix set on the data source, currently.

As you are likely the maintainer of the system, you should do what makes sense to you.

Global scripts are simply stitched into scripts to provide functions or global variables or what have you. Refactoring what gets passed where and how in a script is an implementation decision that I don't see a clear advisement on. It certainly can simplify things if lots of scripts would be doing the same thing to make that a uniform function.

The only thing I can think to add to that is that currently script engines which are in something's runtime do not suddenly execute a global scripts when it is saved to pick up the changes. You would have to restart any meta data sources or scripting sources, for instance.

Hi Nathan

I do believe the OPC data source requires windows.

Good Morning Phil,

You can cancel this request, I was able to solve my Authorization Request Header issue.

Thanks again for all the help!!

Hi Craig,

thanks for the swift reply and the detailed description! It actually did the trick -- many thanks! I would have never guessed from the documentation, that this would be the thing to do. But hey -- always good to learn something.

Cheers,
Frank

Perfect, thanks for your help @phildunlap . Much appreciated!