Error: Server Timeout
-
@mattfox Well, this has been working for some two years or so, and we do need to keep all the data for at least the last one year
-
I know what you mean. I've got an 8Gb nosql db. Plenty of history there!
It's the h2 that will store config, events, datapoints, their configurations and the data sources. Which is why it seems a bit strange. I may be packing around 100 datasources and 7500-8000 points. Plus tags and events. But I don't believe I've even touched 500megs. But it is all just supposition on my end. I don't know all the details and Phil sounds quite on top of this so I'll leave it to him. -
If you breezed past deleting your Mango/work/jsp directory, you should still try that. You need to communicate to me what you have or are trying.
Just to clarify, I didn't state my H2 database size till now, I stated that my NoSql has 6GB. H2 database took forever to show that info on system settings page, actually I stopped waiting for it to show it, I checked properties on the H2 database inside the file system.
Ah, you are correct, my mistake (I was looking at the 7.7GB total memory comment). Nevertheless, an 8GB+ H2 database when you're using NoSQL for pointvalues is way too large. You should go through the steps to shrink it.
@mattfox Well, this has been working for some two years or so, and we do need to keep all the data for at least the last one year
There is a known issue in versions of H2 prior to 1.4.197 where updating a binary long object creates database growth that is not freed because the database is not closed regularly (where they do their compaction). So the database grows until it becomes a problem. And yes paging around many GB of database is slower than the ~100MB it's going to be once you shrink it.
-
Hi Phil,
Had some obligations to fulfill so I was away from my PC.
I have deleted the Mango/work/jsp directory. Also purged all events and checked system settings for backup and purge policies. Currently, the policy is to purge all point data older than 1 year, all events older than 1 day and discard future dated values more than 24h.
NoSql is doing backups every day and keeps 365 versions.
Since I have NoSql backing up everything daily, is it safe to assume that I can actually purge point data much more frequently?
-
The point data is not going to be the cause of the server timeout on the page. The NoSQL datastore can get much larger and not cause issues. A purge task runs every night regardless of where it finds the timestamps to purge values or events.
Since I have NoSql backing up everything daily, is it safe to assume that I can actually purge point data much more frequently?
They are different things. The data is purged if it is older than a cutoff, the backup backs up everything that changed since last time (incremental) or everything in the NoSQL (not incremental), so I don't understand how they can relate as in the question. Definitely as your database gets larger the backup task can take longer to run, you can find that in the logs, so it can become worthwhile to disable backing up to the Mango/backup folder as wasting disk or CPU and instead use a service to create a backup on another disk, so that you're further protected in a case of disk failure.
-
Any suggestions for me on how to determine why is my H2 database so large?
-
You could disable everything and watch the size, the enable things piece by piece to see what's responsible. If you have a persistent publisher doing syncs as I mentioned, don't waste your time and just do the convert to MySQL.
Edit: I would probably shrink it first.... Also, you can start Mango with all data sources disabled by creating a file at Mango/SAFE (no file extension) before starting Mango.
-
I deleted mah2.h2.db and did a backup to January 9, (before I added any new sources, points etc) database is now down to ~320MB. No server timeout issues anymore.
Though, at first, I did a backup to January 22 (yesterday), it fell down to ~550MB, but it went into timeout again when I tried to access data sources page. Did a restart, it jumped up to 2.5GB after restart. Note: PC with Mango server is currently without internet connection though it polls its sources via TCP.
-
And there's nothing relevant in the Mango/logs/ma.log file?
You could try the conversion to MySQL.
It is possible to simply raise the timeout for that page, but it doesn't seem like there's any reason it should be taking more than the default timeout.
-
I forgot to inquire if you have set memory settings for this machine? Perhaps you can try allocating ~70% of the memory explicitly to Java via moving an appropriate memory script from Mango/bin/ext-available into Mango/bin/ext-enabled, modifying it to your system's resources, and stopping, then starting (not restarting) Mango to have it come into effect.