よく聞かれる質問 (FAQ)¶
全ディスクがファイルシステムにマウントされている場合、キャッシュ用の raw ディスクの作成はどうすればいいですか？¶
Create a large file on filesystem (with dd(1)) and mount it as loopback device. This is accomplished with losetup(8) on Linux, and mdconfig(8) on FreeBSD.
ディスク I/O エラーはキャッシュにどのように影響し、キャッシュディスクが動かなくなったとき Traffic Server は何を行いますか？¶
ディスクドライブが I/O 操作に連続して五回失敗すると、Traffic Server はドライブがアクセス不能とみなしキャッシュからディスク全体を外します。通常のキャッシュ操作は Traffic Server の他のすべてのディスクドライブで継続します。
Traffic Server が大きいオブジェクトをダウンロード中にクライアントが接続を閉じた場合、オブジェクトはキャッシュに保存されますか？¶
HTTP の処理中にクライアントが接続を閉じたとき、 Traffic Server は background fill feature を使ってオリジンサーバーからのオブジェクトのダウンロードを継続します。 proxy.config.http.background_fill_active_timeout と proxy.config.http.background_fill_completed_threshold の設定に従ってダウンロードを継続します。
Traffic Server は Java アプレット、 JavaScript のブログラムもしくは VBScript のようなその他のアプリケーションファイルをキャッシュできますか？¶
はい、 Traffic Server は Java アプレット、 JavaScript のプログラム、 VBScript 、その他の実行形式オブジェクトを保管、配信することができます。キャッシュから配信する際は HTTP オブジェクトのフレッシュネスとキャッシュしてよいかの判定ルールに従います。 Traffic Server がアプレット、スクリプトやプログラムを実行することはありません。これらのオブジェクトはもっぱらクライアントサイド (オブジェクトへのリクエストを送出したシステム) で実行され、サーバ上では実行されません。
Squid や Netscape フォーマットのログファイルで、キャッシュ結果コードは何を意味していますか？¶
This is described in detail in the Logging Cache Results documentation.
Traffic Server はホストデータベース内のエントリーが一定期間使われなかった場合にそれらを更新しますか？¶
デフォルトでは、Traffic Server のホストデータベースはネームサーバーによりセットされた time-to-live (ttl) を監視します。ネームサーバーによってセットされた ttl を無視して指定した設定を使用するように Traffic Server を再設定することも可能です。もしくは、ネームサーバーによってセットされた ttl の値と Traffic Server の設定値を比較し、低いものか高いものかどちらかを使用するように Traffic Serverを設定することも可能です。
より詳細な情報は proxy.config.hostdb.ttl_mode を参照してください。
カスタムレスポンスメッセージの見た目を画像やアニメーション GIF や Java アプレットを使用して改善することはできますか？¶
いいえ、Traffic Server はクライアントに一つのテキストもしくは HTML ドキュメントしか返せません。次善策ではありますが、カスタマイズレスポンスページで Web サーバー上にある画像、アニメーション GIF 、Java アプレット、その他テキストではないオブジェクトの参照を提供することは可能です。HTML ドキュメントに画像を追加するのと同じ方法で body_factory テンプレートファイルにリンクを追加してください (例、SRC 属性に完全な URL を指定するなど) 。
Traffic Server はフォワードプロキシーモードとリバースプロキシーモードを同時に実行できますか？¶
はい。リバースプロキシーモードを有効にしている場合、 Traffic Server は受け取ったリクエストを remap.config 内のマッピングルールに従ってリマップします。マッピングルールにマッチしないその他のリクエストはフォワードプロキシーモードで配信されます。
リバースプロキシーだけのモード (マップルールにマッチしないリクエストには Traffic Server は応えなくなります) にしたい場合は、 records.yaml の設定変数 proxy.config.url_remap.remap_required を 1 にしなければなりません。
どうやってフォワードプロキシーモードを有効するのですか？¶
フォワードプロキシー を参照してください。
どうやって Via: ヘッダーコードを解釈するのですか？¶
The Via header string can be decoded with the Via Decoder Ring.
The Via header is an optional HTTP header added by Traffic Server and other HTTP proxies. If a request goes through multiple proxies, each one appends its Via header content to the end of the existing Via header. Via header content is for general information and diagnostic use only and should not be used as a programmatic interface to Traffic Server. The header is cached by each intermediary with the object as received from its downstream node. Thus, the last node in the list to report a cache hit is the end of the transaction for that specific request. Nodes reported earlier were from a previous transaction.
Via ヘッダーの形式は
Via: <protocol> <proxyname> (<product/version> [<via-codes>])
値 |
意味 |
|---|---|
<protocol> |
HTTP リクエストのスキームとバージョン |
<proxyname> |
プロキシーサーバーの設定名 |
<product/version> |
Traffic Server のプロダクト名とバージョン |
<via-codes> |
HTTP リクエストをプロキシーが処理した際のステータス情報を表すアルファベットのコードからなる文字列 |
例えば: Via: HTTP/1.0 storm (Traffic-Server/4.0.0 [cMs f ])
[u lH o f pS eN] キャッシュヒット
[u lM oS fF pS eN] キャッシュミス
[uN l oS f pS eN] no-cache のためオリジンサーバーから取得
短いステータスコードは、下記に説明している完全なステータスコードのリストにあるキャッシュのルックアップ、サーバー情報、キャッシュフィル情報を示します。長いステータスコードは古い、商用製品版の Traffic Server で提供されていたもので、 verbose_via_str 変数を設定することで取得可能です。 via-code の文字は [<request results>:<proxy op>] という形式を取り、 <request results> はクライアントのリクエストの結果についてのステータス情報を表し、 <proxy op> はリクエスト処理中に実行されたプロキシーの処理についての情報を表します。完全な via-code のステータス形式は
[u<client-info> c<cache-lookup> s<server-info> f<cache-fill> p<proxy-info> e<error-codes> : t<tunnel-info>c<cache-type><cache-lookup-result> p<parent-proxy> s<server-conn-info>]
u client-info¶
クライアントから受信したリクエストヘッダー。値は以下のいずれかです:
値 |
意味 |
|---|---|
C |
クッキー |
E |
リクエスト内にエラー |
I |
If Modified Since (IMS) |
N |
no-cache |
S |
(条件無しの) シンプルなリクエスト |
c cache-lookup¶
Traffic Server が URL に対してキャッシュをルックアップした結果。値は以下のいずれかです:
値 |
意味 |
|---|---|
A |
キャッシュに存在したが受理できない (キャッシュ「ミス」) |
H |
キャッシュに存在して新鮮 (キャッシュ「ヒット」) |
M |
ミス (キャッシュ「ミス」) |
R |
キャッシュに存在して、 RAM 上にあり新鮮 (キャッシュ「ヒット」) |
S |
キャッシュに存在したが、新鮮でない (キャッシュ「ミス」) |
blank |
キャッシュのルックアップが実行されなかった |
s server-info¶
オリジンサーバーから受け取ったレスポンス情報。値は以下のいずれかです:
値 |
意味 |
|---|---|
E |
レスポンス内にエラー |
N |
変更されていなかった |
S |
配信された |
blank |
オリジンサーバーへの接続は不要だった |
f cache-fill¶
ドキュメントをキャッシュに書いた結果。値は以下のいずれかです:
値 |
意味 |
|---|---|
D |
キャッシュされたコピーが削除された |
U |
古いキャッシュのコピーを上書きした |
W |
キャッシュに書き込んだ (新しいコピー) |
blank |
キャッシュへの書き込みは実行されなかった |
p proxy-info¶
プロキシー処理結果。値は以下のいずれかです:
値 |
意味 |
|---|---|
N |
変更されていなかった |
R |
オリジンサーバーで再検証された |
S |
配信された |
e error-codes¶
値は以下のいずれかです:
値 |
意味 |
|---|---|
A |
認証失敗 |
C |
サーバーへの接続に失敗した |
D |
DNS失敗 |
L |
loop detected |
F |
リクエストが禁止された |
H |
ヘッダーのシンタックスが受理されなかった |
N |
エラー無し |
R |
キャッシュの読み込みエラー |
M |
moved temporarily |
S |
サーバー関連エラー |
T |
接続タイムアウト |
: = プロキシーのリクエスト情報と操作詳細コードを分離します
t tunnel-info¶
プロキシーのみのサービス処理。値は以下のいずれかです:
値 |
意味 |
|---|---|
A |
トンネルの認証 |
F |
ヘッダーフィールド (If-Range ヘッダーが存在するなど) が原因でトンネリング |
M |
メソッド (例: CONNECT) が原因でトンネリング |
N |
no forward が原因でトンネリング |
O |
キャッシュがオフにされていたためトンネリング |
U |
URL が原因で (URL がダイナミックコンテンツを示唆していた) トンネリング |
blank |
トンネリング無し |
c cache-type and cache-lookup¶
キャッシュの結果の値 (2文字)
キャッシュタイプの文字は以下のいずれかです
値 |
意味 |
|---|---|
C |
cache |
L |
cluster (使用されていません) |
P |
parent |
S |
server |
blank |
キャッシュがミスしたかキャッシュルックアップがされなかった |
キャッシュルックアップの結果の文字は以下のいずれかです:
値 |
意味 |
|---|---|
C |
キャッシュはヒットしたが、設定が再検証を強制した |
D |
キャッシュはヒットしたが、メソッドが再検証を強制した (例: anonymousでないftp) |
H |
キャッシュヒット |
I |
条件付きミス (クライアントが条件付きリクエストを送った、キャッシュ内に新鮮なドキュメントがあった、 304 を返した) |
K |
クッキーによるミス |
M |
キャッシュミス (URL がキャッシュに無かった) |
N |
条件付きヒット (クライアントが条件付きリクエストを送った、キャッシュ内に新鮮なドキュメントがあった、 304 を返した) |
S |
キャッシュヒットしたが、期限切れだった |
U |
キャッシュはヒットしたが、クライアントが再検証を強制した (例: Pragma: no-cache) |
blank |
キャッシュルックアップ無し |
p parent-proxy¶
ペアレントプロキシーへの接続状態
値 |
意味 |
|---|---|
F |
接続オープンに失敗した |
S |
接続オープンに成功した |
blank |
ペアレントプロキシー無し |
s server-conn-info¶
オリジンサーバーへの接続状態
値 |
意味 |
|---|---|
F |
接続オープンに失敗した |
S |
接続オープンに成功した |
blank |
オリジンサーバーへの接続無し |
トラブルシューティングの秘訣¶
スループットの統計が不正確¶
Traffic Server はスループットの統計をオブジェクト全体を転送した後で更新します。大きいファイルではバイト数が転送の終わりで鋭く上昇します。オブジェクトを転送するのに数分かかることもありますが完全な転送バイト数は直近の 10 秒間となります。この不正確さは負荷が軽い場合に顕著です。重い負荷はより正確な統計をもたらします。
You are unable to execute Traffic Control commands¶
traffic_ctl commands do not execute under the following conditions:
- When the traffic_server process is not running
traffic_ctl needs traffic_server to be running, the former needs the later to be running in order to connect to the jsonrpc endpoint. You can check this JSONRPC Endpoint for more information.
- When :program:`traffic_ctl` is unable to locate the jsonrpc socket.
The program needs to know where the path is located, this could be the default build folder or the one specified by the runroot file.
ウェブブラウザーが 'data missing' というメッセージのエラードキュメントを表示します¶
次のようなメッセージがウェブブラウザーに表示されるかもしれません。
Data Missing
This document resulted from a POST operation and has expired from the cache. You can repost the form data to recreate the document by pressing the Reload button.
これはウェブブラウザの問題であり、 Traffic Server に固有の (あるいは Traffic Server によって引き起こされた) 問題ではありません。ウェブブラウザはクライアントシステム上のメモリやディスクに Traffic Server とは別にローカルキャッシュを維持しています。 "documents have expired from cache" というメッセージはブラウザのローカルキャッシュに言及しているものであり Traffic Server に言及しているわけではありません。ウェブブラウザ上にこのようなメッセージを表示させるような Traffic Server のメッセージや状態は存在しません。
Traffic Server がどのウェブサイトも解決しません¶
ブラウザーはホストへ接続しようとしてタイムアウトしたことを次のメッセージで示しています。
The document contains no data; Try again later, or contact the server's Administrator...
システムが正しく設定されていることと Traffic Server が名前解決ファイルを読み込めるを確認してください。
nslookup コマンドでサーバーが DNS 問い合わせを解決できるか ( 例えば、
nslookup www.myhost.com) 確認してください。resolv.conf(5) ファイルが DNS サーバーの妥当な IP アドレスを含んでいるか確認してください。
いくつかのシステムでは、resolv.conf(5) ファイルが読み込めないかネームサーバーの項目がない場合、オペレーティングシステムは
localhostをネームサーバーとして使用します。しかし Traffic Server はこの慣習を使用しません。localhostをネームサーバーとして使用したい場合は、''127.0.0.1`` もしくは0.0.0.0へのネームサーバーの項目を resolv.conf(5) ファイルに追加しなければ成りません。Traffic Server のユーザアカウントが resolv.conf(5) ファイルを読み取るパーミションを持っているか確認してください。もし持っていなければファイルのパーミションを
rw-r--r--(644) に変更してください。
システムログファイル内の 'Maximum document size exceeded' というメッセージ¶
次のメッセージがシステムログファイルに現れます。
WARNING: Maximum document size exceeded
A requested object was larger than the maximum size allowed in the
Traffic Server cache, so Traffic Server provided proxy service for the
oversized object but did not cache it. To set the object size limit for
the cache, modify the proxy.config.cache.max_doc_size
variable in the records.yaml file. If you do not want to limit the
size of objects in the cache, then set the document size
to 0 (zero).
Traffic Server は実行中だがログファイルが作られない¶
Traffic Server は記録する情報があるときだけイベントログファイルに出力します。 Traffic Server がアイドル状態なら、ログファイルが存在しない可能性があります。
Traffic Server がアイドル状態でないのに、ログファイルが作成されていない場合は、以下を確認してください :
正しいディレクトリを見ているかを確認してください。デフォルトでは Traffic Server はログファイルを
logsディレクトリに作成します。これはrecords.yamlのproxy.config.log.logfile_dirで変更可能です。ログディレクトリが Traffic Server のユーザアカウントで読み書き可能なパーミションを持っていることを確認してください。ログディレクトリが正しいパーミションを持っていない場合は、 traffic_server はログファイルを開いたり作成することが出来ません。
ログ出力が有効になっているかどうかを
records.yamlのproxy.config.log.logging_enabled変数の値を見て確認してください。ログフォーマットが有効になっているかを確認してください。
records.config内のログ設定セクションの変数を編集して標準またはカスタムのログ形式を選択してください。
Traffic Server がネットワーク接続が多すぎることを示すエラーを表示する¶
デフォルトでは Traffic Server は 8000 のネットワーク接続をサポートします。この数の半分はクライアントとの接続用に確保されており、残りの半分はオリジンサーバーとの接続に確保されています。 クライアントかオリジンサーバーとの接続が設定された全体のリミットの半分の 90% (デフォルトでは 3600) に達すると connection throttle event が発生します。 connection throttle event が発生すると Traffic Server は既存の全ての接続の処理は継続しますが、接続数がその限界を下回るまで新しいクライアントの接続は受け付けなくなります。
Connection throttle event は次の条件で発生します。
- 接続数のスパイク
(あなたが設定した最大接続数を超えるほどの) 多すぎるクライアントリクエストが Traffic Server に同時に届くとき。そのような出来事はたいていは一時的なものであり、あなたの Traffic Server とオリジンのリソースに対してあなたの最大接続数が事前に適切に設定されていれば修正作業は不要です。
- サービスの過負荷
Traffic Server がクライアントのリクエストに応えるよりも速いペースでクライアントのリクエストが届いているとき。これは Traffic Server とオリジンサーバーの間のネットワークの問題、あるいは Traffic Server がクライアントの負荷を処理するためにより多くのメモリ、 CPU 、 キャッシュディスク、または他のリソースを必要とするかもしれないことを示唆しているかもしれません。
必要ならば records.yaml の proxy.config.net.connections_throttle を編集することで Traffic Server がサポートする接続の最大数を調整することが出来ます。
注釈
要求されたクライアントの接続を処理できるのに十分なメモリをシステムが持っていないかぎり、 connection throttle limit を増やさないでください。 RAM が限られたシステムでは throttle limit をデフォルト値より低くする必要があるかもしれません。この変数を最小値 100 より小さい値に設定しないでください。
メモリ不足の兆候¶
高負荷な状態において、 Linux カーネルは RAM を使い切る可能性があります。このメモリの少ない状態はパフォーマンスの低下とその他様々なシステムの問題を引き起こします。事実、 RAM の枯渇 はシステムが豊富な空きスワップ領域を持っていたとしても発生し得ます。
極限のメモリー消耗の兆候はシステムログファイル (/var/log/messages) の次のメッセージを含みます。
WARNING: errno 105 is ENOBUFS (low on kernel memory), consider a memory upgrade
kernel: eth0: can't fill rx buffer (force 0)!
kernel: recvmsg bug: copied E01BA916 seq E01BAB22
メモリーの消耗を防ぐために、システムにもっと RAM を追加するか Traffic Server の負荷を減らしてください。
Config checker¶
Traffic Server supports the below command to validate the config offline, in order to allow the config to be pre-checked for possible service disruptions due to syntax errors:
traffic_server -Cverify_config -D<config_dir>
<config_dir> は検証する設定ファイルの場所です。
オリジンサーバーとの接続タイムアウト¶
デフォルトでは Traffic Server はオリジンサーバーに接続する際に 30 秒でタイムアウトします。オリジンサーバーのパフォーマンスを改善してこのタイムアウトを回避することが出来ない場合は、 records.yaml の proxy.config.http.connect_attempts_timeout をより大きな値に変更することで Traffic Server のオリジンサーバーへの接続のタイムアウトを調整することが出来ます。
Log entries for some transactions are skipped¶
You will see lines like this in the diags log file:
NOTE: Skipping the current log entry for ...
This happens when a log entry is too big to fit in a log buffer. This is often causeed by very long URLs in the entry. You can truncate long URLs using the slice syntax for the URL log field in the log format, for example:
%<pquc[:1000]>
You can also increase the value of proxy.config.log.log_buffer_size, but this can have impacts
on performance and memory usage. Very large values may trigger software bugs. Some production proxies
have run successfully using 26624 as the value for this configuration variable.