忙しい人のための結論
/etc/php5/apache2/php.ini
opcache.fast_shutdown=0
いつ頃くらいからだったか忘れましたが、このブログの環境でWordPressの更新(プラグイン/本体どちらでも)をするとページが表示できなくなる問題が起きていました。
一応の解決というか経過観察に入ったのでメモ。ググっても結局解決してないような情報が散見しているような感じでしたし同じような現象で悩んでる人の参考になれば。。
目次
まずは環境
Ubuntu 14.04.4 LTS x64 Server version: Apache/2.4.18 (Ubuntu) PHP 5.6.18-1+deb.sury.org~trusty+1 Copyright (c) 1997-2016 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies WordPress 4.4.2–ja Zen Cache Pro v160222
オリンピックまでには一新しないとね・・・。
現象の見た目
- WordPressの本体orプラグイン更新後にサーバーが落ちたように見える。
- 5分くらいすると復活する。
- 1つのWordPressで起きると同じサーバーの別の場所で動かしている他のWordPressも表示できなくなる(いわゆるマルチサイトではなくて、独立してセットアップしたものです)。
- 同じApacheで動いてる別のサービス、例えばSymfonyのアプリは動く。
- 更新自体はちゃんとできてる(面倒くさくて半年以上restartしてました…)。
- どうせキャッシュ関連だろってQuick Cache Pro(Zen Cacheって名前変わって最近またComet Cacheって名前に変わったらしい)を切ったら発生しなくなった。
- PHPのOPcacheをオフにしてもでなくなった。
と問題ははっきりしているものの、やっぱりキャッシュの仕組みはそれなりに使いたくて、Zen Cacheに至ってはPro版も買っちゃったし、他のキャッシュ系プラグインでも何かしら痛い目を見てるので今の環境でうまいことやりたい。
寝てるうちに勝手に直ってくればラッキー…と思いながら季節が3つくらい変わったのでさすがに起きました。
で、まずApacheのエラーログではZendのメモリ管理のエラーっぽいのと一緒にセグってた。
[core:notice] [pid 1219] AH00052: child pid 2213 exit signal Segmentation fault (11) zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted ...同じ行がたくさん zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted
とりあえずこのキーワードから追ってもまあ多岐に渡っておりよくわからない。
コアダンプ
仕方ないのでPHPの何が悪いのかあたりがつけば良いな程度の感覚でcoredumpをとってみることに。
最近じゃ色々面倒なんですね。複数のサイトを参考に以下のように。
/etc/apache2/apache2.conf
コアダンプの出力先の設定。
+ CoreDumpDirectory /tmp
/etc/profile
サーバーデーモンへulimitを効かすためここへ。後述のlimit.confがあればいらないのかも。
+ ulimit -c unlimited > /dev/null 2>&1
/etc/default/apport
クラッシュするとデフォルトでapport経由しちゃうので無効に。
+ #enabled=1 + enabled=0
/etc/sysctl.conf
目的はapacheだけど一応なんでも吐くようにする。
+ kernel.core_pattern = core.%e.%p
/etc/security/limits.conf
ここも必要。もしちゃんとした環境で*指定するとあれなので適宜ユーザー名は設定して下さい。
- #* soft core 0 - #root hard core 100000 - #* hard rss 10000 + * soft core 0 + root hard core 100000 + * hard rss 10000
そして再起動して(しないで済む方法もあるだろうけど…)再現させる。WordPressの再インストールでも起きるのを確認してたのでそこから見ることに。
取れたコアダンプから見たバックトレースがこちら。
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/sbin/apache2 -k start'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fad74c90ba7 in ?? () from /usr/lib/apache2/modules/libphp5.so (gdb) bt #0 0x00007fad74c90ba7 in ?? () from /usr/lib/apache2/modules/libphp5.so #1 0x00007fad74c90dab in ?? () from /usr/lib/apache2/modules/libphp5.so #2 0x00007fad74cc6cde in zend_hash_destroy () from /usr/lib/apache2/modules/libphp5.so #3 0x00007fad74ca8fb3 in shutdown_executor () from /usr/lib/apache2/modules/libphp5.so #4 0x00007fad74cb9222 in zend_deactivate () from /usr/lib/apache2/modules/libphp5.so #5 0x00007fad74c577f1 in php_request_shutdown () from /usr/lib/apache2/modules/libphp5.so #6 0x00007fad74d5f7af in ?? () from /usr/lib/apache2/modules/libphp5.so #7 0x00007fad78e39110 in ap_run_handler () #8 0x00007fad78e39659 in ap_invoke_handler () #9 0x00007fad78e4f5ec in ap_internal_redirect () #10 0x00007fad72b51d4c in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #11 0x00007fad78e39110 in ap_run_handler () #12 0x00007fad78e39659 in ap_invoke_handler () #13 0x00007fad78e5028a in ap_process_async_request () #14 0x00007fad78e50564 in ap_process_request () #15 0x00007fad78e4c67e in ?? () #16 0x00007fad78e42da0 in ap_run_process_connection () #17 0x00007fad75673b30 in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so #18 0x00007fad75673dc2 in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so #19 0x00007fad75674c44 in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so #20 0x00007fad78e1dd1e in ap_run_mpm () #21 0x00007fad78e17256 in main ()
mod_rewriteなの(?)
ここから本来ならphpdbgとかで追うべきなんだろうけど、それはそれで時間がかかりそうなのでゲームしながら色々想像してた。
先の通り時間経過で正常な状態に戻るし恒常的な問題ではない。WordPress更新時(つまりZenCacheの自動キャッシュクリアも動く)のタイミング前後でのみ何かが駄目でゴミ残っていてメモリリークっぽい動きになっちゃうのかも。じゃあphp組み込みのOPcache周りはもう一度見直さなきゃなと。
それでたどり着いたのが、opcacheの設定のこれ。
opcache.fast_shutdown=0
とりあえずこれで更新後にもページはちゃんと表示されるし、エラーログも消えた。
PHP5.5になったときapcから乗り換えて、色んなサイト見ると1が推奨されててなんとなく設定してたのは覚えてる。
ただその時点ではちゃんと動いてたし、その後のアプデで影響が出ちゃったんだと思う。
みんな大好きphp.netになんてあるかというと、
http://php.net/manual/ja/opcache.configuration.php#ini.opcache.fast-shutdown
有効にすると、それぞれに割り当てられたブロックを解放しない、高速シャットダウン・シーケンスが使用されます。 しかし、リクエスト変数のすべてのセットをひとまとめに割当てを解除することは、Zend Engine のメモリ・マネージャに依存します。
仕組みを理解していないので意味が全然わからない。オフにするとキャッシュメモリのブロックをちゃんと解放するので、その後の動きに影響がでなくなったということなんだろうか。
最終的にopcache周りの設定値は次のようになった。revalidate_freqのデフォルト値60だと事故ってたので0はやり過ぎとしても2くらいでいいと思う。
opcache.enable=1 opcache.enable_cli=0 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.revalidate_freq=0 opcache.fast_shutdown=0
表示スコアが著しく落ちた感じもないし、エージングもパスしたから大丈夫かなあ。何かあれば追記したい。
参考
Ubuntuでコアダンプが出力できないことがある | Pistolfly
[SOLVED] How to enable core dump
コメント
zen cache の後に出たcomet cache proでも同様の症状が出ており、調べていたらここにたどり着きました。
昨日「opcache.fast_shutdown=0」を設定しましたが、今朝の更新一発目でまた落ちてしまいました。
貴殿はこちらの設定で同じ症状は出なくなったのでしょうか。
sinさん>
コメントありがとうございます。
一応このときのままセキュリティパッチ等は当てたUbuntu14.04と、最新のWordPress、comet cache proの組み合わせで今日まで同じ現象には陥っていません。
この記事は2016-02-25と1年以上前に書かれたものですので今発生したとなると全く別要因かもしれませんね。
ご返信ありがとうございます。
comet cache proですが、結局外しました。
有料だったためなかなか外すまで躊躇していましたが、query monitorで遅かったので外してみたら、あら不思議、劇的に早くなってしまうではありませんか(笑)
時間のかかっていた投稿も、コメントも直ぐに投稿されるようになり、今までのストレスからかいほうされました。
なお、サーバー環境はお名前VPSの6コア、メモリ8Gのプランで、PHP7.1 Nginx mysql5.6を使用しています。
毎度返答が遅すぎて申し訳ありません。。
外したら速くなったのですね。他にどんなサービスを動かしているか次第ではありますが、comet cacheは所詮はファイルキャッシュなので遅いですね。それをやめたことでopcacheとか別のオンメモリなキャッシュが健全に動くようになって速くなるということはあると思います。
うちのVPSは安いやつなのでこれ以上なんともなりません><