質問編集履歴

11

追記

2016/02/15 01:36

投稿

snic518
snic518

スコア39

test CHANGED
File without changes
test CHANGED
@@ -500,4 +500,10 @@
500
500
 
501
501
 
502
502
 
503
+ 今これをアップデートすると、下記が入るようです。
504
+
505
+ centos-release.x86_64 6-7.e16.centos12.3
506
+
507
+
508
+
503
509
  ご意見いただけますと幸いです。

10

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

2016/02/15 01:36

投稿

snic518
snic518

スコア39

test CHANGED
File without changes
test CHANGED
@@ -4,7 +4,7 @@
4
4
 
5
5
  yum updateでphp7.0.2にアップデートしました。
6
6
 
7
- サーバー上のアプリケーションは、見た目上は特に不具合なく動いているようなのですが、ApacheのエラーログにはSegmentation faultが非常に多く記録されるようになってしまいました。
7
+ サーバー上のアプリケーションは、見た目上は特に不具合なく動いているのですが、ApacheのエラーログにはSegmentation faultが非常に多く記録されるようになってしまいました。
8
8
 
9
9
 
10
10
 
@@ -72,18 +72,6 @@
72
72
 
73
73
 
74
74
 
75
-
76
-
77
- ちなみにyumのリポジトリは下記で更新しました。
78
-
79
- http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
80
-
81
- http://ftp.iij.ad.jp/pub/linux/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
82
-
83
-
84
-
85
-
86
-
87
75
  エラーログの出方ですが、HTTPアクセスの量に応じてログも増えているような傾向があるのですが、いっぺんに3プロセスほどまとまって落ちたり、完全にHTTPアクセスと同期したエラーではなさそうに思えます。
88
76
 
89
77
 
@@ -94,7 +82,7 @@
94
82
 
95
83
  [Wed Feb 03 11:45:07 2016] [notice] child pid 11662 exit signal Segmentation fault (11)
96
84
 
97
- [Wed Feb 03 11:45:08 2016] [notice] child pid 11664 exit signal Segmentation fault (11)
85
+
98
86
 
99
87
 
100
88
 
@@ -112,8 +100,6 @@
112
100
 
113
101
 
114
102
 
115
-
116
-
117
103
  どなたか、ご助言いただけますと幸いです。
118
104
 
119
105
 
@@ -198,20 +184,10 @@
198
184
 
199
185
 
200
186
 
201
-
202
-
203
187
  サイトのアプリケーション動作自体は普通に動いている、サイトアクセスの増加にともなってエラーログも増える、ということを踏まえると、このエラーはhttpdプロセスが終了する時に発生しているのでは、という気がしてきました。
204
188
 
205
189
 
206
190
 
207
-
208
-
209
- どなたか、ご意見伺えますと幸いです。
210
-
211
-
212
-
213
-
214
-
215
191
  ---
216
192
 
217
193
 
@@ -226,7 +202,7 @@
226
202
 
227
203
 
228
204
 
229
- > 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
205
+ > MySQLのAborted clientsが似たようなペースで増えています。
230
206
 
231
207
  これも、PHPアップデート前は発生していませんでした。
232
208
 
@@ -276,14 +252,10 @@
276
252
 
277
253
 
278
254
 
279
-
280
-
281
255
  どなたか、ご意見いただけますと幸いです。
282
256
 
283
257
 
284
258
 
285
-
286
-
287
259
  ###【20160209追記】
288
260
 
289
261
 
@@ -298,56 +270,6 @@
298
270
 
299
271
 
300
272
 
