Varnishのログの眺め方
Upcoming SlideShare
Loading in...5
×
 

Varnishのログの眺め方

on

  • 5,673 views

varnishncsa,varnishstat,varnishlogの簡単な解説

varnishncsa,varnishstat,varnishlogの簡単な解説

Statistics

Views

Total Views
5,673
Views on SlideShare
5,613
Embed Views
60

Actions

Likes
4
Downloads
26
Comments
0

5 Embeds 60

http://blog.xcir.net 53
http://shiroikagami.blogspot.com 3
http://paper.li 2
http://translate.googleusercontent.com 1
http://shiroikagami.blogspot.jp 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Varnishのログの眺め方 Varnishのログの眺め方 Presentation Transcript

  • Varnishのログの眺め方 2011/02/11 いわなちゃん(@xcir)
  • 自己紹介● いわなちゃん(@xcir)● Varnishが好きすぎて困ります!● 六本木とかによくいます● 本当は今日TrafficServerの話をやろうと思ったの ですが検証が間に合わなくて>< 絡んでくれると喜びます!
  • Varnishのログの仕組み ファイル パイプなど よくあるMWリクエストを処理毎に書き込むためディスクIOに左右されたりします。たくさんのリクエストが来るとパイプも重かったりBufferedLogsなんてのもありますが・・・ 共有メモリ ファイルなどvarnishd varnishncsaリクエストを処理するvarnishdはログを高速なメモリに出力するため低速なディスクに影響されることなくレスポンスを返却できます
  • Varnishでよく使うログ関係のコマンド● Varnishncsa● Varnishstat● Varnishlog
  • varnishncsa● NCSA形式のログを出力します● ただ癖が結構あるので注意が必要です ● 以前ESIやってたとき大変でした・・・● 配布してるtgzだとカスタムログ形式は使えません (2.1.5)● trunkのだと-Fオプションで出来るっぽいです 今回のバージョン入ると思ったんですがまだでした・・・
  • varnishstat①● チューニングをするときに一番使います● 注意すべき値 ● スレッド設定を見直したいもの – N worker threads not created ● スレッドを新規につくろうとしたけど作れなかった個数 出ないのが望ましいです – N worker threads limited ● スレッドプールの最大値でもう作れないです>< 0以上なら設定の見直しなどをしたほうが良さそうです – N dropped work requests ● 処理を諦めたリクエストの数 もう限界なので設定を見直しましょう 大体スレッドプールの個数を調整するといいと思います 最初から上がってるスレッド数を大きめにするのも有効です
  • varnishstat②● 注意すべき値 ● キャッシュポリシーを考えたいもの – ヒット率 ● 高いほどいいので頑張りましょう – N LRU nuked objects ● オブジェクトが期限切れ前に削除されています。 ストレージサイズが小さいorいらないものも沢山キャッシュしているでしょう 例えばヒット率が高いのにnukedカウンタが上がっている場合 一部の沢山アクセスされるオブジェクトと ほとんどアクセスされないオブジェクトがあると思われます TTLの調整などでよりパフォーマンスがよくなる可能性があります
  • varnishstat③(ちょっと自信なさげ)● 注意すべき値 ● 共有メモリの設定値を見直したいかも – SHM flushes due to overflow ● ソースをざっくり眺めた感じだとおそらくこの値は共有メモリがフラッシュされた回数です もしログをvarnishncsaなどで保存してるときはどれぐらいの頻度でフラッシュされてる か見たほうがいいと思います。 アクセス数が多いけどログもちゃんと保存したいときは /etc/sysconfig/varnishのMEMLOCKを調整したほうがいいかも?
  • varnishlog● Varnishがログとしているすべての出力を見れます ● めちゃくちゃ量が多いので絞り込みオプションがあります – -b ● Varnish・バックエンド間とのログのみ – -c ● クライアント・Varnish間とのログのみ – -i [tag] ● 特定のタグだけ出力、大文字小文字は区別しません 例えば-i SessionOpenとした場合は新規セッションが確立したときの情報だけ出力します – -I [Regex] データカラムを評価してヒットしたのを出力します ● – 例えばクライアントから送出されるクッキーのヘッダのを出力したい場合は以下になります ● varnishlog -c -i RxHeader -I Cookie ● 基本構造は以下です   ↓メッセージタグ ↓データ 11 RxRequest c GET ↑トランザクションのグループ             ↑データの流れ
  • varnishlog 11 RxRequest c GET   ↓メッセージタグ ↓データ 11 RxRequest c GET ↑トランザクションのグループ             ↑データの流れ● 第一カラム:トランザクションのグループ ● 同じ番号は同じHTTPのトランザクションに属します ● あくまでHTTPのなので ユーザ←→Varnish←バックエンドという一連の流れでは ユーザ←→VarnishとVarnish←バックエンドで別番号が振られます
  • varnishlog 11 RxRequest c GET   ↓メッセージタグ ↓データ 11 RxRequest c GET ↑トランザクションのグループ             ↑データの流れ● 第二カラム:メッセージタグ ● アクティビティの種別でタグが付きます PrefixにRx,Txが付いている場合は意味があります – Rx:Varnishが受け取ったデータ – Tx:Varnishが送信したデータ
  • varnishlog 11 RxRequest c GET   ↓メッセージタグ ↓データ 11 RxRequest c GET ↑トランザクションのグループ            ↑データの流れ● 第三カラム:データの流れ ● どこからデータが来たかを示します – c:クライアントからのデータ – b:バックエンドからのデータ
  • varnishlog 11 RxRequest c GET   ↓メッセージタグ ↓データ 11 RxRequest c GET ↑トランザクションのグループ            ↑データの流れ● 第四カラム:実際のデータ
  • varnishlog example● 12 RxHeader c Host: blog.xcir.net ● クライアント(c)から送出されたHeaderを Varnishが受け取っています(Rx)● 13 TxHeader b Host: blog.xcir.net ● Varnishがバックエンド(b)に対してHeaderを 送出しています(Tx)
  • 自分を追い込むための 宣伝● 上手く行けば夏コミで Varnishの薄い本だします● 在庫は悲しいので見かけたら 買ってくれると踊ります
  • ありがとうございました