libeatmydataを使ってpostfixを劇速にする [用法用量要確認]
libeatmydataというLD_PRELOADを使って、起動したプロセスのfsyncを無効化するライブラリがあったので試してみています。
libeatmydata - disable fsync and SAVE!
fsyncがないと何が嬉しいかというとクラウドのようなIOまわりの環境が弱いところで、安全性は若干犠牲になりますが、パフォーマンスを稼ぐことができるようになります。
まず perlでfsyncを発行してどうなるかstraceをつかって確認してみます。
libeatmydataなし
$ strace perl -MIO::Handle -e 'open(my $fh,">:unix","test.txt"); print $fh "test"; IO::Handle::sync($fh);' open("test.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 fstat(3, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 write(3, "test", 4) = 4 fsync(3) = 0 close(3)
libeatmydataあり
$ strace eatmydata perl -MIO::Handle -e 'open(my $fh,">:unix","test.txt"); print $fh "test"; IO::Handle::sync($fh);' open("test.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 fstat(3, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 write(3, "test", 4) = 4 close(3)
IO::Handle::syncやってるはずなのに、fsyncが表示されていません。
postfixのパフォーマンス改善
某所でPostfixを経由して外部の配信サービスにメールを転送しているサーバがあり、このIO負荷が高いのが課題となってました。
一斉メール送信のタイミングでかなりIO-waitが上がっています。
postfixの構成
がわかりやすい。
postfixはいくつかのプロセスに分かれて動作します。メールを受けるときは、smtpdのプロセスが送信者からデータを受け取り、cleanupというプロセスに渡し、cleanupプロセスが実際にdiskに書き込む流れになっています。このcleanupプロセスがメールをdiskに書き込む時にfsyncを行うので、ここだけlibeatmydataを入れ込めば良いはず。
そこで /usr/libexec/postfix に cleanup_nosync というファイルを用意
#!/bin/sh exec /usr/bin/eatmydata /usr/libexec/postfix/cleanup $*
master.cfを変更する
cleanup unix n - n - 0 cleanup_nosync #最後だけ変更
postfixをreloadすれば設定が反映されます。
効果の確認
以上の設定をいれたサーバにて、受け取ったメールをすべて捨てるサーバ宛に大量にメールを送信して確認しました。
まず libeatmydata 適用前
$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 2420292 249248 1677904 0 0 0 41 2 0 4 0 95 1 0 1 0 0 2420284 249248 1677904 0 0 0 0 1264 325 23 2 74 0 0 1 3 0 2387640 249248 1677904 0 0 0 1180 2660 3530 21 3 64 11 0 0 0 0 2386628 249248 1677916 0 0 0 4356 5434 11669 9 4 77 10 0 0 5 0 2385868 249248 1677956 0 0 0 3620 4632 10255 13 3 75 9 0 0 0 0 2385844 249248 1678004 0 0 0 2792 4294 12083 4 4 88 4 0 0 0 0 2385596 249248 1678052 0 0 0 3724 4772 13095 3 4 88 4 0 0 0 0 2386200 249248 1678116 0 0 0 3408 4452 11660 4 4 86 6 0 0 0 0 2387968 249248 1678136 0 0 0 2908 4327 10611 4 3 82 11 0 0 0 0 2390704 249248 1678200 0 0 0 4724 5314 13459 4 5 86 6 0 0 0 0 2388580 249248 1678240 0 0 0 5212 5520 13300 4 5 85 6 0 3 1 0 2388208 249248 1678292 0 0 0 4716 5934 13486 4 5 86 6 0 0 1 0 2387960 249248 1678344 0 0 0 4608 5947 13964 4 4 85 7 0 0 1 0 2386720 249248 1678392 0 0 0 3164 4561 10527 3 4 81 11 0 0 0 0 2386464 249248 1678424 0 0 0 4544 5555 13150 4 4 86 6 0 0 0 0 2386092 249248 1678472 0 0 0 5052 6135 13801 4 4 85 7 0 0 1 0 2387456 249248 1678524 0 0 0 5232 5905 13530 5 5 84 7 0 0 0 0 2402424 249248 1678560 0 0 0 920 1203 2561 1 1 97 2 0 0 0 0 2402424 249248 1678560 0 0 0 8 160 300 0 0 100 0 0
iowaitが5-10%前後でています。
libeatmydata 適用後
$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 2421320 249256 1678660 0 0 0 8 266 474 0 0 100 0 0 0 0 0 2391500 249256 1678660 0 0 0 0 2248 4025 5 2 93 0 0 0 0 0 2391212 249256 1678652 0 0 0 0 6185 13856 4 4 92 0 0 0 0 0 2390824 249256 1678976 0 0 0 0 6106 13950 4 4 92 0 0 0 0 0 2391552 249256 1678804 0 0 0 0 5932 13648 4 4 92 0 0 0 0 0 2388644 249256 1678868 0 0 0 104 5901 13003 5 5 91 0 0 0 0 0 2389644 249256 1678896 0 0 0 0 5552 13448 4 4 92 0 0 4 0 0 2389280 249256 1678936 0 0 0 0 5912 13921 4 4 93 0 0 5 0 0 2391024 249256 1679004 0 0 0 0 6185 13774 4 4 93 0 0 1 0 0 2390528 249256 1679056 0 0 0 0 5848 13187 4 4 92 0 0 0 0 0 2390404 249256 1679108 0 0 0 116 6250 12982 5 4 91 0 0 0 0 0 2387496 249256 1679156 0 0 0 12 6977 13495 6 6 89 0 0 0 0 0 2389112 249256 1679176 0 0 0 0 6074 14039 4 4 92 0 0 0 0 0 2387616 249256 1679236 0 0 0 0 5966 13956 4 4 92 0 0 0 0 0 2403196 249256 1679296 0 0 0 0 1412 2950 1 1 99 0 0 0 0 0 2403444 249256 1679304 0 0 0 136 217 450 0 0 100 0 0
iowaitは常に 0。圧倒的な効果がでました。
データの安全性対策
念のため、1秒間隔でdiskへのsyncが行われるように設定しました。
$ sudo sysctl -w vm.dirty_writeback_centisecs=100
productionへの適用
IO-waitが消え、送信にかかる時間も短くなりました。やった!
Ruby 2.4.0 preview3 での pico_http_parser のベンチマーク
Ruby 2.4.0-preview3 で Hash まわりの改善があったということで、pico_http_parser のベンチマークを取ってみた
GitHub - kazeburo/pico_http_parser: Fast HTTP Parser using picohttpparser
ベンチマークは。pico_http_parser/benchmark 以下のscript。結果としては1.5倍程度パフォーマンスが上がっていることが観測できました。リアルなアプリケーションでも速度アップが見込めるんじゃないかなと思います。素晴らしい
ヘッダが0個の時だけパフォーマンスが悪くなるのは、Hashの要素数が少ないときの最適化が変わったのかなと予想
最近の Plack のパフォーマンス改善まとめ 2015年11月版
OSS活動の成果発表のお時間です。
Plackの 1.0038と2015年11月27日時点のmasterにはPlack::Request、Plack::Responseのパフォーマンスをあげる変更が入ってます。その紹介とベンチマークです。
Plack 1.0038 で HTTP::Headers::Fast 0.20 につけた flatten メソッドを使うようになってます。Plack::Response->finalizeのパフォーマンス向上が期待できます。
こちらはまだmasterにmergeされた状態。リリースはされてない。POSTリクエストのパースにHTTP::Bodyではなく、HTTP::Entitiy::Parserを使い、パラメータのパースに WWW::Form::UrlEncodedを使うようになっています。
HTTP::Entity::Parserは tokuhirom の pullreq をベースに作ったモジュールで chansen の HTTP::MultiPartParserをuploadデータの解析に利用しています。GETのクエリーパラメータなどの文字列をパースする WWW::Form::UrlEncoded は XS版も用意され、インストールするだけで長いクエリパラメータの処理が超高速になります。
ベンチマーク
以下のような psgi を用意して Plackの 1.0037、10038、そしてmasterでベンチマークを行いました。
use Plack::Builder; use Plack::Request; my $length = 4000; my $body = 'x'x$length; builder { enable 'AccessLog', logger => sub { }; sub { my $env = shift; my $req = Plack::Request->new($env); my @params = $req->param('foo'); my $res = $req->new_response(200); $res->content_type('text/plain'); $res->content_length($length); $res->body($body); $res->finilize; } };
ベンチマークを行ったサーバはgcpの12コアのサーバです。下記のsysctlのチューニングを行いました
sudo sysctl -w net.core.netdev_max_backlog=8192 sudo sysctl -w net.core.somaxconn=32768 sudo sysctl -w net.ipv4.tcp_tw_recycle=1 sudo sysctl -w net.ipv4.tcp_tw_reuse=1
perlは5.20.3、Starletは 0.28、Gazelleは0.40です。
起動オプションは Starlet、Gazelleともに同じです。
plackup -s (Starlet|Gazelle) -E production --max-workers=10 --max-reqs-per-child=5000000 -a app.psgi
ベンチマークは wrk にて取りました
./wrk -t 2 -c 8 -d 30 'http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome'
結果
1.0037から1.0038は微増。1.0038からmasterは PP版で5%ほどのパフォーマンス向上、XSになると15-20%のパフォーマンス向上となりました。WWW::Form::UrlEncoded::XSを使うと実際のアプリケーションでも差異がでるかもしれません。
以下wrkコマンドの結果
Gazelle + Plack 1.0037
$ ./wrk -t 2 -c 8 -d 30 'http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome' Running 30s test @ http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome 2 threads and 8 connections Thread Stats Avg Stdev Max +/- Stdev Latency 375.59us 187.59us 9.30ms 98.41% Req/Sec 8.58k 0.93k 12.50k 91.67% 512632 requests in 30.00s, 1.98GB read Requests/sec: 17085.90 Transfer/sec: 67.46MB
Gazelle + Plack 1.0038
$ ./wrk -t 2 -c 8 -d 30 'http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome' Running 30s test @ http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome 2 threads and 8 connections Thread Stats Avg Stdev Max +/- Stdev Latency 369.07us 188.53us 8.06ms 98.86% Req/Sec 8.73k 686.61 12.24k 89.50% 520994 requests in 30.00s, 2.01GB read Requests/sec: 17365.83 Transfer/sec: 68.56MB
Gazelle + Plack master + WWW::Form::UrlEncoded::PP
$ ./wrk -t 2 -c 8 -d 30 'http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome' Running 30s test @ http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome 2 threads and 8 connections Thread Stats Avg Stdev Max +/- Stdev Latency 347.94us 210.95us 10.08ms 98.87% Req/Sec 9.15k 0.90k 13.45k 91.33% 546160 requests in 30.00s, 2.11GB read Requests/sec: 18204.06 Transfer/sec: 71.87MB
Gazelle + Plack master + WWW::Form::UrlEncoded::XS
$ ./wrk -t 2 -c 8 -d 30 'http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome' Running 30s test @ http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome 2 threads and 8 connections Thread Stats Avg Stdev Max +/- Stdev Latency 297.28us 220.10us 10.23ms 99.33% Req/Sec 10.30k 0.95k 14.73k 92.00% 614871 requests in 30.00s, 2.37GB read Requests/sec: 20494.01 Transfer/sec: 80.91MB
Starlet + Plack 1.0037
$ ./wrk -t 2 -c 8 -d 30 'http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome' Running 30s test @ http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome 2 threads and 8 connections Thread Stats Avg Stdev Max +/- Stdev Latency 450.54us 175.99us 7.97ms 96.39% Req/Sec 7.38k 0.90k 11.11k 92.33% 440509 requests in 30.00s, 1.71GB read Requests/sec: 14683.24 Transfer/sec: 58.20MB
Starlet + Plack 1.0038
$ ./wrk -t 2 -c 8 -d 30 'http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome' Running 30s test @ http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome 2 threads and 8 connections Thread Stats Avg Stdev Max +/- Stdev Latency 443.11us 175.54us 7.51ms 96.42% Req/Sec 7.47k 0.91k 11.22k 92.17% 446088 requests in 30.01s, 1.73GB read Requests/sec: 14866.09 Transfer/sec: 58.92MB
Starlet + Plack master + WWW::Form::UrlEncoded::PP
$ ./wrk -t 2 -c 8 -d 30 'http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome' Running 30s test @ http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome 2 threads and 8 connections Thread Stats Avg Stdev Max +/- Stdev Latency 420.69us 177.07us 6.51ms 98.15% Req/Sec 7.82k 786.01 11.52k 91.33% 467110 requests in 30.00s, 1.81GB read Requests/sec: 15569.02 Transfer/sec: 61.71MB
Starlet + Plack master + WWW::Form::UrlEncoded::XS
$ ./wrk -t 2 -c 8 -d 30 'http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome' Running 30s test @ http://localhost:5000/foo?foo=bar&bar=baz&q=HTTP%3A%3ARequest%3A%3ACommon&ie=UTF-8&sourceid=chrome 2 threads and 8 connections Thread Stats Avg Stdev Max +/- Stdev Latency 373.80us 193.16us 6.98ms 98.96% Req/Sec 8.65k 785.91 12.77k 95.00% 516923 requests in 30.02s, 2.00GB read Requests/sec: 17222.14 Transfer/sec: 68.26MB
crontabのsyntax checkをTravis-CIで行う
crontabファイルをrespositoryで管理していますが、テストができてなかったので、それを解消すべくTravis-CIでやってみました。
.travis.yml
language: ruby script: - cat crontab.ok.txt | crontab - cat crontab.fail.txt | crontab
travisで実行された様子
意外なことに簡単に動いた。
Travisはcrontabが登録されても実際にはコマンドが動かない、はず。
songmuさんのParse::Crontabも非常に良いのですが、今のプロジェクトはPerlのプロジェクトではないので若干入れにくい。
参考
2007-2015 YAPC::Asia Tokyo で喋ってきたまとめ
今年のblogはまだ書いてないけど書きました、これまでYAPC::Asia Tokyo で喋ってきたblog記事をまとめてみました
2007年から2015年まで10回中9回、トーク(2007年はLT)をさせて頂きました。
2015 ISUCONの勝ち方
isucon優勝するぞー!
2014 Dockerで遊んでみよっかー
2014年はDockerの話をしました
2013 PSGI/Plack・Monocerosで学ぶハイパフォーマンスWebアプリケーションサーバの作り方
2013年はPlackのサーバを作る話。前夜祭LTもやりました
2012 1台から500台までのMySQL運用(YAPC::Asia編)
2012年はDB運用の話
2011 運用しやすいWebアプリケーションの構築方法
2011年は運用しやすいWebアプリケーションというテーマで、ログやSQLについて
2010 Introduction to CloudForecast
cloudforecastの話。最近はkuradoというのを作って使ってます
2009 大規模画像配信とPerl
大規模画像配信の話
2008 memcached in mixi
mixiのエンジニアblogで書いてました。2つトークをしていて、1つはmemcachedの話、もう一つはmod_perlをつかったjob処理でした
2007 Expectをつかった Expectをつかったサーバ管理レシピ
LTでコマンドを複数のサーバで実行する話をしました
Rhebok, a High Performance Rack Handler/Server 2x faster than Unicorn
Last December I released Rhebok to rubygems. Rhebok is a High Performance Rack Handler/Server.
rhebok | RubyGems.org | your community gem host
Rhebok is a standalone Preforking Web Server. This server is optimized for running HTTP application server behind a reverse proxy like nginx. When start Rhebok as upstream server of nginx and connect via unix domain socket, Rhebok is 2 times faster than Unicorn.
Benchmark
"nginx static file" represents req/sec when delivering 13 bytes static files from nginx
Benchmark details is here.
Features
Rhebok supports following features.
- ultra fast HTTP processing using picohttpparser
- uses accept4(2) if OS support
- uses writev(2) for output responses
- prefork and graceful shutdown using prefork_engine
- hot deploy using start_server (here is golang version by lestrrat-san)
- supports HTTP/1.1. But does not have Keepalive.
- supports OobGC
Installation and Usage
Add this line to your application's Gemfile and execute bundle install
gem 'rhebok'
Or install it yourself as
$ gem install rhebok
To run Rhebok, use the rackup command.
$ rackup -s Rhebok --port 8080 -O MaxWorkers=5 -O MaxRequestPerChild=1000 -O OobGC=yes -E production config.ru
For more details, please read README.md. If you found problems and bug, please send p-r or issue to github
SqaleでRailsアプリを高速サーバ「Rhebok」を使って起動する
Herokuに続き、Unicornの2倍のパフォーマンス発揮するRackサーバ「Rhebok」をパパボさんのPaaSであるSqaleで動かしてみる。15日間は無料お試しが出来るそうですよ。
Sqale - 開発者のためのホスティングサービス【スケール】 Ruby on Rails 対応。
Gemfileの用意
まず Gemfileを用意します。適当なディレクトリで
$ bundle init
して Gemfileを編集します
cat Gemfile # A sample Gemfile source "https://rubygems.org" gem "rails", "4.2.0"
とりあえず最新のRails 4.2.0で固定して、bundle install
$ bundle install --path vendor/bundle
Railsアプリケーションの作成
$ bundle exec rails new . --skip-bundle
すると、途中でGemfileを上書きするか聞かれるので、そのままリターンで続行
conflict Gemfile Overwrite /Users/kazeburo/Develop/sqale-rhebok/Gemfile? (enter "h" for help) [Ynaqdh]
上書きされたGemfileにRhebokを追加する
$ tail Gemfile gem 'gctools' gem 'rhebok', '>= 0.2.1'
OobGCを使う為にgctoolsも入れる。
ここまで出来たらbundle install
$ bundle install
Hello Worldだけでは面白くないので、Scaffoldを使ってアプリケーションのひな形を作る
$ bundle exec rails g scaffold msg nick:string body:text $ bundle exec rake db:migrate
ローカル環境で動くかどうか確認します。
$ bundle rails s
ローカルでRhebokを起動するには以下のコマンド
$ bundle exec rackup -s Rhebok -O MaxWorkers=1 -O OobGC=yes -O MaxRequestPerChild=0
Rhebokに変更しても問題なく動作すると思われます。
デプロイ準備
secrets.ymlのsecret_key_baseを設定する必要があります。今回はとりあえず環境変数にて設定してみました。
echo 'SECRET_KEY_BASE="'$(bundle exec rake secret)'"' > .env
Sqaleは.env
というファイルに環境変数を書いておくと起動時に読み込んでくれます。ちなみに、SqaleではデータベースにMySQLを使う事ができますが、今回はテストなのでSQLiteのままいきます
Rhebokでアプリケーションを起動したいので、Procfileも書きます。
$ cat Procfile app: bundle exec rackup -s Rhebok -O Path=/var/run/app/app.sock -O MaxWorkers=3 -O OobGC=yes -O MaxRequestPerChild=1000 -O MinRequestPerChild=500
Sqaleのコンテナはnginxとアプリケーションサーバが起動していて、間の通信にUnix Domain Socketを使うのが大きな特徴。なので、RhebokもUnix Domain SocketをListenさせる。
Rubyのバージョンを2.1.4に変更。ちなみに手元はrbenvを使わずにxbuildで2.1.5をいれてる
echo '2.1.4' > .ruby-version
vendorディレクトリをgitで管理しないようにして、git commit
$ echo '/vendor' >> .gitignore $ git init $ git add . $ git commit -m 'init'
最後に、sqaleにpush。
$ git remote add sqale ssh://sqale@gateway.sqale.jp:2222/userid/app_name.git $ git push sqale master
最初は起動までに数分かかりました。2回目からは1分ぐらいでデプロイされた。
ブラウザでみると、こんなページができました。
SqaleにSSHして確認
ちゃんとRhebokで起動したか、SSHでコンテナにログインして ps コマンドを打ってみました。
$ ssh -p 2222 sqale@gateway.sqale.jp sqale@app_name-1:~$ ps fax PID TTY STAT TIME COMMAND 6816 ? S 0:07 sshd: sqale@pts/0 6817 pts/0 Ss 0:00 \_ -bash 11236 pts/0 R+ 0:00 \_ ps fax 92 ? S 0:00 nginx: worker process 11133 ? Sl 0:00 foreman: master 11218 ? Sl 0:02 \_ ruby /home/sqale/current/vendor/bundle/ruby/2.1.0/bin/rackup -s Rhebok -O Path=/var/run/app/app.sock -O MaxWorkers=3 -O OobGC=yes -O MaxRequestPerC 11223 ? Sl 0:00 \_ ruby /home/sqale/current/vendor/bundle/ruby/2.1.0/bin/rackup -s Rhebok -O Path=/var/run/app/app.sock -O MaxWorkers=3 -O OobGC=yes -O MaxRequest 11226 ? Sl 0:00 \_ ruby /home/sqale/current/vendor/bundle/ruby/2.1.0/bin/rackup -s Rhebok -O Path=/var/run/app/app.sock -O MaxWorkers=3 -O OobGC=yes -O MaxRequest 11229 ? Sl 0:00 \_ ruby /home/sqale/current/vendor/bundle/ruby/2.1.0/bin/rackup -s Rhebok -O Path=/var/run/app/app.sock -O MaxWorkers=3 -O OobGC=yes -O MaxRequest
ちゃんと起動出来ているようですね〜
SSHで入ってログ見たり、straceでデバックしたり、killコマンドでアプリケーションの再起動できたりするのでSqale便利!