5

私のウェブサイトは常にいくつかのページにぶら下がっていると人々は主張し続けています. ユニコーンの stderr ログを確認したところ、次のような多くのタイムアウト エラーが見つかりました。

E, [2013-08-14T09:27:32.236478 #30027] ERROR -- : worker=5 PID:11619 timeout (601s > 600s), killing
E, [2013-08-14T09:27:32.252252 #30027] ERROR -- : reaped #<Process::Status: pid=11619,signaled(SIGKILL=9)> worker=5
I, [2013-08-14T09:27:32.266141 #4720]  INFO -- : worker=5 ready

みたいなエラーメッセージが多いです。

次に、Rails のプロダクション ログに移動し、ユニコーンのエラー時間から 601 秒を引いた値を検索して、正確なリクエストを見つけます。これらのタイムアウト リクエストは、ページ レンダリング フェーズですべて停止します。これらのリクエストのSQLはすでに完了しています。それは決して終わりません：

Processing by XXXController#index as HTML
  Rendered xxx/index.html.erb within layouts/application (41.4ms)
  Rendered shared/_sidebar.html.erb (200.9ms)

完全ではありません。これらのリクエストのほとんどは正常に処理されました。なぜランダムな時間にそこにたむろするのかわかりません。

何が原因なのかわかりません。ユニコーンワーカーがタイムアウトする本当の理由を見つける方法の手がかりを誰か教えてもらえますか?

アップデート：

NSC を使用して、リクエストとレスポンスを unicorn に転送しました。また、タイムアウトの問題を改善するために、NSC とユニコーンの間に nginx を追加しました。ユニコーン ワーカーのタイムアウトが引き続き発生し、各タイムアウトが nginx エラー ログの nginx アップストリーム タイムアウトと一致することが判明しました。

ユニコーンのTCP接続に何らかのボトルネックがあるかどうかは誰にもわかりませんか?

4

1 に答える 1

2

Rack::Timeout を使用して、ユニコーンの前にタイムアウトします。Unicorn タイムアウトは kill -9 を使用しますが、それで何かを行う方法が得られるとは思いません。

于 2015-06-20T00:44:38.113 に答える