Taobaoが公開しているnginxベースのWebサーバ Tengine の health check 機能 を試す - blog.nomadscafe.jp
Tengineはアジア最大級のECサイト「淘宝網」が公開しているWebサーバです。 The Tengine Web Server alibaba/tengine Nginxをベースにいくつかの機能拡張を行い、また開発も続いていて最新のstableバージョンに追従しているようです。 主な機能拡張は上記のサイトにも上がっていますが、興味があるところを上げると、 nginx-1.6.2をベース。nginxと100%互換性がある ダイナミックなモジュールの読み込みをサポート。モジュールの追加にTengineの再ビルドが必要ない SO_REUSEPORT をサポート。接続がnginxの3倍高速化 SPDY v3をサポート upstreamの負荷分散方式の追加。consistent hashやsticky session、upstreamのヘルスチェック、リクエスト処理中のホスト名の名前解決 acce
Docker と SO_REUSEPORT を組み合わせてみる。おそらくその1 - blog.nomadscafe.jp
SO_REUSEPORTはLinux Kernel 3.9からサポートされている機能で、複数のプロセス/Listenerから同じTCPポートをbind可能にして、Kernelが それぞれのプロセスに接続を分散してくれるという機能です。preforkなサーバはlistenしてからworkerをforkし、それぞれでacceptを行うという手順を踏みますが、SO_REUSEPORTを使えばその手順を踏まなくても複数プロセスから同じポートをListenして処理の並列性をあげたり、hot-depolyが実現できます。 Docker のHost networking機能とSO_REUSEPORTを使って、複数のコンテナから同じポートをbindできれば、コンテナのhot-deployができるんじゃないかと思ったので、試してみました。 SO_REUSEPORTについては以下のblogが参考になります。
Docker と SO_REUSEPORT を組み合わせてコンテナのHot Deployにチャレンジ - blog.nomadscafe.jp
「Docker と SO_REUSEPORT を組み合わせてみる。おそらくその1」のその2です。 結論から言うと、「単体ではリクエストの取りこぼしが若干あるけど、Reverse Proxyを工夫すればコンテナのHot Deployを実現できるかも」という感じです。 Rhebok の SO_REUSEPORT 対応 前回は簡単に検証するためにmemcachedを使いましたが、今回はアプリケーションサーバが対象ということで、 unicornの2倍ぐらい速いRackサーバであるRhebokに手をいれてSO_REUSEPORT対応しました。version 0.2.3〜です。 rhebok | RubyGems.org | your community gem host 起動時に ReusePort オプションを追加します。 $ bundle exec rackup -Ilib -s Rhebok
listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jp
TCP_DEFER_ACCEPTは、LinuxでサポートされているTCPのオプションで、サーバ側で使用した場合にはaccept(2)からのブロック解除をTCP接続が完了したタイミングではなく最初のデータが到着したタイミングで行ってくれるオプションです。 Webサーバ・アプリケーションサーバではリクエストが到着してからaccept(2)のブロックを解除するので、リクエストの到着をWebサーバ・アプリケーションサーバで待つ必要がなくなり、特にprefork型のサーバでは効率的にプロセスを使えるようになるという利点があります。PerlではStarletがこの機能を有効にしています ところが、某サービスでTCP_DEFER_ACCEPTが有効にも関わらず、accept後のreadでデータが読めず、最悪の場合、デフォルトのtimeoutである5分間プロセスがストールすることがありました。strace
一時ファイルとdentry cacheとメモリ - blog.nomadscafe.jp
わりと長い間悩んでいたんだけど、最近解決したのでメモ。 サービスで利用しているsmalllightの画像変換サーバが、Apacheが使っているメモリ以上のメモリを使用し、Swapしたりメモリ枯渇でサーバがダウンするなどのことが何度かありました。 ↑メモリの動きはこんな感じ いろいろ調べた結果「dentry cache」なるものがメモリ多くを占めていることがわかりました。dentry cacheはディレクトリやファイル名とinodeとを結びつけに使われるキャッシュです。smalllightでは画像を変換する際に一時ファイルを作成するので、その情報が残るようです。 手元で再現させる 本番で使っているサーバはCentOS5系ですが、手元のVagrant上のCentOS6(ファイルシステムはext4)で、再現させてみました。 use Parallel::Prefork; use File::Tem
memcached おすすめ起動オプションまとめ - blog.nomadscafe.jp
ここを書き直して転載 memcachedに関する記事は「第1回 memcachedの基本：memcachedを知り尽くす｜gihyo.jp … 技術評論社」など何回か書いていますが、最近のmemcachedでの起動オプションのおすすめをまとめてみようと思います。なおこの記事はMemcached Advent Calendarではありません。 まとめるとこんな感じです。 $ memcached -v -p 11211 -U 0 -u memcached -m 1024 \ -c 100000 -t 4 -C -B ascii ひとつずつ簡単に紹介します。 -v ログ出力 ログを verbose モードで起動します。エラーや警告が表示されます。弊社ではmemachedをdaemontools経由で起動し、ログを記録しています。 -v -vオプションは -vv、-vvv と v の数を増やす事で
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
HTTP/1.1 の Transfer-Encoding: chunked をビジュアライズするツール書いてみた - blog.nomadscafe.jp
Chunked Transferとは 一般にHTTP KeepAliveを利用するには、レスポンスのボディがどこで終わり、次のレスポンスがどこから始まるかをクライアントが知る必要があります、そのためHTTP/1.0ではKeepAliveを行う為にボディの長さをContent-Lengthをヘッダに入れなければなりませんでしたが、サイズを測るためにデータをすべてメモリに読み込むなどの処理が必要になり、レスポンス開始までの時間もかかります。（一般的なアプリケーションにはあまり影響がありませんが） そこでHTTP/1.1ではChunked Transferという仕組みが入っていて、事前に全体のレスポンスの長さが分からなくても、chunk=固まり毎にサイズを記してレスポンスを返していき、最後に0byteと送信することで、コンテンツの切れ目がわかるようになっています。 HTTP/1.1 200 OK
Monoceros というPrefork型だけどC10Kの接続を捌くことができるPSGI/Plackサーバ書きました - blog.nomadscafe.jp
Monoceros というPSGI/Plackサーバ書きました https://metacpan.org/release/Monoceros https://github.com/kazeburo/Monoceros StarmanやStarletのようなPreforkなアプリケーションサーバでは、コネクションの維持イコールプロセスの占有なので、HTTPのKeepAliveは無効にするのが一般的ですが、負荷の高いサービスではTIME_WAIT状態のソケットが溜まったり、SYN-ACKの再送問題などあり、KeepAliveを使いたいという欲求があったりなかったりします。 Monoceros はリクエストを処理するworkerの他に、イベントドリブンで動くコネクション管理プロセスを立てて、クライアントからの接続ソケットをunix domain socketを使いプロセス間でやりとりします。待機
MySQLの設定ファイル my.cnf をgithubにて公開しました & チューニングポイントの紹介 - blog.nomadscafe.jp
YAPC::Asiaのスライドで予告していた通り、実際に弊社のいくつかのサービスで使っている my.cnf を公開しました。 github: https://github.com/kazeburo/mysetup/tree/master/mysql 今回、公開した理由はMySQl Beginners Talksの発表の中でも触れている通りです。MySQLのソースコード中に含まれるサンプルのmy.cnfが最近のサーバハードウェアや運用に合わなくなって来ているという状況で、自分の設定にイマイチ自信が持てていない人は少なくないはず。そこで各社秘伝のタレ的な my.cnf をOpen & Shareすることで、モダンなmy.cnfを作り上げる事ができるんじゃないかという考えの下、今回 github にて公開しました。 ファイルは4つあり、それぞれ MySQL 4.0、5.1、5.5、そしてテスト中
sort と uniq でさくっとランキングを出力する - blog.nomadscafe.jp
知っている人多いと思うけど、よく使うイディオム $ .. | sort | uniq -c | sort -nr 「sort | uniq -c」で重複行をカウントでき、さらに「sort -n」で行を数字と見なしてソートすることで重複行のカウントで並べなおすことができます 例えば、Webサーバのaccess_logからよくアクセスしてくるIPアドレスを集計してランキングを表示するには以下のよう書けます $ tail -10000 access_log |cut -f 1 -d ' ' | sort |uniq -c|sort -nr|head -10 209 207.46.204.192 203 59.106.108.114 202 66.249.69.108 171 199.59.149.168 137 78.46.45.35 129 66.249.69.65 120 66.249.69
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
