Performance Graphs tab freezing browser

[dwasswa]

If the commands return a number greater than 20,000 then it is likely you will need to delete the files as the processes will get caught in a loop and not be able to process them.

To delete a large amount of files in a directory, execute this command:

Code: Select all

find /usr/local/nagios/var/spool/perfdata/ -type f -delete

This command can take a long time to execute, simply due to the volume of files. You can open another SSH session and observe the count of files in the folder with this command:

Code: Select all

watch 'ls /usr/local/nagios/var/spool/perfdata/ | wc -l'

When the files are finally deleted, wait approximately thirty minutes to see if performance graphs start to work

[gwakem]

I’m confused. There were only three files in that directory (as shown by the output I posted) and they date to 2016.
Also, as I mentioned before, I can view the rrd with no issues... as long as I dont use the performance graphs tab under the service, which calls the gauge dashlet. The rrd can be viewed, zoomed in on, different timeframes selected etc, via the “quick view pop up” which does not call the gauge. I just want to make sure we’re not heading toward deleting the rrd unless we absolutely have to.

[dwasswa]

If there were only three files in that directory then you dont have to delete anything

[gwakem]

Ok. I’m not sure where that leaves us, but I still strongly suspect the gauge can’t handle the type of numbers the service check is cranking out. I posted the exact uri that the browser was stalling out on in a previous post. I can provide additional details or run any other commands needed tomorrow. Just let me know.

[tacolover101]

I have attached the RRD and XML.

these look OK. the issue may be with how php is rendering the RRD via JS. i've seen something in the past similar to this in the past.

i don't have an active XI install, but here's some information that may help you get to that point to find what you're looking for. (or the staff can help)
- load the page, look at the source for the browser (or get the URL, and CURL it so we can get a source.)
- in this, you should see a reference to JS where parameters are being passed for the data it renders. (this will be a long string)

if this is similar to what i saw in the past, there was corruption within the data being passed, thus causing issues client side.

this is a long shot, but perhaps it will help.

[gwakem]

Thanks! Im not having any luck tracking down which query is doing it, since everything slows down so much when this happens. At one point, firefox used 14GB of memory and pretty much everything fell apart. No luck in curling the URI either, but this was a solid lead to try. If anything, it convinces me that this is the right track.

[dwasswa]

Hi @ gwakem,

You could submit a ticket if you wish to dig a little further.

[gwakem]

To be clear, are you saying we have exhausted all other troubleshooting steps available via the forums? If that's the case, I'm extremely surprised. I have seen almost no suggestions (outside of tacolover101's suggestion) on how to verify the gause is the issue. Are we not even going to try and verify that?

[dwasswa]

No, don't worry,you have not exhausted any all other troubleshooting steps available via the forums. You don't have to open a ticket if you don't want to. You have unlimited access on the support forum.

Please try what @tacolover101 suggested as we are still trying to investigate/troubleshot your issue so, no worries we are working on it.

[gwakem]

Thanks for the clarification! I have attempted to do what @tacolover101suggested but as mentioned above, was not able to find the specific query as in a matter of 45 seconds to a minute that browser has used up 14GB of memory. I will see if I can find a better way to do it than what I was doing, but I am still open to what ever you all think of to verify this another way.