Node.js でメモリ肥大化の原因を特定してみた
はじめに ユビーでエンジニアをしているおおいしつかさです。 これは、Ubie Engineering Advent Calendar 2023の12月7日の記事になります。 何を書こうかなー、最近はユビーの根幹システムのリアーキテクチャをやっているのでその辺かなーと思ったのですが、まだ仕掛かり中だということと具体な業務に直結しそうな内容なので抽象化して書くのが面倒そうだなーと思ってたところに軽いトピックが飛び込んできたので、そのことを書くことにしました。 ChatGPTはみなさん使われていると思いますが、ぼくも別の業務でOpenAI関連の機能開発に携わっています(ユビーで働くといろんな業務に携われるのがいいところです) 。 その仕事の中で、Node.js環境でメモリ肥大化の事象に遭遇したので、それをどのように発見して改善したかについてお話します。 ぼくは今も昔もRubyが大好きですが、ふだ
GoのGC (garbage collector)について理解する
プロトタイピングによる不確実性の低減 / Reducing Uncertainty through Prototyping
GoはいつGCするのか?
TL;DR Go(のランタイム)は以下のタイミングで自動的にGCを実行する 前回のGC後に占有していたメモリと同量を新たに確保したとき 前回のGCから2分後 cgroupなどでメモリ制限しているときは、メモリ使用量が制限の50%以上になったらruntime.GC()を呼び手動でGCすべきである 前置き: GoとOOMのこれまで 以下はGo 1.16での調査結果です。Goのバージョンが異なった場合は事情が異なる可能性があります。 Goでプログラムを書く際に、使用メモリ量を気にしなければならないシーンはGCのおかげでそう多くはありません。実際それは間違いではないのですが、運用まで視野に入れるとそうは言ってられないことがあるのもまた現実です。昨今はコンテナの利用が当たり前になったことに伴い、OOMによりプロセスが強制的に終了させられることもあり、それを避けるために一定量以下のメモリで動くことが重
Rustの所有権（ownership）を語義から理解する - igagurimk2の日記
所有権（ownership）と借用（borrowing）とライフタイム（lifetime）はRust特有の言語仕様として有名である。 Rustではガベージコレクション（GC）を使用せずにメモリ安全性を確保するために所有権と借用とライフタイムの仕様を採用している。 この機構によって、Rustではプログラマが変数の値が有効である範囲を意識する必要がある代わりに、GCに関する実行時のオーバーヘッドがなくともメモリ安全でありスレッドセーフであるプログラムを記述することができる。 一方で、所有権は「『変数が値の所有権を持っている』というのは結局何のことなのかわからない」という混乱を生む要因でもある。 単純に考えると、変数に値が入っているのだから、変数が値を持っているのは当然のことのように思える。 そうすると、「値の所有権を持つ」とは一体何のことを言っているのかがはっきりとしなくなってしまう。 この混
JavaのGCの仕組みを整理する - Qiita
最近メモリを大量に使うJavaのプロセスに関する仕事があり、GCの知識が必要になったので調べたことをまとめておきます。調べたら色々出てくる時代ですが考えを整理するために書きました。間違った認識をしている可能性はあるのでそこはご指摘いただけると幸いです。 注: この記事は最新のGC事情を整理するものではなく、古典的?な手法について書いてます。 JVM まずはざっくりJavaの基本的な仕組みから。 JavaのプロセスはJVMと呼ばれる仮想マシンの上で動作します。この仕組みは様々なOSで動作し、環境の差異を気にする事なくコンパイルされたJavaのコード(クラスファイル)を様々な環境で実行可能にしてくれます。 JVMにはいくつ種類がありますが、本記事はOpen JDKで用いられるHotSpot VMの場合を想定しています。(他のJVMとの違いはわからない) ヒープ領域 Javaのプロセスを開始する
Chromium のメモリ管理 (Oilpan) - Qiita
はじめに 前回の PartitionAlloc の記事 に続いて、PartitionAlloc と双璧をなす Chromium のメモリ管理 Oilpan について紹介します。 本文中に出てくるデバッガー コマンドは、以下のエクステンションに含まれています。 GitHub - msmania/chromium-debug: Debugger extension for Chromium https://github.com/msmania/chromium-debug Oilpan 概要 Chromium プロジェクト公式のページはこちらです。 Blink GC Design https://chromium.googlesource.com/chromium/src.git/+/master/third_party/blink/renderer/platform/heap/BlinkGC
ざっくりわかった気になるモダンGC入門 - Cybozu Inside Out | サイボウズエンジニアのブログ
どうも！@yokotaso です！ 2018/05/26のJJUG CCC 2018で「ざっくりわかった気になるモダンGC入門」というタイトルで登壇させていただきました。 現在開発中の新しいGCアルゴリズムをざっくり理解することをテーマに発表しました。 発表練習用に作ったカンペの内容を公開します。ブックマークコメントでもツイートでも感想を書いていただけると喜びます！ 発表資料は、speakerdeck にあります。はじまり〜はじまり〜 はじめに 今日はざっくりわかった気になるモダンGC入門というお話をさせていただきます。 現在開発中のGCアルゴリズムの全体像を理解してもらうことを目的としたセッションです。よろしくおねがいします。 さて今日のアジェンダですが、まず簡単にこれまでのGCを復習した後に新しいGCが必要になってきた背景について少し話します。 次にShenandoahGC、ZGC、E
C言語でインクルードするだけで使えるNon-movingで正確なコピーGCを作った - Qiita
インクルードするだけで使えるNon-movingで正確なGCをC言語用に作りました。 行数がコメントを除いて100行に満たない非常に小さなライブラリです。 GCのアルゴリズムとしてはCheneyのコピーGCを採用しています。 通常のCheneyのコピーGCではメモリ空間のうち半分が無駄になってしまいメモリ効率が悪かったり、 GC発生時にオブジェクトが移動してしまいC言語のようなポインタを直接触れる言語との相性が悪いという欠点がありました。 今回はヒープ全体を二重連結リストとして管理することでそのような問題を解決しています。 ちなみにこれはTreadmill GCのアイデアと同じです。(が、アルゴリズム自体はTreadmill GCではありません。) APIはLinuxのlist.hに非常に近い見た目になっています。 ある構造体をgcで管理したい場合はstruct gc_head型のメンバを
Go言語のリアルタイムGC 理論と実践 | POSTD
(編注：誤訳、意味の分かりづらい訳を修正しました。リクエストありがとうございました。) 毎日、Pusherは数十億のメッセージをリアルタイム、つまり送り元から宛先まで100ms未満で送信しています。どのようにしてそれを可能にしているのでしょうか。重要となる要因はGoの低レイテンシのガベージコレクタです。 ガベージコレクタはプログラムを一時停止させるものであり、リアルタイムシステムの悩みの種です。そのため、新しいメッセージバスを設計する際には慎重に言語を選びました。Goは 低レイテンシを強調している ものの、私たちは懐疑的でした。「本当にGoを使えば実現できるのか？ もしできるならどうやって？」 このブログ記事ではGoのガベージコレクタを、どのように機能し（トリコロールアルゴリズム）、なぜ機能し（こんなに短いGCによる一時停止時間の実現）、そして何よりも、それが機能するのかどうか（GCによる
Go言語の低レイテンシGC実現のための取り組み | POSTD
(訳注：2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) 私たち Twitch では、通信が大変混み合うシステムの多くで Go を採用しています。ライブ映像を配信したり、何百万人というユーザにチャットサービスを提供したりする場合に直面する問題を考慮すると、Goはそのシンプルさや安全性、パフォーマンス、読みやすさの点で良いツールだと言えます。 しかしこれは、私たちにとってGoがいかに素晴らしいツールかを説明する、よくある記事ではありません。Goで現在実装されているランタイムにより行き詰まったいくつかの局面をどう打開するか、さらに、私たちはそうした限界に達した時にどう対応したらいいのかについて書いたものです。 これからお話しするのは、「Go 1.4からGo 1.6へのGoランタイムの改善が、どのようにしてガベージコレクション（GC）の停止時間を20倍も改善することに
Java 7 CMS GCの基本的な情報の整理 - nekop's blog
バッチ処理などスループット重視のアプリケーションはデフォルトのパラレルGCで良いが、Java EEアプリケーションサーバなどレスポンスタイム重視のものやHadoopなどのクラスタ系ソフトウェアで死活監視に引っ掛る系などのstop the worldをなるべく避けたいいわゆるサーバ系ソフトウェアを運用する場合には、UseConcMarkSweepGCを付与して停止時間の短いCMS GCを使う。その場合にCMSのチューニングに踏み込もうとするとなんだか難しい記述がいっぱいで若干困るので、簡単なガイドをメモとして書いておく。 対象バージョンは以下。 $ java -version java version "1.7.0_51" OpenJDK Runtime Environment (fedora-2.4.5.1.fc20-x86_64 u51-b31) OpenJDK 64-Bit Serve
徹底解剖「G1GC」 アルゴリズム編
書誌情報 著者: 中村成洋 発行日: 2011-06-27 最終更新日: 2012-02-03 バージョン: 1.0.0 ページ数: 62ページ(A4PDF版換算) 対応フォーマット: EPUB, PDF 出版社: 達人出版会 対象読者 高度なGCのアルゴリズムに興味のある方。すでに『ガベージコレクションのアルゴリズムと実装』を読まれていて、続きを読みたい方 著者について 中村成洋 中村成洋（nari）はネットワーク応用通信研究所に勤めているRubyistです。仕事ではRailsを使ってWebアプリケーションを開発しています。高校を卒業してからはアイス工場に2年半いて、それからプログラマに転職しました。 GCに魅了されてしまった人間で、GC歴は4年になります。CRubyのコミッタとして1年に1度のペースでGCの改善に取り組んでいます。去年はCRubyに新しく取り込まれたLazySweepG
スレッドローカルGCって？
くまぎ @kumagi 僕の観測範囲では、日本で今一番熱狂的なブームを巻き起こしているのはスレッドローカルGCなんだけど、ググってもまともな説明が見当たらない。自分のスタックフレームだけ見るM&Sじゃ誤爆しかしないだろうし想像が付かない。 2011-04-08 13:38:54 IGARASHI Shinji＠無職 @s50 @kumagi D的にスレッドは激しく隔離されてて「ほとんど」共有するものがないけど、GCは正直よっぽど変な思い付きする人が出なけりゃ共有でいくだろうなーとか思ってマス 2011-04-08 13:42:02
メモリ破壊の現場を見つけるTips - I am Cruby!
RubyAdventJP, GC, Ruby（この記事はRuby Advent Calendar jp: 2009 : ATNDの4日目です。前日はmrknさんでした） 健全なるRubyistであれば、RubyのGCをいじることが週に一度はあるでしょう。そのときに困るのが、GCをいじってしまったことによるバグの修正です。GCをいじるというのは想像以上に難しく、少しでも書き間違えるとメモリ破壊が発生します。そのときに使えるTipsをこの記事で書くことにします。 みなさんご存じの通り、メモリ破壊というのは原因を特定するのが困難です。これは問題が発覚する場所とメモリ破壊が起こった現場が位置的に遠いことに起因しています。偉大なるハッカーのまつもとさんですら、その発見は困難です。 [ruby-dev:38628] Re: [BUG: trunk] called on terminated objec
Network Attached Processing の Pauseless GC
更新履歴 (2005.11.18) 脚注*2を加筆。 (2005.11.17) 文章を推敲。 (2005.11.14) NMT bit の read barrier について嘘を書いていたので修正。 目次 前置き Pauseless GC Marking Phase Relocation & Remap Phase おしまい 参考文献 Azul Sysmtes (米日) は Java や .NET に特化した専用計算機 Network Attached Processing (NAP) を提唱し、 製品として Azul Compute Appliance を開発した。 Azul Compute Appliance は、 すでに稼動中の Solaris/Linux の J2SE/J2EE システムの Java VM を Azul Systems が提供するスタブ JVM に置き換えるだけで、
Scalaで実装するGC
AZAREA-Cluster (Hadoop Conference Japan 2013 Winter Demo Image) AzareaCluster
GC - GCアルゴリズム詳細解説 - livedoor Wiki（ウィキ）
GC¥¢¥ë¥´¥ê¥º¥à¾ÜºÙ²òÀâ ÆüËܸì¤Î»ñÎÁ¤¬¤¹¤¯¤Ê¤¤GC¥¢¥ë¥´¥ê¥º¥à¤Ë¤Ä¤¤¤Æ¾ÜºÙ¤Ë²òÀ⤷¤Þ¤¹ ¥È¥Ã¥×¥Ú¡¼¥¸¥Ú¡¼¥¸°ìÍ÷¥á¥ó¥Ð¡¼ÊÔ½¸ GC ºÇ½ª¹¹¿·¡§ author_nari 2010ǯ03·î14Æü(Æü) 20:47:11ÍúÎò Tweet ¤³¤ÎWiki¤¬Ìܻؤ¹½ê GC¤È¤Ï¡© GC¤ò³Ø¤ÖÁ°¤ËÃΤäƤª¤¯»ö ¼Â¹Ô»þ¥á¥â¥ê¹½Â¤ ´ðËÜ¥¢¥ë¥´¥ê¥º¥àÊÔ Reference Counter Mark&Sweep Copying ±þÍÑ¥¢¥ë¥´¥ê¥º¥àÊÔ IncrementalGC À¤ÂåÊÌGC ¥¹¥Ê¥Ã¥×¥·¥ç¥Ã¥È·¿GC LazySweep TwoFinger Lisp2 Pa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - authorNari/minigc: minimum gc
GC本をGCしないための100の方法
Home · ujihisa/nari.gc Wiki · GitHub