質問編集履歴
11
追記
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
環境のアップデートについて追記
test
CHANGED
File without changes
|
test
CHANGED
@@ -4,7 +4,7 @@
|
|
4
4
|
|
5
5
|
yum updateでphp7.0.2にアップデートしました。
|
6
6
|
|
7
|
-
サーバー上のアプリケーションは、見た目上は特に不具合なく動いている
|
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
|
-
|
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
|
-
>
|
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
|
-
[
|
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の結果追記
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
|
-
エラーログ
|
104
|
-
|
105
|
-
|
106
|
-
|
107
|
-
|
108
|
-
|
109
|
-
|
110
|
-
|
111
|
-
[
|
112
|
-
|
113
|
-
|
114
|
-
|
115
|
-
|
116
|
-
|
117
|
-
|
118
|
-
|
119
|
-
|
120
|
-
|
121
|
-
|
122
|
-
|
123
|
-
|
124
|
-
|
125
|
-
|
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
|
-
|
146
|
-
|
147
|
-
|
148
|
-
|
149
|
-
|
150
|
-
|
151
|
-
|
152
|
-
|
153
|
-
|
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を1個1個の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捜査について追記
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
進捗です。
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
進捗について書きました。
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
誤字修正
test
CHANGED
File without changes
|
test
CHANGED
@@ -292,7 +292,7 @@
|
|
292
292
|
|
293
293
|
|
294
294
|
|
295
|
-
思いたる節としては、諸事情でPHPのインストールユーザーとApacheの実行ユーザーに違いがあるため、sess
|
295
|
+
思いあたる節としては、諸事情でPHPのインストールユーザーとApacheの実行ユーザーに違いがあるため、sesston_save_pathの所有者がそのままだとセッションの書き込みが出来ないために、そのディレクトリの所有者をchownしている点です。
|
296
296
|
|
297
297
|
|
298
298
|
|
4
調査進捗について追記。
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
ログの詳細な調査を追加してみました。
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
説明追記
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
エラーログの傾向について追記しました。
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
|
+
よろしくお願いいたします。
|