私は、さまざまな量のメモリ (1GB - 16GB) を使用して、さまざまなアーキテクチャで同じデータベースのアプリケーションを実行しています。データの一括インポートを行うと、タイムアウトやメモリ不足エラーが頻繁に発生します。
ドキュメントを見た後、大量のインポートの下で良好なパフォーマンスを得るためのベスト プラクティスを概説しているように見えるこの役立つドキュメント(およびこのドキュメント) にたどり着きました。
私はパフォーマンスにはあまり関心がありませんが、インポートを「うまく機能させる」ことに関心があります。これは私の主な質問につながります：
任意の大規模なインポート プロセスが特定のマシンで終了することを保証するための最小限の複雑さの構成は何ですか?
この構成は、使用可能なメモリの関数である可能性があることを理解しています。それで問題ありません。また、パフォーマンスが最大限に発揮されない可能性があることも理解しています。それもいいです。しかし、それが終了することを知っておく必要があります。
あなたの質問から欠落している重要な情報は、データのタイプとその分布、および一括インポート中にシステムで使用できるメトリックであると思います。なんで？
Datomic のトランザクション レートは、バックグラウンドのインデックス作成ジョブのコストによって制限されます。そのインデックス作成のコストは、新しい値の分布とデータベースのサイズの関数です。
これが意味することは、たとえば、インデックス化された属性 (つまり:db/index) があり、一括インポートが行われるときに、それらの属性値の分布がランダムである場合、書き換え時にインデックス作成ジョブに多くの圧力をかけることになります。増え続けるセグメント。データベースのサイズが大きくなるにつれて、インデックス作成がトランザクターの作業を支配し、追いつくことができなくなります。
ドキュメントで説明されているように、より多くのメモリを に与えることができればobject-cache-max、より良い結果が得られます。これは、データに多くの一意性制約 (つまりdb/unique) がある場合に特に重要です。これにより、トランザクターが一部のストレージ セグメントを複数回フェッチすることが防止されるからです。
データの分布によっては、 と の設定を大きくするmemory-index-thresholdとmemory-index-max、インポートの実行時間が長くなる可能性があります... インデックス作成ジョブが追いつかなくなるまで。これはあなたに起こっていることのようです。
memory-index-thresholdとのmemory-index-max設定を減らしてみてください。これは直感に反するように思えるかもしれませんが、インポートを完了する可能性がはるかに高くなります (もちろん、時間がかかりますが、完了することはほぼ保証できます)。重要なのは、インデックス作成ジョブに追いつくことができなくなる前に、トランザクターが (ピア) リクエストを抑制できるようにすることです。