Q&A
cache.log には何かエラーは出ていないでしょうか。
debug_options でログレベルを上げると何かわかるかもしれませんが、
ググると disk full とか i-node full でダウンする事例がありますので、慎重に。
###前提・実現したいこと
標題：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にアップデートしてみたいが、事象発生の契機、事象解消の目処が不明のため、許可が頂けない。
以上、よろしくお願いします。
回答1件
0
自己解決
結局、その後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サイトへも、キャッシュダイジェスト通信は行おうとしていたと思われるため、なぜ特定サイトへの接続時だけ、無限ループに陥るのかは結局わかりませんでしたが、一旦事象が発生しない状態にはできたので、本件はクローズとさせて頂きます。
ご意見を頂いた皆様方、ありがとうございました。
投稿2016/07/06 01:44
総合スコア12
あなたの回答
tips
プレビュー
