2016年08月

Released mysql_getlock gem

Released mysql_getlock gem to provide distributed locking using mysql get_lock().
Unlike distributed locking using redis, this ensures releasing orphaned lock.


How It Works

This gem uses MySQL get_lock().

Simple ruby codes which describes how it works are as follows:

mysql.query(%Q[select get_lock('db_name.key', -1)])
puts 'get lock'
begin
  # do a job
ensure
  mysql.query(%Q[select release_lock('db_name.key')])
end

MySQL get_lock() has a characteristic that the lock is implicitly released when your session terminates (either normally or abnormally). 


NOTICE

Note that

  1. Before 5.7.5, only a single simultaneous lock can be acquired in a session, and GET_LOCK() releases any existing lock. This gem raises MysqlGetlock::Error on such situation.
  2. The key name is global in a mysql instance. It is advised to use database-specific or application-specific lock names such as db_name.str or app_name.environment.str


Installation

Add this line to your application's Gemfile:

gem 'mysql_getlock'

And then execute:

$ bundle

Or install it yourself as:

$ gem install mysql_getlock


Usage

Similarly with ruby standard library mutex, following methods are available:

  • lock
    • Attempts to grab the lock and waits if it isn’t available.
  • locked?
    • Returns true if this lock is currently held by some.
  • synchronize {}
    • Obtains a lock, runs the block, and releases the lock when the block completes.
  • unlock
    • Releases the lock.

Options of MysqlGetlock.new are:

  • mysql2
    • Provide a mysql2 instance
  • key
    • Key name for a distributed lock
  • timeout
    • The timeout of trying to get the lock. A negative value means infinite timeout (default: -1)
  • logger
    • Provide a logger for MysqlGetlock (for debug)


Example

require 'mysql2'
require 'mysql_getlock'

mysql2 = Mysql2::Client.new # Mysql2::Client.new(options)
mutex = MysqlGetlock.new(mysql2: mysql2, key: 'db_name.lock_key')

mutex.lock
begin
  puts 'get lock'
ensure
  mutex.unlock
end

mutex.synchronize do
  puts 'get lock'
end

Released redis_getlock gem

Released redis_getlock gem to provide distributed locking using redis. This is useful, for example, when you want to run only one worker among multiple workers deployed on multiple servers. 

Unlike other implementations avilable, this gem ensures releasing orphaned lock shortly.


How It Works

This gem basically works as http://redis.io/commands/set describes for redis >= 2.6.12, and http://redis.io/commands/setnx describes for redis < 2.6.12.

Simple ruby codes which http://redis.io/commands/set describes are as follows:

loop do
  break if redis.set(key, 'anystring', {nx: true, ex: expire})
  sleep 1
end
puts 'get lock'
begin
  # do a job
ensure
  redis.del(key) # unlock
end

The problem here is the value of expire. The expiration time expire is necessary so that a lock will eventually be released even if a process is crashed or killed by SIGKILL before deleting the key. However, how long should we set if we are uncertain how long a job takes?

This gem takes a following approach to resolve this problem.

  1. Expiration time is set to 2 (default) seconds
  2. Extend the lock in each 1 (default) sencond interval invoking another thread

This way ensures to release orphaned lock in 2 seconds, and we are released from caring of the value of expire!!

Simple ruby codes to explain how this gem works are as follows:

loop do
  break if redis.set(key, 'anystring', {nx: true, ex: 2})
  sleep 1
end
puts 'get lock'
thr = Thread.new do
  loop do
    redis.expire(key, 2)
    sleep 1
  end
end
begin
  # do a job
ensure
  thr.terminate
  redis.del(key) # unlock
end


Installation

Add this line to your application's Gemfile:

gem 'redis_getlock'

And then execute:

$ bundle

Or install it yourself as:

$ gem install redis_getlock


Usage

Similarly with ruby standard library mutex, following methods are available:

  • lock
    • Attempts to grab the lock and waits if it isn’t available.
  • locked?
    • Returns true if this lock is currently held by some.
  • synchronize {}
    • Obtains a lock, runs the block, and releases the lock when the block completes.
  • unlock
    • Releases the lock.


Example

require 'redis'
require 'redis_getlock'

