Ruby 仮想マシンの動作を把握することで、アプリケーション全体のパフォーマンスを理解し、改善することができます。New Relic は、Ruby 仮想マシンの動作を把握するのに役立ついくつかの主要なメトリクスを収集します。また、パフォーマンスを向上させるためにVMの構成を調整する際の影響を評価するのにも役立ちます。
最低限の条件 Ruby VMの測定値収集は、Rubyエージェントのバージョン3.8.0以降で利用可能です（ただし、それ以前のバージョンでは、いくつかの基本的なガベージコレクション測定値の収集をサポートしていました）。
また、この機能を使用するには、CRuby 1.9.2 以降と互換性のある Ruby バージョンが必要です 。個々の測定値に関する以下のセクションでは、各測定値の収集をサポートする Ruby バージョンについて説明します。
最後に、GC のタイミングをキャプチャするために、アプリケーションで GC::Profiler を有効にする必要があります。
Ruby VMデータの閲覧 Ruby VM のパフォーマンスに関するデータを表示するには。one.newrelic.com >All capabilities > APM > (アプリを選択) > Monitoring > Ruby VMs
測定内容 これらのメトリクスのほとんどは、Rubyのガベージコレクタの動作を理解するのに役立ちます。
すべてのメトリクスをすべての Ruby バージョンで収集できるわけではありません。一般に、CRuby の最新バージョンを使用している場合、最も完全なデータを取得できます。以下のリストは、どこで何が利用できるかを正確に説明しています。
オブジェクトの割り当て 利用可能 : CRuby 2.0+
プロセスで割り当てられたRubyオブジェクトの数。UIでは、この測定値はリクエスト数で正規化されており、リクエストごとにいくつのオブジェクトが割り当てられているかを把握することができます。
オブジェクトの割り当て頻度は、Ruby のガベージコレクタの実行頻度を決定する最大の要因の 1 つであるため、これは重要な数値となります。
CRuby では、この値はGC.stat[:total_allocated_object]から派生します。
ガベージコレクションの時間 利用可能 : CRuby 1.9.2+,Rubinius 2.x (JRuby サポートについては以下の注を参照)
あなたのRubyプロセスでガベージコレクション（マークフェーズとスイープフェーズの両方）に費やされた時間です。
Rubyエージェントでは、この値を実際には2つの異なる方法で測定します。リクエスト処理の途中で発生したガベージコレクション時間と、ガベージコレクション時間の合計です。リクエスト処理の途中で発生したガベージ・コレクション・タイムは、メインの概要グラフ上に帯状に表示され、個々のトランザクションの内訳グラフにも表示されます。総ガベージコレクション時間のウォールクロック時間に対する割合は、「Ruby VMs」タブに表示されます。
この測定値はGC::Profiler.total_timeから導出されます。
注 : この測定値を取得するには、 GC::Profilerを有効にする必要があります。詳細については、 GC インスツルメンテーション を参照してください。
JRuby 注 : JRuby または特定のバージョンの JVMのバグ と思われるものにより、JRuby では GC のタイミングが 1000 倍もずれている可能性があります。このため、現在、JRuby でGC::Profilerを有効にすることはお勧めしません。
ガベージコレクタの実行頻度 利用可能 : CRuby 1.9.2+,JRuby 1.7+、ルビニウス 2.x
Ruby プロセスを実行するためにガベージ コレクターが停止する必要がある頻度はどれくらいですか?CRuby 2.1+ では、これはメジャー GC 実行とマイナー GC 実行に分割されます。この数は、GC 実行ごとに処理されるリクエストの数として UI に表示されます。
使用中の Ruby のバージョンに応じて、この値はGC.countまたはGC.stat[:minor_gc_count]とGC.stat[:major_gc_count]から導出されます。
Rubyのヒープの大きさ 利用可能 : CRuby 1.9.2+
Ruby インタープリタはオブジェクトを ヒープ に格納し、各オブジェクトは ヒープスロット を 1 つ占有します。ヒープ内のスロットがオブジェクトでいっぱいになると、必要に応じてRuby VMによってヒープが拡張されます。
Rubyエージェントは、ヒープ内のライブオブジェクトの数と、ヒープの未使用スロットの数を定期的に測定します。
一般的に、ヒープ上のオブジェクトが多ければ多いほど、各GCの実行に時間がかかります（ヒープ上のすべてのオブジェクトを調べる必要があるため）。また、ヒープ上のオブジェクトが多いと、アプリケーションのメモリ使用量が多くなります。
この値は、 GC.stat[:heap_live_slot]またはGC.stat[:heap_live_num] 、およびGC.stat[:heap_free_slot]またはGC.stat[:heap_free_num]から導出されます。
メモリ使用量 Available on : 任意のRubyバージョン
この測定値は、Rubyプロセスのメモリ使用量（レジデント・セット・サイズ）を、インスタンス（プロセス）ごとの平均サイズで表示します。メモリ使用量をチェックすることは、Ruby VMの設定を調整する際の重要な考慮事項です。メモリ使用量が大きくなりすぎると、ホストマシンがディスクへのページングを開始したり、ソフトウェアによるメモリ制限に抵触したりする可能性があります。
Linux ホストでは、これは/proc/PID/statusのVmRSSフィールドから導出されます。
メソッドキャッシュ無効化率 利用可能 : CRuby 2.1+
オブジェクト上でメソッドが呼び出されるたびに、Ruby はそのオブジェクトの祖先の連鎖を検索してメソッドの実装を見つけなければなりません。これらの検索にはコストがかかるため、Ruby VM は検索結果をキャッシュします。
CRuby の古いバージョン (2.0 より前) では、単一のグローバル メソッド キャッシュがあり、キャッシュ全体を無効にするさまざまな操作 がありました。
CRuby 2.1 以降では、グローバル キャッシュがクラスごとの小さなキャッシュ セットに分割されているため、1 つのクラスに対するキャッシュ無効化の変更によって、関連のない他のクラスのキャッシュ エントリが破棄されることはありません。
しかし、すべてのメソッド・キャッシュを無効にしてしまう操作もあります。Rubyエージェントはこれらの無効化の頻度を測定し、リクエスト数で正規化して報告します。これにより、リクエストごとに何回メソッド・キャッシュが無効化されるかを知ることができます。
詳細については、Aman Gupta による ブログ投稿を 参照してください。
この値はRubyVM.stat[:global_method_state]から導出されます。
一定のキャッシュ無効化率 利用可能 : CRuby 2.1+
Ruby では、上述のメソッドキャッシュの動作と同様の方法で定数の位置をキャッシュします。Ruby エージェントは、グローバル定数キャッシュが無効化された回数を測定し、リクエストごとの平均無効化回数として報告することもできます。
この値はRubyVM.stat[:global_constant_state]から導出されます。
糸数 利用可能 : CRuby 1.9.2+,JRuby 1.7+、ルビニウス 2.x
Ruby エージェントは、Ruby プロセスのスレッド数を把握することができます。マルチスレッドの Web サーバを使用している場合、この機能を使って、スレッドプールが実際に設定したサイズになっているかどうかを確認できます。また、スレッドリーク（削除されないスレッドを生成すること）が発生しているかどうかを確認することもできます。
バックグラウンド・プロセス デフォルトでは、New Relic の特定のアプリケーション名にレポートしているすべてのプロセスからのデータは、ユーザーインターフェイスの Ruby VM ページで結合されます。これは、同じNew Relicアプリケーションにウェブプロセスとバックグラウンドプロセス（Resque、Sidekiq、DelayedJobなど）の両方がレポートしている場合、データが混乱する可能性があることを意味します。
この問題を回避するには2つの方法があります。
app_name構成設定またはNEW_RELIC_APP_NAME環境変数を設定して、Web プロセスとバックグラウンド プロセスを New Relic の個別のアプリケーションにプルします。構成ファイルでdisable_vm_sampler: trueを設定するか、アプリケーションの環境でNEW_RELIC_DISABLE_VM_SAMPLER=1を設定して、バックグラウンド プロセスでの Ruby VM メトリックの収集を無効にします。 その他のドキュメントリソース その他のドキュメンテーションリソースには、以下が含まれます。