Bug #49383 [Nab]: Lots of empty fstat() calls slow performance

Edit report at https://bugs.php.net/bug.php?id=49383&edit=1 ID: 49383 Updated by: nikic@php.net Reported by: olga at metacafe dot com Summary: Lots of empty fstat() calls slow performance Status: Not a bug Type: Bug Package: Performance problem Operating System: Red Hat 3.4.6-10 PHP Version: 5.3, 6 Block user comment: N Private report: N New Comment: Okay, duplicate fstat removed after all in https://github.com/php/php-src/commit/07a4d134abd07690f9921eb0d0c7eeb671b0b875, now there should be just the one. Previous Comments: ------------------------------------------------------------------------ [2019-07-17 10:08:59] nikic@php.net I commented too early ... there will be two fstats after all. Still one less than before... ------------------------------------------------------------------------ [2019-07-17 09:25:51] nikic@php.net I've dropped two fstat() calls per include in 7.4, so only a single fstat() call should be happening now. ------------------------------------------------------------------------ [2019-01-23 02:54:28] 593948970 at qq dot com 我也遇到了这个问题好像是opchache无法使用的情况下 access("/data/web/releases/20190122_1036111_2/src/application/Models/LocalModel.php", F_OK) = 0 open("/data/web/releases/20190122_1036111_2/src/application/Models/LocalModel.php", O_RDONLY) = 9 fstat(9, {st_mode=S_IFREG|0755, st_size=416, ...}) = 0 fstat(9, {st_mode=S_IFREG|0755, st_size=416, ...}) = 0 fstat(9, {st_mode=S_IFREG|0755, st_size=416, ...}) = 0 mmap(NULL, 416, PROT_READ, MAP_SHARED, 9, 0) = 0x7fea60241000 munmap(0x7fea60241000, 416) = 0 close(9) = 0 ------------------------------------------------------------------------ [2018-12-17 22:01:45] mtausk at gmail dot com I wonder if this has been fixed. I've noticed the same behavior in php5.6 (PHP 5.6.39-1+ubuntu16.04.1+deb.sury.org+1). I know it's an old version but I am just checking if some solution was proposed. - opcache enabled - open_basedir disabled after open() is issued, 4 exactly same fstat() calls occur. I guess 3 of them are not necessary and in long-term it eats sys% like this: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 20.23 0.008665 2 5511 fstat 18.91 0.008097 3 2382 poll 14.58 0.006244 3 2382 recvfrom 10.25 0.004390 3 1341 munmap 9.69 0.004151 3 1467 open 9.34 0.004000 222 18 shutdown 7.20 0.003083 10 318 brk 4.07 0.001741 1 1481 sendto 2.55 0.001093 1 1072 19 access 1.30 0.000555 6 90 write 0.72 0.000308 0 1341 mmap ... See the time CPU mostly spent in syscalls is at the very fast but redundant fstat() call. ... access("luigisBoxHtmlBodyEnd.php", R_OK) = 0 open("luigisBoxHtmlBodyEnd.php", O_RDONLY) = 7 fstat(7, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0 fstat(7, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0 fstat(7, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0 fstat(7, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0 mmap(NULL, 438, PROT_READ, MAP_SHARED, 7, 0) = 0x7f8560433000 ... Would this be fixed in php7 if the site is moved there? Thanks. ------------------------------------------------------------------------ [2010-08-12 16:36:14] rasmus@php.net The reason open_basedir affects this is because for security reasons we can't enable the stat cache when open_basedir is enabled which will also affect stats after the file is opened since it isn't the open_basedir check itself causing the stat but the fact that the open_basedir feature forces the stat cache to be disabled. The main thing that changed between 5.2.x and 5.3.x with respect to stats is that we rewrote the stat cache to be more efficient. It now does intra-path caching of realpath() lookups as opposed to just caching the return of the realpath() call, but it doesn't sound like this is the issue here. One thing you can try is to compile PHP without phar support. ./configure -- disable-phar and see if that changes things. Beyond that you would need to set a gdb breakpoint and get a backtrace of those calls. Generally we are not too concerned about fstat calls since they tend to be extremely fast in most environments. It is the full stat/lstat calls that need to hit the disk that tend to be slow. ------------------------------------------------------------------------ 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=49383 -- Edit this bug report at https://bugs.php.net/bug.php?id=49383&edit=1