背景
Excel Importer を使用してデータをインポートする場合、データ量が 1w 行を超えると、OutOfMemory エラーが発生することがよくあります。(Excel Exporter を使用してデータをエクスポートする場合も、同様の問題が発生します)。
通常の症状は次のとおりです。つまり、数行インポートに成功した後、 java.lang.OutOfMemoryError: Java heap space エラーが発生します。
以下は、顧客向けのこのようなエラーに関する具体的な情報です。
- ログの問題は次のとおりです (キー部分のみが傍受されます)。
- この問題はお客様のテスト環境でのみ発生し、ローカルの開発環境では発生しません。
- テスト環境はプライベート クラウドにデプロイされ、Docker を使用してデプロイされます。
- インポートされたデータの量が 2W 行を超える場合、このエラーはインポートが成功してから常に約 1.2W で発生します。データ量が 1w 行未満の場合、この問題は発生しません。
java.lang.OutOfMemoryError: Java heap space この記事では、エラーを修正する方法を見てみましょう 。
Java ヒープ サイズとは何ですか?
ava ヒープ サイズは、Java 仮想マシン (JVM) の構成パラメータであり、JVM の実行時にヒープ メモリ サイズを指定するために使用されます。ヒープ メモリは、Java プログラムでオブジェクト インスタンスと配列を格納するために使用されるメモリ領域です。Java プログラムの実行中、動的に作成されたすべてのオブジェクトはヒープ メモリに格納されます。
Java ヒープ サイズは、Java プログラムのパフォーマンスと安定性にとって非常に重要です。ヒープ メモリが小さすぎると、JVM がプログラムの実行に必要なメモリを満たせないため、メモリ不足エラー (メモリ不足エラー) が発生する可能性があります。一方、ヒープ メモリが大きすぎると、ガベージ コレクションが頻繁に実行され、プログラムの応答時間とパフォーマンスに影響を与えます。
Java ヒープ サイズを調整することで、アプリケーションのニーズに応じてメモリ使用量を最適化できます。一般に、ヒープ メモリが大きいほど、大規模なデータ処理などのメモリを大量に使用するアプリケーションには有益ですが、軽量サービスなどの小規模なアプリケーションには、より小さいヒープ メモリが必要な場合があります。
Java では、Java ヒープ サイズは次のパラメータで設定できます。
- Xms: JVM の初期ヒープ メモリ サイズを指定します。
- Xmx: JVM の最大ヒープ メモリ サイズを指定します。
例：
java -Xms256m -Xmx1024m MyApp 上記のコマンドは、「MyApp」という名前の Java アプリケーションを起動し、初期ヒープ メモリ サイズを 256MB に、最大ヒープ メモリ サイズを 1024MB に設定します。
このエラーの一般的な理由は何ですか?
通常、次の 2 つの理由があります。
- Java ヒープ サイズの設定が小さすぎます。
- アプリケーションにメモリ リークが発生し、短期間に多数のオブジェクトが GC できなくなります。
このシナリオでは、次の理由から最初の原因をトラブルシューティングします。
- まず、この問題は Excel Importer の内部で発生しますが、このモジュールは何万回もダウンロードされ、長年にわたって公式によってメンテナンスされているため、問題が発生する可能性は非常に低いです。公式コンポーネントに絶対に問題がないとは言いませんが、確率的なトラブルシューティングの観点から、安定した部品ではなく壊れやすい部品を最初に確認するため、他の情報が不足している場合はそれが最善の選択となります。
- 次に、この問題は Excel Importer 内で発生しますが、ソース コードがありません。Excel Importer の問題であることが確認された場合でも、外部からその問題を回避することが第一の選択であり、この方法でのみプロジェクトを予定通りに完了することができます。
認証の問題
Java ヒープ サイズの設定が小さすぎることが原因かどうかを確認するために、次の 2 つの試みを行いました。
- ローカル開発環境 Mendix Studio Pro で Java ヒープ サイズを減らして、エラーが再現できるかどうかを確認します。設定方法は以下の通りです。
- ローカル開発環境で、10w 行を含む Excel ファイルをインポートして、エラーが再現できるかどうかを確認します。
上記の実験の後、Java ヒープ サイズを 512MB に設定し、データを 2w 個にインポートすると、同じエラーがポップアップすることがわかりました。
この現象は、Java ヒープ サイズが実際に小さすぎることを証明しています。
問題を解決するにはどうすればよいですか?
修復のアイデアは非常にシンプルで、Java ヒープ サイズを変更することです。
docker-mendix-buildpackのドキュメントでは 、コンテナーの環境変数が従属メソッドを通じて変更できることがわかります。
上の図のリンクを開いて cf- mendix-buildpack のドキュメントを入力します (docker-mendix-buildpack は実行時に cf-mendix-buildpack を呼び出します)。Java ヒープ サイズは次のように設定できることがわかります。
したがって、次のコマンドでコンテナを起動します。
docker run -it \
-e HEAP_SIZE=4096M
...
ただし、 HEAP_SIZE この環境変数を設定しただけでは、問題はまだ解決されていないことがわかりました。
その後、cf-mendix-buildpack のコードを読んだところ、次のことがわかりました。
- 設定されていない場合は 、 に従って自動的に設定
HEAP_SIZEできます 。limit - また、それ
HEAP_SIZEを超える 場合はlimit認められません。
そこで、 この環境変数limit を設定する方法を 見つけましたMEMORY_LIMIT 。
したがって、次のコマンドでコンテナを起動します。
docker run -it \
-e MEMORY_LIMIT=4096M
... ついに問題が無事解決しました！
要約する
- 問題の原因を分析する際、他の情報が不足している場合は、安定している部分ではなく、弱い部分を最初に調べることが最善の選択です。
- 少量の実験を行うことで、盲目的な推測に頼るのではなく、問題の根本原因をより確実に知ることができます。
- オープンソースツール、ソースコードをもっと見てみると、また違った収穫があるでしょう。
メンディックスについて
デジタルファーストの世界では、顧客はあらゆるニーズが満たされることを期待し、従業員は仕事を遂行するためのより優れたツールを期待し、企業は完全なデジタル変革によってのみ生き残り、成功できることを認識しています。シーメンスの企業である Mendix Corporation は、企業のデジタル変革を実現する存在として急速に成長しています。業界をリードするローコード プラットフォームと包括的なエコシステムは、最先端のテクノロジーを統合し、企業が対話性を向上させ、運用を簡素化し、IT ボトルネックを克服するソリューションを作成できるように支援します。Mendix は、抽象化、自動化、クラウド、コラボレーションの 4 つの柱により、開発者の生産性を大幅に向上させ、独自のエンジニアリング コラボレーション機能と直感的なビジュアル インターフェイスを利用して、テクノロジーに精通していない多数の「シチズン」開発者を支援しました。専門分野のアプリケーションを作成します。Mendix は、権威ある業界アナリストの目にはリーダーであり先見の明があるだけでなく、クラウドネイティブ、オープン、スケーラブル、機敏で実証済みのプラットフォームでもあります。人工知能や拡張現実から、インテリジェント オートメーションやネイティブ モビリティに至るまで、Mendix はデジタル ファースト ビジネスのバックボーンとなっています。Mendix のエンタープライズ ローコード プラットフォームは、世界中の 4,000 社を超える大手企業に採用されています。