問題タブ [chronicle]

しばらく前に、ChronicleMap が として使用されていることについて、この質問Map<String,Set<Integer>>をしました。基本的に、平均Set<Integer>が 400 のコレクションがありますが、最大長は 20,000 です。ChronicleMap 2 では、これにより悪質な JVM クラッシュが発生していました。ChronicleMap 3.9.1 に移行したところ、例外が発生し始めました (少なくとも JVM クラッシュではありません)。

これは、平均値よりもはるかに外れている値を持っているためだと思います。ビルダーに与えた平均値に基づいて ChronicleMap が最大チャンク数を 6328 と判断したと思いますが、23045 チャンクを必要とする巨大な値があるとは予想していませんでした。

だから私の質問は、これを解決するための最良の方法は何ですか? 私が検討しているいくつかのアプローチですが、まだ確信が持てません:

1. ChronicleMapBuilder.maxChunksPerEntryまたはを使用しChronicleMapBuilder.actualChunkSizeます。とはいえ、それらを何に設定する必要があるかを決定論的に把握するにはどうすればよいですか? また、設定が高すぎると、断片化が多くなり、パフォーマンスが低下する可能性がありますよね?
2. 「最大コレクション サイズ」を設定し、非常に大きなコレクションを多くの小さなコレクションに分割し、それに応じてキーを設定します。たとえば、私のキーがサイズ 10000 のXYZを生成する場合、おそらくそれをサイズ 2000 のセットを持つ5 つのキー、などSet<Integer>に分割できます。その結果、不要なコードが大量に作成されます。他の質問にも同じ計画がありました。XYZ:1XYZ:2

他の考え/アイデアは大歓迎です!

これは、クロニクル キュー v3 で機能していました。v4 ではキューを作成しません。私は何を間違っていますか？ありがとう。

ChroniclechronicleSignal = ChronicleQueueBuilder.vanilla("somePath").build();

ExcerptAppender アペンダー = クロニクルシグナル.createAppender();

openHFT/java-runtime-compilerを使用して、ディスク アクセスの多用からインメモリ コンパイルのみの使用まで、ミューテーション テスト ツールを改善しようとしています。

変異テストでは、2 種類のクラスがありました 。 A. 変異クラス、その定義が常に操作/変更され、再コンパイルされるクラス。 B. その他のクラス、その定義が変更されないクラス、つまりテスト ケース クラス、または変更されたクラスが必要とするその他のクラス。

openHFT/java-runtime-compiler を使用すると、以下のコードを使用して簡単に実行できます。これは、変更されたクラスと他のクラスの両方を再コンパイルするたびに新しい classLoader を作成することでした。

これはうまく機能し、クラス A の新しい定義がコンパイルされるたびに、AClassは新しい定義に適応します。

ただし、以下のコード ( BClassが最初にロードされ、次にAClass ) のように順序が逆になっていると、これは機能しません。クラス A の再コンパイルは、新しい定義に適応せず、クラス A のコンパイルに使用された最初の定義を常に使用します。

openHFT/java-runtime-compiler ライブラリ (以下のコード) からloadFromJavaクラスを変更する必要があったのではないかと思います。私はすでに行を省略して試しています

loadFromJavaが呼び出されるたびに、すべてのソースコード (既にコンパイルされているものも含む) を常に再コンパイルするようにすることを期待していました。しかし、それは間違った結果をもたらします。

機能させるために必要な変更を指摘するのを手伝ってください。

大変お世話になりました。

編集済み

ピーター・ローリーに感謝します。あなたの提案を試してみましたが、同じ結果が得られました。A クラスは最初に使用された定義に固執し (最初の反復で)、新しい定義への変更/使用に失敗しました (次の反復で)。 .

私は症状を集めました。考えられる説明は、次の反復とは異なる最初の反復 (初めてクラスがコンパイル/ロードされた) の処理があったことです。そこから、いくつかのことを試します。

第 1 の症状

loadFromJava (下) に出力行 (System.out.println) を入れたときでした。

出力は次のとおりです。

最初の反復では、loadClassesMap には classLoader がないため、正しい出力 "loadClasses Null" (B をロードするとき) が返され、loadClassesMap には classLoader があるが、ないため、"clazz Null" (A をロードするとき) が返されました。 t は A クラス名を持っています。

ただし、次の反復では (A をロードするとき)、「clazz Not Null」が出力されます。A クラス名が既に loadedClassesMap.get(classLoader) に格納されているように見えますが、これは発生しないはずです。CachedCompiler コンストラクターで loadedClassesMap をクリアしようとしました。

しかし、それは LinkageError: loader (main/Utama$2 のインスタンス): 重複したクラス定義を試みました。

2 番目の症状

最初の繰り返しでの差別化のより強い症状は、s_fileManager バッファーをチェックしたときでした。

最初のイテレーションは予想どおりでしたが、次のイテレーションでは、s_fileManager バッファーは既にサイズ 2 を取得しているようで、0 にリセットされていません。

CachedCompiler コンストラクター (以下) で FileManager バッファーをクリアしようとしましたが、

しかし、ExceptionInInitializerError が発生します。

オフヒープメモリの仕組みに少し混乱しています。32 GB の RAM を搭載したサーバーと、サイズが約 1 TB のキーと値のマッピングのデータ セットがあります。この 1 TB のデータセットに従ってキーを値にマップできる、シンプルで高速な組み込み Java データベースを探しています。これは主にディスクから読み取る必要があります。このデータ セットの各エントリは小さいため (<500 バイト)、ファイル システムを使用するのは効率が悪いと思います。

これにはクロニクル マップを使用したいと思います。オフ ヒープ メモリの使用量が RAM サイズを超える可能性があり、何らかの方法でファイルシステムと対話することを読みましたが、同時に、Chronicle Map はメモリ内データベースとして説明されています。Chronicle Map はサーバーの 1 TB のデータ セットを処理できますか? それとも、32 GB 以下のデータ セットしか使用できないのですか?

1)クロニクル キュー v4 では、ほとんどのテスト パターンは、 がキューの最後に配置され、コードがからの新しいエントリの到着を待機しているときに、何らかの形式のDocumentContext.isPresent() ビジー状態チェックを示します。ExcerptTailerExcerptAppender

2) 非同期appender -> tailer通知用の組み込みのクロニクル キュー メカニズムはtailerありますか?appender

3）そうでない場合、そのような実装に推奨されるパターンevent listenerは何ですか？実際の例を教えてください。