redis = Redis.new # Redis.new(options)
mutex = RedisGetlock.new(redis: redis, key: 'lock_key')

mutex.lock
begin
  puts 'get lock'
ensure
  mutex.unlock
end

mutex.synchronize do
  puts 'get lock'
end


SOFT SKILLS を読んだ

SOFT SKILLS を読んだ。

SOFT SKILLS ソフトウェア開発者の人生マニュアル
日経BP社 (2016-06-02)
売り上げランキング: 2,682

目次

  • 第1部 キャリアを築こう
  • 第2部 自分を売り込め!
  • 第3部 学ぶことを学ぼう
  • 第4部 生産性を高めよう
  • 第5部 お金に強くなろう
  • 第6部 やっぱり、体が大事
  • 第7部 負けない心を鍛えよう

それぞれ10章ぐらいあって、付録を入れると全75章。1日10章ぐらいで7日かけて読んだ。

感想としては、前半(4部ぐらいまでかな)は「うんうん、わかる」という感じで良かったのだが、後半になってきたら株とか不動産とか筋肉とかの話になってきて個人的には参考にならなさそうな感じがしてきて、最後のほうは読み飛ばしになってしまった。


著者について

著者は33歳で社員として働くのをリタイアして、その頃にこの本を書いたようだ。つまり、自分と年齢はたいして変わらない。確かにその年齢にしては色々やっているようだが、そこまで人生経験が豊富なわけではないので、本の内容はある程度偏りがあると思って読んだほうが良さそうに感じた(そう思って読んだ)。

リタイアしてからは、不動産とかオンライン講師としての収入が大きいらしく、プログラミング講座もやっているが、どうやら筋肉とか、不動産の講座とかもやっているっぽい。

本には書いてなかったが、その講座ネタに使えるというモチベーションもあって、継続的にフィットネスを続けていられるんじゃないか?という疑問があって、筋肉あたりの話は参考にならないと思ってしまった。

著者の twitter やホームページLinked In のページを見ると、確かに本に書いてあったようにとても見映えが良くできていて、すごい。不動産などに時間を使いすぎて、実はプログラミングスキルないんじゃないか?、講座もiOSアプリ開発入門とか、入門ばかりじゃないか?と疑念を抱いていたのだが、Linked In のページを見ると、HP で Tech Lead もやっていたことがあって「この人はすごい」と推薦も書いてあって、やっぱりスキルもある人なのか、と思い改めさせられた (それすらも、自己宣伝の一環なのだが、他に判断材料がないのでもはやそう思うしかない)。

とかそんなことを思いながら読んでた。


ハイライト

以下、ハイライトしてた文章を引用


第1部 キャリアを築こう

  • ソフトウェア開発という競争の激しい世界で本当に成功したいのなら、単に履歴書を磨いてたまたま手に入れた仕事をする以上のことをしなければならない。


第2章 スタートから派手にいこう!:誰もがするようなことはするな

  • 一時的なキャリアとして、あなたが特定の会社の従業員であることに間違いはないのかもしれないが、そのときの肩書が自分や自分のキャリアを表していると考えないことが大切だ
    • それよりも、ソフトウェア開発というあなたの事業の顧客として、雇用主を考えたほうがいい
    • 一般にソフトウェア開発者は、アイデアを受け取ってそれをデジタル化された現実に変身させる能力を売っている。
  • 自分が提供するサービスに全力を集中し、そのサービスの売り方を考える
    • 特別なクライアントを対象に専門的なサービスを提供するスペシャリストに力を注ぐ(いい仕事を探すソフトウェア開発者は、1クライアントを確保するだけでいいことを忘れないように)


第3章 未来について考える:あなたの目標はなに?

  • 心のなかに大きな目標を描く所からはじめ、その大きな目標に到達するために役に立つ小さな目標を途中に設けていく。大きな目標を貼りだしておく。
  • 目標を再設定する時期は決めておくことをオススメする。週末、翌週のプランを練る前に、その週に対して設定した目標をレビューするようにしよう。各月、各季節、各年にも、同じことが当てはまる。


第4章 社交術

  • いい行動を褒めることの方が悪いことを懲らしめることよりもはるかに効果的だということは、数々の研究が示していることだ(補足:リーダーについて)


