Edit report at https://bugs.php.net/bug.php?id=73265&edit=1
ID: 73265
Updated by: yohgaki@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:
Much of time is spent on malloc.
This is wild guess
--disable-huge-code-pages
configure option might help.
Previous Comments:
------------------------------------------------------------------------
[2016-12-15 01:24:08] spam2 at rhsoft dot net
"Massif writes to a file, not to stdout..." - well, how should a serveradmin and
php-developer (with PHP the language) know that....
http://access.thelounge.net/harry/massif.txt
------------------------------------------------------------------------
[2016-12-15 01:14:36] nikic@php.net
Massif writes to a file, not to stdout...
------------------------------------------------------------------------
[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;
}
}
?>
------------------------------------------------------------------------
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