Slow web ui response

[theWizard]

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.

[Wayne Workman]

what’s the output of top ?

[theWizard]

@Wayne-Workman
mysql using around 25% cpu then around 15 apache2 processes using around 2-3% cpu each

[Wayne Workman]

@theWizard What version of FOG and what verson of php? php -v

[theWizard]

@Wayne-Workman
php 5.6

trunk 6907

[Tom Elliott]

@theWizard Do you have many nodes?

[theWizard]

@Tom-Elliott
Just 3 currently

Error log is a mess with 6907

0_1458660926716_error.log

[Tom Elliott]

@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.

[theWizard]

@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

[Sebastian Roth]

@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.

[Tom Elliott]

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 Technologies

The 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 Technologies

Notice 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.