nginxで高負荷時に「upstream timed out (110: Connection timed out) 」とかエラーがでる
■nginxで稀にエラーが発生して500系のエラーがでる 以下のようなエラーメッセージが吐き出されていました。APIサーバで発生していたので、結構たくさんのアクセス(1秒間に1500～2000アクセス）あったときに本当に稀に出ていました。 upstream timed out (110: Connection timed out) while reading response header from upstream どうにも、バックエンドのphp-fpmに接続して、戻りを待っているときにタイムアウトが発生してnginx側から接続を切っているようでした。一旦タイムアウトの時間を伸ばして対応することにしました。 ■暫定対応 以下の設定をnginxの設定のところに追加しています。60秒がデフォルトでタイムアウトが発生していたようですね。一旦、暫定対応で時間を伸ばします。 fastcgi_rea
インフラ苦手な人が知っておくといい、Webサイトにつながらない障害パターンと解決方法 - Qiita
みなさん、障害対応してますか？ 今回はインフラをある程度経験していれば、なんとなく当たりがつくような、サイトにアクセス出来ない時のパターンをいくつか紹介します。 パターンを知っているだけで調査のあたりの付け方が早くなるので、いつかきっと役に立つ日がくるでしょう。 インフラ: AWS Webアプリケーション: Rails Webサーバ: Nginx アプリケーションサーバ: Unicorn or Puma 調査のキモ まず最初に調査のキモについて。 ここだけ押さえておけば大体なんとかなる、きっと。 ログを見ること エラーログはシステムのダイイングメッセージ。 ログに全ての答えがあります。 まずはWebサーバ、アプリケーション、各ミドルウェアのログを良く見ましょう。 どこまでは正常に動作して、どこでエラーが発生したのかの原因を切り分けやすくなります。 HTTPステータスを見ること chrome
nginx 今日あったトラブルシューティング
現象 とあるページだけ 404 になる. 大丈夫な時もある 原因 nginx をリバースプロキシとして使い, 後ろに starman でアプリ (UI) のプロセスが立っている構成. ある 1 ページは処理が重く, nginx 側の proxy_read_timeout に引っかかって nginx 側で切られていた. その重い処理のページは過去しばらくの期間のレポートを取得するようなもので, 時間がかかることは承知のもの proxy_read_timeout は他のアプリと共通設定のため, かなり辛めの数値になっていた 対応 proxy_read_timeout を伸ばす puppet に今回のアプリ用の設定をたてて, デフォルトの設定を使わないように ポイント 特定のページだけ 404 だったので, アプリのルーティングまわりがおかしいのかと推定, コントローラーあたりのコミットログを見
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
