Opcache状态内存大小问题

I'm currently having some issues invalidating some troublesome opcache entries on using PHP7.0-FPM.

Some files are being cached with a the a memory size of 680.00b when I view in opcache_get_status. These files are usually around 50kb in size and appear to be cached correctly, but Opcache is reporting a number of these files to be exactly 680.00b.

Opcache Settings:

; configuration for php opcache module
; priority=10
zend_extension=opcache.so
opcache.memory_consumption=16384
opcache.max_accelerated_files=32531
opcache.validate_timestamps=0
opcache.revalidate_freq=600
opcache.max_file_size=0
opcache.fast_shutdown=1

It's an unusual setup where generated files are being cached so occassionally there are issues and the files are replaced/recached.

Is there any reason anyone can think of why opcache is showing these files as 680.00b? An opcache_reset or an opcache_invalidate doesn't help. I have to replace the files completely and use an opcache_reset for them to show up with their true filesize and it's making monitoring/troubleshooting difficult.

Thanks in advance.

When it comes to different scripts showing the same consumption: One possible reason is that opcache needs to allocate memory aligned for the best performance on the current platform.

For example (none of this code is real):

void *mem = zend_opcache_alloc(sizeof(void*));

mem will be sizeof void* + ZEND_MM_ALIGNMENT(sizeof void*, platform)

So there is some kind of padding at the end of the region to force the best alignment, this means though that you could allocate (for example) 8 bytes or 64 bytes, and would be returned a 128 byte block (none of those numbers are correct).

This can lead to different scripts having the same size by coincidence.

When it comes to why some scripts are using a very tiny amount of memory:

<?php
$a = 1;
?>

Yields the following statistics:

["/usr/src/php-src/test.php"]=>
array(6) {
  ["full_path"]=>
  string(25) "/usr/src/php-src/test.php"
  ["hits"]=>
  int(0)
  ["memory_consumption"]=>
  int(696)
  ["last_used"]=>
  string(24) "Wed Nov 16 05:47:26 2016"
  ["last_used_timestamp"]=>
  int(1479275246)
  ["timestamp"]=>
  int(1479275244)
}

So, you should suspect that the code is not being cached correctly, unless these files contain similar (single statement, single instruction) code.