Tips for writing clear, performant, and idiomatic Go code
![Getting to Go: The Journey of Go's Garbage Collector - The Go Programming Language](https://cdn-ak-scissors.b.st-hatena.com/image/square/61955b2029cca886435bd7bb93b949e8f18ae48d/height=288;version=1;width=512/https%3A%2F%2Fgo.dev%2Fdoc%2Fgopher%2Frunningsquare.jpg)
This post is not available in your language. Here are some other options: English Go memory ballast: How I learned to stop worrying and love the heap I’m a big fan of small code changes that can have large impact. This may seem like an obvious thing to state, but let me explain: These type of changes often involve diving into and understanding things one is not familiar with. Even with the most we
Phusion Passenger now supports the new Ruby 2.1 Out-Of-Band GC Phusion Passenger is a fast and robust web server and application server for Ruby, Python, Node.js and Meteor. Passenger takes a lot of complexity out of deploying web apps, and adds powerful enterprise-grade features that are useful in production. High-profile companies such as Apple, New York Times, AirBnB, Juniper, American Express,
EngineeringPerformance Impact of Removing OOBGCUntil last week, GitHub used an Out of Band Garbage Collector (OOBGC) in production. Since removing it, we decreased CPU time across our production machines by 10%. Let's talk about… Until last week, GitHub used an Out of Band Garbage Collector (OOBGC) in production. Since removing it, we decreased CPU time across our production machines by 10%. Let’s
James FisherはGHCのランタイムシステムが彼らのHaskellのプログラム上でレイテンシに悪影響を及ぼしたケースを、ブログに投稿しています。 低レイテンシ、大きなワーキングセット、そしてGHCのガベージコレクタ:3つのうち2つを選べ この記事では、その問題(基本的に、レイテンシはコピー時間の影響を受ける)を示す非常にシンプルな合成ベンチマークを提案していて、さらに「50ミリ秒のレイテンシは過剰」と言っています。それで、他のGCがどのようにこの問題を処理しているかを見るため、OCamlとRacketで合成ベンチマークを再現したら面白いだろうと思いました。 細かい話は抜きにすると、要点は次のとおりです。OCamlのGCは古い世代にある大きなオブジェクトに関しては問題はありません。コレクションをコピーするのではなくマーク & スイープで処理するためで、このベンチマークではワーストケー
gc(garbage collection)とは 確保したメモリを自動的に解放してくれる仕組み メモリを確保する際は、アプリケーションが要求した量より多い量が確保される。その多い分は、要求したメモリの管理のためで、管理領域があることで要求したメモリが辿れるようになっている。アプリケーションが要求した領域を解放する際は、管理領域を使って、順次メモリを辿っていき、合致する領域を探すといった事を行う。 mark & sweep 古典的なgcの一つにmark & sweepがある mark & sweepでは、使っていないメモリを探して解放する。 例えば、rootと呼ばれるglobal変数があって、rootからたどることが出来る(参照がある)場合は、まだ使っていると判断出来る。反対に、どこからも参照されていない場合、そのメモリはもう使っていないと判断できる。 このように、どこからも参照されていない
世代別ガベージコレクション (英: generational garbage collection) はガベージコレクションの手法のひとつである。別名として、ジェネレーション・スキャベンジング (英: generation scavenging) とも呼ばれる。以下、ガベージコレクションをGCと省略する。 概要[編集] GCを持つ言語上で動く実システムでは、経験上メモリオブジェクトの利用に、ある偏りが存在する。それは「計算途上で利用される一時オブジェクトは数が多く、かつすぐさま破棄される率が高い」「ある程度長く生存したオブジェクトは、以降も長く生存する率が高い」という傾向である。 この傾向に着目し、メモリ領域を2つの世代に分離する。 第1世代 (young generation) に属するオブジェクトは小さな領域で高速なコピーGCを繰り返し、積極的に回収する。 第2世代 (old gene
JVMにチューニング項目は多々あれど、プロダクションで運用する際に予めおさえておきたい項目をまとめてみるエントリです。*1 勿論、OSもJVMもデフォルトである程度のパフォーマンスは発揮でき、計測を伴わないチューニングは悪手であることはよく知られています。 しかし、設定しておかないとパフォーマンスにそのまま影響すると分かるものを調べないのは裸で戦場に赴くようなものです。*2 どんな項目をどう変更すれば良いのか知っていることは重要な武器なのです。 なぜ調べるのか 今回、チューニングポイントを調べるにあたって、私のモチベーションはどこにあるのかを考えると、以下の要件を満たしたいということがあげられます。 アプリケーションとして求められる品質水準として動作する → 性能目標 異常時に事象を追うことができる ここでいう品質水準・異常とは、パフォーマンスが明らかに低い、アプリケーションがクラッシュす
Rubyでは、作成したオブジェクトがなにかのタイミングでGCによってメモリから解放されています。 一般的なオブジェクトは、どこからかに参照されている間は必要、参照されていないなら不要とGCに判断され、メモリから解放されます。 例外的に 弱い参照 -Wikipedia として定義されたオブジェクトは、まだ参照されていてもなにかのタイミングでGCにぽいぽいされてしまいます。 一見、使いようが無いようですが、生成コストがかかる値をキャッシュしておき、メモリに余裕がない場合(一般にGCが動くタイミング)にキャッシュを破棄する、というようなことができます。 機能の実現に必要となることはありませんが、速度改善などに役立つテクニック的な。 なおタイトルはてきとーです。「○○編」と書いていますが、別の編があったりはしません。たぶん。 Ruby2.1で動作検証をしましたが、1.9以降ならたぶん大丈夫なんじゃ
お世話になっております。五十島と申します。 Armadillo-IoTからTreasure Dataにログデータを格納する際に、fluentdを使用しています。 fluentdのメモリ使用量がいつの間にか肥大化しており、他プログラムを実行すると 「Cannot allocate memory」というエラーが出て、実行したプログラムが異常終了します。 fluentdのメモリ使用量を減らすことはできるでしょか。 fluentdの設定は下記記事を参考に行いました。 https://users.atmark-techno.com/blog/46/1219 /etc/config/fluent.confに次のように記述しています。 <source> type tail format json path /etc/config/fluent/fluent-log pos_file /etc/confi
Anyone who’s run Unicorn (or Puma, or Einhorn) may have noticed a curious phenomena. Worker processes that have been forked from a master start with low memory usage, but before too long will bloat to a similar size as their parent. In a big production installation, each worker can be 100s of MBs or more, and before long memory is far and away the most constrained resource on servers. CPUs sit idl
Rodrigo Kumpera, Miguel de Icaza May 17, 2017 runtime Concurrent GC In Mono 5.0 we are shipping a new operation mode for our Garbage Collector: Concurrent Garbage Collection. Traditionally, when Mono’s memory manager determined that it should perform a garbage collection, the collector had to pause all Mono running threads, perform the garbage collection, and once it was done, it resumed the execu
Where to get the collector Platforms Scalable multiprocessor versions Some collector details Further reading Current users Local links for this collector Local background Links Contacts, Updates, and Reporting Issues Translations of this page [ This is an updated version of the page formerly at http://www.hpl.hp.com/personal/Hans_Boehm/gc, and before that at http://reality.sgi.com/boehm/gc.html an
This document discusses the internals of SGen. If you are interested on how to use SGen and how to tune it for your own application workloads, see the document Working With SGen. For a few releases, Mono has shipped with a new garbage collector, we call this the SGen garbage collector. This garbage collector can be enabled by passing the –gc=sgen flag to Mono or if you are embedding Mono, by linki
The Boehm–Demers–Weiser garbage collector, often simply known as the Boehm GC or Boehm collector, is a conservative garbage collector for C and C++[1] developed by Hans Boehm, Alan Demers, and Mark Weiser.[2][3] Boehm GC is free software distributed under a permissive free software licence similar to the X11 license. The first paper introducing this collector appeared in 1992.[4] Design[edit] Hans
Summary: Have you ever wondered how the heck Ruby's GC works? Let's see what we can learn by reading some of the statistics it provides us in the GC.stat hash. (1560 words/8 minutes) I call that an object leak. Most Ruby programmers don’t have any idea how garbage collection works in their runtime - what triggers it, how often it runs, and what is garbage collected and what isn’t. That’s not entir
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く