第5章 面接をハッキングするコツ

  • 面接に合格するためのもっともてっとり早い方法は、面接官に気に入ってもらうことだ。そのための方法はたくさんあり、その大半は、面接が始まる前にできることである。
    • 行きたい会社で働いている開発者のすべてのブログをフォローし、よく考えて意味のあるこトメントを残していった。結果として、その会社で働く開発者の多くから認知をえて、何人かは、私のブログを読み始めるようにさえなった。結果として、公募での仕事よりもずっと高いポストを射止めた。
  • 本物の面接ではどうすれば良いのか?私なら、スキルは非常に高くても、いつも手をかけてやらないと生産的になれない開発者より、知っていることはいくらか少なくても、何をすべきか、それをどのようにしてすればいいかを突き止める方法がわかっている開発者を雇うだろう。自分が制御できる範囲内で、頼まれなくても仕事を終わらせられるタイプの開発者だということを具体的に示すことに注力しよう。


第6章 雇用形態:3つの選択肢を理解する

  • 会社員になるということは、収入があらかじめ決まっているということであり、一定水準で「頭打ち」になるということでもある。会社員で要るかぎり、いずれ収入の面でも昇進昇格の機会でも「ガラスの天井」にぶち当たる。
  • 自分が自分の上司になれたらどんなにいいだろうと思ったのだが、まさか独立系コンサルタントになっても上司が一人からたくさんになるだけだとは思いもしなかった。
  • 現在の私は、クライアントのために1時間仕事をするごとに300ドルを請求しているが・・


第7章 あなたはどのタイプのソフトウェア開発者か

  • 弁護士は専門分野を持っており、最初からその専門分野が何なのかをわかるようにしている。税や不動産の問題で、離婚弁護士に代理人になってもらうのは避けたいものである。だから、専門性は重要だ。
  • 弁護士はロースクールをでたときに、単なる「弁護士」になろうとは思っていない。しかし、ほとんどのソフトウェア開発者は、自分の職業のこととなると、それに等しいことをしている。
  • 「私はC#プログラマーです」とか「私はJavaプログラマーです」という専門の表し方は広すぎる。
  • ジェネラリストになれば、クライアントの枠が大きくなるように見えるかもしれない。しかし、実際には、スペシャリストが必要だということを知らないくらい事情にうとい人々しか、クライアントにならないのである。
  • 専門分野を非常に深く掘り下げ、ごく限定されたプラットフォームやフレームワークの専門家になっている人々もいる。このような開発者の場合、クライアントになる可能性のある人(会社)は非常に少ないが、非常に高い時間給を要求できる。


第8章 どの会社も同じではない

  • 小さな会社とスタートアップ
    • 一人ひとりの貢献が直接会社の業績に影響を与え、それがわかる。そのため、偉大な達成をすれば、それが大きくみえる。ただし、ヘマについても同じことが言える。
  • 中規模の起業
    • 中起業では、じっくり堅実なタイプの方が、競争に勝つことが多い
    • 最先端の仕事をしたい場合、中企業ではリスクを負ってもいいという理由付けが難しい
  • 大企業
    • 大企業の多くでは、技術イノベーションは日常茶飯事である。そういった大規模な取り組みで人から気づかれるようなインパクトを与えることはたぶんできないだろうが、注目すべき製品やサービスを市場に投入するチームの一員にはなれるだろう


第9章 出世階段の上り方

  • 地位を上げるために出来るもっとも大切なことは、それまでよりも重い責任を引き受けることだ。
  • 探してみるといいのは、ほかの人が誰も関わりたがらないようなところだ。
  • 自分の問題以外にも他人の問題を知って解決すると、自分がより多く学べるだけでなく、時間とともにチーム内であなたは頼れる人だという評判が生まれる。このような評判が生まれると、あなたにはチームリーダーやマネージャーのポストが回ってくるはずだ。
  • 上司、あるいはもっと偉い人にあなたがしていることを知らせる方法がなければ、あなたのハードワークも無駄になってしまう。
  • しかし、政治ゲームにあまり時間をかけすぎるべきではないと思う。価値のある社員に見せるのではなく、本当に価値のある社員になってしっかりとした基礎を築くほうがいい結果を残せることを私は見てきた。


