トップに関する質問 PHP7update後、Segmentation faultが起きます。追記・PHPのGCが原因？

編集履歴

質問編集履歴

追記

2016/02/15 01:36

投稿

snic518

スコア39

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -500,4 +500,10 @@
+今これをアップデートすると、下記が入るようです。
+centos-release.x86_64 6-7.e16.centos12.3
 ご意見いただけますと幸いです。

環境のアップデートについて追記

2016/02/15 01:36

投稿

snic518

スコア39

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -4,7 +4,7 @@
 yum updateでphp7.0.2にアップデートしました。
-サーバー上のアプリケーションは、見た目上は特に不具合なく動いているようなのですが、ApacheのエラーログにはSegmentation faultが非常に多く記録されるようになってしまいました。
+サーバー上のアプリケーションは、見た目上は特に不具合なく動いているのですが、ApacheのエラーログにはSegmentation faultが非常に多く記録されるようになってしまいました。
@@ -72,18 +72,6 @@
-ちなみにyumのリポジトリは下記で更新しました。
-http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
-http://ftp.iij.ad.jp/pub/linux/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
 エラーログの出方ですが、HTTPアクセスの量に応じてログも増えているような傾向があるのですが、いっぺんに3プロセスほどまとまって落ちたり、完全にHTTPアクセスと同期したエラーではなさそうに思えます。
@@ -94,7 +82,7 @@
 [Wed Feb 03 11:45:07 2016] [notice] child pid 11662 exit signal Segmentation fault (11)
-[Wed Feb 03 11:45:08 2016] [notice] child pid 11664 exit signal Segmentation fault (11)
@@ -112,8 +100,6 @@
 どなたか、ご助言いただけますと幸いです。
@@ -198,20 +184,10 @@
 サイトのアプリケーション動作自体は普通に動いている、サイトアクセスの増加にともなってエラーログも増える、ということを踏まえると、このエラーはhttpdプロセスが終了する時に発生しているのでは、という気がしてきました。
-どなたか、ご意見伺えますと幸いです。
 ---
@@ -226,7 +202,7 @@
-> 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
+> MySQLのAborted clientsが似たようなペースで増えています。
 これも、PHPアップデート前は発生していませんでした。
@@ -276,14 +252,10 @@
 どなたか、ご意見いただけますと幸いです。
 ###【20160209追記】
