Edit report at https://bugs.php.net/bug.php?id=73265&edit=1
ID: 73265
Updated by: nikic@php.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:
Massif writes to a file, not to stdout...
Previous Comments:
------------------------------------------------------------------------
[2016-12-15 01:09:20] spam2 at rhsoft dot net
sadly no - there is not much output at all, see at bottom, before CTRL+C it cosumes around 220 MB
memory, likely the valgrind overhead
____________________________
by the quoted comment in the bugreport below we hoped that the 50% dropdown could be solved with
7.0.14 - the opposite is true - is it possible there some bug and nobody noticed the large memory
allocation?
i have currently only one machine running a while(true) loop to look if there are call files for
asterisk which is around 30 MB and fine as well as our adminpanel in the same range - anything else
running PHP 7.0.14/7.1.0 is around 100 MB and above
"check-dbmail-service.php" is far above 100 MB (CLI script) while the idle webserver on
that machine "only" consumes 90 MB per forker
https://bugs.php.net/bug.php?id=72736
"It's not really necessary to bring mysql into this. Just allocating a bunch of strings
without deallocating them in between is enough"
____________________________
[root@testserver:~]$ USE_ZEND_ALLOC=0 valgrind --tool=massif /usr/bin/php
/usr/local/bin/check-dbmail-service.php 20143 dbmail-imapd
==8780== Massif, a heap profiler
==8780== Copyright (C) 2003-2015, and GNU GPL'd, by Nicholas Nethercote
==8780== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==8780== Command: /usr/bin/php /usr/local/bin/check-dbmail-service.php 20143 dbmail-imapd
==8780==
^C==8780==
==8780== Process terminating with default action of signal 2 (SIGINT)
==8780== at 0x685BA97: kill (in /usr/lib64/libc-2.23.so)
==8780== by 0x2F7BD8: ??? (in /usr/bin/php)
==8780== by 0x40BB89: ??? (in /usr/bin/php)
==8780== by 0x661BC2F: ??? (in /usr/lib64/libpthread-2.23.so)
==8780== by 0x68EF9DF: __nanosleep_nocancel (in /usr/lib64/libc-2.23.so)
==8780== by 0x68EF949: sleep (in /usr/lib64/libc-2.23.so)
==8780== by 0x24251B: ??? (in /usr/bin/php)
==8780== by 0x3C5FEF: ??? (in /usr/bin/php)
==8780== by 0x3C3CF2: execute_ex (in /usr/bin/php)
==8780== by 0x40CA1C: zend_execute (in /usr/bin/php)
==8780== by 0x3A70F1: zend_execute_scripts (in /usr/bin/php)
==8780== by 0x379500: php_execute_script (in /usr/bin/php)
==8780==
------------------------------------------------------------------------
[2016-12-15 00:54:18] nikic@php.net
You can use
USE_ZEND_ALLOC=0 valgrind --tool=massif php script.php
to profile the memory usage of PHP, and then run
ms_print massif.out.NNNNNN
to convert it into a more readable output.
Maybe this will provide some insight into the problem.
------------------------------------------------------------------------
[2016-12-15 00:24:29] spam2 at rhsoft dot net
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;
}
}
?>
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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