5.1.2がリリースされました。
5.1.1の記事で4月中旬まで様子を見たほうがよいと言っていたのはこの件です。
︵まだ確定じゃなかったので微妙にぼかした表現でしたが・・︶
今回のリリースは1件の機能強化と主にHTTP/2関連のバグフィックスです。
[changelog] [リリース文] [パッケージDL] [ソースDL]
機能強化
std.collectでセパレータを指定できるようになりました std.collectは同一名のヘッダが複数行送られてきた場合に1行にまとめる関数ですが今までは[, ]でまとめられていました。 通常の場合は特に問題ないのですが、Cookieの場合は[; ]でまとめる必要があり、追加で置換が必要など面倒でした。 デフォルト値には[, ]が指定されているので、既に使用している場合は特に追加指定は不要ですが Cookieで使用する場合は以下のように指定するとよいです。std.collect(req.http.cookie, "; ");
バグ修正(h2以外)
#2295 動的バックエンドを使用しているときにヘルスチェックが無限ループに陥ることが合ったのを修正 #2207 #2278 PROXYプロトコルを使用したバックエンドのヘルスチェックで競合状態がおきるのを修正バグ修正(h2)
#2291 #2300 Cookieヘッダを1行にまとめるように修正 #2247 ボディを含むリクエストにContent-Lengthが存在した場合でもTransfer-Encoding: chunkedを追加していたのを修正 上記2つの修正により、前回紹介したVCLトリックは不要になりました。 #2238 ReqAcctの値がないためvarnishncsa等で入出力したバイト0になるのが修正されました わかりやすいところだとvarnishncsaの%bなどが常に0になっていたのですが、この部分が実装されたためサイズがでるようになりました。 多数のassertを修正Varnishでのhttp/2について
5.1.1では検証環境で使用できると書きましたが、今回は十分な検証を行った上であれば本番環境に入れることもできなくはないと考えています。 もちろんまだexperimentalで残バグもおそらく新規バグもあると思いますが 主にSimonや自分が相当数踏み抜き、修正されているので 以下の幾つかの注意点を守れば比較的安定的に動作すると思います。 #2268 PRIV_TASK/TOPを利用しているvmodを避ける PRIV_TASK/TOPについてはこちらの記事を御覧ください。 このPRIVの確保・解放を行う際に競合状態が起きているようで、稀にassertが起こります。 現時点で回避するには使用しているvmodの関数を避けるしかありません(例:vmod_cookie) 使用しているかどうかの判定はvccファイルを見てPRIV_TASKかPRIV_TOPがあるかで判定できます。 スレッドのメモリ使用サイズがh/1の時と比べて大幅に増える可能性があるのでチューニングが必要 h2はh1と比べるとメモリをより多く使用するため一瞬なんか漏れてると思うぐらい増えます。 元々メモリに余裕がある環境であれば特に問題はないのですが、VPSなどあまりメモリがない環境の場合は問題といえます。 解決方法としては単純にスレッド数に余分があれば減らす感じです。 もし、減らしすぎてスレッドが足りなくなったとしても、そのリクエストはキューイングされて、すぐにスレッドを追加作成して処理されます。 関連するパラメータとカウンタはこれです。| パラメータ | |
|---|---|
| thread_pools | スレッドプール数 |
| thread_pool_min | スレッドプール毎の最低スレッド数 |
| thread_pool_max | スレッドプール毎の最大スレッド数 |
| thread_queue_limit | スレッド枯渇時のキュー長 |
| カウンタ | |
|---|---|
| MAIN.threads_limited | ドロップされたセッション数 |
| MAIN.sess_dropped | ドロップされたセッション数 |
| MAIN.sess_queued | キューイングされたセッション数 |
| MAIN.threads | 現在のスレッド数 |
スレッド数はthread_pools * thread_pool_min以上thread_pools * thread_pool_max以下となります。
チューニングをする際はMAIN.sess_droppedが起きるのは論外で、MAIN.sess_queuedもそんなに起きないのが望ましいです。
このあたりのチューニングは今回の本筋ではないので詳しくは解説しませんが、要は過剰であればthread_pool_minを減らしてみて
MAIN.threadsが止まったあたりでdropped/queuedも起きないように調整するとよいのではとか思います。
本当にメモリが辛い場合は多少パフォーマンスは落ちますがqueuedを覚悟してthread_pool_minをガッツリ下げてthread_queue_limitを上げるのも手だと思います。︵その前にスペックとか他のパラメータを再検討したほうが良いと思いますが︶
結局のところ、ここでいいたいのはメモリの使用傾向が変わるとおもうのできちんとチューニングしようねって話です。
追記‥上記で長めに運用しましたが、多少ましになる程度でした。︵とはいえスレッド数の調整はしたほうがよいかなと思います。
とはいえ、HTTP/2を使う際はpkg-varnishcacheを使ってなるだけ最新を追っておくと良いかと思います。
hitch1.4.4を使う場合の注意事項
hitchは設定のreloadをサポートしているのですが(HUPを投げる)
ocsp staplingが有効だとreload時にゾンビプロセスが残る場合があります(#167)
以下のように設定して無効にすることで回避も可能です。
ocsp-dir = ""あくまでoffにすることを推奨しているのではなく、ここは各自考えてといった感じでお願いします。 最後に ぜひVarnishのhttp/2を試してみてほしいなと思います。 また、Varnishの開発を助けるためにVMLを購入するのをぜひ検討してみてください
