Bug #73265 [Opn]: PHP7 dramatically slower in some cases

Edit report at https://bugs.php.net/bug.php?id=73265&edit=1 ID: 73265 User updated 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: 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== Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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