第10章 プロであること

  • プロは、自分の仕事に対して高品質を維持できるような基準を持っており、プロなら毎日いつでもその基準を守ってくれるとあてにすることができる。
  • プロ
    • 常に従う規則を持っている。頼まれたことなら何でもやるのはアマチュア
    • 仕事を正しく終わらせることに集中している。
    • 間違っているときや知らない時にそれを認める
    • 首尾一貫していて安定している
    • 責任を取る
  • プロフェッショナルには、絶対に超えない一線があるので、たとえ上司が相手でも言うべき時には「ノー」と言わなければならない。たとえそれで首になったとしても、自分をプロと呼ぶためにはそのような代償を払わなければならないことがある。


第11章 自由を得る:仕事の辞め方


第12章 フリーランサー:外に出て独立する

  • クライアントになる人のところに出て行くのではなく、そういう人にあなたのところに来てもらうのがインバウンドマーケティングだ
  • ブログ、本の執筆、カンファレンスでの公園、ポッドキャッシュとの出演
  • ほとんどのフリーランサーは、クライアントに請求できる額、クライアントに請求する必要のある作業量をともに大幅に過小評価している
  • 一般的な目安として、フリーランサーになったときには、フルタイムの社員だった時の時間給与の約2倍を請求する必要がある
  • コモディティ扱いされてはだめで、専門家として扱われなければならない
  • 「ノー」という返事がくるようになるまで、料金は引き上げていい


第13章 初めての製品開発

  • 始めてアントレプレナーの世界に飛び込むソフトウェア開発者の多くは、製品を使ってくれる人を見つける前に製品を作ってしまうという過ちを犯している。


第14章 スタートアップを起業したい場合


第15章 遠隔勤務サバイバル戦略

  • やるきがない時にたよりになるものとして、スケジュールと習慣は重要である
  • ポモドーロ
  • どうすれば孤独は癒やされるだろうか。外に出かければいい。


第16章 うまくやり遂げるまではできたふりをする

  • 「うまくやり遂げるまではできたふりをする」というのは、行動こそが重要で、自分の心身に言い聞かせてその行動を現実のものにするということである。


第17章 ダメな履歴書をよくする方法


第18章 テクノロジーに対して頑なな態度をとる

  • すでに知っているものだけにしがみついてそれがベストだと主張しようとせず、開かれた心でテクノロジーに接するようにすれば、あなたの前にはるかに多くのチャンスが開けてくるだろう


第19章 コードモンキーのためのマーケティング

  • ただ、才能だけでは、人生にそれだけの差がついてしまう。スーパースターとのホントの違いは、マーケティングにすぎない
  • 自分をマーケティングするとは、あなたが提供できるものを、欲しいと思っている人と結びつけることにほかならない
  • ブログ、ポッドキャスト、執筆がマーケティングに貢献し、個人ブランドの認知度はあがっていく


第20章 自分だと気づいてもらえるブランドを確立しよう

  • ブランドを持つには、メッセージ、ビジュアル、一貫性、反復的な接触の4つが必要だ
  • たとえば、私の「シンプルプログラマー」というブランドは、複雑なものを単純にするというメッセージを基礎としている。私のメッセージは、「私なら複雑なコンセプトを分解し、単純にして、誰もが理解できるようにする」というものである。
  • 何らかのニッチを選び、それを中心として自分のブランドを構築する。限定されていればいるほどいい。
  • 自分が力を入れていくことをもとに選ぶより、純粋に戦略的な視点から選んだほうがうまくはまる場合が多い。


第21章 大成功するブログの作り方

  • 頻度


第22章 最大の目標:他人のために価値を生み出せ!

  • 成功した人ではなく、価値を生み出す人になるよう努力せよ ーーアルバート・アインシュタイン


第23章 ソーシャルメディアの使い方

  • https://buffer.com というSNS予約投稿サービスを使って、1周間かけていろいろなタイミングで公開するようスケジューリングしたりしている
  • LinkedIn でもっとも活用されていない機能は、コネクションに推薦を求める機能だろう。


