Using PHP
Notes on battling with PHP, lastest update on Feb 01, 2017.
PHP + opcache
I ran into an issue whereby turning ON the opcache on PHP 5.6 would result in blank screens and request failures in CiviCRM.
- I came across similar issues
- and a civi opcache issue
- that pointed to a php issue
- Looking at the PHP opcache config yielded an odd, obscure and vague setting - dups_fix - described as a ‘hack’
Turning it on, seemed to have sorted out civi - I can turn on the opcache and not get the failures.
But after a while that didn’t solve it seems :(
And the php-fpm process is throwing errors - “zend_mm_heap corrupted” and kill in the worker process.
More searching yielded this stack conversation. First answer was a maybe (but without rationale), but third one is worth a quick try.
Nope!
The second pointed to the USE_ZEND_ALLOC=0 mentioned here and various PHP issues that speak about it.
Onto learning about PHP memory management and finding a note that you shouldn’t do what is suggested
More comments mentioned disabling GC settings
This was also suggested by this note to do the same.
Eventually I found two reports about Debian PHP packages that suggested it had been dealt with. But which packages? So I decided to install the packages from this alternate repository on to a dev server.
But it seems that my regular update to Debian and a restart has resolved the issue - none of this was needed :(
Nope, wrong again.
After hours of working fine, the worker processes are crashing again :( but only on one of the servers.
So I have run diff on the 3 config files from the servers. There are a couple of differences in them, based on testing some of the suggestions above, so they are noted, but shouldn’t be the issue.
And then I notices the php-fpm.conf has a difference in the events.mechanism - ‘epoll’ was set on the server that is crashing. After some reading up on the options I commented the setting to go back to the default - I presume it is poll(), but could be select().
Stable again.
Next up will be to migrate CiviCRM back off the dev server.
- we adjusted VMs to relieve memory pressure, but this was on a different server to the one that initially had symptoms
- we kill a failing civi mailing that was aborting - maybe it was corrupting memory and killing the child process
- a recent PHP bug that is similar.
- this offers ‘best opcache settings’
- this is a great overview of how the opcache handles memory
- and some fpm configuration suggestions
upgrading to ondrej-php
- following https://github.com/oerdnj/deb.sury.org/wiki/PPA-migration-to-ppa:ondrej-php
- and https://medium.com/@federicopanini/update-php5-5-on-ubuntu-to-5-6-version-or-7-0-cb1370882faf#.6rzmozex9
- upgrade to Jessie https://linuxconfig.org/how-to-upgrade-debian-linux-system-from-wheezy-to-jessie-stable-release
- use deb.sury.org builds of php https://github.com/oerdnj/deb.sury.org/wiki/PPA-migration-to-ppa:ondrej-php
- sudo vi /etc/apt/sources.list.d/php.list
- sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
- sudo apt-get update
- sudo apt-get install php5.6-fpm
- sudo /etc/init.d/php5.6-fpm start
- edit to set listen 9000 - sudo vi /etc/php/5.6/fpm/pool.d/www.conf
-
check if fpm is running: netstat -nlp less - check modules listing: php -m > /home/www/rohan/php-mods.hermas
- sudo apt-cache search php5.6
- sudo apt-get install php5.6-zip php5.6-xml php5.6-opcache php5.6-mysql php5.6-mbstring php5.6-intl php5.6-bz2 php5.6-curl php5.6-gd php5.6-json php5.6-ldap php5.6-mcrypt php5.6-soap php5.6-sqlite3 php5.6-xmlrpc php-memcache php-memcached
- sudo /etc/init.d/php5.6-fpm restart