Php – How to flush PHP-FPM OpCache on an autoscaling PHP cluster

Note: prepend sudo if not root

• Using SysV Init scripts directly:

  /etc/init.d/php-fpm restart    # typical
  /etc/init.d/php5-fpm restart   # debian-style
  /etc/init.d/php7.0-fpm restart # debian-style PHP 7
  

• Using service wrapper script

  service php-fpm restart    # typical
  service php5-fpm restart   # debian-style
  service php7.0-fpm restart # debian-style PHP 7
  

• Using Upstart (e.g. ubuntu):

  restart php7.0-fpm         # typical (ubuntu is debian-based) PHP 7
  restart php5-fpm           # typical (ubuntu is debian-based)
  restart php-fpm            # uncommon
  

• Using systemd (newer servers):

  systemctl restart php-fpm.service    # typical
  systemctl restart php5-fpm.service   # uncommon
  systemctl restart php7.0-fpm.service # uncommon PHP 7
  

Or whatever the equivalent is on your system.

If it is an EBS-backed image, note that Amazon uses some pretty aggressive caching behind-the-scenes (i.e. your settings mean nothing) to get EBS performance vaguely in the ballpark for common read tasks. Writes are slower to be committed to disk.

I have enjoyed some success with <command to modify disk> && sync. So it's possible Amazon is trapping the sync system call and forcing EBS to sync as well. Or maybe it's the natural behavior of sync speeding up the process (i.e. pushing in-memory changes to the filesystem immediately also kicks EBS). Unfortunately Amazon is not particularly forthcoming about their EBS tech.

If the problem truly lies with Apache, you don't specify if you are doing anything to try to alert Apache to pay attention... a "apachectl -k graceful" will tell each worker thread to finish what it is doing and exit, then launch a new thread to replace it, in theory one that does not have the content cached. (I doubt the destination of the symlink is cached by Apache, it might be cached in the file descriptor table for the process; sync should solve that.)