第24章 講演、プレゼンテーション

  • 外でなくても社内でも。仕事でプレゼンテーションを行うと、同僚、さらには上司に影響を与えることができ、キャリアにとって大きな意味がある。


第25章 フォロワーを惹きつけるような本屋記事を執筆する

  • 特定のテーマについて本を書いたり記事を発表したりすると、その人はその分野の専門家なのだろうと思う。自分をマーケティングするつもりなら、専門家と見られて損はない。
  • 小さな雑誌に記事を載せてもらうところから始めることをお勧めする。実績を積み、その専門領域でのあなたの評価が上がっていくと、より大きな出版社で仕事できるようになっていく。
  • きちんと書かれた提案書が必要だ。その提案書は、本の目的、ターゲットとする読者層、本が成功すると自分で思う理由、その本を書く最良の著者が自分だということを示す証拠などをはっきりと示していなければならない。
  • 自費出版は、完全に自分だけですることができ、簡単なので、最初の方法として優れている。


第26章 馬鹿にされるのを恐れるな

  • 私は人生のなかで繰り返し繰り返し失敗してきている。私が成功したのはそのためだ。ーーマイケル・ジョーダン


第27章 学び方を学ぶ

  • あるテーマについて、本をじっくり読む前に、ざっと流し読みしてその世界に飛び込み、すぐに遊んでみよう。実験し、探りを入れているうちにどのような疑問が頭に浮かんでくるかを観察するので。あらゆる疑問が浮かんだら、始めて本に戻って文章を読む。
  • 自分が学んだことを他の人におしえて知識をセメントで封印しておこう


第28章 私の10ステッププロセス

  • 私が学べるのは20%だが、その20%で日常の用途の80%をカバーする部分を見つける
  • 学習したいことのスコープと学習成功のイメージを定義する


第29章 ステップ1〜6:1度限りのステップ

  • 本の全体像をつかむ
  • スコープを決める


第30章 ステップ7〜10:繰り返すステップ


第31章 メンターを探す

  • メンターとしては、あなたがしたいことを成し遂げた人か、あなたがしたいことをしたほかの人を支えた人を探すべきだ
  • 自分でメンターを作ることにした。それは、本のことである。
  • 当然ながら、本物のメンターの方がいいに決まっている。行き詰まったら、現実にメンターとして受け言えれてくれればいいのにと思う人を探そう。実際、インターネットを介してそういった人々と連絡をトリ、本当にアドバイスを受けられる場合もある
  • あたたが差し出せるもののなかでもっともいいものは、学びたいという熱心な気持ちと、無償労働である。メンター候補があなたの提案を受け入れる可能性はかなり高くなる。


第32章 弟子を取る

  • 結局はメンタリングしている相手よりも自分の方がよく学んでいることが多い


第35章 知識の中の隙間を見つける

  • 作業効率を下げている知識の隙間を見つけるための方法のなかでも特に優れているのは、作業にもっとも時間がかかっているところはどこか、繰り返し行なっていることは何かを意識することである。
  • 私にとってのラムダ式はまさにそういうものだった。ラムダ式が含まれているコードのデバッグ、その他の操作に非常に長い時間がかかっていたのだ。
  • わからないものが出てきた時、すぐに学ぶ必要はないが、少なくともリストにその事項を追加しておこう


第36章 すべては集中から始まる

  • 生産性が高いからといって、有能だとは限らない。正しい仕事をしてこそ有能になれる。
  • しかし、さしあたり生産性を上げる事に焦点を絞ろう


第37章 私の生産性向上策を明かそう

  • 基本的な考え方は、週全体で2時間異常に終わる小さなタスクの実行計画を作るというものだ
  • 4半期の計画
  • 月次計画: 毎月1日に計画していく
  • 週次計画:毎週月曜日の朝にその週の計画をたてる


第38章 ポモドーロテクニック

  • ポモドーロテクニックの本当の力は、作業量を見積もり、トラッキングするためのツールとして使ったときに現れる。1日に実行したポモドーロの数を数え、1日に何個のポモドーロを達成するかという目標を設定する。
  • 1周間をポモドーロ何個分の限りある資源として考えられるようになる。
  • 1ポモドーロ30分 => 8時間労働なら16ポモドーロ。実際には、6ポモドーロをこなすことさえ難しいと感じた。