@@ -298,56 +270,6 @@
-================================================================================================================================
-パッケージ アーキテクチャ バージョン リポジトリー 容量
-================================================================================================================================
-更新:
-php x86_64 7.0.3-1.el6.remi remi-php70 2.7 M
-php-devel x86_64 7.0.3-1.el6.remi remi-php70 1.3 M
-php-opcache x86_64 7.0.3-1.el6.remi remi-php70 135 k
-依存性関連での更新をします。:
-php-bcmath x86_64 7.0.3-1.el6.remi remi-php70 55 k
-php-cli x86_64 7.0.3-1.el6.remi remi-php70 3.9 M
-php-common x86_64 7.0.3-1.el6.remi remi-php70 973 k
-php-gd x86_64 7.0.3-1.el6.remi remi-php70 61 k
-php-gmp x86_64 7.0.3-1.el6.remi remi-php70 52 k
-php-json x86_64 7.0.3-1.el6.remi remi-php70 49 k
-php-mbstring x86_64 7.0.3-1.el6.remi remi-php70 969 k
-php-mcrypt x86_64 7.0.3-1.el6.remi remi-php70 46 k
-php-mysqlnd x86_64 7.0.3-1.el6.remi remi-php70 208 k
-php-pdo x86_64 7.0.3-1.el6.remi remi-php70 102 k
-php-recode x86_64 7.0.3-1.el6.remi remi-php70 33 k
-php-tidy x86_64 7.0.3-1.el6.remi remi-php70 49 k
-php-xml x86_64 7.0.3-1.el6.remi remi-php70 168 k
-トランザクションの要約
-================================================================================================================================
-アップグレード 16 パッケージ
 ```
@@ -380,8 +302,6 @@
 ###【20160209追記2】
@@ -390,18 +310,16 @@
-[https://bugs.php.net/bug.php?id=71492](https://bugs.php.net/bug.php?id=71492)
+[こちら](https://bugs.php.net/bug.php?id=71492)
-「見かけは動いているけど、Segmentation faultエラーが大量に出る」という点で一致していますね。
+「見かけは動いているけど、Segmentation faultエラーが大量に出る」という点で一致しています。
 gdbの結果の内容は違うみたいですが、原因は同じなのでしょうか。
 また、httpdのプロセスidを観察してみたところ、やはり終了時にSegmentation faultが発生しているので間違い無さそうでした。
@@ -416,10 +334,6 @@
 他、使用しているPHPライブラリに問題がないか確かめましたが、これも無関係のようでした。
-※AWS for PHP 2を使っていました。[最新版](https://github.com/aws/aws-sdk-php/releases/tag/2.8.27)に差し替えましたが、変化なしでした。
 引き続き調査しようと思います。
@@ -488,8 +402,6 @@
 (gdb) list
 539 nIndex = h | ht->nTableMask;
@@ -516,8 +428,6 @@
 zend_hash_index_find_bucketの問題なのかと思い検索してみましたが、過去この部分にバグフィックスがあったらしい（もう直ってる）ことくらいしかわかりませんでした。
@@ -526,8 +436,6 @@
 ご意見いただけますと幸いです。
-よろしくお願いいたします。
 ###【20160212追記2】
@@ -542,4 +450,54 @@
-どこかに引っかかっているのだと思いますが、ここからもし原因がわかれば、ご助言いただけますと幸いです。
+ここからもし原因がわかれば、ご助言いただけますと幸いです。
+###【20160215追記】
+環境の問題かも、と思い、yum updateで諸々のモジュールを最新にしたり、カーネルアップデートをしたりしてみました。
+```ここに言語を入力
+カーネルバージョン
+cat /proc/version
+Linux version 2.6.32-358.23.2.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (g cc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Wed Oct 16 18:37:12 U TC 2013
+※20160213 kernel update
+Linux version 2.6.32-573.18.1.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Tue Feb 9 22:46:17 UTC 2016
+```
+が、これでも改善はされませんでした。
+あと残るはCentOSが6.4なのを最新にしてみるか、くらいなのですが、関係あるのかどうかは今のところわかりません…。
+6.4だとPHP7で問題あるのかどうかの情報はないようです。
+```
+# cat /etc/redhat-release
+CentOS release 6.4 (Final)
+```
+ご意見いただけますと幸いです。

更にgdbの結果追記

2016/02/15 01:35

投稿

snic518

スコア39

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -14,8 +14,6 @@
 coreファイルを取得し、gdbを見てみたのですが、下記のような結果になりました。
@@ -86,460 +84,462 @@
+エラーログの出方ですが、HTTPアクセスの量に応じてログも増えているような傾向があるのですが、いっぺんに3プロセスほどまとまって落ちたり、完全にHTTPアクセスと同期したエラーではなさそうに思えます。
+[Wed Feb 03 11:45:07 2016] [notice] child pid 11648 exit signal Segmentation fault (11)
+[Wed Feb 03 11:45:07 2016] [notice] child pid 11651 exit signal Segmentation fault (11)
+[Wed Feb 03 11:45:07 2016] [notice] child pid 11662 exit signal Segmentation fault (11)
+[Wed Feb 03 11:45:08 2016] [notice] child pid 11664 exit signal Segmentation fault (11)
+プロセスはhttpdで間違い無さそうなのですが、やはり普通にサイトは動作しているようで、
+このエラーが発生した時にユーザーに障害が発生しているということでもなさそうです。
+キャッシュ関連の動作（Opchaceなど？）が関連しているのかもと思いましたが、正体がわかりません…。
+他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
+これも、PHPアップデート前は発生していませんでした。
+どなたか、ご助言いただけますと幸いです。
 よろしくお願いいたします。
 ---
-追記です。
-エラーログの出方ですが、HTTPアクセスの量に応じてログも増えているような傾向があるのですが、いっぺんに3プロセスほどまとまって落ちたり、完全にHTTPアクセスと同期したエラーではなさそうに思えます。
-[Wed Feb 03 11:45:07 2016] [notice] child pid 11648 exit signal Segmentation fault (11)
-[Wed Feb 03 11:45:07 2016] [notice] child pid 11651 exit signal Segmentation fault (11)
-[Wed Feb 03 11:45:07 2016] [notice] child pid 11662 exit signal Segmentation fault (11)
-[Wed Feb 03 11:45:08 2016] [notice] child pid 11664 exit signal Segmentation fault (11)
-プロセスはhttpdで間違い無さそうなのですが、やはり普通にサイトは動作しているようで、
-このエラーが発生した時にユーザーに障害が発生しているということでもなさそうです。
-キャッシュ関連の動作（Opchaceなど？）が関連しているのかもと思いましたが、正体がわかりません…。
-他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
+###【201602031909追記】
+エラーログとプロセスを確認したところ、少し事象が見えてきたきがしたので追記です。
+ある時間（2016-02-03-1825）のtopのスクリーンショットを取り、その後のエラーログを確認したところ、殆どのhttpdプロセスはこのエラーを吐いているということがわかりました。
+![top](6c76a59d80ea876f3f5b47ac3dfb1773.gif)
+これに映っているhttpdのPIDを全て調べたところ、2/3くらいはエラーログが存在しました。
+```apache
+# 201602031902頃のエラーログを検索
+[Wed Feb 03 18:26:52 2016] [notice] child pid 21489 exit signal Segmentation fault (11)
+[Wed Feb 03 18:27:41 2016] [notice] child pid 21493 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:25 2016] [notice] child pid 21440 exit signal Segmentation fault (11)
+[Wed Feb 03 18:27:43 2016] [notice] child pid 21366 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:19 2016] [notice] child pid 21522 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:22 2016] [notice] child pid 21520 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:25 2016] [notice] child pid 21494 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:27 2016] [notice] child pid 21257 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:47 2016] [notice] child pid 21519 exit signal Segmentation fault (11)
+[Wed Feb 03 18:30:15 2016] [notice] child pid 21455 exit signal Segmentation fault (11)
+[Wed Feb 03 18:31:15 2016] [notice] child pid 21376 exit signal Segmentation fault (11)
+↓無かったPID
+21521
+21444
+21403
+21453
+21525
+```
+また、topコマンドで今生きているPIDをエラーログから探しても見つかりませんでした。（これは当たり前ですかね…）
+サイトのアプリケーション動作自体は普通に動いている、サイトアクセスの増加にともなってエラーログも増える、ということを踏まえると、このエラーはhttpdプロセスが終了する時に発生しているのでは、という気がしてきました。
+どなたか、ご意見伺えますと幸いです。
+---
+###【20160205追記】
+更に色々と調査しました。
+最初の書き込み時に下記の現象について書きました。
+> 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
 これも、PHPアップデート前は発生していませんでした。
-どなたか、ご助言いただけますと幸いです。
+これの原因が判明しました。
+[オブログ — Statement の解放漏れには気をつけよう](http://objectclub.tumblr.com/post/97692551321/statement-%E3%81%AE%E8%A7%A3%E6%94%BE%E6%BC%8F%E3%82%8C%E3%81%AB%E3%81%AF%E6%B0%97%E3%82%92%E3%81%A4%E3%81%91%E3%82%88%E3%81%86)
+スクリプトを調べたところ、いくつかMySQLのStatementをcloseしていない箇所が見つかり、それをcloseするように直したところ、Aborted cliantの増加は止まりました。
+> 正常に動作する場合は、新しい PreparedStatement が上書きされた後に GC が上手く動作して古い PreparedStatement が解放されるのですが、GC が上手く動作しない場合は古い PreparedStatement が解放されず、データベースとの接続を保った状態のまま残ってしまいます。
+この問題が発生する前ではStatementをcloseしなくてもAborted cliantが増えてなかったのが、問題発生後に顕在化したということは、上記引用にある通り、**GCが上手く動作しない状態**にあるのではと推察します。
+0. PHPをupdate後、GCに問題が発生し、Segmentation faultが大量発生
+1. GCが上手く動かないため、これまではよしなにされていたPHPスクリプトのStatement解放漏れが顕在化
+というのが現状なのかと思います。
+2に関してはもともとスクリプト側の問題ということで、それはそれで修正出来て良かったのですが、1に関しては未だに原因不明です。
+思いあたる節としては、諸事情でPHPのインストールユーザーとApacheの実行ユーザーに違いがあるため、sesston_save_pathの所有者がそのままだとセッションの書き込みが出来ないために、そのディレクトリの所有者をchownしている点です。
+他に所有者変更が必要なディレクトリがあるのかもしれませんが、調べても見つかりませんでした。
+どなたか、ご意見いただけますと幸いです。
+###【20160209追記】
+PHP7.0.3がリリースされていたので、アップデートしてみては、との助言をいただきました。
+```ssh
+yum --enablerepo=remi-php70 update php php-devel php-opcache
+================================================================================================================================
+パッケージ アーキテクチャ バージョン リポジトリー 容量
+================================================================================================================================
+更新:
+php x86_64 7.0.3-1.el6.remi remi-php70 2.7 M
+php-devel x86_64 7.0.3-1.el6.remi remi-php70 1.3 M
+php-opcache x86_64 7.0.3-1.el6.remi remi-php70 135 k
+依存性関連での更新をします。:
+php-bcmath x86_64 7.0.3-1.el6.remi remi-php70 55 k
+php-cli x86_64 7.0.3-1.el6.remi remi-php70 3.9 M
+php-common x86_64 7.0.3-1.el6.remi remi-php70 973 k
+php-gd x86_64 7.0.3-1.el6.remi remi-php70 61 k
+php-gmp x86_64 7.0.3-1.el6.remi remi-php70 52 k
+php-json x86_64 7.0.3-1.el6.remi remi-php70 49 k
+php-mbstring x86_64 7.0.3-1.el6.remi remi-php70 969 k
+php-mcrypt x86_64 7.0.3-1.el6.remi remi-php70 46 k
+php-mysqlnd x86_64 7.0.3-1.el6.remi remi-php70 208 k
+php-pdo x86_64 7.0.3-1.el6.remi remi-php70 102 k
+php-recode x86_64 7.0.3-1.el6.remi remi-php70 33 k
+php-tidy x86_64 7.0.3-1.el6.remi remi-php70 49 k
+php-xml x86_64 7.0.3-1.el6.remi remi-php70 168 k
+トランザクションの要約
+================================================================================================================================
+アップグレード 16 パッケージ
+```
+```
+PHP 7.0.3 (cli) (built: Feb 3 2016 11:40:05) ( NTS )
+Copyright (c) 1997-2016 The PHP Group
+Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
+with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
+```
+アップデートは問題なく終了したのですが、サーバー再起動後、やはり継続してSegment faultは発生し続けています。
+PHP本体の問題ではなかったのですかね…。
+Zend OPcache がv7.0.6-devなのが少し気になりますが、もしかしてこれのverを下げたほうがいいのでしょうか。
+ご意見いただけますと幸いです。
+###【20160209追記2】
+PHPのバグフォーラムを調べたところ、PHP7.0.2で似たような状況の報告を見つけました。
+[https://bugs.php.net/bug.php?id=71492](https://bugs.php.net/bug.php?id=71492)
+「見かけは動いているけど、Segmentation faultエラーが大量に出る」という点で一致していますね。
+gdbの結果の内容は違うみたいですが、原因は同じなのでしょうか。
+また、httpdのプロセスidを観察してみたところ、やはり終了時にSegmentation faultが発生しているので間違い無さそうでした。
+topコマンドで今ある適当なpidを選び、
+/proc ディレクトリにあるプロセスディレクトリを監視、
+それが消去された時点でApacheエラーログを見たところ、同じpidのSegmentation faultログが出力されていることを確認しました。
+他、使用しているPHPライブラリに問題がないか確かめましたが、これも無関係のようでした。
+※AWS for PHP 2を使っていました。[最新版](https://github.com/aws/aws-sdk-php/releases/tag/2.8.27)に差し替えましたが、変化なしでした。
+引き続き調査しようと思います。
+###【20160212追記】
+コメントにて、php-debuginfoを入れて再度gdbをとのご意見をいただきましたので、結果を記載します。
+```ssh
+yum --enablerepo=remi-php70 install php-debuginfo
+```
+php70-php-debuginfo-7.0.3-1.el6.remi.x86_64がインストールされました。
+coreファイルをgdbで実行し、where,listをしてみた結果が以下です。
+```
+(gdb) where
+#0 0x00007f177b70a2ff in zend_hash_index_find_bucket (ht=0x0,
+h=13841567621774083997) at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:544
+#1 zend_hash_index_exists (ht=0x0, h=13841567621774083997)
+at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:2021
+#2 0x00007f177b60745e in ?? ()
+at /usr/src/debug/php-7.0.3/ext/session/session.c:1676
+from /etc/httpd/modules/libphp7.so
+#3 0x00007f17790174a0 in ?? ()
+#4 0x00007f177bacb368 in labels.92387 () from /etc/httpd/modules/libphp7.so
+#5 0x00007f17882f0410 in ?? ()
+#6 0x00007f1779017030 in ?? ()
+#7 0x00007f177bacb366 in labels.92387 () from /etc/httpd/modules/libphp7.so
+#8 0x00007f177b60793d in zend_string_release ()
+at /usr/src/debug/php-7.0.3/Zend/zend_string.h:271
+#9 php_session_start () at /usr/src/debug/php-7.0.3/ext/session/session.c:1644
+#10 0x0000000000000000 in ?? ()
+(gdb) list
+539 nIndex = h | ht->nTableMask;
+540 idx = HT_HASH_EX(arData, nIndex);
+541 while (idx != HT_INVALID_IDX) {
+542 ZEND_ASSERT(idx < HT_IDX_TO_HASH(ht->nTableSize));
+543 p = HT_HASH_TO_BUCKET_EX(arData, idx);
+544 if (p->h == h && !p->key) {
+545 return p;
+546 }
+547 idx = Z_NEXT(p->val);
+548 }
+```
+zend_hash_index_find_bucketの問題なのかと思い検索してみましたが、過去この部分にバグフィックスがあったらしい（もう直ってる）ことくらいしかわかりませんでした。
+ご意見いただけますと幸いです。
 よろしくお願いいたします。
----
-###【201602031909追記】
-エラーログとプロセスを確認したところ、少し事象が見えてきたきがしたので追記です。
-ある時間（2016-02-03-1825）のtopのスクリーンショットを取り、その後のエラーログを確認したところ、殆どのhttpdプロセスはこのエラーを吐いているということがわかりました。
-![top](6c76a59d80ea876f3f5b47ac3dfb1773.gif)
-これに映っているhttpdのPIDを全て調べたところ、2/3くらいはエラーログが存在しました。
-```apache
-# 201602031902頃のエラーログを検索
-[Wed Feb 03 18:26:52 2016] [notice] child pid 21489 exit signal Segmentation fault (11)
-[Wed Feb 03 18:27:41 2016] [notice] child pid 21493 exit signal Segmentation fault (11)
-[Wed Feb 03 18:28:25 2016] [notice] child pid 21440 exit signal Segmentation fault (11)
-[Wed Feb 03 18:27:43 2016] [notice] child pid 21366 exit signal Segmentation fault (11)
-[Wed Feb 03 18:28:19 2016] [notice] child pid 21522 exit signal Segmentation fault (11)
-[Wed Feb 03 18:28:22 2016] [notice] child pid 21520 exit signal Segmentation fault (11)
-[Wed Feb 03 18:28:25 2016] [notice] child pid 21494 exit signal Segmentation fault (11)
-[Wed Feb 03 18:28:27 2016] [notice] child pid 21257 exit signal Segmentation fault (11)
-[Wed Feb 03 18:28:47 2016] [notice] child pid 21519 exit signal Segmentation fault (11)
-[Wed Feb 03 18:30:15 2016] [notice] child pid 21455 exit signal Segmentation fault (11)
-[Wed Feb 03 18:31:15 2016] [notice] child pid 21376 exit signal Segmentation fault (11)
-↓無かったPID
-21521
-21444
-21403
-21453
-21525
-```
-また、topコマンドで今生きているPIDをエラーログから探しても見つかりませんでした。（これは当たり前ですかね…）
-サイトのアプリケーション動作自体は普通に動いている、サイトアクセスの増加にともなってエラーログも増える、ということを踏まえると、このエラーはhttpdプロセスが終了する時に発生しているのでは、という気がしてきました。
-どなたか、ご意見伺えますと幸いです。
----
-###【20160205追記】
-更に色々と調査しました。
-最初の書き込み時に下記の現象について書きました。
-> 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
-これも、PHPアップデート前は発生していませんでした。
-これの原因が判明しました。
-[オブログ — Statement の解放漏れには気をつけよう](http://objectclub.tumblr.com/post/97692551321/statement-%E3%81%AE%E8%A7%A3%E6%94%BE%E6%BC%8F%E3%82%8C%E3%81%AB%E3%81%AF%E6%B0%97%E3%82%92%E3%81%A4%E3%81%91%E3%82%88%E3%81%86)
-スクリプトを調べたところ、いくつかMySQLのStatementをcloseしていない箇所が見つかり、それをcloseするように直したところ、Aborted cliantの増加は止まりました。
-> 正常に動作する場合は、新しい PreparedStatement が上書きされた後に GC が上手く動作して古い PreparedStatement が解放されるのですが、GC が上手く動作しない場合は古い PreparedStatement が解放されず、データベースとの接続を保った状態のまま残ってしまいます。
-この問題が発生する前ではStatementをcloseしなくてもAborted cliantが増えてなかったのが、問題発生後に顕在化したということは、上記引用にある通り、**GCが上手く動作しない状態**にあるのではと推察します。
-0. PHPをupdate後、GCに問題が発生し、Segmentation faultが大量発生
-1. GCが上手く動かないため、これまではよしなにされていたPHPスクリプトのStatement解放漏れが顕在化
-というのが現状なのかと思います。
-2に関してはもともとスクリプト側の問題ということで、それはそれで修正出来て良かったのですが、1に関しては未だに原因不明です。
-思いあたる節としては、諸事情でPHPのインストールユーザーとApacheの実行ユーザーに違いがあるため、sesston_save_pathの所有者がそのままだとセッションの書き込みが出来ないために、そのディレクトリの所有者をchownしている点です。
-他に所有者変更が必要なディレクトリがあるのかもしれませんが、調べても見つかりませんでした。
-どなたか、ご意見いただけますと幸いです。
-###【20160209追記】
-PHP7.0.3がリリースされていたので、アップデートしてみては、との助言をいただきました。
-```ssh
-yum --enablerepo=remi-php70 update php php-devel php-opcache
-================================================================================================================================
-パッケージ アーキテクチャ バージョン リポジトリー 容量
-================================================================================================================================
-更新:
-php x86_64 7.0.3-1.el6.remi remi-php70 2.7 M
-php-devel x86_64 7.0.3-1.el6.remi remi-php70 1.3 M
-php-opcache x86_64 7.0.3-1.el6.remi remi-php70 135 k
-依存性関連での更新をします。:
-php-bcmath x86_64 7.0.3-1.el6.remi remi-php70 55 k
-php-cli x86_64 7.0.3-1.el6.remi remi-php70 3.9 M
-php-common x86_64 7.0.3-1.el6.remi remi-php70 973 k
-php-gd x86_64 7.0.3-1.el6.remi remi-php70 61 k
-php-gmp x86_64 7.0.3-1.el6.remi remi-php70 52 k
-php-json x86_64 7.0.3-1.el6.remi remi-php70 49 k
-php-mbstring x86_64 7.0.3-1.el6.remi remi-php70 969 k
-php-mcrypt x86_64 7.0.3-1.el6.remi remi-php70 46 k
-php-mysqlnd x86_64 7.0.3-1.el6.remi remi-php70 208 k
-php-pdo x86_64 7.0.3-1.el6.remi remi-php70 102 k
-php-recode x86_64 7.0.3-1.el6.remi remi-php70 33 k
-php-tidy x86_64 7.0.3-1.el6.remi remi-php70 49 k
-php-xml x86_64 7.0.3-1.el6.remi remi-php70 168 k
-トランザクションの要約
-================================================================================================================================
-アップグレード 16 パッケージ
-```
-```
-PHP 7.0.3 (cli) (built: Feb 3 2016 11:40:05) ( NTS )
-Copyright (c) 1997-2016 The PHP Group
-Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
-with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
-```
-アップデートは問題なく終了したのですが、サーバー再起動後、やはり継続してSegment faultは発生し続けています。
-PHP本体の問題ではなかったのですかね…。
-Zend OPcache がv7.0.6-devなのが少し気になりますが、もしかしてこれのverを下げたほうがいいのでしょうか。
-ご意見いただけますと幸いです。
-###【20160209追記2】
-PHPのバグフォーラムを調べたところ、PHP7.0.2で似たような状況の報告を見つけました。
-[https://bugs.php.net/bug.php?id=71492](https://bugs.php.net/bug.php?id=71492)
-「見かけは動いているけど、Segmentation faultエラーが大量に出る」という点で一致していますね。
-gdbの結果の内容は違うみたいですが、原因は同じなのでしょうか。
-また、httpdのプロセスidを観察してみたところ、やはり終了時にSegmentation faultが発生しているので間違い無さそうでした。
-topコマンドで今ある適当なpidを選び、
-/proc ディレクトリにあるプロセスディレクトリを監視、
-それが消去された時点でApacheエラーログを見たところ、同じpidのSegmentation faultログが出力されていることを確認しました。
-他、使用しているPHPライブラリに問題がないか確かめましたが、これも無関係のようでした。
-※AWS for PHP 2を使っていました。[最新版](https://github.com/aws/aws-sdk-php/releases/tag/2.8.27)に差し替えましたが、変化なしでした。
-引き続き調査しようと思います。
-###【20160212追記】
-コメントにて、php-debuginfoを入れて再度gdbをとのご意見をいただきましたので、結果を記載します。
-```ssh
-yum --enablerepo=remi-php70 install php-debuginfo
-```
-php70-php-debuginfo-7.0.3-1.el6.remi.x86_64がインストールされました。
-coreファイルをgdbで実行し、where,listをしてみた結果が以下です。
-```
-(gdb) where
-#0 0x00007f177b70a2ff in zend_hash_index_find_bucket (ht=0x0,
-h=13841567621774083997) at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:544
-#1 zend_hash_index_exists (ht=0x0, h=13841567621774083997)
-at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:2021
-#2 0x00007f177b60745e in ?? ()
-at /usr/src/debug/php-7.0.3/ext/session/session.c:1676
-from /etc/httpd/modules/libphp7.so
-#3 0x00007f17790174a0 in ?? ()
-#4 0x00007f177bacb368 in labels.92387 () from /etc/httpd/modules/libphp7.so
-#5 0x00007f17882f0410 in ?? ()
-#6 0x00007f1779017030 in ?? ()
-#7 0x00007f177bacb366 in labels.92387 () from /etc/httpd/modules/libphp7.so
-#8 0x00007f177b60793d in zend_string_release ()
-at /usr/src/debug/php-7.0.3/Zend/zend_string.h:271
-#9 php_session_start () at /usr/src/debug/php-7.0.3/ext/session/session.c:1644
-#10 0x0000000000000000 in ?? ()
-(gdb) list
-539 nIndex = h | ht->nTableMask;
-540 idx = HT_HASH_EX(arData, nIndex);
-541 while (idx != HT_INVALID_IDX) {
-542 ZEND_ASSERT(idx < HT_IDX_TO_HASH(ht->nTableSize));
-543 p = HT_HASH_TO_BUCKET_EX(arData, idx);
-544 if (p->h == h && !p->key) {
-545 return p;
-546 }
-547 idx = Z_NEXT(p->val);
-548 }
-```
-zend_hash_index_find_bucketの問題なのかと思い検索してみましたが、過去この部分にバグフィックスがあったらしい（もう直ってる）ことくらいしかわかりませんでした。
-ご意見いただけますと幸いです。
-よろしくお願いいたします。
+###【20160212追記2】
+文字数の制限に達してしまったので、gdb listを1個1個のframeに対して実行した結果を作成しました。
+[gdb list一覧](https://www.evernote.com/shard/s45/sh/dc7bfa9f-fbf5-439f-b4b5-4135fed74ca5/b99debb01d4a3b8aeb43574ba404d5dd)
+どこかに引っかかっているのだと思いますが、ここからもし原因がわかれば、ご助言いただけますと幸いです。

php-debuginfo追加後のgdb捜査について追記

2016/02/12 12:18

投稿

snic518

スコア39

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -112,14 +112,6 @@
 [Wed Feb 03 11:45:08 2016] [notice] child pid 11664 exit signal Segmentation fault (11)
-[Wed Feb 03 11:45:10 2016] [notice] child pid 11658 exit signal Segmentation fault (11)
-[Wed Feb 03 11:46:40 2016] [notice] child pid 11628 exit signal Segmentation fault (11)
-[Wed Feb 03 11:46:40 2016] [notice] child pid 11686 exit signal Segmentation fault (11)
-[Wed Feb 03 11:46:40 2016] [notice] child pid 11704 exit signal Segmentation fault (11)
 プロセスはhttpdで間違い無さそうなのですが、やはり普通にサイトは動作しているようで、
@@ -447,3 +439,107 @@
 引き続き調査しようと思います。
+###【20160212追記】
+コメントにて、php-debuginfoを入れて再度gdbをとのご意見をいただきましたので、結果を記載します。
+```ssh
+yum --enablerepo=remi-php70 install php-debuginfo
+```
+php70-php-debuginfo-7.0.3-1.el6.remi.x86_64がインストールされました。
+coreファイルをgdbで実行し、where,listをしてみた結果が以下です。
+```
+(gdb) where
+#0 0x00007f177b70a2ff in zend_hash_index_find_bucket (ht=0x0,
+h=13841567621774083997) at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:544
+#1 zend_hash_index_exists (ht=0x0, h=13841567621774083997)
+at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:2021
+#2 0x00007f177b60745e in ?? ()
+at /usr/src/debug/php-7.0.3/ext/session/session.c:1676
+from /etc/httpd/modules/libphp7.so
+#3 0x00007f17790174a0 in ?? ()
+#4 0x00007f177bacb368 in labels.92387 () from /etc/httpd/modules/libphp7.so
+#5 0x00007f17882f0410 in ?? ()
+#6 0x00007f1779017030 in ?? ()
+#7 0x00007f177bacb366 in labels.92387 () from /etc/httpd/modules/libphp7.so
+#8 0x00007f177b60793d in zend_string_release ()
+at /usr/src/debug/php-7.0.3/Zend/zend_string.h:271
+#9 php_session_start () at /usr/src/debug/php-7.0.3/ext/session/session.c:1644
+#10 0x0000000000000000 in ?? ()
+(gdb) list
+539 nIndex = h | ht->nTableMask;
+540 idx = HT_HASH_EX(arData, nIndex);
+541 while (idx != HT_INVALID_IDX) {
+542 ZEND_ASSERT(idx < HT_IDX_TO_HASH(ht->nTableSize));
+543 p = HT_HASH_TO_BUCKET_EX(arData, idx);
+544 if (p->h == h && !p->key) {
+545 return p;
+546 }
+547 idx = Z_NEXT(p->val);
+548 }
+```
+zend_hash_index_find_bucketの問題なのかと思い検索してみましたが、過去この部分にバグフィックスがあったらしい（もう直ってる）ことくらいしかわかりませんでした。
+ご意見いただけますと幸いです。
+よろしくお願いいたします。

進捗です。

2016/02/12 00:52

投稿

snic518

スコア39

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -401,3 +401,49 @@
 ご意見いただけますと幸いです。
+###【20160209追記2】
+PHPのバグフォーラムを調べたところ、PHP7.0.2で似たような状況の報告を見つけました。
+[https://bugs.php.net/bug.php?id=71492](https://bugs.php.net/bug.php?id=71492)
+「見かけは動いているけど、Segmentation faultエラーが大量に出る」という点で一致していますね。
+gdbの結果の内容は違うみたいですが、原因は同じなのでしょうか。
+また、httpdのプロセスidを観察してみたところ、やはり終了時にSegmentation faultが発生しているので間違い無さそうでした。
+topコマンドで今ある適当なpidを選び、
+/proc ディレクトリにあるプロセスディレクトリを監視、
+それが消去された時点でApacheエラーログを見たところ、同じpidのSegmentation faultログが出力されていることを確認しました。
+他、使用しているPHPライブラリに問題がないか確かめましたが、これも無関係のようでした。
+※AWS for PHP 2を使っていました。[最新版](https://github.com/aws/aws-sdk-php/releases/tag/2.8.27)に差し替えましたが、変化なしでした。
+引き続き調査しようと思います。

進捗について書きました。

2016/02/09 12:51

投稿

snic518

スコア39

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -303,3 +303,101 @@
 どなたか、ご意見いただけますと幸いです。
+###【20160209追記】
+PHP7.0.3がリリースされていたので、アップデートしてみては、との助言をいただきました。
+```ssh
+yum --enablerepo=remi-php70 update php php-devel php-opcache
+================================================================================================================================
+パッケージ アーキテクチャ バージョン リポジトリー 容量
+================================================================================================================================
+更新:
+php x86_64 7.0.3-1.el6.remi remi-php70 2.7 M
+php-devel x86_64 7.0.3-1.el6.remi remi-php70 1.3 M
+php-opcache x86_64 7.0.3-1.el6.remi remi-php70 135 k
+依存性関連での更新をします。:
+php-bcmath x86_64 7.0.3-1.el6.remi remi-php70 55 k
+php-cli x86_64 7.0.3-1.el6.remi remi-php70 3.9 M
+php-common x86_64 7.0.3-1.el6.remi remi-php70 973 k
+php-gd x86_64 7.0.3-1.el6.remi remi-php70 61 k
+php-gmp x86_64 7.0.3-1.el6.remi remi-php70 52 k
+php-json x86_64 7.0.3-1.el6.remi remi-php70 49 k
+php-mbstring x86_64 7.0.3-1.el6.remi remi-php70 969 k
+php-mcrypt x86_64 7.0.3-1.el6.remi remi-php70 46 k
+php-mysqlnd x86_64 7.0.3-1.el6.remi remi-php70 208 k
+php-pdo x86_64 7.0.3-1.el6.remi remi-php70 102 k
+php-recode x86_64 7.0.3-1.el6.remi remi-php70 33 k
+php-tidy x86_64 7.0.3-1.el6.remi remi-php70 49 k
+php-xml x86_64 7.0.3-1.el6.remi remi-php70 168 k
+トランザクションの要約
+================================================================================================================================
+アップグレード 16 パッケージ
+```
+```
+PHP 7.0.3 (cli) (built: Feb 3 2016 11:40:05) ( NTS )
+Copyright (c) 1997-2016 The PHP Group
+Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
+with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
+```
+アップデートは問題なく終了したのですが、サーバー再起動後、やはり継続してSegment faultは発生し続けています。
+PHP本体の問題ではなかったのですかね…。
+Zend OPcache がv7.0.6-devなのが少し気になりますが、もしかしてこれのverを下げたほうがいいのでしょうか。
+ご意見いただけますと幸いです。

誤字修正

2016/02/09 01:26

投稿

snic518

スコア39

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -292,7 +292,7 @@
-思いたる節としては、諸事情でPHPのインストールユーザーとApacheの実行ユーザーに違いがあるため、sessiton_save_pathの所有者がそのままだとセッションの書き込みが出来ないために、そのディレクトリの所有者をchownしている点です。
+思いあたる節としては、諸事情でPHPのインストールユーザーとApacheの実行ユーザーに違いがあるため、sesston_save_pathの所有者がそのままだとセッションの書き込みが出来ないために、そのディレクトリの所有者をchownしている点です。

調査進捗について追記。

2016/02/05 03:35

投稿

snic518

スコア39

test CHANGED Viewed

	@@ -1 +1 @@
1	- PHP7update後、Segmentation faultが起きます。
1	+ PHP7update後、Segmentation faultが起きます。追記・PHPのGCが原因？

test CHANGED Viewed

@@ -150,7 +150,7 @@
-【201602031909追記】
+###【201602031909追記】
@@ -231,3 +231,75 @@
 どなたか、ご意見伺えますと幸いです。
+---
+###【20160205追記】
+更に色々と調査しました。
+最初の書き込み時に下記の現象について書きました。
+> 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
+これも、PHPアップデート前は発生していませんでした。
+これの原因が判明しました。
+[オブログ — Statement の解放漏れには気をつけよう](http://objectclub.tumblr.com/post/97692551321/statement-%E3%81%AE%E8%A7%A3%E6%94%BE%E6%BC%8F%E3%82%8C%E3%81%AB%E3%81%AF%E6%B0%97%E3%82%92%E3%81%A4%E3%81%91%E3%82%88%E3%81%86)
+スクリプトを調べたところ、いくつかMySQLのStatementをcloseしていない箇所が見つかり、それをcloseするように直したところ、Aborted cliantの増加は止まりました。
+> 正常に動作する場合は、新しい PreparedStatement が上書きされた後に GC が上手く動作して古い PreparedStatement が解放されるのですが、GC が上手く動作しない場合は古い PreparedStatement が解放されず、データベースとの接続を保った状態のまま残ってしまいます。
+この問題が発生する前ではStatementをcloseしなくてもAborted cliantが増えてなかったのが、問題発生後に顕在化したということは、上記引用にある通り、**GCが上手く動作しない状態**にあるのではと推察します。
+0. PHPをupdate後、GCに問題が発生し、Segmentation faultが大量発生
+1. GCが上手く動かないため、これまではよしなにされていたPHPスクリプトのStatement解放漏れが顕在化
+というのが現状なのかと思います。
+2に関してはもともとスクリプト側の問題ということで、それはそれで修正出来て良かったのですが、1に関しては未だに原因不明です。
+思いたる節としては、諸事情でPHPのインストールユーザーとApacheの実行ユーザーに違いがあるため、sessiton_save_pathの所有者がそのままだとセッションの書き込みが出来ないために、そのディレクトリの所有者をchownしている点です。
+他に所有者変更が必要なディレクトリがあるのかもしれませんが、調べても見つかりませんでした。
+どなたか、ご意見いただけますと幸いです。

ログの詳細な調査を追加してみました。

2016/02/05 03:26

投稿

snic518

スコア39

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -143,3 +143,91 @@
 よろしくお願いいたします。
+---
+【201602031909追記】
+エラーログとプロセスを確認したところ、少し事象が見えてきたきがしたので追記です。
+ある時間（2016-02-03-1825）のtopのスクリーンショットを取り、その後のエラーログを確認したところ、殆どのhttpdプロセスはこのエラーを吐いているということがわかりました。
+![top](6c76a59d80ea876f3f5b47ac3dfb1773.gif)
+これに映っているhttpdのPIDを全て調べたところ、2/3くらいはエラーログが存在しました。
+```apache
+# 201602031902頃のエラーログを検索
+[Wed Feb 03 18:26:52 2016] [notice] child pid 21489 exit signal Segmentation fault (11)
+[Wed Feb 03 18:27:41 2016] [notice] child pid 21493 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:25 2016] [notice] child pid 21440 exit signal Segmentation fault (11)
+[Wed Feb 03 18:27:43 2016] [notice] child pid 21366 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:19 2016] [notice] child pid 21522 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:22 2016] [notice] child pid 21520 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:25 2016] [notice] child pid 21494 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:27 2016] [notice] child pid 21257 exit signal Segmentation fault (11)
+[Wed Feb 03 18:28:47 2016] [notice] child pid 21519 exit signal Segmentation fault (11)
+[Wed Feb 03 18:30:15 2016] [notice] child pid 21455 exit signal Segmentation fault (11)
+[Wed Feb 03 18:31:15 2016] [notice] child pid 21376 exit signal Segmentation fault (11)
+↓無かったPID
+21521
+21444
+21403
+21453
+21525
+```
+また、topコマンドで今生きているPIDをエラーログから探しても見つかりませんでした。（これは当たり前ですかね…）
+サイトのアプリケーション動作自体は普通に動いている、サイトアクセスの増加にともなってエラーログも増える、ということを踏まえると、このエラーはhttpdプロセスが終了する時に発生しているのでは、という気がしてきました。
+どなたか、ご意見伺えますと幸いです。

説明追記

2016/02/03 10:17

投稿

snic518

スコア39

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -122,6 +122,10 @@
+プロセスはhttpdで間違い無さそうなのですが、やはり普通にサイトは動作しているようで、
+このエラーが発生した時にユーザーに障害が発生しているということでもなさそうです。
 キャッシュ関連の動作（Opchaceなど？）が関連しているのかもと思いましたが、正体がわかりません…。

エラーログの傾向について追記しました。

2016/02/03 03:10

投稿

snic518

スコア39

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -87,3 +87,55 @@
 よろしくお願いいたします。
+---
+追記です。
+エラーログの出方ですが、HTTPアクセスの量に応じてログも増えているような傾向があるのですが、いっぺんに3プロセスほどまとまって落ちたり、完全にHTTPアクセスと同期したエラーではなさそうに思えます。
+[Wed Feb 03 11:45:07 2016] [notice] child pid 11648 exit signal Segmentation fault (11)
+[Wed Feb 03 11:45:07 2016] [notice] child pid 11651 exit signal Segmentation fault (11)
+[Wed Feb 03 11:45:07 2016] [notice] child pid 11662 exit signal Segmentation fault (11)
+[Wed Feb 03 11:45:08 2016] [notice] child pid 11664 exit signal Segmentation fault (11)
+[Wed Feb 03 11:45:10 2016] [notice] child pid 11658 exit signal Segmentation fault (11)
+[Wed Feb 03 11:46:40 2016] [notice] child pid 11628 exit signal Segmentation fault (11)
+[Wed Feb 03 11:46:40 2016] [notice] child pid 11686 exit signal Segmentation fault (11)
+[Wed Feb 03 11:46:40 2016] [notice] child pid 11704 exit signal Segmentation fault (11)
+キャッシュ関連の動作（Opchaceなど？）が関連しているのかもと思いましたが、正体がわかりません…。
+他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
+これも、PHPアップデート前は発生していませんでした。
+どなたか、ご助言いただけますと幸いです。
+よろしくお願いいたします。