Is there a way to speed up DataReconciliation sending

[adimitrov]

Hello team ,

I have NetXMS server 2.0.7 installed and agent 2.1-M1. The issue:

The server crashed for some time and the agent cached all the data, its about 600MB, and now i can see that it is sending the data pretty much with the rate it is collecting. So this means it will never fill in all the data in the server. On version 2.1-M1 of the agent i can change parameter:

DataReconciliationBlockSize = ****

But the server wont receive block size bigger than 1024, in the change log of the version:

• Agent data reconciliation block size and timeout can be configured

1. Does this mean that server 2.1-M1 will accept blocksize bigger than 1024. Will this speed up the process of filling up the old data?
2. Is there any other way i can dump the data from the agent and manually insert it in the server database?
3. If not, is there any other way i can speed up the process.

any help would be greatly appreciated.

Best regards,
Adrian

[adimitrov]

Hello Team ,

It seems that only agent version 2.1-M1 supports:

DataReconciliationBlockSize = ****
DataReconciliationTimeout = ******

still I haven't had the chance to test all the versions. We noticed that the agent sends DataReconciliationBlockSize on every 30 seconds which means 2048 in a minute. Is there an easy way to make it send more often ?

I can solve the issue here only with deleting the local database of the agent. Once deleted everything starts working perfectly. However this is not suitable solution for us. What can be done in such situations where the agent must constantly sends big amounts of data and still flush the cache ?

I noticed that the agent send the cached data "1st in 1st out". In our situation it will be better to fill in the latest data first, this way we will kind of minimize the impact of the issue, as we will know what is happening in the monitoring in real time, not 2 days back as we are in the moment. Is there a way to control how the agent sends the data ?

[adimitrov]

Hello Team ,

Issue is solved. The problem was with the time for the SQLlite select query (it was taking too long 40-50 seconds). It was solved by backing up the local database. separating it in small pieces and import the pieces one by one.