$s1 = microtime(1);$a = [];for ($i = 0; $i < 150000; $i++) { //故意做读取，并跳过 if ($a[$i] == 111) { continue; } // 写 $a[$i] = 23; if ($i % 1000 == 0) { $m = round(memory_get_usage()/1024/1024,2); var_dump(date("H:i:s") . ' id ' . $i. " mem " .$m); }}$s2 = microtime(1);var_dump(($s2 - $s1));
通过比拟创造artisan实行的代码一贯在开释和重新申请内存中的一个固定地址,如图
以上测试只在部分机器会有问题, 和没问题的机器的差异为php版天职歧,php有开启opcache,先从php配置下手,通过利用不同的ini配置创造都没改进,关闭opcache测试也没有改进.但是如果php代码里把$a[$i]的读取前加一个isset判断就会快了,但是这很难担保所有数组操作前都有isset呀接下来编译不同php版本测试,创造有问题机器换了php版本(7.4.5 和7.4.9)bug就不存在了.那该当便是此版本的bug.查了7.4.9创造修复了一大堆bug,个中3条都和数组有关系,我在不会出问题的机器也装7.4.8也涌现问题了,也验证了问题所在.
当然可以通过
error_reporting(E_ALL & ~E_NOTICE);
屏蔽掉报错,之前的代码库就有屏蔽以是没有看到过这个提示,屏蔽完创造用7.4.8版本实行还是很慢,我于是想难道是由于这个notice级别的缺点?随着提示查看了Illuminate\Foundation\Bootstrap\HandleExceptions文件并把test.php做了修正
<?phpset_error_handler('handleError');function handleError($level, $message, $file='',$line=0,$context=[]){}error_reporting(E_ALL & ~ E_NOTICE);$s1 = microtime(1);$a = [];for ($i = 0; $i < 150000; $i++) { if ($a[$i] == 111) { continue; } $a[$i] = 23; if ($i % 1000 == 0) { $m = round(memory_get_usage()/1024/1024,2); var_dump(date("H:i:s") . ' id ' . $i. " mem " .$m); }}$s2 = microtime(1);var_dump(($s2 - $s1));
实行后创造test.php也变慢了,解释和laravel也没有关系.要触发问题便是要3个点
php 7.4.8 + notice级别缺点 + set_error_handler捕获缺点
到这边问题就算定位好了.
补丁验证我根据https://bugs.php.net/bug.php?id=78598找到了https://github.com/php/php-src/pull/5149 可惜的是更换代码后bug并没有消逝,那能办理问题的补丁又是哪个呢?
通过比较php7.4.9和php7.4.8源码的差异,紧张看Zend目录,反复编译测试,由最初的多个文件
modified: Zend/zend.cmodified: Zend/zend_closures.cmodified: Zend/zend_compile.cmodified: Zend/zend_exceptions.cmodified: Zend/zend_execute.cmodified: Zend/zend_generators.cmodified: Zend/zend_hash.cmodified: Zend/zend_object_handlers.cmodified: Zend/zend_vm_def.hmodified: Zend/zend_vm_execute.h
到末了定位到只有Zend/zend.c是影响此bug的文件, 再根据差异代码反查commit得到bug修复地址 https://github.com/php/php-src/commit/a3cb6122430cb43877a558f51f78bffd78cb86ca (Fixed bug #97599 (coredump in set_error_handler))故障排查结束
