Bug #73265 [Com]: PHP7 dramatically slower in some cases
| From: | spam2 at rhsoft dot net | Date: | Thu, 15 Dec 2016 00:24:32 +0000 |
| Subject: | Bug #73265 [Com]: PHP7 dramatically slower in some cases | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-206013@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=73265&edit=1
ID: 73265
Comment by: spam2 at rhsoft dot net
Reported by: spam2 at rhsoft dot net
Summary: PHP7 dramatically slower in some cases
Status: Open
Type: Bug
Package: Performance problem
Operating System: Linux
PHP Version: 7.0.14
Block user comment: N
Private report: N
New Comment:
and that this simple shellscript running as systemd service with 7.1.0 and 7.0.14 consumes 102 MB is
also not normal
[root@testserver:~]$ cat /usr/local/bin/check-dbmail-service.php
#!/usr/bin/php
<?php
/** make sure we are running as shell-script */
if(PHP_SAPI != 'cli')
{
exit('FORBIDDEN');
}
/** verify that port and binary-name are given */
if(empty($_SERVER['argv'][1]) || empty($_SERVER['argv'][2]))
{
exit('USAGE: check-dbmail-service <port> <process-name>' . "\n");
}
/** delay monitoring for 30 seconds */
sleep(30);
/** service loop */
while(1 == 1)
{
if(!check_service())
{
sleep(5);
if(!check_service())
{
passthru('/usr/bin/killall -s SIGTERM ' .
escapeshellarg($_SERVER['argv'][2]));
usleep(750000);
passthru('/usr/bin/killall -s SIGKILL ' .
escapeshellarg($_SERVER['argv'][2]));
}
}
sleep(30);
}
/**
* check if service is available and responds
*
* @access public
* @return boolean
*/
function check_service()
{
$errno = 0;
$errstr = '';
$fp = @fsockopen('tcp://127.0.0.1', $_SERVER['argv'][1], $errno, $errstr,
/**$timeout*/5);
if($fp)
{
$response = @fgets($fp, 128);
@fclose($fp);
if(!empty($response))
{
return true;
}
else
{
return false;
}
}
else
{
return false;
}
}
?>
Previous Comments:
------------------------------------------------------------------------
[2016-12-15 00:21:22] spam2 at rhsoft dot net
xdebug looks normal
*how* do i find out what allocates that much memory inside of PHP and especially what made it *that*
worse with 7.0.14
given that httpd-prefork regulary kills processes and forks news ones allocating so much memory
explains the performance drop-down - i guess that are not memory leaks or at least not only and they
are obviously not easy to debug, as shown even not with debug builds crying out loud at their own -
see
https://bugs.php.net/bug.php?id=72734
that below is not normal on a machine with no traffic and nearly anything loaded as shared extension
[root@prometheus:~]$ ps aux | grep httpd | grep -v grep
root 789 0.0 8.3 315396 127268 ? Ss Dez14 0:03 /usr/sbin/httpd -D FOREGROUND
apache 893 0.0 6.4 315140 98548 ? S Dez14 0:00 /usr/sbin/httpd -D FOREGROUND
apache 23994 0.0 6.3 315428 96600 ? S 00:42 0:00 /usr/sbin/httpd -D FOREGROUND
apache 23995 0.0 6.3 315428 96600 ? S 00:42 0:00 /usr/sbin/httpd -D FOREGROUND
[root@prometheus:~]$ php -m
[PHP Modules]
apcu
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
gd
hash
iconv
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcre
readline
Reflection
session
SimpleXML
soap
SPL
standard
tokenizer
xml
zlib
[root@prometheus:~]$ ls /lib64/php/modules/
insgesamt 6,4M
-rwxr-xr-x 1 root root 80K 2016-12-08 12:59 apcu.so
-rwxr-xr-x 1 root root 31K 2016-12-08 12:48 bcmath.so
-rwxr-xr-x 1 root root 28K 2016-12-08 12:48 calendar.so
-rwxr-xr-x 1 root root 15K 2016-12-08 12:48 ctype.so
-rwxr-xr-x 1 root root 91K 2016-12-08 12:48 curl.so
-rwxr-xr-x 1 root root 167K 2016-12-08 12:48 dom.so
-rwxr-xr-x 1 root root 59K 2016-12-08 12:48 exif.so
-rwxr-xr-x 1 root root 3,1M 2016-12-08 12:48 fileinfo.so
-rwxr-xr-x 1 root root 95K 2016-12-08 12:48 gd.so
-rwxr-xr-x 1 root root 151K 2016-12-08 12:48 hash.so
-rwxr-xr-x 1 root root 39K 2016-12-08 12:48 iconv.so
-rwxr-xr-x 1 root root 43K 2016-12-08 12:48 json.so
-rwxr-xr-x 1 root root 1,4M 2016-12-08 12:48 mbstring.so
-rwxr-xr-x 1 root root 131K 2016-12-08 12:48 mysqli.so
-rwxr-xr-x 1 root root 236K 2016-12-08 12:48 opcache.so
-rwxr-xr-x 1 root root 135K 2016-12-08 12:48 openssl.so
-rwxr-xr-x 1 root root 96K 2016-12-08 12:48 session.so
-rwxr-xr-x 1 root root 47K 2016-12-08 12:48 simplexml.so
-rwxr-xr-x 1 root root 431K 2016-12-08 12:48 soap.so
-rwxr-xr-x 1 root root 51K 2016-12-08 12:48 tidy.so
-rwxr-xr-x 1 root root 19K 2016-12-08 12:48 tokenizer.so
-rwxr-xr-x 1 root root 59K 2016-12-08 12:48 zip.so
------------------------------------------------------------------------
[2016-12-15 00:07:56] nikic@php.net
Please provide either a means to reproduce, or some profiles showing a difference. Profiles may be
xdebug, perf, strace, or anything else that shows some kind of actionable cause of this problem.
There is nothing we can do based on the information currently provided.
------------------------------------------------------------------------
[2016-12-14 23:39:19] spam2 at rhsoft dot net
and that memory usage is independet of load, here it is 00:38 AM and a few seconds after hard
restart httpd all processes are afr above 100 MB, the fattest one cosumes 173 MB
------------------------------------------------------------------------
[2016-12-14 23:36:56] spam2 at rhsoft dot net
what i can assure you is that with 7.0.14 things got *much* worser and the system dropped down below
4 per second with "ab -c 20" and is raising OOM killers because each apache preforker in
htop is showing 120 MB to 160 MB RES memory usage in htop while with PHP5.6 it was constantly around
50 MB
this can not be opcache (or at least should not be) because shared memory typically is not counted
as "resident" for each process
Requests per second: 3.85 [#/sec] (mean)
Time per request: 5198.089 [ms] (mean)
Time per request: 259.904 [ms] (mean, across all concurrent requests)
Transfer rate: 55.88 [Kbytes/sec] received
------------------------------------------------------------------------
[2016-10-07 14:05:31] spam2 at rhsoft dot net
configuration is 100% identical, even the CFLAGS and ./configure as well as RPM sub-pckaging, two
days before the upgrade i "backported" the RPM-SPEC and deployed a new 5.5.26 build
something eats twice CPU it seems
a second VM on the same host has exactly twice requests per second with PHP7 which is caused by the
fact the VM has 12 instead of only 6 cores
well, we will downgrade a developer machine on monday and try to compare xdebug outputs with PHP5
and PHP7, IMHO that should show changes in how expensive parts of the application are and lead to
find the critical code paths
hopefully we can nail that down to specific native php-functions which would lead in isolted loop
cases and reprocuder-sample code, i guess the php developers are also curious in which bordercases
the results go in the exactly wrong direction
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=73265
--
Edit this bug report at https://bugs.php.net/bug.php?id=73265&edit=1