Why does this happens?

This happens when the data processing server (Data Server) cannot process all the load it’s receiving.

You should disable the statistical system of hourly packet collection graphs for each agent (Setup -> Performance -> Use agent access graph), this loads the system a lot and is not recommended for environments with several hundred agents.

Ensure that event data histories do not exceed seven days, and data retention does not exceed one month.

Adjust the number of threads on the data server. To process at maximum capacity, we can increase the number of data server threads up to a maximum of threads similar to the number of processors of the machine (if it has 8 cores, 8 threads). A server can process data from more than 3000 agents without any problem, even more if it is correctly configured, has a powerful hardware and the DB is in another independent server as long as it has the necessary settings.

It is necessary to be aware that the maximum number of threads in a single server cannot exceed 30-40 threads.

If we have many threads adding all the threads used by data server and other servers (e.g. Network server) it would be convenient to raise different server instances (independent processes) by means of independent configurations in /etc/pandora/pandora_server.conf.d/ (from version 770).

You can try to improve these server parameters that will make your server consume more CPU but can improve the performance:

server_threshold 1

max_queue_files 2000

dataserver_lifo 0

Another reason why the XML queuing can be generated could be when there is a bottleneck in the DB that degrades its operation. In this case we should check the size of the DB and make sure that the pandora_db is running regularly.

You can check the size of the DDBB in the About tab of the left menu of the Console and the pandora_db status in the Performance view:

BBDD Size:

To check the size of the DB you can execute in the PandoraFMS server terminal the following command:

du -h /var/lib/mysql

This way you will be able to see the size of the DB and in case its size is considerable, check the state of the Pandora DB that is in charge of debugging this DB. It would also be productive to enable the historical DB in the case that it is not enabled, or to send a greater amount of data to it to maintain in the main DB the minimum of possible data and to obtain with it that it is faster in its reading/writing.

Pandora DB:

In case that the indicator is in red, it would be necessary to try to execute the Pandora DB manually from the terminal and check if it is indicating some error in the execution.

For this, inside the PandoraFMS server terminal we can execute:

/usr/bin/pandora_db /etc/pandora/pandora_server.conf

If you see any kind of error, you can contact with the Support team to try to find the cause of the failure.