第39章 以前よりも安定して多くの仕事ができるわけ

  • 定期的に必ずしておきたい作業についてクォータ(ノルマ)を追加していった。


第40章 自分自身に対して責任をとる

  • 監視している人がいないときに生産性を上げるためには、自分に対する責任という感覚を育てることが大切になる


第41章 マルチタスク、やっていいこと、悪いこと

  • フィットネスと学習は良い
  • 頭を使うもの同士は効率を下げるだけだ


第42章 燃え尽き症候群の直し方

あまり参考にならなかった


第43章 時間を浪費するメカニズム

  • http://rescuetime.com などのツールを使えば、仕事中に何のために時間を費やしているかをトラッキングし、コンピューター上でSNSや生産的でないもののために費やした時間を正確に示すレポートを作ることができる
  • 庭仕事や掃除をしてくれる人を雇ったら何時間空くかを明らかにしよう。なにかを解約したら、それで節約できたお金でこういったサービスを使える場合もある


第44章 ルーチンを持つことの重要性

  • 食事の時間、なにを食べるかまでルーチン化
  • 着る服もルーチン化
  • 仕事で使っているテクノロジーについて、毎日30分ずつ学習するようにしていた


第45章 習慣を作る:コードを書こう

  • 習慣は、キュー、ルーチン、褒美の3つで構成されている
    • キューは、習慣が現れる引き金になるもの


第47章 ハードワーク

  • 非常に大きなターニングポイントがあった。それは、成功のためにはハードワークは必要であり、避けるべきものではないと考えるようになったときのことだ。


第48章 どんなことでも、しないよりしたほうがまし

  • 行動をとらなかったために逃した過去のチャンスを探そう。たとえば、株の売買、会社への投資、起業などである。


第49章 給料をどのように運用するか

  • 家は負債であって資産ではない(土地は資産か)
  • 給料を浪費しないだけではなく、私のためにいずれお金を生み出してくれる資産に給料のかなりの部分を投資しなければならないことを認識したのはそのときだった。


第50章 給与交渉の方法

  • 会社の一員になってしまうと、固定されてしまった第一印象を振り払うのは難しくなる。
  • 交渉は応募する前から決まっている。パーソナルブランドを作る
  • 求人票を見て応募する。これは、職を求める方法として最悪だ。
  • 必ず個人推薦を手に入れるようにすべきである。
  • 数字を先にいったほうが負け
    • 今の給与額を言わない。自分を安く売らない
  • 提示が手に入ったら、ほとんどかならず反対意見をいいたい
  • 高い額を言うと、少し額を上げた回答がかえってくるだろう。あと1回だけ希望をいうことをお勧めする
    • 「もし$Xにしていただけるのなら、迷いはなくなり、今すぐにでも契約したいと思います」


第67章 プラスの自己イメージを築く

  • なりたいイメージを築き、うまくやり遂げるまではできたふりをする
  • 自分は不器用だとか物忘れがひどいと何度も言えば、心の意識下の部分はそれを信じてしまう。


第70章 失敗に正面からぶつかれ

  • 失敗を恐れて避けてきたことのうち、少なくともひとつを本気でしてみよう。腰が引けた形でするのもいけない。本気で試し、本気で失敗しよう。

Released resque_starter gem

Resque is widely used Redis-backed Ruby library for creating background jobs. ResqueStarter is a tool to start and manage multiple resque workers supporting graceful shutdown and restart, leveraging the Copy-on-write (COW).

PID   COMMAND
14814 resque_starter # preload app
14815  \_ resque worker[0]
14816  \_ resque worker[1]
14817  \_ resque worker[2]

The process model is similar with unicorn :-p

Background

Resque provides resque:workers task to run multiple resque workers, but it is only for development purpose as code comments says. It also provides an example configuration of god as resque.god, but it does not allow us to leverage Copy-on-write (CoW) to save memory of preloaded application.


Installation

Add this line to your application's Gemfile:

gem 'resque_starter'

And then execute:

$ bundle

Or install it yourself as:

$ gem install resque_starter


Configuration