301
- ================================================================================================================================
302
-
303
- パッケージ アーキテクチャ バージョン リポジトリー 容量
304
-
305
- ================================================================================================================================
306
-
307
- 更新:
308
-
309
- php x86_64 7.0.3-1.el6.remi remi-php70 2.7 M
310
-
311
- php-devel x86_64 7.0.3-1.el6.remi remi-php70 1.3 M
312
-
313
- php-opcache x86_64 7.0.3-1.el6.remi remi-php70 135 k
314
-
315
- 依存性関連での更新をします。:
316
-
317
- php-bcmath x86_64 7.0.3-1.el6.remi remi-php70 55 k
318
-
319
- php-cli x86_64 7.0.3-1.el6.remi remi-php70 3.9 M
320
-
321
- php-common x86_64 7.0.3-1.el6.remi remi-php70 973 k
322
-
323
- php-gd x86_64 7.0.3-1.el6.remi remi-php70 61 k
324
-
325
- php-gmp x86_64 7.0.3-1.el6.remi remi-php70 52 k
326
-
327
- php-json x86_64 7.0.3-1.el6.remi remi-php70 49 k
328
-
329
- php-mbstring x86_64 7.0.3-1.el6.remi remi-php70 969 k
330
-
331
- php-mcrypt x86_64 7.0.3-1.el6.remi remi-php70 46 k
332
-
333
- php-mysqlnd x86_64 7.0.3-1.el6.remi remi-php70 208 k
334
-
335
- php-pdo x86_64 7.0.3-1.el6.remi remi-php70 102 k
336
-
337
- php-recode x86_64 7.0.3-1.el6.remi remi-php70 33 k
338
-
339
- php-tidy x86_64 7.0.3-1.el6.remi remi-php70 49 k
340
-
341
- php-xml x86_64 7.0.3-1.el6.remi remi-php70 168 k
342
-
343
-
344
-
345
- トランザクションの要約
346
-
347
- ================================================================================================================================
348
-
349
- アップグレード 16 パッケージ
350
-
351
273
  ```
352
274
 
353
275
 
@@ -380,8 +302,6 @@
380
302
 
381
303
 
382
304
 
383
-
384
-
385
305
  ###【20160209追記2】
386
306
 
387
307
 
@@ -390,18 +310,16 @@
390
310
 
391
311
 
392
312
 
393
- [https://bugs.php.net/bug.php?id=71492](https://bugs.php.net/bug.php?id=71492)
313
+ [こちら](https://bugs.php.net/bug.php?id=71492)
394
-
395
-
396
-
314
+
315
+
316
+
397
- 「見かけは動いているけど、Segmentation faultエラーが大量に出る」という点で一致しています
317
+ 「見かけは動いているけど、Segmentation faultエラーが大量に出る」という点で一致しています。
398
318
 
399
319
  gdbの結果の内容は違うみたいですが、原因は同じなのでしょうか。
400
320
 
401
321
 
402
322
 
403
-
404
-
405
323
  また、httpdのプロセスidを観察してみたところ、やはり終了時にSegmentation faultが発生しているので間違い無さそうでした。
406
324
 
407
325
 
@@ -416,10 +334,6 @@
416
334
 
417
335
  他、使用しているPHPライブラリに問題がないか確かめましたが、これも無関係のようでした。
418
336
 
419
- ※AWS for PHP 2を使っていました。[最新版](https://github.com/aws/aws-sdk-php/releases/tag/2.8.27)に差し替えましたが、変化なしでした。
420
-
421
-
422
-
423
337
 
424
338
 
425
339
  引き続き調査しようと思います。
@@ -488,8 +402,6 @@
488
402
 
489
403
 
490
404
 
491
-
492
-
493
405
  (gdb) list
494
406
 
495
407
  539 nIndex = h | ht->nTableMask;
@@ -516,8 +428,6 @@
516
428
 
517
429
 
518
430
 
519
-
520
-
521
431
  zend_hash_index_find_bucketの問題なのかと思い検索してみましたが、過去この部分にバグフィックスがあったらしい(もう直ってる)ことくらいしかわかりませんでした。
522
432
 
523
433
 
@@ -526,8 +436,6 @@
526
436
 
527
437
  ご意見いただけますと幸いです。
528
438
 
529
- よろしくお願いいたします。
530
-
531
439
 
532
440
 
533
441
  ###【20160212追記2】
@@ -542,4 +450,54 @@
542
450
 
543
451
 
544
452
 
545
- かに引っかかっているのだと思いますが、からもし原因がわかれば、ご助言いただけますと幸いです。
453
+ ここからもし原因がわかれば、ご助言いただけますと幸いです。
454
+
455
+
456
+
457
+ ###【20160215追記】
458
+
459
+
460
+
461
+ 環境の問題かも、と思い、yum updateで諸々のモジュールを最新にしたり、カーネルアップデートをしたりしてみました。
462
+
463
+
464
+
465
+ ```ここに言語を入力
466
+
467
+ カーネルバージョン
468
+
469
+ cat /proc/version
470
+
471
+ 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
472
+
473
+
474
+
475
+ ※20160213 kernel update
476
+
477
+
478
+
479
+ 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
480
+
481
+ ```
482
+
483
+
484
+
485
+ が、これでも改善はされませんでした。
486
+
487
+ あと残るはCentOSが6.4なのを最新にしてみるか、くらいなのですが、関係あるのかどうかは今のところわかりません…。
488
+
489
+ 6.4だとPHP7で問題あるのかどうかの情報はないようです。
490
+
491
+
492
+
493
+ ```
494
+
495
+ # cat /etc/redhat-release
496
+
497
+ CentOS release 6.4 (Final)
498
+
499
+ ```
500
+
501
+
502
+
503
+ ご意見いただけますと幸いです。

9

更にgdbの結果追記

2016/02/15 01:35

投稿

snic518
snic518

スコア39

test CHANGED
File without changes
test CHANGED
@@ -14,8 +14,6 @@
14
14
 
15
15
 
16
16
 
17
-
18
-
19
17
  coreファイルを取得し、gdbを見てみたのですが、下記のような結果になりました。
20
18
 
21
19
 
@@ -86,460 +84,462 @@
86
84
 
87
85
 
88
86
 
87
+ エラーログの出方ですが、HTTPアクセスの量に応じてログも増えているような傾向があるのですが、いっぺんに3プロセスほどまとまって落ちたり、完全にHTTPアクセスと同期したエラーではなさそうに思えます。
88
+
89
+
90
+
91
+ [Wed Feb 03 11:45:07 2016] [notice] child pid 11648 exit signal Segmentation fault (11)
92
+
93
+ [Wed Feb 03 11:45:07 2016] [notice] child pid 11651 exit signal Segmentation fault (11)
94
+
95
+ [Wed Feb 03 11:45:07 2016] [notice] child pid 11662 exit signal Segmentation fault (11)
96
+
97
+ [Wed Feb 03 11:45:08 2016] [notice] child pid 11664 exit signal Segmentation fault (11)
98
+
99
+
100
+
101
+ プロセスはhttpdで間違い無さそうなのですが、やはり普通にサイトは動作しているようで、
102
+
103
+ このエラーが発生した時にユーザーに障害が発生しているということでもなさそうです。
104
+
105
+ キャッシュ関連の動作(Opchaceなど?)が関連しているのかもと思いましたが、正体がわかりません…。
106
+
107
+
108
+
109
+ 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
110
+
111
+ これも、PHPアップデート前は発生していませんでした。
112
+
113
+
114
+
115
+
116
+
117
+ どなたか、ご助言いただけますと幸いです。
118
+
119
+
120
+
89
121
  よろしくお願いいたします。
90
122
 
91
123
 
92
124
 
93
-
94
-
95
125
  ---
96
126
 
97
127
 
98
128
 
99
- 追記です。
100
-
101
-
102
-
103
- エラーログの出方ですが、HTTPアクセスの量に応じてログも増えているような傾向があるのですが、いっぺんに3プロセスほどままっ落ちり、完全にHTTPアクセスと同期したエラーはなさそうに思えます。
104
-
105
-
106
-
107
- [Wed Feb 03 11:45:07 2016] [notice] child pid 11648 exit signal Segmentation fault (11)
108
-
109
- [Wed Feb 03 11:45:07 2016] [notice] child pid 11651 exit signal Segmentation fault (11)
110
-
111
- [Wed Feb 03 11:45:07 2016] [notice] child pid 11662 exit signal Segmentation fault (11)
112
-
113
- [Wed Feb 03 11:45:08 2016] [notice] child pid 11664 exit signal Segmentation fault (11)
114
-
115
-
116
-
117
- プロセスはhttpdで間違い無さそうなのですが、やはり普通にサイトは動作しているようで、
118
-
119
- このエラーが発生した時にユーザーに障害が発生しているということでもなさそうです。
120
-
121
- キャッシュ関連動作(Opchaceなど?)が関連しているのかもと思いましたが、正体がわかりません…。
122
-
123
-
124
-
125
- 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
129
+ ###【201602031909追記
130
+
131
+
132
+
133
+ エラーログプロセスを確認したころ、少し事象が見えきがした追記です。
134
+
135
+
136
+
137
+ ある時間(2016-02-03-1825)のtopのスクリーンショットを取り、その後のエラーログを確認したところ、殆どのhttpdプロセスはこのエラーを吐いているということがわかりました。
138
+
139
+
140
+
141
+ ![top](6c76a59d80ea876f3f5b47ac3dfb1773.gif)
142
+
143
+
144
+
145
+ これに映っているhttpdのPIDを全て調べたところ、2/3くらいはエラーログが存在しました。
146
+
147
+
148
+
149
+ ```apache
150
+
151
+ # 201602031902頃エラーログを検索
152
+
153
+ [Wed Feb 03 18:26:52 2016] [notice] child pid 21489 exit signal Segmentation fault (11)
154
+
155
+ [Wed Feb 03 18:27:41 2016] [notice] child pid 21493 exit signal Segmentation fault (11)
156
+
157
+ [Wed Feb 03 18:28:25 2016] [notice] child pid 21440 exit signal Segmentation fault (11)
158
+
159
+ [Wed Feb 03 18:27:43 2016] [notice] child pid 21366 exit signal Segmentation fault (11)
160
+
161
+ [Wed Feb 03 18:28:19 2016] [notice] child pid 21522 exit signal Segmentation fault (11)
162
+
163
+ [Wed Feb 03 18:28:22 2016] [notice] child pid 21520 exit signal Segmentation fault (11)
164
+
165
+ [Wed Feb 03 18:28:25 2016] [notice] child pid 21494 exit signal Segmentation fault (11)
166
+
167
+ [Wed Feb 03 18:28:27 2016] [notice] child pid 21257 exit signal Segmentation fault (11)
168
+
169
+ [Wed Feb 03 18:28:47 2016] [notice] child pid 21519 exit signal Segmentation fault (11)
170
+
171
+ [Wed Feb 03 18:30:15 2016] [notice] child pid 21455 exit signal Segmentation fault (11)
172
+
173
+ [Wed Feb 03 18:31:15 2016] [notice] child pid 21376 exit signal Segmentation fault (11)
174
+
175
+
176
+
177
+
178
+
179
+ ↓無かったPID
180
+
181
+ 21521
182
+
183
+ 21444
184
+
185
+ 21403
186
+
187
+ 21453
188
+
189
+ 21525
190
+
191
+
192
+
193
+ ```
194
+
195
+
196
+
197
+ また、topコマンドで今生きているPIDをエラーログから探しても見つかりませんでした。(これは当たり前ですかね…)
198
+
199
+
200
+
201
+
202
+
203
+ サイトのアプリケーション動作自体は普通に動いている、サイトアクセスの増加にともなってエラーログも増える、ということを踏まえると、このエラーはhttpdプロセスが終了する時に発生しているのでは、という気がしてきました。
204
+
205
+
206
+
207
+
208
+
209
+ どなたか、ご意見伺えますと幸いです。
210
+
211
+
212
+
213
+
214
+
215
+ ---
216
+
217
+
218
+
219
+ ###【20160205追記】
220
+
221
+
222
+
223
+ 更に色々と調査しました。
224
+
225
+ 最初の書き込み時に下記の現象について書きました。
226
+
227
+
228
+
229
+ > 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
126
230
 
127
231
  これも、PHPアップデート前は発生していませんでした。
128
232
 
129
233
 
130
234
 
131
-
132
-
133
- どなたか、ご助言いただけますと幸いです。
134
-
135
-
235
+ これの原因が判明しました。
236
+
237
+
238
+
239
+ [オブログ — 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)
240
+
241
+
242
+
243
+ スクリプトを調べたところ、いくつかMySQLのStatementをcloseしていない箇所が見つかり、それをcloseするように直したところ、Aborted cliantの増加は止まりました。
244
+
245
+
246
+
247
+ > 正常に動作する場合は、新しい PreparedStatement が上書きされた後に GC が上手く動作して古い PreparedStatement が解放されるのですが、GC が上手く動作しない場合は古い PreparedStatement が解放されず、データベースとの接続を保った状態のまま残ってしまいます。
248
+
249
+
250
+
251
+ この問題が発生する前ではStatementをcloseしなくてもAborted cliantが増えてなかったのが、問題発生後に顕在化したということは、上記引用にある通り、**GCが上手く動作しない状態**にあるのではと推察します。
252
+
253
+
254
+
255
+
256
+
257
+ 0. PHPをupdate後、GCに問題が発生し、Segmentation faultが大量発生
258
+
259
+ 1. GCが上手く動かないため、これまではよしなにされていたPHPスクリプトのStatement解放漏れが顕在化
260
+
261
+
262
+
263
+ というのが現状なのかと思います。
264
+
265
+ 2に関してはもともとスクリプト側の問題ということで、それはそれで修正出来て良かったのですが、1に関しては未だに原因不明です。
266
+
267
+
268
+
269
+
270
+
271
+ 思いあたる節としては、諸事情でPHPのインストールユーザーとApacheの実行ユーザーに違いがあるため、sesston_save_pathの所有者がそのままだとセッションの書き込みが出来ないために、そのディレクトリの所有者をchownしている点です。
272
+
273
+
274
+
275
+ 他に所有者変更が必要なディレクトリがあるのかもしれませんが、調べても見つかりませんでした。
276
+
277
+
278
+
279
+
280
+
281
+ どなたか、ご意見いただけますと幸いです。
282
+
283
+
284
+
285
+
286
+
287
+ ###【20160209追記】
288
+
289
+
290
+
291
+ PHP7.0.3がリリースされていたので、アップデートしてみては、との助言をいただきました。
292
+
293
+
294
+
295
+ ```ssh
296
+
297
+ yum --enablerepo=remi-php70 update php php-devel php-opcache
298
+
299
+
300
+
301
+ ================================================================================================================================
302
+
303
+ パッケージ アーキテクチャ バージョン リポジトリー 容量
304
+
305
+ ================================================================================================================================
306
+
307
+ 更新:
308
+
309
+ php x86_64 7.0.3-1.el6.remi remi-php70 2.7 M
310
+
311
+ php-devel x86_64 7.0.3-1.el6.remi remi-php70 1.3 M
312
+
313
+ php-opcache x86_64 7.0.3-1.el6.remi remi-php70 135 k
314
+
315
+ 依存性関連での更新をします。:
316
+
317
+ php-bcmath x86_64 7.0.3-1.el6.remi remi-php70 55 k
318
+
319
+ php-cli x86_64 7.0.3-1.el6.remi remi-php70 3.9 M
320
+
321
+ php-common x86_64 7.0.3-1.el6.remi remi-php70 973 k
322
+
323
+ php-gd x86_64 7.0.3-1.el6.remi remi-php70 61 k
324
+
325
+ php-gmp x86_64 7.0.3-1.el6.remi remi-php70 52 k
326
+
327
+ php-json x86_64 7.0.3-1.el6.remi remi-php70 49 k
328
+
329
+ php-mbstring x86_64 7.0.3-1.el6.remi remi-php70 969 k
330
+
331
+ php-mcrypt x86_64 7.0.3-1.el6.remi remi-php70 46 k
332
+
333
+ php-mysqlnd x86_64 7.0.3-1.el6.remi remi-php70 208 k
334
+
335
+ php-pdo x86_64 7.0.3-1.el6.remi remi-php70 102 k
336
+
337
+ php-recode x86_64 7.0.3-1.el6.remi remi-php70 33 k
338
+
339
+ php-tidy x86_64 7.0.3-1.el6.remi remi-php70 49 k
340
+
341
+ php-xml x86_64 7.0.3-1.el6.remi remi-php70 168 k
342
+
343
+
344
+
345
+ トランザクションの要約
346
+
347
+ ================================================================================================================================
348
+
349
+ アップグレード 16 パッケージ
350
+
351
+ ```
352
+
353
+
354
+
355
+ ```
356
+
357
+ PHP 7.0.3 (cli) (built: Feb 3 2016 11:40:05) ( NTS )
358
+
359
+ Copyright (c) 1997-2016 The PHP Group
360
+
361
+ Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
362
+
363
+ with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
364
+
365
+ ```
366
+
367
+
368
+
369
+ アップデートは問題なく終了したのですが、サーバー再起動後、やはり継続してSegment faultは発生し続けています。
370
+
371
+ PHP本体の問題ではなかったのですかね…。
372
+
373
+
374
+
375
+ Zend OPcache がv7.0.6-devなのが少し気になりますが、もしかしてこれのverを下げたほうがいいのでしょうか。
376
+
377
+
378
+
379
+ ご意見いただけますと幸いです。
380
+
381
+
382
+
383
+
384
+
385
+ ###【20160209追記2】
386
+
387
+
388
+
389
+ PHPのバグフォーラムを調べたところ、PHP7.0.2で似たような状況の報告を見つけました。
390
+
391
+
392
+
393
+ [https://bugs.php.net/bug.php?id=71492](https://bugs.php.net/bug.php?id=71492)
394
+
395
+
396
+
397
+ 「見かけは動いているけど、Segmentation faultエラーが大量に出る」という点で一致していますね。
398
+
399
+ gdbの結果の内容は違うみたいですが、原因は同じなのでしょうか。
400
+
401
+
402
+
403
+
404
+
405
+ また、httpdのプロセスidを観察してみたところ、やはり終了時にSegmentation faultが発生しているので間違い無さそうでした。
406
+
407
+
408
+
409
+ topコマンドで今ある適当なpidを選び、
410
+
411
+ /proc ディレクトリにあるプロセスディレクトリを監視、
412
+
413
+ それが消去された時点でApacheエラーログを見たところ、同じpidのSegmentation faultログが出力されていることを確認しました。
414
+
415
+
416
+
417
+ 他、使用しているPHPライブラリに問題がないか確かめましたが、これも無関係のようでした。
418
+
419
+ ※AWS for PHP 2を使っていました。[最新版](https://github.com/aws/aws-sdk-php/releases/tag/2.8.27)に差し替えましたが、変化なしでした。
420
+
421
+
422
+
423
+
424
+
425
+ 引き続き調査しようと思います。
426
+
427
+
428
+
429
+ ###【20160212追記】
430
+
431
+
432
+
433
+ コメントにて、php-debuginfoを入れて再度gdbをとのご意見をいただきましたので、結果を記載します。
434
+
435
+
436
+
437
+ ```ssh
438
+
439
+ yum --enablerepo=remi-php70 install php-debuginfo
440
+
441
+
442
+
443
+ ```
444
+
445
+ php70-php-debuginfo-7.0.3-1.el6.remi.x86_64がインストールされました。
446
+
447
+
448
+
449
+ coreファイルをgdbで実行し、where,listをしてみた結果が以下です。
450
+
451
+
452
+
453
+ ```
454
+
455
+ (gdb) where
456
+
457
+ #0 0x00007f177b70a2ff in zend_hash_index_find_bucket (ht=0x0,
458
+
459
+ h=13841567621774083997) at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:544
460
+
461
+ #1 zend_hash_index_exists (ht=0x0, h=13841567621774083997)
462
+
463
+ at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:2021
464
+
465
+ #2 0x00007f177b60745e in ?? ()
466
+
467
+ at /usr/src/debug/php-7.0.3/ext/session/session.c:1676
468
+
469
+ from /etc/httpd/modules/libphp7.so
470
+
471
+ #3 0x00007f17790174a0 in ?? ()
472
+
473
+ #4 0x00007f177bacb368 in labels.92387 () from /etc/httpd/modules/libphp7.so
474
+
475
+ #5 0x00007f17882f0410 in ?? ()
476
+
477
+ #6 0x00007f1779017030 in ?? ()
478
+
479
+ #7 0x00007f177bacb366 in labels.92387 () from /etc/httpd/modules/libphp7.so
480
+
481
+ #8 0x00007f177b60793d in zend_string_release ()
482
+
483
+ at /usr/src/debug/php-7.0.3/Zend/zend_string.h:271
484
+
485
+ #9 php_session_start () at /usr/src/debug/php-7.0.3/ext/session/session.c:1644
486
+
487
+ #10 0x0000000000000000 in ?? ()
488
+
489
+
490
+
491
+
492
+
493
+ (gdb) list
494
+
495
+ 539 nIndex = h | ht->nTableMask;
496
+
497
+ 540 idx = HT_HASH_EX(arData, nIndex);
498
+
499
+ 541 while (idx != HT_INVALID_IDX) {
500
+
501
+ 542 ZEND_ASSERT(idx < HT_IDX_TO_HASH(ht->nTableSize));
502
+
503
+ 543 p = HT_HASH_TO_BUCKET_EX(arData, idx);
504
+
505
+ 544 if (p->h == h && !p->key) {
506
+
507
+ 545 return p;
508
+
509
+ 546 }
510
+
511
+ 547 idx = Z_NEXT(p->val);
512
+
513
+ 548 }
514
+
515
+ ```
516
+
517
+
518
+
519
+
520
+
521
+ zend_hash_index_find_bucketの問題なのかと思い検索してみましたが、過去この部分にバグフィックスがあったらしい(もう直ってる)ことくらいしかわかりませんでした。
522
+
523
+
524
+
525
+
526
+
527
+ ご意見いただけますと幸いです。
136
528
 
137
529
  よろしくお願いいたします。
138
530
 
139
531
 
140
532
 
141
- ---
142
-
143
-
144
-
145
- ###【201602031909追記】
146
-
147
-
148
-
149
- エラーログとプロセスを確認したところ、少し事象が見えてきたきがしたので追記です。
150
-
151
-
152
-
153
- ある時間(2016-02-03-1825)のtopのスクリーンショットを取り、その後のエラーログを確認したところ、殆のhttpdプロセスはのエラーを吐いているといがわかした
154
-
155
-
156
-
157
- ![top](6c76a59d80ea876f3f5b47ac3dfb1773.gif)
158
-
159
-
160
-
161
- これに映っているhttpdのPIDを全て調べたところ、2/3くらいはエラーログが存在しました。
162
-
163
-
164
-
165
- ```apache
166
-
167
- # 201602031902頃のエラーログを検索
168
-
169
- [Wed Feb 03 18:26:52 2016] [notice] child pid 21489 exit signal Segmentation fault (11)
170
-
171
- [Wed Feb 03 18:27:41 2016] [notice] child pid 21493 exit signal Segmentation fault (11)
172
-
173
- [Wed Feb 03 18:28:25 2016] [notice] child pid 21440 exit signal Segmentation fault (11)
174
-
175
- [Wed Feb 03 18:27:43 2016] [notice] child pid 21366 exit signal Segmentation fault (11)
176
-
177
- [Wed Feb 03 18:28:19 2016] [notice] child pid 21522 exit signal Segmentation fault (11)
178
-
179
- [Wed Feb 03 18:28:22 2016] [notice] child pid 21520 exit signal Segmentation fault (11)
180
-
181
- [Wed Feb 03 18:28:25 2016] [notice] child pid 21494 exit signal Segmentation fault (11)
182
-
183
- [Wed Feb 03 18:28:27 2016] [notice] child pid 21257 exit signal Segmentation fault (11)
184
-
185
- [Wed Feb 03 18:28:47 2016] [notice] child pid 21519 exit signal Segmentation fault (11)
186
-
187
- [Wed Feb 03 18:30:15 2016] [notice] child pid 21455 exit signal Segmentation fault (11)
188
-
189
- [Wed Feb 03 18:31:15 2016] [notice] child pid 21376 exit signal Segmentation fault (11)
190
-
191
-
192
-
193
-
194
-
195
- ↓無かったPID
196
-
197
- 21521
198
-
199
- 21444
200
-
201
- 21403
202
-
203
- 21453
204
-
205
- 21525
206
-
207
-
208
-
209
- ```
210
-
211
-
212
-
213
- また、topコマンドで今生きているPIDをエラーログから探しても見つかりませんでした。(これは当たり前ですかね…)
214
-
215
-
216
-
217
-
218
-
219
- サイトのアプリケーション動作自体は普通に動いている、サイトアクセスの増加にともなってエラーログも増える、ということを踏まえると、このエラーはhttpdプロセスが終了する時に発生しているのでは、という気がしてきました。
220
-
221
-
222
-
223
-
224
-
225
- どなたか、ご意見伺えますと幸いです。
226
-
227
-
228
-
229
-
230
-
231
- ---
232
-
233
-
234
-
235
- ###【20160205追記】
236
-
237
-
238
-
239
- 更に色々と調査しました。
240
-
241
- 最初の書き込み時に下記の現象について書きました。
242
-
243
-
244
-
245
- > 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
246
-
247
- これも、PHPアップデート前は発生していませんでした。
248
-
249
-
250
-
251
- これの原因が判明しました。
252
-
253
-
254
-
255
- [オブログ — 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)
256
-
257
-
258
-
259
- スクリプトを調べたところ、いくつかMySQLのStatementをcloseしていない箇所が見つかり、それをcloseするように直したところ、Aborted cliantの増加は止まりました。
260
-
261
-
262
-
263
- > 正常に動作する場合は、新しい PreparedStatement が上書きされた後に GC が上手く動作して古い PreparedStatement が解放されるのですが、GC が上手く動作しない場合は古い PreparedStatement が解放されず、データベースとの接続を保った状態のまま残ってしまいます。
264
-
265
-
266
-
267
- この問題が発生する前ではStatementをcloseしなくてもAborted cliantが増えてなかったのが、問題発生後に顕在化したということは、上記引用にある通り、**GCが上手く動作しない状態**にあるのではと推察します。
268
-
269
-
270
-
271
-
272
-
273
- 0. PHPをupdate後、GCに問題が発生し、Segmentation faultが大量発生
274
-
275
- 1. GCが上手く動かないため、これまではよしなにされていたPHPスクリプトのStatement解放漏れが顕在化
276
-
277
-
278
-
279
- というのが現状なのかと思います。
280
-
281
- 2に関してはもともとスクリプト側の問題ということで、それはそれで修正出来て良かったのですが、1に関しては未だに原因不明です。
282
-
283
-
284
-
285
-
286
-
287
- 思いあたる節としては、諸事情でPHPのインストールユーザーとApacheの実行ユーザーに違いがあるため、sesston_save_pathの所有者がそのままだとセッションの書き込みが出来ないために、そのディレクトリの所有者をchownしている点です。
288
-
289
-
290
-
291
- 他に所有者変更が必要なディレクトリがあるのかもしれませんが、調べても見つかりませんでした。
292
-
293
-
294
-
295
-
296
-
297
- どなたか、ご意見いただけますと幸いです。
298
-
299
-
300
-
301
-
302
-
303
- ###【20160209追記】
304
-
305
-
306
-
307
- PHP7.0.3がリリースされていたので、アップデートしてみては、との助言をいただきました。
308
-
309
-
310
-
311
- ```ssh
312
-
313
- yum --enablerepo=remi-php70 update php php-devel php-opcache
314
-
315
-
316
-
317
- ================================================================================================================================
318
-
319
- パッケージ アーキテクチャ バージョン リポジトリー 容量
320
-
321
- ================================================================================================================================
322
-
323
- 更新:
324
-
325
- php x86_64 7.0.3-1.el6.remi remi-php70 2.7 M
326
-
327
- php-devel x86_64 7.0.3-1.el6.remi remi-php70 1.3 M
328
-
329
- php-opcache x86_64 7.0.3-1.el6.remi remi-php70 135 k
330
-
331
- 依存性関連での更新をします。:
332
-
333
- php-bcmath x86_64 7.0.3-1.el6.remi remi-php70 55 k
334
-
335
- php-cli x86_64 7.0.3-1.el6.remi remi-php70 3.9 M
336
-
337
- php-common x86_64 7.0.3-1.el6.remi remi-php70 973 k
338
-
339
- php-gd x86_64 7.0.3-1.el6.remi remi-php70 61 k
340
-
341
- php-gmp x86_64 7.0.3-1.el6.remi remi-php70 52 k
342
-
343
- php-json x86_64 7.0.3-1.el6.remi remi-php70 49 k
344
-
345
- php-mbstring x86_64 7.0.3-1.el6.remi remi-php70 969 k
346
-
347
- php-mcrypt x86_64 7.0.3-1.el6.remi remi-php70 46 k
348
-
349
- php-mysqlnd x86_64 7.0.3-1.el6.remi remi-php70 208 k
350
-
351
- php-pdo x86_64 7.0.3-1.el6.remi remi-php70 102 k
352
-
353
- php-recode x86_64 7.0.3-1.el6.remi remi-php70 33 k
354
-
355
- php-tidy x86_64 7.0.3-1.el6.remi remi-php70 49 k
356
-
357
- php-xml x86_64 7.0.3-1.el6.remi remi-php70 168 k
358
-
359
-
360
-
361
- トランザクションの要約
362
-
363
- ================================================================================================================================
364
-
365
- アップグレード 16 パッケージ
366
-
367
- ```
368
-
369
-
370
-
371
- ```
372
-
373
- PHP 7.0.3 (cli) (built: Feb 3 2016 11:40:05) ( NTS )
374
-
375
- Copyright (c) 1997-2016 The PHP Group
376
-
377
- Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
378
-
379
- with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
380
-
381
- ```
382
-
383
-
384
-
385
- アップデートは問題なく終了したのですが、サーバー再起動後、やはり継続してSegment faultは発生し続けています。
386
-
387
- PHP本体の問題ではなかったのですかね…。
388
-
389
-
390
-
391
- Zend OPcache がv7.0.6-devなのが少し気になりますが、もしかしてこれのverを下げたほうがいいのでしょうか。
392
-
393
-
394
-
395
- ご意見いただけますと幸いです。
396
-
397
-
398
-
399
-
400
-
401
- ###【20160209追記2】
402
-
403
-
404
-
405
- PHPのバグフォーラムを調べたところ、PHP7.0.2で似たような状況の報告を見つけました。
406
-
407
-
408
-
409
- [https://bugs.php.net/bug.php?id=71492](https://bugs.php.net/bug.php?id=71492)
410
-
411
-
412
-
413
- 「見かけは動いているけど、Segmentation faultエラーが大量に出る」という点で一致していますね。
414
-
415
- gdbの結果の内容は違うみたいですが、原因は同じなのでしょうか。
416
-
417
-
418
-
419
-
420
-
421
- また、httpdのプロセスidを観察してみたところ、やはり終了時にSegmentation faultが発生しているので間違い無さそうでした。
422
-
423
-
424
-
425
- topコマンドで今ある適当なpidを選び、
426
-
427
- /proc ディレクトリにあるプロセスディレクトリを監視、
428
-
429
- それが消去された時点でApacheエラーログを見たところ、同じpidのSegmentation faultログが出力されていることを確認しました。
430
-
431
-
432
-
433
- 他、使用しているPHPライブラリに問題がないか確かめましたが、これも無関係のようでした。
434
-
435
- ※AWS for PHP 2を使っていました。[最新版](https://github.com/aws/aws-sdk-php/releases/tag/2.8.27)に差し替えましたが、変化なしでした。
436
-
437
-
438
-
439
-
440
-
441
- 引き続き調査しようと思います。
442
-
443
-
444
-
445
- ###【20160212追記】
446
-
447
-
448
-
449
- コメントにて、php-debuginfoを入れて再度gdbをとのご意見をいただきましたので、結果を記載します。
450
-
451
-
452
-
453
- ```ssh
454
-
455
- yum --enablerepo=remi-php70 install php-debuginfo
456
-
457
-
458
-
459
- ```
460
-
461
- php70-php-debuginfo-7.0.3-1.el6.remi.x86_64がインストールされました。
462
-
463
-
464
-
465
- coreファイルをgdbで実行し、where,listをしてみた結果が以下です。
466
-
467
-
468
-
469
- ```
470
-
471
- (gdb) where
472
-
473
- #0 0x00007f177b70a2ff in zend_hash_index_find_bucket (ht=0x0,
474
-
475
- h=13841567621774083997) at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:544
476
-
477
- #1 zend_hash_index_exists (ht=0x0, h=13841567621774083997)
478
-
479
- at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:2021
480
-
481
- #2 0x00007f177b60745e in ?? ()
482
-
483
- at /usr/src/debug/php-7.0.3/ext/session/session.c:1676
484
-
485
- from /etc/httpd/modules/libphp7.so
486
-
487
- #3 0x00007f17790174a0 in ?? ()
488
-
489
- #4 0x00007f177bacb368 in labels.92387 () from /etc/httpd/modules/libphp7.so
490
-
491
- #5 0x00007f17882f0410 in ?? ()
492
-
493
- #6 0x00007f1779017030 in ?? ()
494
-
495
- #7 0x00007f177bacb366 in labels.92387 () from /etc/httpd/modules/libphp7.so
496
-
497
- #8 0x00007f177b60793d in zend_string_release ()
498
-
499
- at /usr/src/debug/php-7.0.3/Zend/zend_string.h:271
500
-
501
- #9 php_session_start () at /usr/src/debug/php-7.0.3/ext/session/session.c:1644
502
-
503
- #10 0x0000000000000000 in ?? ()
504
-
505
-
506
-
507
-
508
-
509
- (gdb) list
510
-
511
- 539 nIndex = h | ht->nTableMask;
512
-
513
- 540 idx = HT_HASH_EX(arData, nIndex);
514
-
515
- 541 while (idx != HT_INVALID_IDX) {
516
-
517
- 542 ZEND_ASSERT(idx < HT_IDX_TO_HASH(ht->nTableSize));
518
-
519
- 543 p = HT_HASH_TO_BUCKET_EX(arData, idx);
520
-
521
- 544 if (p->h == h && !p->key) {
522
-
523
- 545 return p;
524
-
525
- 546 }
526
-
527
- 547 idx = Z_NEXT(p->val);
528
-
529
- 548 }
530
-
531
- ```
532
-
533
-
534
-
535
-
536
-
537
- zend_hash_index_find_bucketの問題なのかと思い検索してみましたが、過去この部分にバグフィックスがあったらしい(もう直ってる)ことくらいしかわかりませんでした。
538
-
539
-
540
-
541
-
542
-
543
- ご意見いただけますと幸いです。
544
-
545
- よろしくお願いいたします。
533
+ ###【20160212追記2】
534
+
535
+
536
+
537
+ 文字数の制限に達してしまったので、gdb listを11個のframeに対して実行した結果を作成しました。
538
+
539
+
540
+
541
+ [gdb list一覧](https://www.evernote.com/shard/s45/sh/dc7bfa9f-fbf5-439f-b4b5-4135fed74ca5/b99debb01d4a3b8aeb43574ba404d5dd)
542
+
543
+
544
+
545
+ どこかに引っかかっているのだますが、こからもし原因がわかれば、ご助言いただけすと幸いです

8

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

2016/02/12 12:18

投稿

snic518
snic518

スコア39

test CHANGED
File without changes
test CHANGED
@@ -112,14 +112,6 @@
112
112
 
113
113
  [Wed Feb 03 11:45:08 2016] [notice] child pid 11664 exit signal Segmentation fault (11)
114
114
 
115
- [Wed Feb 03 11:45:10 2016] [notice] child pid 11658 exit signal Segmentation fault (11)
116
-
117
- [Wed Feb 03 11:46:40 2016] [notice] child pid 11628 exit signal Segmentation fault (11)
118
-
119
- [Wed Feb 03 11:46:40 2016] [notice] child pid 11686 exit signal Segmentation fault (11)
120
-
121
- [Wed Feb 03 11:46:40 2016] [notice] child pid 11704 exit signal Segmentation fault (11)
122
-
123
115
 
124
116
 
125
117
  プロセスはhttpdで間違い無さそうなのですが、やはり普通にサイトは動作しているようで、
@@ -447,3 +439,107 @@
447
439
 
448
440
 
449
441
  引き続き調査しようと思います。
442
+
443
+
444
+
445
+ ###【20160212追記】
446
+
447
+
448
+
449
+ コメントにて、php-debuginfoを入れて再度gdbをとのご意見をいただきましたので、結果を記載します。
450
+
451
+
452
+
453
+ ```ssh
454
+
455
+ yum --enablerepo=remi-php70 install php-debuginfo
456
+
457
+
458
+
459
+ ```
460
+
461
+ php70-php-debuginfo-7.0.3-1.el6.remi.x86_64がインストールされました。
462
+
463
+
464
+
465
+ coreファイルをgdbで実行し、where,listをしてみた結果が以下です。
466
+
467
+
468
+
469
+ ```
470
+
471
+ (gdb) where
472
+
473
+ #0 0x00007f177b70a2ff in zend_hash_index_find_bucket (ht=0x0,
474
+
475
+ h=13841567621774083997) at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:544
476
+
477
+ #1 zend_hash_index_exists (ht=0x0, h=13841567621774083997)
478
+
479
+ at /usr/src/debug/php-7.0.3/Zend/zend_hash.c:2021
480
+
481
+ #2 0x00007f177b60745e in ?? ()
482
+
483
+ at /usr/src/debug/php-7.0.3/ext/session/session.c:1676
484
+
485
+ from /etc/httpd/modules/libphp7.so
486
+
487
+ #3 0x00007f17790174a0 in ?? ()
488
+
489
+ #4 0x00007f177bacb368 in labels.92387 () from /etc/httpd/modules/libphp7.so
490
+
491
+ #5 0x00007f17882f0410 in ?? ()
492
+
493
+ #6 0x00007f1779017030 in ?? ()
494
+
495
+ #7 0x00007f177bacb366 in labels.92387 () from /etc/httpd/modules/libphp7.so
496
+
497
+ #8 0x00007f177b60793d in zend_string_release ()
498
+
499
+ at /usr/src/debug/php-7.0.3/Zend/zend_string.h:271
500
+
501
+ #9 php_session_start () at /usr/src/debug/php-7.0.3/ext/session/session.c:1644
502
+
503
+ #10 0x0000000000000000 in ?? ()
504
+
505
+
506
+
507
+
508
+
509
+ (gdb) list
510
+
511
+ 539 nIndex = h | ht->nTableMask;
512
+
513
+ 540 idx = HT_HASH_EX(arData, nIndex);
514
+
515
+ 541 while (idx != HT_INVALID_IDX) {
516
+
517
+ 542 ZEND_ASSERT(idx < HT_IDX_TO_HASH(ht->nTableSize));
518
+
519
+ 543 p = HT_HASH_TO_BUCKET_EX(arData, idx);
520
+
521
+ 544 if (p->h == h && !p->key) {
522
+
523
+ 545 return p;
524
+
525
+ 546 }
526
+
527
+ 547 idx = Z_NEXT(p->val);
528
+
529
+ 548 }
530
+
531
+ ```
532
+
533
+
534
+
535
+
536
+
537
+ zend_hash_index_find_bucketの問題なのかと思い検索してみましたが、過去この部分にバグフィックスがあったらしい(もう直ってる)ことくらいしかわかりませんでした。
538
+
539
+
540
+
541
+
542
+
543
+ ご意見いただけますと幸いです。
544
+
545
+ よろしくお願いいたします。

7

進捗です。

2016/02/12 00:52

投稿

snic518
snic518

スコア39

test CHANGED
File without changes
test CHANGED
@@ -401,3 +401,49 @@
401
401
 
402
402
 
403
403
  ご意見いただけますと幸いです。
404
+
405
+
406
+
407
+
408
+
409
+ ###【20160209追記2】
410
+
411
+
412
+
413
+ PHPのバグフォーラムを調べたところ、PHP7.0.2で似たような状況の報告を見つけました。
414
+
415
+
416
+
417
+ [https://bugs.php.net/bug.php?id=71492](https://bugs.php.net/bug.php?id=71492)
418
+
419
+
420
+
421
+ 「見かけは動いているけど、Segmentation faultエラーが大量に出る」という点で一致していますね。
422
+
423
+ gdbの結果の内容は違うみたいですが、原因は同じなのでしょうか。
424
+
425
+
426
+
427
+
428
+
429
+ また、httpdのプロセスidを観察してみたところ、やはり終了時にSegmentation faultが発生しているので間違い無さそうでした。
430
+
431
+
432
+
433
+ topコマンドで今ある適当なpidを選び、
434
+
435
+ /proc ディレクトリにあるプロセスディレクトリを監視、
436
+
437
+ それが消去された時点でApacheエラーログを見たところ、同じpidのSegmentation faultログが出力されていることを確認しました。
438
+
439
+
440
+
441
+ 他、使用しているPHPライブラリに問題がないか確かめましたが、これも無関係のようでした。
442
+
443
+ ※AWS for PHP 2を使っていました。[最新版](https://github.com/aws/aws-sdk-php/releases/tag/2.8.27)に差し替えましたが、変化なしでした。
444
+
445
+
446
+
447
+
448
+
449
+ 引き続き調査しようと思います。

6

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

2016/02/09 12:51

投稿

snic518
snic518

スコア39

test CHANGED
File without changes
test CHANGED
@@ -303,3 +303,101 @@
303
303
 
304
304
 
305
305
  どなたか、ご意見いただけますと幸いです。
306
+
307
+
308
+
309
+
310
+
311
+ ###【20160209追記】
312
+
313
+
314
+
315
+ PHP7.0.3がリリースされていたので、アップデートしてみては、との助言をいただきました。
316
+
317
+
318
+
319
+ ```ssh
320
+
321
+ yum --enablerepo=remi-php70 update php php-devel php-opcache
322
+
323
+
324
+
325
+ ================================================================================================================================
326
+
327
+ パッケージ アーキテクチャ バージョン リポジトリー 容量
328
+
329
+ ================================================================================================================================
330
+
331
+ 更新:
332
+
333
+ php x86_64 7.0.3-1.el6.remi remi-php70 2.7 M
334
+
335
+ php-devel x86_64 7.0.3-1.el6.remi remi-php70 1.3 M
336
+
337
+ php-opcache x86_64 7.0.3-1.el6.remi remi-php70 135 k
338
+
339
+ 依存性関連での更新をします。:
340
+
341
+ php-bcmath x86_64 7.0.3-1.el6.remi remi-php70 55 k
342
+
343
+ php-cli x86_64 7.0.3-1.el6.remi remi-php70 3.9 M
344
+
345
+ php-common x86_64 7.0.3-1.el6.remi remi-php70 973 k
346
+
347
+ php-gd x86_64 7.0.3-1.el6.remi remi-php70 61 k
348
+
349
+ php-gmp x86_64 7.0.3-1.el6.remi remi-php70 52 k
350
+
351
+ php-json x86_64 7.0.3-1.el6.remi remi-php70 49 k
352
+
353
+ php-mbstring x86_64 7.0.3-1.el6.remi remi-php70 969 k
354
+
355
+ php-mcrypt x86_64 7.0.3-1.el6.remi remi-php70 46 k
356
+
357
+ php-mysqlnd x86_64 7.0.3-1.el6.remi remi-php70 208 k
358
+
359
+ php-pdo x86_64 7.0.3-1.el6.remi remi-php70 102 k
360
+
361
+ php-recode x86_64 7.0.3-1.el6.remi remi-php70 33 k
362
+
363
+ php-tidy x86_64 7.0.3-1.el6.remi remi-php70 49 k
364
+
365
+ php-xml x86_64 7.0.3-1.el6.remi remi-php70 168 k
366
+
367
+
368
+
369
+ トランザクションの要約
370
+
371
+ ================================================================================================================================
372
+
373
+ アップグレード 16 パッケージ
374
+
375
+ ```
376
+
377
+
378
+
379
+ ```
380
+
381
+ PHP 7.0.3 (cli) (built: Feb 3 2016 11:40:05) ( NTS )
382
+
383
+ Copyright (c) 1997-2016 The PHP Group
384
+
385
+ Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
386
+
387
+ with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
388
+
389
+ ```
390
+
391
+
392
+
393
+ アップデートは問題なく終了したのですが、サーバー再起動後、やはり継続してSegment faultは発生し続けています。
394
+
395
+ PHP本体の問題ではなかったのですかね…。
396
+
397
+
398
+
399
+ Zend OPcache がv7.0.6-devなのが少し気になりますが、もしかしてこれのverを下げたほうがいいのでしょうか。
400
+
401
+
402
+
403
+ ご意見いただけますと幸いです。

5

誤字修正

2016/02/09 01:26

投稿

snic518
snic518

スコア39

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

4

調査進捗について追記。

2016/02/05 03:35

投稿

snic518
snic518

スコア39

test CHANGED
@@ -1 +1 @@
1
- PHP7update後、Segmentation faultが起きます。
1
+ PHP7update後、Segmentation faultが起きます。追記・PHPのGCが原因?
test CHANGED
@@ -150,7 +150,7 @@
150
150
 
151
151
 
152
152
 
153
- 【201602031909追記】
153
+ ###【201602031909追記】
154
154
 
155
155
 
156
156
 
@@ -231,3 +231,75 @@
231
231
 
232
232
 
233
233
  どなたか、ご意見伺えますと幸いです。
234
+
235
+
236
+
237
+
238
+
239
+ ---
240
+
241
+
242
+
243
+ ###【20160205追記】
244
+
245
+
246
+
247
+ 更に色々と調査しました。
248
+
249
+ 最初の書き込み時に下記の現象について書きました。
250
+
251
+
252
+
253
+ > 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
254
+
255
+ これも、PHPアップデート前は発生していませんでした。
256
+
257
+
258
+
259
+ これの原因が判明しました。
260
+
261
+
262
+
263
+ [オブログ — 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)
264
+
265
+
266
+
267
+ スクリプトを調べたところ、いくつかMySQLのStatementをcloseしていない箇所が見つかり、それをcloseするように直したところ、Aborted cliantの増加は止まりました。
268
+
269
+
270
+
271
+ > 正常に動作する場合は、新しい PreparedStatement が上書きされた後に GC が上手く動作して古い PreparedStatement が解放されるのですが、GC が上手く動作しない場合は古い PreparedStatement が解放されず、データベースとの接続を保った状態のまま残ってしまいます。
272
+
273
+
274
+
275
+ この問題が発生する前ではStatementをcloseしなくてもAborted cliantが増えてなかったのが、問題発生後に顕在化したということは、上記引用にある通り、**GCが上手く動作しない状態**にあるのではと推察します。
276
+
277
+
278
+
279
+
280
+
281
+ 0. PHPをupdate後、GCに問題が発生し、Segmentation faultが大量発生
282
+
283
+ 1. GCが上手く動かないため、これまではよしなにされていたPHPスクリプトのStatement解放漏れが顕在化
284
+
285
+
286
+
287
+ というのが現状なのかと思います。
288
+
289
+ 2に関してはもともとスクリプト側の問題ということで、それはそれで修正出来て良かったのですが、1に関しては未だに原因不明です。
290
+
291
+
292
+
293
+
294
+
295
+ 思いたる節としては、諸事情でPHPのインストールユーザーとApacheの実行ユーザーに違いがあるため、sessiton_save_pathの所有者がそのままだとセッションの書き込みが出来ないために、そのディレクトリの所有者をchownしている点です。
296
+
297
+
298
+
299
+ 他に所有者変更が必要なディレクトリがあるのかもしれませんが、調べても見つかりませんでした。
300
+
301
+
302
+
303
+
304
+
305
+ どなたか、ご意見いただけますと幸いです。

3

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

2016/02/05 03:26

投稿

snic518
snic518

スコア39

test CHANGED
File without changes
test CHANGED
@@ -143,3 +143,91 @@
143
143
 
144
144
 
145
145
  よろしくお願いいたします。
146
+
147
+
148
+
149
+ ---
150
+
151
+
152
+
153
+ 【201602031909追記】
154
+
155
+
156
+
157
+ エラーログとプロセスを確認したところ、少し事象が見えてきたきがしたので追記です。
158
+
159
+
160
+
161
+ ある時間(2016-02-03-1825)のtopのスクリーンショットを取り、その後のエラーログを確認したところ、殆どのhttpdプロセスはこのエラーを吐いているということがわかりました。
162
+
163
+
164
+
165
+ ![top](6c76a59d80ea876f3f5b47ac3dfb1773.gif)
166
+
167
+
168
+
169
+ これに映っているhttpdのPIDを全て調べたところ、2/3くらいはエラーログが存在しました。
170
+
171
+
172
+
173
+ ```apache
174
+
175
+ # 201602031902頃のエラーログを検索
176
+
177
+ [Wed Feb 03 18:26:52 2016] [notice] child pid 21489 exit signal Segmentation fault (11)
178
+
179
+ [Wed Feb 03 18:27:41 2016] [notice] child pid 21493 exit signal Segmentation fault (11)
180
+
181
+ [Wed Feb 03 18:28:25 2016] [notice] child pid 21440 exit signal Segmentation fault (11)
182
+
183
+ [Wed Feb 03 18:27:43 2016] [notice] child pid 21366 exit signal Segmentation fault (11)
184
+
185
+ [Wed Feb 03 18:28:19 2016] [notice] child pid 21522 exit signal Segmentation fault (11)
186
+
187
+ [Wed Feb 03 18:28:22 2016] [notice] child pid 21520 exit signal Segmentation fault (11)
188
+
189
+ [Wed Feb 03 18:28:25 2016] [notice] child pid 21494 exit signal Segmentation fault (11)
190
+
191
+ [Wed Feb 03 18:28:27 2016] [notice] child pid 21257 exit signal Segmentation fault (11)
192
+
193
+ [Wed Feb 03 18:28:47 2016] [notice] child pid 21519 exit signal Segmentation fault (11)
194
+
195
+ [Wed Feb 03 18:30:15 2016] [notice] child pid 21455 exit signal Segmentation fault (11)
196
+
197
+ [Wed Feb 03 18:31:15 2016] [notice] child pid 21376 exit signal Segmentation fault (11)
198
+
199
+
200
+
201
+
202
+
203
+ ↓無かったPID
204
+
205
+ 21521
206
+
207
+ 21444
208
+
209
+ 21403
210
+
211
+ 21453
212
+
213
+ 21525
214
+
215
+
216
+
217
+ ```
218
+
219
+
220
+
221
+ また、topコマンドで今生きているPIDをエラーログから探しても見つかりませんでした。(これは当たり前ですかね…)
222
+
223
+
224
+
225
+
226
+
227
+ サイトのアプリケーション動作自体は普通に動いている、サイトアクセスの増加にともなってエラーログも増える、ということを踏まえると、このエラーはhttpdプロセスが終了する時に発生しているのでは、という気がしてきました。
228
+
229
+
230
+
231
+
232
+
233
+ どなたか、ご意見伺えますと幸いです。

2

説明追記

2016/02/03 10:17

投稿

snic518
snic518

スコア39

test CHANGED
File without changes
test CHANGED
@@ -122,6 +122,10 @@
122
122
 
123
123
 
124
124
 
125
+ プロセスはhttpdで間違い無さそうなのですが、やはり普通にサイトは動作しているようで、
126
+
127
+ このエラーが発生した時にユーザーに障害が発生しているということでもなさそうです。
128
+
125
129
  キャッシュ関連の動作(Opchaceなど?)が関連しているのかもと思いましたが、正体がわかりません…。
126
130
 
127
131
 

1

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

2016/02/03 03:10

投稿

snic518
snic518

スコア39

test CHANGED
File without changes
test CHANGED
@@ -87,3 +87,55 @@
87
87
 
88
88
 
89
89
  よろしくお願いいたします。
90
+
91
+
92
+
93
+
94
+
95
+ ---
96
+
97
+
98
+
99
+ 追記です。
100
+
101
+
102
+
103
+ エラーログの出方ですが、HTTPアクセスの量に応じてログも増えているような傾向があるのですが、いっぺんに3プロセスほどまとまって落ちたり、完全にHTTPアクセスと同期したエラーではなさそうに思えます。
104
+
105
+
106
+
107
+ [Wed Feb 03 11:45:07 2016] [notice] child pid 11648 exit signal Segmentation fault (11)
108
+
109
+ [Wed Feb 03 11:45:07 2016] [notice] child pid 11651 exit signal Segmentation fault (11)
110
+
111
+ [Wed Feb 03 11:45:07 2016] [notice] child pid 11662 exit signal Segmentation fault (11)
112
+
113
+ [Wed Feb 03 11:45:08 2016] [notice] child pid 11664 exit signal Segmentation fault (11)
114
+
115
+ [Wed Feb 03 11:45:10 2016] [notice] child pid 11658 exit signal Segmentation fault (11)
116
+
117
+ [Wed Feb 03 11:46:40 2016] [notice] child pid 11628 exit signal Segmentation fault (11)
118
+
119
+ [Wed Feb 03 11:46:40 2016] [notice] child pid 11686 exit signal Segmentation fault (11)
120
+
121
+ [Wed Feb 03 11:46:40 2016] [notice] child pid 11704 exit signal Segmentation fault (11)
122
+
123
+
124
+
125
+ キャッシュ関連の動作(Opchaceなど?)が関連しているのかもと思いましたが、正体がわかりません…。
126
+
127
+
128
+
129
+ 他、関連するかはわからないですが起きている事象としては、MySQLのAborted clientsが似たようなペースで増えています。
130
+
131
+ これも、PHPアップデート前は発生していませんでした。
132
+
133
+
134
+
135
+
136
+
137
+ どなたか、ご助言いただけますと幸いです。
138
+
139
+
140
+
141
+ よろしくお願いいたします。