だいありー (2015-10-05)
答え合わせ。 おっと、実時間だと、世代別 GC を、ちゃんと有効にしているやつと、あまり変わりませんね。 とありますが、system time が長いですよね。これ、システムからメモリを確保するために必要となる時間です、多分。800MB 以上ぶんどらないといけないですから。この場合、user 時間を比べて、GC の影響を見ておくのが良いでしょう。つまり、GC の影響は 1.64 sec - 1.47 = 0.17 sec。これが、GC による影響だとみることが出来ます。 まとめると、大ざっぱに オブジェクトの生成 0.7 sec GC 時間 0.2 sec という感じです。潰すべきオーバヘッドはどちらか、というのは、わかりやすい。GC は本当に遅いんですかね。 あと、オブジェクトを 100M 個作っておいた、すぐあとのベンチマークでは、また違った様子ですね。これも、OS とのやりとりやら、
RubyとPythonにおけるガベージコレクションの視覚化 | POSTD
本稿は、ブダペストで開かれたイベント「 RuPy 」で、Pat Shaughnessyが披露したプレゼンの内容をまとめたものです。 プレゼンの映像はここ から視聴できます。 本稿は当初、 同氏の個人ブログ に投稿されましたが、同氏の了承を得て、Codeshipに再掲載します。 このイベントは「RubyとPython」に関するカンファレンスなので、RubyとPythonでは、ガベージコレクション（以下「GC」）の動作がどう違うのかを比較すると面白いだろうと私は思いました。 ただしその本題に入る前に、そもそもなぜ、GCを取り上げるのかについてお話しします。正直言って、すごく魅力的な、わくわくするテーマではないですよね？ 皆さんの中でGCと聞いて、心がときめいた方はいらっしゃいますか？ ［実はこのカンファレンス出席者の中で、ここで手を挙げた人は数名いました！］ Rubyコミュニティで最近、Rub
ActiveRecordを速くしたいだけの人生だった - Qiita
Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを
有効なWikiNameではありません
2019-03-28 Python/インスタンス生成 2018-01-02 Python/クロージャ Pythonを読む 2018-01-01 Python/メソッド呼び出し 2017-12-31 Python/build_class後編 2017-12-30 Python/読解対象とするPythonコードと解析方法 2017-12-24 Python/build_class前編（というよりPyTypeObject） 2017-12-07 Python/ビルトインがビルトインされるまで 2017-12-03 Python/C関数実行とPyObject 2017-10-22 Django/テンプレートシステムを読む（レンダリング） Djangoを読む 2017-10-21 Django/テンプレートシステムを読む（テンプレートのパース） 2017-09-24 Django/テンプレートシステ
Heroku Proxying becomes Free Software | Heroku
We’ve transitioned to a Sustaining Engineering model to better serve the customers who rely on us every day. Our mission is simple: to provide the most stable, secure, and reliable environment for your apps and data. We will continue releasing features and functionality that align with our Sustaining Engineering goals and provide a more robust and efficient platform to our customers. Today we are
(翻訳) Ruby 2.2 のシンボル GC - FIVETEESIXONE
Ruby 2.2 の新機能にシンボル GC というものがあります。 正直、「え、シンボルって GC されないから速いんじゃないの？なのにシンボル GC で Rails が速くなるとか話聞くけど、いったいどういうことなの？」という感じでサッパリ理解できてなかったのですが、その辺りの疑問に対してまとめられている記事がありました。 Symbol GC in Ruby 2.2 とても分かりやすく素晴らしい記事だと感じたので、許可をもらって以下に日本語訳を公開します。 Symbol GC in Ruby 2.2 シンボル GC ってなに？それって気にしなくちゃいけないことなの？ リリースされたばかりの Ruby 2.2 の大きな新機能として「インクリメンタル GC」が挙げられますが、もう1つの注目すべき新機能が、この「シンボル GC」 です。 もしあなたがこれまで Ruby の世界で過ごしてきたのな
Ko1 at RubyConf 2014: Massive Garbage Collection Speedup in Ruby 2.2 - The Omniref Blog
Ko1 at RubyConf 2014: Massive Garbage Collection Speedup in Ruby 2.2 Today at RubyConf 2014, Koichi Sasada (Ko1) gave a detailed description of some massive speedups that are going to be released as part of Ruby 2.2. In addition to some minor changes to APIs and internal code cleanups, the the big wins for Ruby 2.2 appears to be a series of performance optimizations: a massive speedup of the perfo
Symbol GC
This document summarizes Narihiro Nakamura's presentation on symbol garbage collection in Ruby. It describes the problem that symbols are currently uncollectable in Ruby and outlines an idea to make symbols collectable by differentiating between immortal symbols and mortal symbols. Immortal symbols would refer to symbols used in the C layer like method names, while mortal symbols like those genera
RGenGCの発表資料を読んだ - oupoの日記
ささだこういちさんによるRGenGCの発表資料を読みました。 英語だったので条件反射的にｳｯとなったのですが印刷してボールペンを片手に辞書を開きながら読み通しました。 RGenGCとは何物か、その仕組みはどうなっているのかということに注目してまとめます。誤りがあれば指摘していただけると助かります。 世代別GCの復習 世代別GCではオブジェクトを新世代と旧世代にわけます。 オブジェクトは最初新世代として生成され、一度でもGCして生き残ったオブジェクトは旧世代となります。ふだんのGC (minor GC)では新世代のみを扱い、旧世代オブジェクトは死んでいても回収しません。たまに行うmajor GCで旧世代も含めてGCします。 世代別GCのminor GCでは次のことをします: ルートオブジェクトからたどれるオブジェクトにマークをつけます マークをつけたオブジェクトは旧世代へ移行します ただしマ
ruby-trunk-changes r47444 - r47452 - ruby trunk changes
今日はインクリメンタルGC の導入がありました!! ko1: r47444 2014-09-08 13:11:00 +0900 インクリメンタルGC が導入されました! [ruby-core:64383] [Feature #10137] 今回 CRuby に導入されたインクリメンタルGC は、既に導入されている世代別GC (RGenGC) の major GC の make & sweep の mark 処理を複数回に分割して実行することで、major GC の停止時間を分散させるようにする機能のことです。オーバヘッドがあるのでスループット(全体の処理時間)は少しのびる可能性がありますが、応答性は良くなる(グッ、と固まる時間が短くなる)ことが期待されます。 mark を断続的に実施するので、markの途中で Ruby のコードが動くことがあるため、既に mark 済みのオブジェクトにまだ
最近の Ruby のメモリ管理
最近の Ruby のメモリ管理 Recent Ruby’s memory management Koichi Sasada ko1@heroku.com K.Sasada: 最近の Ruby のメモリ管理, 2014 Summary •Ruby’s new two GC implementation • RGenGC: Restricted Generational GC • RincGC: Restricted incremental GC K.Sasada: 最近の Ruby のメモリ管理, 2014 Who am I ? Koichi Sasada from Heroku, Inc. •CRuby/MRI committer • Virtual machine (YARV) from Ruby 1.9 • YARV development since 2004/1/1 • Recen
Feature #10137: Introducing Incremental GC algorithm - Ruby - Ruby Issue Tracking System
Abstract¶ Introduce incremental GC algorithm to reduce pause time of major/full GC. This ticket includes design and implementation note and a working patch. Background and problem¶ Ruby 2.1 uses generational GC algorithm (named RGenGC) to improve GC throughput. Genrational GC algorithm separates existing objects into young generation objects and old generation objects. At the most of GC timing, GC
rebuildfm 53のRubyのGCとスレッドの話が面白かった - wyukawa's diary
Rebuild: 53: Less Code Is Better Code (Matz) rebuildfm 53のRubyのGCとスレッドの話が面白かったので書いてみる。 RubyのGCというとクックパッドがユーザのリクエスト中にGCを止めるっていう話があったぐらいなので改善が望まれる分野なんだと思います。 例えば GC を止める・Ruby ウェブアプリケーションの高速化 - 2nd life Rubyは2.1になって世代別GCが導入されるようになりました。その辺は下記に詳しいです。 WEB+DB PRESS Vol.79 作者: 成瀬ゆい,そらは(福森匠大),西磨翁,小川航佑,佐藤新悟,塚越啓介,藤原亮,堀哲也,田村孝文,桑野章弘,松浦隼人,中村俊之,田中哲,福永亘,杉山仁則,伊藤直也,登尾徳誠,近藤宇智朗,若原祥正,松木雅幸,奥野幹也,後藤秀宣,羽二生厚美,笹田耕一,平河正博,東舘智
Ruby 2.1.1 GC Tuning - Qiita
Help us understand the problem. What is going on with this article? Ruby2.1では、RGenGCによりかなりパフォーマンスが改善されている。 また、チューニングパラメータが増えているが、まとまった日本語の解説が無かったので書いてみた。 間違いがある可能性があるので、指摘は歓迎です。 RGenGCとは RGenGC(Restricted Generational Garbage Collection)については、まずはこれを読むべし www.atdot.net/~ko1/activities/rubyconf2013-ko1_pub.pdf www.atdot.net/~ko1/activities/2014_rubyconf_ph_pub.pdf Ruby 2.1: RGenGC · computer talk by
日本語訳: Ruby 2.1: Out-of-Band GC — sawanoboly.net
@azukiwasher さんからRuby2.1のGCについて解説されている記事の日本語訳を頂きました。 『WEB+DB の Ruby 2.1 特集を読んでたら、ガベージコレクション（RGenGC）の説明で参照されてた記事の次の記事がためになったので訳してみた。』 Vol.79ですね。 ソース Ruby 2.1: Out-of-Band GC · computer talk by @tmm1 Ruby 2.1: Out-of-Band GC Ruby 2.1 で GC は以前よりずっとマシになったが、相変わらず "Stop The World" な実装に変わりはない。リクエスト処理中にコレクションが始まると、リクエストへの応答時間に遅延が生じる。遅延を緩和する方法のひとつにリクエストとリクエストの間に GC を走らせる、いわゆる「Out-of-Band」がある。 OOBGC はよく知られた
Ruby 2.1: Out-of-Band GC · computer talk by @tmm1
29 Jan 2014 Ruby 2.1's GC is better than ever, but ruby still uses a stop-the-world GC implementation. This means collections triggered during request processing will add latency to your response time. One way to mitigate this is by running GC in-between requests, i.e. "Out-of-Band". OOBGC is a popular technique, first introduced by Unicorn and later integrated into Passenger. Traditionally, these
Ruby 2.1: RGenGC · computer talk by @tmm1
30 Dec 2013 Ruby 2.1 adds a "restricted" generational collector, with minor mark phases that dramatically reduce the cost of GC. Let's take a look at the evolution of Ruby's GC. Ruby 1.8: simple mark and sweep Classic mark and sweep implementation. The entire world is stopped during both phases. Traverse object graph from roots and mark live objects, using a bit inside the object structure (FL_MAR
[その1] Ruby 2.0のガベージコレクタを使いこなす - ワザノバ | wazanova
http://samsaffron.com/archive/2013/11/22/demystifying-the-ruby-gc Ruby 2.1のガベージコレクタ (GC) については、「RubyとPythonの違いからガベージコレクタを理解する [その1] [その2] 」で取り上げましたが、今回は、DiscourseのSam SaffronがまとめているRuby 2.0のGCを利用するにあたっての学びを紹介します。 1) Heaps of heaps MRIはヒープにRVALUEとして知られているオブジェクトをもつ。各ヒープは約16KB。RVALUE構造体は、マシンのアーキテクチャによって異なる量のメモリを消費する。x64マシンでは40 byte、x32マシンではサブアーキテクチャー次第で20 byteから24 byte。RVALUEはマジカルなC構造体で、Rubyの様々なローレベル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://tunemygc.com/
Ruby2.1+でのunicornのGCチューニング - Qiita
