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

From: 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

« previous php.bugs (#206013) next »