Gorilla: A fast, scalable, in-memory time series database | the morning paper
the morning paper a random walk through Computer Science research, by Adrian Colyer Made delightfully fast by strattic Gorilla: A fast, scalable, in-memory time series database – Pelkonen et al. 2015 Error rates across one of Facebook’s sites were spiking. The problem had first shown up through an automated alert triggered by an in-memory time-series database called Gorilla a few minutes after the
the Garbage Collection Page
The GC Handbook Richard Jones, Antony Hosking, Eliot Moss covers state-of-the-art parallel, incremental, concurrent, and real-time garbage collection. Algorithms and concepts are often described with pseudocode and illustrations. Available as hardback or hyperlink-rich e-book. Second edition CRC 2023. Garbage Collection Richard Jones pools the abundant but disparate literature on the subject of ga
「Virtualを仮想と誤訳した責任は我々にあります」 - Plan9日記
書籍「ソフトを他人に作らせる日本、自分で作る米国」を読んでいたところ、元日本IBMの方によるタイトルの発言が飛び出した。この業界に長くいると、仮想記憶に仮想計算機と「仮想」という訳語にはまったく違和感を感じなくなってしまったが。。。曰く、IBMがVirtual memoryを発表したとき（MVSのことかな*1）、日本IBMが仮想記憶と訳したのだそうな。『virtualは「事実上の」「実質的」という意味であり、virtual memoryは「本来のメモリーではないが事実上メモリーとして使える技術」を意味する。』 大学時代の恩師も次のように言っていた。 「仮想」という概念が、コンピュータの世界に入ったのは、１９７５１９６５年のことである。MITがMULTICSという汎用大型TSSの構想を発表した。これが現在の、パソコンネットワーク時代の幕開けの狼煙であった。この中の技術に「仮想記憶」の概念が含
Classloader leaks: the dreaded "java.lang.OutOfMemoryError: PermGen space" exception
Did you ever encounter a java.lang.OutOfMemoryError: PermGen space error when you redeployed your application to an application server? Did you curse the application server, while restarting the application server, to continue with your work thinking that this is clearly a bug in the application server. Those application server developers should get their act together, shouldn't they? Well, perhap
メモリリークトラブルシューティング記 – その5: Memory Analyzer でヒープダンプを解析(最終回) – yusuke.blog
– その1: 自宅サーバがハング – その2: フリーズの原因はガベージコレクション – その3: 侍でヒープ使用量を確認 – その4: リーク箇所を確認する色々な方法 – その5: Memory Analyzer でヒープダンプを解析(最終回) 延々と連載してきたメモリリークトラブルシューティング記もいよいよ最終回です。 今回のメモリリーク現象はリークの再現方法がわからないため、運用環境から詳細なデータが取得できるheapdumpを取得した、というのが前回までのあらすじです。 次は、ヒープダンプの解析。 ヒープダンプは JDK に付属の jmap コマンドで取得します。 jmap -heap:format=x [pid] または jmap -heap:format=b [pid] といった形で実行するとヒープダンプを xml 形式、またはバイナリ形式で記録できます。 通常生のヒープダンプ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.vldb.org/pvldb/vol8/p1816-teller.pdf