Please see example/resque.conf.rb

You can configure logger, pid file, number of concurrency, dequeue interval, queue lists.


Usage

bundle exec resque_starter -c /path/to/resque.conf.rb


Signals

Resque starter responds to a few different signals:

  • TERM / INT - Quick shutdown, kills all workers immediately then exit
  • QUIT - Graceful shutdown, waits for workers to finish processing then exit
  • USR1 - Send USR1 to all workers, which immediately kill worker's child but don't exit
  • USR2 - Send USR2 to all workers, which don't start to process any new jobs
  • CONT - Send CONT to all workers, which start to process new jobs again after a USR2
  • TTIN - Increment the number of worker processes by one
  • TTOU - Decrement the number of worker processes by one with QUIT


Graceful restart

Resque starter itself does not support graceful restart, yet. But, graceful restart can be done with server-starter.

Example configuration is available at server-starter/example/resque. See start_server and config/resque.conf.rbfiles.

HOW IT WORKS

On receiving HUP signal, server starter creates a new resque_starter (master) process. The new resque_starter(master) process forks a new resque worker. On after_fork, send TTOU to old resque_starter (master) process to gracefully shutdown one old resqueworker. By repeating this procedure, new resque_starter process can be gracefully restarted. The number of working resque workers will be suppressed up to concurrency + 1 in this way.

ILLUSTRATION

On bootup:

PID   COMMAND
14813 server_starter
14814  \_ resque_starter
14815      \_ resque worker[0]
14816      \_ resque worker[1]
14817      \_ resque worker[2]

Send HUP:

PID   COMMAND
14813 server_starter
14814  \_ resque_starter (old)
14815      \_ resque worker[0] (dies)
14816      \_ resque worker[1]
14817      \_ resque worker[2]
14818  \_ resque_starter (new)
14819      \_ resque worker[0]

Finally:

PID   COMMAND
14813 server_starter
14818  \_ resque_starter (new)
14819      \_ resque worker[0]
14820      \_ resque worker[1]
14821      \_ resque worker[2]

Released resque-worker-killer gem

Resque is widely used Redis-backed Ruby library for creating background jobs. One thing we thought Resque missed, is killing a forked child of Resque worker based on consumed memories.

resque-worker-killer gem provides automatic kill of a forked child of Resque worker based on process memory size (RSS) not to exceed the maximum allowed memory size.

The name was inspired by unicorn-worker-killer :-p 


Installation

Add this line to your application's Gemfile:

gem 'resque-worker-killer'

And then execute:

$ bundle

Or install it yourself as:

$ gem install resque-worker-killer


Usage

Use the plugin:

require 'resque'
require 'resque-worker-killer'

class MyJob
  extend Resque::Plugins::WorkerKiller
  @queue = :example_queue

  extend Resque::Plugins::WorkerKiller
  @worker_killer_monitor_interval = 0.5 # sec
  @worker_killer_mem_limit = 300_000 # KB
  @worker_killer_max_term = 10 # try TERM 10 times, then KILL
  @worker_killer_verbose = false # verbose log
  @worker_killer_logger = Resque.logger

  def self.perform(*args)
    puts 'started'
    sleep 10
    puts 'finished'
  rescue Resque::TermException => e # env TERM_CHILD=1
    puts 'terminated'
  end
end

TERM_CHILD environment variable must be set on starting resque worker:

$ TERM_CHILD=1 bundle exec rake resque:work

Options are:

  • @worker_killer_monitor_interval: Monotring interval to check RSS size (default: 1.0 sec)
  • @worker_killer_mem_limit: RSS usage limit, in killobytes (default: 300MB)
  • @worker_killer_max_term: Try kiling child process with SIGTERM in @worker_killer_max_term times (default: 10), then SIGKILL if it still does not die.
  • @worker_killer_verbose: Verbose log
  • @worker_killer_logger: Logger instance (default: Resque.logger)
A Ruby and Fluentd committer working at DeNA. 記事本文および記事中のコード片は引用および特記あるものを除いてすべて修正BSDライセンスとします。 #ruby #fluentd #growthforecast #haikanko #yohoushi #specinfra #serverspec #focuslight
はてぶ人気エントリー