質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.01%

Squid-3.5.17ハング事象の解決方法について

解決済

回答 1

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 4,077

ktotsuka

score 10

前提・実現したいこと

標題:Squidハング事象の解決方法について
導入環境(OS):RHELinux6.4
ソフトウェアバージョン:Squid-3.5.17
1CPU(Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz)、メモリ2GB

発生している問題・エラーメッセージ

①Squid-3.5.17をコンパイルインストールし、諸設定を実施、リバースプロキシとして正常に動作することを確認
②サービス起動後、しばらくは正常に動作するが、比較的高頻度で応答を返さなくなってしまう事象が発生。契機は不明。負荷は殆どかけていない。
③応答を返さない状態となった場合、access.logには何も出力されない状態となるが、サービス(プロセス)は落ちていない。
④本事象はsquidデーモンを停止/起動することにより復旧する。
⑤ファイルディスクリプタの設定は/etc/init.d/squid内でsquid起動前に「ulimit -HSn 65536」コマンドを実行していて、特に関連するエラーは出ていない。
⑥cache.logには特にエラーメッセージは何も出ていない。

事象のデバッグ手段、Squid-3.5.17のバグ情報等があるようでしたら、ご教示下さい。
※現在debug_optionsを「ALL,1」で設定し、事象再現待ちの状態です。

【squid.conf】
http_port 80 accel vhost
http_port 8443 accel vhost

reply_header_access Via deny all
reply_header_access X-Cache deny all
reply_header_access X-Squid-Error deny all
reply_header_access Server deny all
reply_header_replace Server CpPrx

visible_hostname Secret
shutdown_lifetime 15 seconds
dead_peer_timeout 30 seconds
request_timeout 60 seconds
httpd_suppress_version_string on
cache deny all

ssl_bump server-first all
sslproxy_cert_error allow all #SSL ERROR: ignore

acl ext_res url_regex -i \.(jpg|jpeg|gif|png|pic|pict|bmp|pbm|ico|mp2|mp3|ogg|wav|snd|aif|aiff|au|swf|flv|mp4|wmw|avi|mpg|mpeg)$
acl ext_dat url_regex -i \.(pdf|exe|dat|data|zip|Z|tar|gz|tgz|bz|bz2)$
http_access deny ext_res
http_access deny ext_dat

acl monitoring src xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx    # DEVPRX monitor

logfile_rotate 365
access_log daemon:/var/log/squid/access.log combined !monitoring

debug_options ALL,1

url_rewrite_program /etc/squid/squid_redirector.pl

acl 名前1 url_regex ^http:接続先URL
cache_peer 接続先ホスト名FQDN 443 0 ssl no-query originserver name=名前1
cache_peer_access 名前1 allow 名前2
※acl/cache_peer/cache_peer_accessを多数定義

補足情報(言語/FW/ツール等のバージョンなど)

最新版Squid-3.5.19にアップデートしてみたいが、事象発生の契機、事象解消の目処が不明のため、許可が頂けない。

以上、よろしくお願いします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • TaichiYanagiya

    2016/06/21 23:35

    cache.log には何かエラーは出ていないでしょうか。
    debug_options でログレベルを上げると何かわかるかもしれませんが、
    ググると disk full とか i-node full でダウンする事例がありますので、慎重に。

    キャンセル

  • ktotsuka

    2016/06/22 16:27 編集

    コメントありがとうございます。
    cache.logには何もエラーが出ていない件、記載を修正しました。
    現在debug_optionsを設定し事象の再現を待っております。
    空き容量については随時チェックするようにしています。

    キャンセル

  • matobaa

    2016/06/25 12:23

    シグナル投げ込んでコアダンプ取ってデバッガに喰わせるとかってやりました?

    キャンセル

  • ktotsuka

    2016/06/27 11:18

    コメントありがとうございます。 コアダンプは取っていません。
    その後、事象が再現しておらず、只今経過観察中です。

    キャンセル

回答 1

check解決した方法

+2

結局、その後3.5.19にアップグレードしました。

しばらくたって再び事象が再発したのですが、ある特定のサイトに接続した時だけ発生する事が判明。
事象発生時のリソース状態を確認したところ、squidのCPU使用率が100%近くなっており、プロセスは生きているものの、以降の応答が返せない状態でした。
※この環境のsquidはリバースプロキシサーバとして使用しています。

cache.logを確認したところ、事象発生以降、squidが無限ループ状態になっていることが確認できました。
そこで、ループする直前に何をしていたか確認したところ、転送先のWebサーバとキャッシュダイジェスト通信を行おうとしていることがわかりました。
キャッシュダイジェスト通信は、保持しているキャッシュのダイジェスト情報を、別のPROXYサーバからもらうための通信で、通常PROXY同士のサーバ間で行うもの...のようです。

別のPROXYサーバと自PROXYサーバの関連付けを行う場合、squid.conf内でcache_peer定義により行うのですが、本環境のように、自PROXYサーバ(リバースプロキシサーバ)(http)から接続先のWebサーバ(https)へ、異なるプロトコルの通信を転送するため場合にも、同じcache_peer定義を使用します。
今回使用している設定は、旧環境のconfをそのまま流用しているため、特に設定内容には問題がない認識でいましたが、キャッシュダイジェスト通信を行うポートは、キャッシュダイジェスト通信を実施しない意図で0としていただけで、「no-digest」設定が入っていませんでした。cache_peer定義に明示的に「no-digest」設定を入れてあげないと、キャッシュダイジェスト通信は行おうとしてしまうようです。
そこで各Webサーバの転送設定(cache_peer定義)全てに「no-digest」オプションを設定し、事象が発生する特定サイトへの接続を実施したところ、無限ループ事象が発生しなくなりました。
正常に接続できていたWebサイトへの接続は、これまでと同様正常に接続できることも確認できました。

正常に接続できていた他のWebサイトへも、キャッシュダイジェスト通信は行おうとしていたと思われるため、なぜ特定サイトへの接続時だけ、無限ループに陥るのかは結局わかりませんでしたが、一旦事象が発生しない状態にはできたので、本件はクローズとさせて頂きます。

ご意見を頂いた皆様方、ありがとうございました。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.01%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る