Slow web ui response
-
Does anyone else has very slow ui response from fog ? Runing latest trunk but has been the same on others for the last few weeks, running mint os.
I get an error in apache log about reaching maxrequestworkers but even if i increase that ten fold i still get the error ?
Any ideas would be great. -
what’s the output of
top? -
@Wayne-Workman
mysql using around 25% cpu then around 15 apache2 processes using around 2-3% cpu each -
@theWizard What version of FOG and what verson of php?
php -v -
@Wayne-Workman
php 5.6trunk 6907
-
@theWizard Do you have many nodes?
-
-
@theWizard I wonder if the slowness is just the continued spamming of the logs, though I’d also recommend ensuring all nodes are at the same level. These last few builds I’ve changed how files are picked up for reading/scanning. Because of this there are some minor requirements.
I’ve also made updates in an attempt to fix the error’s that are being passed as some of what you saw is not really problematic (as we should be able to expect that sometimes no data is found). I don’t know if it is indeed fixed, but hey, I tried.
-
@Tom-Elliott
Thanks i completely removed apache and php then ran the latest trunk and let it install the nessesary components, after that i updated the nodes to the same trunk too but does not seem to have helped much.
I am also getting this error
[Wed Mar 23 09:00:27.367136 2016] [:error] [pid 12952] [client 135.100.90.120:49307] PHP Warning: Error while sending QUERY packet. PID=12952 in /var/www/fog/lib/db/mysql.class.php on line 49 -
@theWizard said:
PHP Warning: Error while sending QUERY packet. PID=12952 in /var/www/fog/lib/db/mysql.class.php on line 49
To me this error seams not like being the cause but more likely one of the results of whatever is causing your system to respond very slowly. I guess you need to read about and get into system debugging. Unfortunately there is not much we can do from here.
-
With any luck, I hope to have found a potential partial cause of the load. Again, this only appears to happen on Ubuntu based systems, but why I couldn’t tell you.
By moving the servicemodule-active.php file I can limit the load, but I think it’s not a suitable test because it essentially keeps the FOG Clients from doing anything related to the work the modules are expected to do.
This seems, to me, to be two part. First the servicemodule-active was calling at least 12 separate calls to the database per system. I’ve now limited this to a single call to the database to return all the values. The second part that I have no good way to test is the php versioning.
While most are running 5.6.20 (or very close to it), the values should be operating in normal ranges. However, the output of Fedora 23 system running PHP 7 (sorry I don’t feel like downgrading to php 5 for now).
PHP 7.0.5 (cli) (built: Mar 30 2016 09:13:39) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend TechnologiesThe output of PHP 7 on Ubuntu 15.10
PHP 7.0.5-2+deb.sury.org~wily+1 (cli) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend TechnologiesNotice the “extra line” of “With Zend OPcache v7.0.6-dev, Copyright” stuff.
I don’t know if that’s actually supposed to do that. Meaning, I believe the Zend OPcache value should match the php version as php is written by Zend (or so I thought). In either case, it’s intriguing to say the least.
