JVM上で動くWebアプリケーションがリソースを食いつぶす原因を探るためにやったこと【Backlog Play化プロジェクト】
ヌーラボでScalaを書くRubyistの谷本です。ヌーラボでは、Backlogの開発を担当しており、最近ではBacklogをJavaからScala / Play Frameworkに移行するプロジェクトのメンバーでした。 BacklogのPlay化プロジェクトでは、OutOfMemorryError(以下、OOM)の発生やCPU使用率とロードアベレージが上がったままという、Java Virtual Machine（以下、JVM）上で動くBacklogのパフォーマンスに関する問題に対処すべく、何度かHeap/Thread dumpを見る機会がありました。 私がPlay化プロジェクトで取り組んだパフォーマンス改善の知見や経験をもとに、本記事では「JVMで起こったパフォーマンスの問題の切り分け方」についてお届けします。 はじめに 本番環境でしばらく動かしていると、コード自体は正しく実行できるけ
C言語でインクルードするだけで使えるNon-movingで正確なコピーGCを作った - Qiita
C言語でインクルードするだけで使えるNon-movingで正確なコピーGCを作った インクルードするだけで使えるNon-movingで正確なGCをC言語用に作りました。 行数がコメントを除いて100行に満たない非常に小さなライブラリです。 GCのアルゴリズムとしてはCheneyのコピーGCを採用しています。 通常のCheneyのコピーGCではメモリ空間のうち半分が無駄になってしまいメモリ効率が悪かったり、 GC発生時にオブジェクトが移動してしまいC言語のようなポインタを直接触れる言語との相性が悪いという欠点がありました。 今回はヒープ全体を二重連結リストとして管理することでそのような問題を解決しています。 ちなみにこれはTreadmill GCのアイデアと同じです。(が、アルゴリズム自体はTreadmill GCではありません。) APIはLinuxのlist.hに非常に近い見た目になって
null安全でない言語は、もはやレガシー言語だ - Qiita
これらは、表中の「リプレース対象言語」に挙げたように、多くのメジャー言語に対する代替手段でもあります。 Java の代わりには Kotlin や Ceylon が、 JavaScript には TypeScript や Flow が、 Objective-C には Swift が、そして PHP には Hack があります。 Python は自身に null 安全 を取り込みました。 Crystal は直接 Ruby と連携して使えるわけではありませんが、 Ruby 風の null 安全 な言語です。 Rust は C++ の代替を目指して開発され、 Firefox の一部で C++ のコードを置き換えるのに使われています 2 。 null が引き起こしてきた数々の問題を考えると、僕は、 null 安全 は GC （やその他の安全なメモリ管理手法）に匹敵するプログラミング言語の進化だと考え
Node.jsでのJavaScriptメモリリークを発見するための簡単ガイド | POSTD
目次 初めに 極小理論 ステップ1. 問題の再現と確認 ステップ2. 最低3回のヒートダンプ採取 ステップ3. 問題の発見 ステップ4. 問題解決の確認 他のリソースへのリンク まとめ Something you might want to bookmark: Simple Guide to Finding a JavaScript Memory Leak in Node.js by @akras14 https://t.co/oRyQboa8Uw — Node.js (@nodejs) January 6, 2016 注釈：お気に入りに登録してください。 Simple Guide to Finding a JavaScript Memory Leak in Node.js （Node.jsでのJavaScriptメモリリーク発見簡単ガイド） @akras14 http://www.ale
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を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
