If you have all 60 targets on a single page, that's a lot of processing before it can draw that page.
I don't have that many targets on a single page, and I've never tried something similar. But I'd guess that's the source of the problem.
Perhaps someone else can chime in, who has a lot of targets in a single page, or you can try breaking them into smaller groups as a test and see if that helps.
[Or live with the long load time.]
-Greg
| Hey Greg, I took your advice for disabling apparmour which still doesn't help. This box is definitely not doing anything I/O intensive. It's also a relatively powerful box (12 core, 24gb ram). It's basically a cron server and web server for a local intranet occupied by maybe 20 people at the moment but will be used for more cpu intensive stuff later down the line. I tested top when loading the page and the footprint was minimal. I didn't realize I had slaves entered in the slave section, I was just using the template config, so I removed those. No slaves are configured for this. I debugged this further and found that when I upped the default timeout and found that once apache2 was restarted, it would increasingly take more time to show the page initially as I increased the number of Targets, however, once the page was loaded, it would refresh almost instantly. I also upgraded my local install of RRDTool, however, this doesn't seem to help the initial load time. On Tue, Mar 4, 2014 at 4:51 PM, Gregory Sloop <[email protected]> wrote: [Tue Mar 04 15:15:36 2014] [warn] [client 192.168.1.66] mod_fcgid: read data timeout in 40 seconds, referer: http://pipeline/ Looks like the smokeping cgi times out reading data. Is this box I/O bound? What does top show when you try to get a web-page from SP? [load averages in particular] In any case, you need to figure out why the CGI is failing to read the data in the allowed time of 40 secs. Changing the default time-out might help if the box is I/O bound, but not totally buried. [And I'm not sure where that might be.] However, if the box is seriously overloaded I/O wise, then waiting longer won't really solve your problem - it will just push the box further below the water. [And this all gets back to - how many RRD's and how big are they. See the database section. Are there slaves? If so, how many?] Finally: >Is fping being ran as soon as the cgi script is executed from the webserver? You appear to misunderstand how SP works. The daemon runs fping and logs the results and writes to the RRD's. The CGI pulls data from the RRD and generates graphs for the http output. It appears from the debug log from SP that writing the data went fine. [At least for the small subset of targets.] However reading the RRD's and generating the graphs appears to fail/timeout when reading the RRD's. [Or reading something - in any case.] Is selinux or apparmour running? If so, then stop them or run in permissive mode and see if that helps. -Greg
|
_______________________________________________ smokeping-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
