Performance penalty for accessing the psql DB

[adarsh]

@roy

to get that data you would need to call qstat every time a new job is submitted and I would like to avoid doing that because it would put stress on the scheduler.

Thats right, it would be load on the PBS Server

@roy

I would like to access the psql once every time a new job is submitted and extract all of the fields from the psql DB.

I am not sure whether this is a recommended method, that is accessing the database externally when the system is in production. Instead, you can take a snapshot every 30 seconds and gather information from it

@roy

What are your thoughts? is that a scalable solution? would that also put pressure on the scheduler?
After the data is extracted from psql and injected into Elasticsearch then our dashboards and tools would use the ElasticSearch DB and the psql DB would be left alone, it’s only once per job submission.

Any repeated or high frequency or watching qstat’ / q commands will put pressure on the PBS Server.
If you could let us know the end goal of using Elastic Search that would be helpful. The data in the postgres database are updated periodically based on the changes to the configuration of queue, nodes , jobs, job history etc.

Please refer the below links and they might helpful

PBS accounting and metrics and Elastic stack

Hi everyone, Just to share with the community (I don’t know really how yet), at the HPC cluster in CNES, we have plugged some information coming from PBS into an Elastic stack instance: PBS Sever accounting logs: thanks to this, we are able to view some statistics about our users job and cpu hours consumption. I give only a quick glance at PBS analytics, but this seems to be quite the same goal, but with more history capacity and reactivity, and also some real time information. qstat and pbsn…

PBS MoM Log Analysis in ELK Stack

Hi Adarsh, Please refer to the below link: Thanks, Rakhen

GitHub - guillaumeeb/pbs-elastic: Some script and configurations files to...

Thank you