質問編集履歴
7
サーバーのワーカープロセスについて追記を行いました。
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -171,4 +171,38 @@
|
|
|
171
171
|
|
|
172
172
|
|
|
173
173
|
ただ、どちらも対処療法の領域をでておらず、
|
|
174
|
-
原因の特定に至っていないためまだ調査中と言った感じです。
|
|
174
|
+
原因の特定に至っていないためまだ調査中と言った感じです。
|
|
175
|
+
|
|
176
|
+
### ワーカープロセスについて
|
|
177
|
+
今回のことで初めて調べたのであっているかわかりませんがご了承ください。
|
|
178
|
+
nginx,gunicorn共にすべてのサーバーで同じ設定を行っています。
|
|
179
|
+
サーバーのスペックも同スペックで作成しています。
|
|
180
|
+
|
|
181
|
+
まずこちらのサイトを参考にCPUや最大プロセス数を調べたところ
|
|
182
|
+
http://www.crystalsnowman.com/?p=344
|
|
183
|
+
|
|
184
|
+
CPU : 1
|
|
185
|
+
最大プロセス数 ： 1024
|
|
186
|
+
|
|
187
|
+
とわかりました。
|
|
188
|
+
また、nginxにはワーカープロセスについての設定を行って無い状態でした。
|
|
189
|
+
|
|
190
|
+
gunicornでは以下の設定は行っていました。
|
|
191
|
+
``
|
|
192
|
+
workers = multiprocessing.cpu_count() * 2 + 1
|
|
193
|
+
worker_class = 'sync'
|
|
194
|
+
worker_connections = 1000
|
|
195
|
+
max_requests = 0
|
|
196
|
+
``
|
|
197
|
+
|
|
198
|
+
以下は動いているnginxとgunicornのプロセスを確認したものです。
|
|
199
|
+
```
|
|
200
|
+
[ec2-user@ip-xxx-xx-xx-xx ~]$ ps aux |grep nginx |grep -v grep
|
|
201
|
+
root 17576 0.0 0.1 58088 1080 ? Ss 11:58 0:00 nginx: master process nginx
|
|
202
|
+
ec2-user 17578 0.0 0.4 58600 4756 ? S 11:58 0:00 nginx: worker process
|
|
203
|
+
[ec2-user@ip-xxx-xx-xx-xx ~]$ ps aux |grep gunicorn |grep -v grep
|
|
204
|
+
ec2-user 17614 0.0 2.1 202156 22332 ? S 11:58 0:01 /home/ec2-user/.pyenv/versions/3.5.2/bin/python3.5 /home/ec2-user/.pyenv/versions/3.5.2/bin/gunicorn run:app --config guniconf.py
|
|
205
|
+
ec2-user 17646 0.4 2.5 223292 25996 ? S 11:58 0:44 /home/ec2-user/.pyenv/versions/3.5.2/bin/python3.5 /home/ec2-user/.pyenv/versions/3.5.2/bin/gunicorn run:app --config guniconf.py
|
|
206
|
+
ec2-user 17647 0.3 2.5 223296 26000 ? S 11:58 0:38 /home/ec2-user/.pyenv/versions/3.5.2/bin/python3.5 /home/ec2-user/.pyenv/versions/3.5.2/bin/gunicorn run:app --config guniconf.py
|
|
207
|
+
ec2-user 17648 0.4 2.5 223248 26004 ? S 11:58 0:41 /home/ec2-user/.pyenv/versions/3.5.2/bin/python3.5 /home/ec2-user/.pyenv/versions/3.5.2/bin/gunicorn run:app --config guniconf.py
|
|
208
|
+
```
|
6
修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -162,7 +162,7 @@
|
|
|
162
162
|
InfoサーバーやDataサーバーから取得するデータ量を減少させたて、
|
|
163
163
|
タイムアウトまでの時間を伸ばすことでほぼ502エラーが出ないことが確認できました。
|
|
164
164
|
一応以前は502エラーが発生していた時以上にはアクセスを繰り返してもエラーは発生しませんでした。
|
|
165
|
-
例としては
|
|
165
|
+
例としては 10プロセスから 10/s で 各1千回リクエストを飛ばすと行ったことをしましたが
|
|
166
166
|
エラーは発生せずに終えることができました。
|
|
167
167
|
|
|
168
168
|
また、UserサーバーからInfoサーバーにリクエストを飛ばした際に
|
5
メモリに負荷をかけてリクエストの結果 と 仕様と現在の状況について追記しました。
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -123,4 +123,52 @@
|
|
|
123
123
|
Mem: 995 871 123 0 32 682
|
|
124
124
|
-/+ buffers/cache: 157 838
|
|
125
125
|
Swap: 0 0 0
|
|
126
|
-
```
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
### 追記4：メモリに負荷をかけてリクエストの結果
|
|
129
|
+
|
|
130
|
+
stress コマンドでメモリに負荷をかけて
|
|
131
|
+
```
|
|
132
|
+
stress --vm 2 --vm-bytes 400M --timeout 10m
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
10のプロセスから各1000回づつ、10/sでリクエストの送信を行っている状態での
|
|
136
|
+
vmstatコマンドの結果です。
|
|
137
|
+
|
|
138
|
+
```
|
|
139
|
+
2017/01/26 11:05:25 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
|
|
140
|
+
2017/01/26 11:05:25 r b swpd free buff cache si so bi bo in cs us sy id wa st
|
|
141
|
+
2017/01/26 11:05:25 2 0 0 291484 4024 18948 0 0 10 25 77 85 1 1 98 0 0
|
|
142
|
+
2017/01/26 11:05:26 2 0 0 266260 4032 18940 0 0 0 48 265 298 13 87 0 0 0
|
|
143
|
+
2017/01/26 11:05:27 2 0 0 261168 4032 18940 0 0 0 0 251 258 16 84 0 0 0
|
|
144
|
+
2017/01/26 11:05:28 3 0 0 179840 4044 20852 0 0 1940 0 1979 1332 32 68 0 0 0
|
|
145
|
+
|
|
146
|
+
...省略
|
|
147
|
+
```
|
|
148
|
+
|
|
149
|
+
メモリに負荷をかけていない状態ではcpu の id に余裕がありましたが、
|
|
150
|
+
負荷をかけた状態では上記のようになっています。
|
|
151
|
+
|
|
152
|
+
### 仕様について追記
|
|
153
|
+
|
|
154
|
+
nginxを起動後、gunicornを起動させて
|
|
155
|
+
その状態でずっと稼働しっぱなしにして動かしています。
|
|
156
|
+
|
|
157
|
+
そして、問題の502が起きるのは、しばらくアクセスを繰り返した後に発生し始めること
|
|
158
|
+
アクセスするたびにメモリが減っていく様子が確認できたことからそこら辺に原因があるかもしれないと思っています。
|
|
159
|
+
|
|
160
|
+
### 現在の状況
|
|
161
|
+
|
|
162
|
+
InfoサーバーやDataサーバーから取得するデータ量を減少させたて、
|
|
163
|
+
タイムアウトまでの時間を伸ばすことでほぼ502エラーが出ないことが確認できました。
|
|
164
|
+
一応以前は502エラーが発生していた時以上にはアクセスを繰り返してもエラーは発生しませんでした。
|
|
165
|
+
例としては 5プロセスから 10/s で 各5千回リクエストを飛ばすと行ったことをしましたが
|
|
166
|
+
エラーは発生せずに終えることができました。
|
|
167
|
+
|
|
168
|
+
また、UserサーバーからInfoサーバーにリクエストを飛ばした際に
|
|
169
|
+
正常な結果が得られるまでリクエストを飛ばすことで、無理やり押し通すことが出来るのも確認しました。
|
|
170
|
+
（これはコメントアウトした状態で検証しています。）
|
|
171
|
+
|
|
172
|
+
|
|
173
|
+
ただ、どちらも対処療法の領域をでておらず、
|
|
174
|
+
原因の特定に至っていないためまだ調査中と言った感じです。
|
4
追記3:メモリ周りが怪しそうでした
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -110,4 +110,17 @@
|
|
|
110
110
|
そして、502エラーが発生するまで無限ループを行うようスクリプトを準備し
|
|
111
111
|
それを12個ほどcmdから実行しています。
|
|
112
112
|
現在30分ほど経ちましたが今のところ502エラーは発生していません。
|
|
113
|
-
AWSでも同じことをして試してみます。
|
|
113
|
+
AWSでも同じことをして試してみます。
|
|
114
|
+
|
|
115
|
+
### 追記3：メモリが怪しそうです
|
|
116
|
+
free コマンドでメモリの使用量を確認したところ以下のように表示されました。
|
|
117
|
+
また、GETを繰り返すたびにMem-usedの値が上がっていくのが確認できました。
|
|
118
|
+
Mem-cachedはすぐには上がりませんでしたがココらへんについてもう少し深く調査してみようと思います。
|
|
119
|
+
|
|
120
|
+
```
|
|
121
|
+
[ec2-user@ip-172-31-29-13 ~]$ free -m
|
|
122
|
+
total used free shared buffers cached
|
|
123
|
+
Mem: 995 871 123 0 32 682
|
|
124
|
+
-/+ buffers/cache: 157 838
|
|
125
|
+
Swap: 0 0 0
|
|
126
|
+
```
|
3
Dockerで同じような状況を作って試してみました。
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -97,4 +97,17 @@
|
|
|
97
97
|
キャッシュは作られていませんでした。（設定もしてないです）
|
|
98
98
|
|
|
99
99
|
また現在サーバーの再起動や何やらは切ってある状態で試しているため
|
|
100
|
-
もし停止したら停止しっぱなしになります。
|
|
100
|
+
もし停止したら停止しっぱなしになります。
|
|
101
|
+
|
|
102
|
+
### 追記2
|
|
103
|
+
|
|
104
|
+
Dockerで同じような状況を作って試してみました。
|
|
105
|
+
DockerでMySQLサーバーを立てて、
|
|
106
|
+
CentOSのサーバーを立てて、
|
|
107
|
+
AWSのEC2インスタンスとRDSインスタンスと同じ内容を詰め込んで
|
|
108
|
+
Docker内でやり取りさせてみました。
|
|
109
|
+
|
|
110
|
+
そして、502エラーが発生するまで無限ループを行うようスクリプトを準備し
|
|
111
|
+
それを12個ほどcmdから実行しています。
|
|
112
|
+
現在30分ほど経ちましたが今のところ502エラーは発生していません。
|
|
113
|
+
AWSでも同じことをして試してみます。
|
2
情報を追記しました。
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -76,4 +76,25 @@
|
|
|
76
76
|
RDSインスタンス
|
|
77
77
|
MySQL
|
|
78
78
|
|
|
79
|
-
APIの取得の確認は主にChromeで行っています。
|
|
79
|
+
APIの取得の確認は主にChromeで行っています。
|
|
80
|
+
|
|
81
|
+
### 追記、試したこと1
|
|
82
|
+
gunicornの設定の下記2つを変更しての動作を確認してみました。
|
|
83
|
+
変更したところインスタンスを作成してから
|
|
84
|
+
約1時間ほどで適当に百数回以上GETを試しましたが502エラーは発生しませんでした。
|
|
85
|
+
しかし、時間がたってからGETを行ったところ502が発生。
|
|
86
|
+
以降発生するのは変わりませんが頻度は少しだけ減ったように感じます。
|
|
87
|
+
（1/7から1/10くらいに変化）
|
|
88
|
+
|
|
89
|
+
```
|
|
90
|
+
timeout = 30 -> 3000
|
|
91
|
+
keepalive = 2 -> 20
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
### 追記
|
|
95
|
+
|
|
96
|
+
nginxのキャッシュが溜まっているとかそういう面について調べましたが
|
|
97
|
+
キャッシュは作られていませんでした。（設定もしてないです）
|
|
98
|
+
|
|
99
|
+
また現在サーバーの再起動や何やらは切ってある状態で試しているため
|
|
100
|
+
もし停止したら停止しっぱなしになります。
|
1
設定周りの情報を追記
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -38,6 +38,23 @@
|
|
|
38
38
|
urllib.error.URLError: <urlopen error [Errno 111] Connection refused>
|
|
39
39
|
```
|
|
40
40
|
|
|
41
|
+
###設定周りの情報
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
gunicornの設定です。
|
|
45
|
+
関係ありそうな部分だけ抜粋しました。
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
workers = multiprocessing.cpu_count() * 2 + 1
|
|
49
|
+
worker_class = 'sync'
|
|
50
|
+
worker_connections = 1000
|
|
51
|
+
max_requests = 0
|
|
52
|
+
timeout = 30
|
|
53
|
+
keepalive = 2
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
nginxの.confではアクセス数やレスポンスまでの時間制限などの設定は行っていないです。
|
|
57
|
+
|
|
41
58
|
### 試したこと
|
|
42
59
|
|
|
43
60
|
Connection refusedは必ず発生するわけではありませんでした。
|