よく聞かれる質問 (FAQ)

全ディスクがファイルシステムにマウントされている場合、キャッシュ用の raw ディスクの作成はどうすればいいですか?

ファイルシステム上に大きなファイルを ( dd(1) を使って ) 作成し、それをループバックデバイスとしてマウントしてください。これは Linux 上では losetup(8) で、Solaris と Illumos 上では lofiadm(1m) 、FreeBSD 上では mdconfig(8) を使って行えます。

ディスク I/O エラーはキャッシュにどのように影響し、キャッシュディスクが動かなくなったとき Traffic Server は何を行いますか?

ディスクドライブが I/O 操作に連続して五回失敗すると、Traffic Server はドライブがアクセス不能とみなしキャッシュからディスク全体を外します。通常のキャッシュ操作は Traffic Server の他のすべてのディスクドライブで継続します。

Traffic Server が大きいオブジェクトをダウンロード中にクライアントが接続を閉じた場合、オブジェクトはキャッシュに保存されますか?

HTTP の処理中にクライアントが接続を閉じたとき、 Traffic Server は background fill feature を使ってオリジンサーバーからのオブジェクトのダウンロードを継続します。 proxy.config.http.background_fill_active_timeoutproxy.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 Squid documentation.

カスタムログファイル内の cqtx フィールドには何が記録されていますか?

  • フォワードプロキシーモード では、 cqtx フィールドは完全なクライアントのリクエストをログファイルに記録します (例: GET http://www.company.com HTTP/1.0)。
  • リバースプロキシーモード では cqtx フィールドはオリジンサーバーのホスト名または IP アドレスを記録します。なぜなら Traffic Server はリクエストを remap.config ファイル内のマッピングルールごとにリクエストをまずリマップを行うからです。

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.config の設定変数 proxy.config.url_remap.remap_required1 にしなければなりません。

どうやってフォワードプロキシーモードを有効するのですか?

フォワードプロキシー を参照してください。

どうやって Via: ヘッダーコードを解釈するのですか?

Via ヘッダーは Via Decoder Ring でデコードできます。

Via ヘッダーは省略可能な HTTP ヘッダーで Traffic Server や他の HTTP プロキシーによって追加されます。リクエストが複数のプロキシーを経由する場合は、それぞれのプロキシーが既存の Via ヘッダーの最後に自分の Via ヘッダーの内容を追加します。 Via ヘッダーの内容は一般情報と診断のみに用いるためのものであり、 Traffic Server へのプログラムのインターフェースとして使用するべきではありません。

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> i<icp-conn-info> 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失敗
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
I icp
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 キャッシュルックアップ無し

i icp-conn-info

ICP の状態

意味
F 接続オープンに失敗した
S 接続オープンに成功した
blank ICP 無し

p parent-proxy

ペアレントプロキシーへの接続状態

意味
F 接続オープンに失敗した
S 接続オープンに成功した
blank ペアレントプロキシー無し

s server-conn-info

オリジンサーバーへの接続状態

意味
F 接続オープンに失敗した
S 接続オープンに成功した
blank オリジンサーバーへの接続無し

HTTP Expect: ヘッダーのサポート

Traffic Server は現在 HTTP/1.1 仕様による Expect: ヘッダーを扱いません。

cURL のようなクライアントは巨大な POST のボディを持つ POST のリクエストを送る際に自動的に Expect ヘッダーを送りますが、100 Continue レスポンスを受け取らない場合は 1 秒のタイムアウトが発生します。 cURL を Traffic Server へのクライアントとして使用する際にこのタイムアウトを回避するには、 Expect ヘッダーをオフにすることが出来ます。

curl -H"Expect:" http://www.example.com/

あるいはあなた自身のアプリケーションから C (libcurl) ライブラリを使う場合は

struct curl_slist *header_list=NULL;
header_list = curl_slist_append(header_list, "Expect:");
curl_easy_setopt(my_curlp, CURLOPT_HTTPHEADER, header_list);

あるいは PHP の cURL ライブラリを使う場合は

curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:'));

トラブルシューティングの秘訣

スループットの統計が不正確

Traffic Server はスループットの統計をオブジェクト全体を転送した後で更新します。大きいファイルではバイト数が転送の終わりで鋭く上昇します。オブジェクトを転送するのに数分かかることもありますが完全な転送バイト数は直近の 10 秒間となります。この不正確さは負荷が軽い場合に顕著です。重い負荷はより正確な統計をもたらします。

You are unable to execute Traffic Control commands

traffic_ctl commands do not execute under the following conditions:

When the traffic_manager process is not running

以下のコマンドを入力して実行することで traffic_manager プロセスが実行中かどうかを確認してください

pgrep -l traffic_manager

traffic_manager プロセスが実行中ではない場合は、開始するために Traffic Server の bin ディレクトリで次のコマンドを入力してください。

./traffic_manager
When you are not executing the command from $TSHome/bin
If the Traffic Server bin directory is not in your path, then prepend the Traffic Control commands with ./ (for example, ./traffic_ctl -h).

When multiple Traffic Server installations are present and you are not executing the Traffic Control command from the active Traffic Server path specified in ``/etc/trafficserver``

クラスター内の他のノードからあるノードがオブジェクトを取得する際に矛盾した振る舞いを観測した

最初のシステム準備の一環で、クラスター内のすべてのノードの時刻を同期しなければ成りません。多少の違いは問題となりませんが、数分以上のずれは Traffic Server の動作に影響を与えます。

xntpd などの時刻同期デーモンを実行するべきです。 xntpd の最新版を取得するには、 http://www.eecis.udel.edu/~ntp/ にアクセスしてください。

ウェブブラウザーが '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

リクエストされたオブジェクトが Traffic Server のキャッシュで許された最大サイズより大きかったので、Traffic Server はその大きすぎるオブジェクトへのプロキシーは提供しましたがキャッシュは行いませんでした。キャッシュのオブジェクトサイズ制限を設定するには、records.config ファイルの proxy.config.cache.max_doc_size 設定変数を変更してください。キャッシュ内のオブジェクトとのサイズを制限したくない場合は、ドキュメントサイズを 0 ( ゼロ ) に設定してください。

システムログファイル内の 'DrainIncomingChannel' というメッセージ

次のメッセージがシステムログファイルに現れるかもしれません。

Feb 20 23:53:40 louis traffic_manager[4414]: ERROR ==> [drainIncomingChannel] Unknown message: 'GET http://www.telechamada.pt/ HTTP/1.0'
Feb 20 23:53:46 louis last message repeated 1 time
Feb 20 23:53:58 louis traffic_manager[4414]: ERROR ==> [drainIncomingChannel] Unknown message: 'GET http://www.ip.pt/ HTTP/1.0'

これらのエラーメッセージは Traffic Server のクラスターポート rsport (デフォルトは 8088 番ポート) か mcport (デフォルトは 8089 番ポート)にブラウザが HTTP リクエストを送っていることを意味しています。 Traffic Server はこれらのリクエストを破棄します。このエラーは Traffic Server に何か問題を引き起こすわけではありません。設定を間違えたブラウザはプロキシーの正しいポートを使うように設定を変更しなければなりません。 Traffic Server は理想的には別のネットワークインターフェースを使用してクラスターはプライベートなサブネットを使うように設定し、クライアントマシンがクラスターのポートにアクセスできないようにするべきです。

システムログファイル内の 'No cop file' というメッセージ

次のメッセージがシステムログファイルに繰り返し現れます。

traffic_cop[16056]: encountered "var/trafficserver/no_cop" file...exiting

var/trafficserver/no_cop ファイルは traffic_cop プロセスに traffic_manager を開始したりヘルスチェックを実行したりすることなしに即座に終了することを指示します。 no_cop ファイルは Traffic Server が option:trafficserver stop コマンドで停止されたときに自動的に起動しないようにします。 この静止の制御が無ければ、Traffic Server はシステムのリブート時には自動的に再起動されます。 no_cop は Traffic Server が明示的に再起動されるまでは停止状態を保つようにします。

trafficserver start

vaddrs.config を手動で編集したときのシステムログファイルの警告

もしあなたが vaddrs.config を非 root ユーザで手動で編集したら、 Traffic Server はシステムログファイルに以下のような警告メッセージを出力します

WARNING: interface is ignored: Operation not permitted

Traffic Server はあなたの設定編集を反映しますのでこのメッセージは安全に無視することが出来ます。

Traffic Server は実行中だがログファイルが作られない

Traffic Server は記録する情報があるときだけイベントログファイルに出力します。 Traffic Server がアイドル状態なら、ログファイルが存在しない可能性があります。

Traffic Server がアイドル状態でないのに、ログファイルが作成されていない場合は、以下を確認してください :

  • 正しいディレクトリを見ているかを確認してください。デフォルトでは Traffic Server はログファイルを logs ディレクトリに作成します。これは records.configproxy.config.log.logfile_dir で変更可能です。
  • ログディレクトリが Traffic Server のユーザアカウントで読み書き可能なパーミションを持っていることを確認してください。ログディレクトリが正しいパーミションを持っていない場合は、 traffic_server はログファイルを開いたり作成することが出来ません。
  • ログ出力が有効になっているかどうかを records.configproxy.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.configproxy.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 はオフラインで設定が正しいかを検証するために以下のコマンドをサポートしています。これにより文法エラーのために起こりうるサービス障害を回避するためにサービスを事前にチェックすることが出来ます。

traffic_server -Cverify_config -D<config_dir>

<config_dir> は検証する設定ファイルの場所です。

オリジンサーバーとの接続タイムアウト

デフォルトでは Traffic Server はオリジンサーバーに接続する際に 30 秒でタイムアウトします。オリジンサーバーのパフォーマンスを改善してこのタイムアウトを回避することが出来ない場合は、 records.configproxy.config.http.connect_attempts_timeout をより大きな値に変更することで Traffic Server のオリジンサーバーへの接続のタイムアウトを調整することが出来ます。