Cicada：Dependably Fast Multi-Core In-Memory Transactions - 急がば回れ、選ぶなら近道
Cicada: Dependably Fast Multi-Core In-Memory Transactions https://www.cs.cmu.edu/~hl/papers/cicada-sigmod2017.pdf SIGMOD2017で発表されている。現状の分散OLTPのアーキテクチャをうまくまとめて、欠点をうまくカバーアップし、言って見れば次世代MVCCの一つの形を提示している。その上で、現在世界最高のパフォーマンスを叩き出している。現時点で世界最速DB（ただし自称）。 現状の分散OLTPは大きな流れは、SILO/Foedus/MOCC/等のOCC系、すなわち2PLをベースにした実装で理論上はmonoversionでのserializableの実現を行っている方式と、Hekaton/HyPer/Bohm/ERMIAといったMVCC系、すなわちMVTOの派生をベースにしてmu
Golangの新しいGCアルゴリズム Transaction Oriented Collector（TOC）
http://golang.org/s/gctoc Goの新しいGCのProposalが出た．まだProposal段階であり具体的な実装はないが簡単にどのようなものであるかをまとめておく． GoのGCはGo1.5において単純なStop The World（STW）からConcurrent Mark & Sweepへと変更され大きな改善があった（詳しくは“GolangのGCを追う”に書いた）．先の記事に書いたようにGo1.5におけるGCの改善は主にレイテンシ（最大停止時間）に重きが置かれいた．数値目標として10msが掲げられGo1.6においては大きなヒープサイズ（500GB）においてそれを達成していた． GCの評価項目はレイテンシのみではない．スループットやヒープの使用効率（断片化の対処）なども重要である．Go1.6までのGCではそれらについて大きく言及されていなかった（と思う）．例えばスル
OutOfMemoryError の調べ方 - Qiita
OutOfMemoryError (以下 OOME)が起こったときにお手上げ状態にならないためにも、 Java のメモリ管理の仕組みとか、 OOME が起こったときの調査方法とかを調べる。 環境 OS Windows 7 > java -version java version "1.8.0_74" Java(TM) SE Runtime Environment (build 1.8.0_74-b02) Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode) Java 8 で、 Oracle の JVM を前提とした話です。 Java のメモリ管理 これを知っておかないと、 OOME が起こっても、メモリ内で何が起こっていて、どこを調査すべきで、どのように対処したらいいのかが判断できない。 なので、まずは、そもそも J
CPython の GC チューニング - methaneのブログ
ISUCON は Go で参戦しているんだけど、複数のチームが Python で予選通過したらしいので、応援のために Tips を公開していこうと思う。 目次 CPython の GC について 統計情報を出力する 第一世代GCの間隔を調整する Out of Band GC 循環参照を見つけて対処する CPython の GC について CPython のGCは参照カウント＋循環参照コレクタだ。そして参照カウント方式は(幾つかの欠点はあるものの)Webアプリのボトルネックになったりはしにくい。 なのでGCチューニングの基本は次のようになる。 循環参照を避ける 循環参照コレクタの呼び出しタイミングを制御する 循環参照コレクタは、生きているオブジェクトの数がある程度増えると第一世代が実行され、第一世代が一定回数実行されると第二世代が、第二世代が一定回数実行されると第三世代が実行される。 各世代
[その２] RubyとPythonの違いからガベージコレクタを理解する - ワザノバ | wazanova.jp
http://patshaughnessy.net/2013/10/30/generational-gc-in-python-and-ruby 前回のエントリーはこちら。 ブタペストで開催されたRUPY2013でのPat Shaughnessyのプレゼンの後半です。RubyとPythonのガベージコレクタの違いを、今回は、Pythonの循環データ構造への対応とRuby 2.1の世代別ガベージコレクタの話題に触れながら、紹介しています。 1) Pythonの循環データ構造と参照カウント Pythonは、いくつのポインタがそのオブジェクトを参照しているかを、参照カウントと呼ばれる整数で管理している。変数もしくはオブジェクトが、そのオブジェクトを参照しはじめれば数字が増えて、プログラムがそのオブジェクトを使うのをやめれば数字が減る仕組み。 1960年代以来、コンピュータ科学者が気づいているアルゴ
RubyとGCについて - mirichiの日記
思ったことをつらつらと支離滅裂な個人的メモ。 １．シンプルマルチスレッドGC このあいだからいじってるやつだが、とりあえず世代別GCがあるのとないので3倍も違うというのはおかしいのでまだどこかバグっているんじゃないかと思う。効率面での話なのでヒープスロットの取得・解放戦略のへんが怪しい。 単純な再帰型マーク関数を2つのスレッドで同時に動かすというのは、まあそれなりに短時間で終わるのだろうが、それはあくまでも遊んでるCPUがあるという前提であって、システム全体のスループットとしてはたぶんあまり嬉しい話ではないだろう。作るのは楽だが無駄が多い。 このシンプルな手法が通用するのは関数を再帰呼び出しするというマシンスタックを使った探索の場合のみであり、たとえばmrubyやrubyのようにリストを繋いだりたどったりする方法ではリストのアクセスに排他制御が必要になって思ったような性能は出ないと思われる
メモリリークとは何か - kuenishi's blog
メモリリークに悩まされている技術者は多いだろう。メモリリークが嫌でGCという技術が開発されたといっても過言ではないし、歴史的にはC++からJavaへシフトが起きた大きな理由のひとつといっていい。Unix系の簡単な定義でいえば、ヒープ領域を指すポインタ（アドレス）をロストしてしまえばそのメモリはもう漏れたといってよい。たとえばこういったコードだ。 struct { int i; char c; } spam; int main(){ void* p; int i; for(i=0; i<1024; ++i){ p = malloc(sizeof(struct spam)); } pause(); } このコードではpause(3)の時点で約5KBのメモリが漏れている。free(3)を使えばメモリをOSに返却できるが、アドレスが分からないので返却できない。 ところが、ここでいいたいのは、メモリ
C++ のヘッダファイルを #include するだけで使える GC 書いてみた - kazuhoのメモ置き場
そういえば C++ のヘッダファイルを #include するだけで使える GC を書きました。使い方は下のサンプルコードを見てもらえばいいとして、特徴としては、 ヘッダファイルを #include するだけで使える C++ の標準機能だけを使っているのでポータブル*1 mark-and-sweep, precise GC ってなあたりでしょうか。コードは GitHub - kazuho/picogc: a tiny, portable, precise, mark-and-sweep GC in C++ にあります。 C++ のプロジェクトで、ちょっとここだけは GC がほしいんだけど、ってなケースで使いやすいと思います。速度も、そこそこでるんじゃないかな*2。 というわけで、以下、サンプルコード。軽く説明しておくと、 GC を使うクラスは picogc::gc_object を継承する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
runtime: reported Go 1.6 GC throughput problems · Issue #14161 · golang/go
Ruby 2.1がガベージコレクションを変更，大規模システムでの批判に対処
I am Cruby!