SolrのJMXは長年私にとって悩みの種でした。ビーンが出現したり消えたりし、名前が変わったりします。New Relicがリークすることには驚きません。

唯一安定したモニタリングは、HTTP管理APIからのXML情報です。New Relicは以前（6.x？）Solrとの優れたAPM統合を持っていましたが、それをやめてしまいました。

それらとうまくやっていくことを祈っています。良い解決策を見つけたら教えてください。

私たちはNRを使用しており、時間の経過とともにパフォーマンスの低下を経験していますが、まだその原因を特定していませんでした。この情報を提供してくれて本当にありがとうございます。チケットへの公開リンクはありますか？

同じです。私たちのいくつかのアプリでNRのメモリリークに苦しんでいます。ほとんどの場合、最新のエージェントにアップグレードすることで問題が解決しました。

これがあなたにどのように影響しているかをよりよく理解するために、NRによって引き起こされたリークをどのように見つけましたか？jmapを使用しましたか、それともヒープの完全なスナップショットがありますか？

みなさん、こんにちは。

リークをトリガーするために、以下のスクリプトを使用しました：

• 古いコレクションを取得 = 現在エイリアスが指すコレクション
• 新しいコレクションを作成
• 新しいコレクションにインポート
• エイリアスを古いコレクションから新しいコレクションに移動
• 古いコレクションを削除
• 繰り返す

これを行うと、VisualVMでSolrCoreのインスタンス数が増加し、手動でのガベージコレクションの後も減少しません。

VisualVMからのヒープダンプをEclipse Memory Analyserで分析し、単一のSolrCoreインスタンスを選択してGCルートへのパスをトレースすると、
com.agent.instrumentation.solr.MeteredMetricが
org.apache.solr.core.DirectUpdateHandler2を参照し、それがorg.apache.solr.core.SolrCoreを参照していることがわかります。これがリークです。

IntelliJでcom.newrelic.instrumentation.solr-jmx-7.4.0およびcom.newrelic.instrumentation.solr-jmx-7.0.0のJARを逆コンパイルした結果、
org.apache.solr.metrics.SolrMetricManager.SolrMetricManager_Instrumentationが
org.apache.solr.metrics.SolrMetricManager.SolrMetricManagerの役割を引き継ぎ、
メトリクスを登録できますが、登録解除はできません。
org.apache.solr.metrics.SolrMetricManager.SolrMetricManagerでは、
unregisterGauges、clearMetrics、またはclearRegistryなどのメソッドが使用され、オブジェクトが閉じられるときにこれらが使用されます。
これがリークの原因であり、それをNRに報告しました。

他の方にも役立つことを願っており、他の方が同じような現象を見たことがあるかどうかを知りたいと思います。

では、よろしくお願いします。
Dan