さくらVPS 上で Thin で動いている Railsアプリ Gogengo! を Nginx + Unicorn で動かすようにしました（JMeter 負荷テスト付き） - bekkou68 の日記
はじめに Gogengo! はさくらVPS 上で Thin のインスタンス 1つで動いていました。これだと重い処理のリクエストがきたら他のリクエストが待ちになってしまったり、大量の負荷がきたときに耐えられない恐れがあるので Nginx + Unicorn で動かしたくなりました。 Passenger ではなく Unicorn にした理由は 2つです。 Passenger は動かしたことがあったけど Unicorn はなかった Unicorn はダウンタイムがないのがカッコいいと思った さくらVPS で環境をつくったときの手順はこちらにまとめてあります。 対応する前に Unicorn の仕組みについて知るため『次世代RailsサーバーUnicornを使ってみた | TechRacho』を読みました。とても詳しくてわかりやすい文献です。 今回の対応の大半はミニ開発合宿でやりました。@satoc
railsのログローテート - komagataのブログ
怖話ではさくらVPS512を使ってます。性能的にはまだ問題無いんだけど、HDD容量が20GBとちと不安。先日もproduction.logが1.7GBになってたのでちゃんとローテートする。 $ cat /etc/logrotate.d/kowabana /var/www/kowabana/shared/log/*.log { weekly missingok rotate 24 dateext compress delaycompress lastaction pid=/var/www/kowabana/shared/pids/unicorn.pid test -s $pid && kill -USR1 "$(cat $pid)" endscript } newrelicのログとかunicornのログとかも一辺にローテートされるから楽でいいですね。-dをつければdry run。-fで強制実
RailsのデプロイとUnicornのトラブルシューティング
デプロイしたけど何かおかしい？ 先日、Unicornを採用しているウェブアプリで問題が発生しました。デプロイした最新のコードが実行されているように見えますが、時々古いコードの挙動を見せるのです。 今回はそのトラブルシューティングの一部始終を紹介しながら、Unicornのホットデプロイ（ダウンタイムなしでアプリケーションを更新すること）の仕組みをおさらいします。担当は私、去年KRAYに入社しました@irohirokiです。よろしくお願いします。 問題 まずはデプロイ先のサーバにSSHして、Unicornのプロセスを調べてみました。 $ ps ax -H PID TTY STAT TIME COMMAND 3159 ? Sl 0:00 unicorn master (old) -c unicorn.conf -D 3162 ? Sl 0:00 unicorn worker[0] -c unic
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
