IronOCRでは常に64ビットアーキテクチャを使用する
IronOCRは膨大なメモリを消費する作業をバックグラウンドで行うため、32ビット(x86)ビルドでは約2GBのメモリ上限に達し、大きなドキュメントや大量のドキュメント処理で失敗し始めます。 64ビット(x64)をターゲットにすることで修正されます。
32ビットのプロセスは、マシンがどれだけのRAMを持っていても、約2GBの使用可能メモリに制限されます。 この制限を下回ると、OCR作業は通常以下のように示されます:
System.OutOfMemoryException
同じ上限による他の症状には、OCRエンジン実行中のデッドロック、画像前処理でのリソース不足、クラッシュや未処理例外、またはタイムアウトや静かに失敗するOCR結果があります。
圧力はIronOCRが1ドキュメントあたりに行う操作からきます:高解像度画像レンダリング、一時ラスタリゼーション、光学文字認識、SearchablePDF出力に使用される機械学習モデルでの深いテキスト抽出。 これらの各操作は、1ドキュメントあたり数百MBの要求をすることがあり、マルチページPDF、マルチページTIFF、300+DPIの画像ではそれ以上に増加します。
解決策
オプション1:Visual Studioでプラットフォームターゲットを設定する
ビルド設定を通じてプロジェクトをx64に切り替えます:
- プロジェクトを右クリックしてプロパティを開きます。
- ビルドタブを開きます。
- プラットフォームターゲットを
x64に設定します。 - 32ビット優先を外します。
オプション2:CLIまたは.csprojからターゲットを設定する
64ビットランタイムに対して公開し、ビルド時にアーキテクチャを強制します:
dotnet publish -c Release -r win-x64
dotnet publish -c Release -r win-x64
またはターゲットを.csprojに直接固定します:
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
プロジェクトが<Prefer32Bit>false</Prefer32Bit>の行が重要です:これが有効な場合でも、アプリは依然として32ビットプロセスとして起動し、同じ上限を引き継ぎます。
アーキテクチャを疑うとき
OCRジョブが予期せず停止したりクラッシュしたり、時折発生するメモリ不足例外、高ボリューム文書でのパフォーマンス低下が見られる場合、最初にアーキテクチャを確認してください。 x86で実行している場合は、他を調査する前にx64に切り替えます。
本番環境でいくつかの習慣を持続する:
- 本番用にx64をターゲット:これは重いOCRワークロードに唯一サポートされている構成です。
- x64で開発: x64でのテストは現実のメモリ動作を反映し、初期段階で問題を発見します。
- 64ビットDockerイメージをビルド:ベースイメージが
linux/amd64であることを確認します。
並行OCR作業はメモリを急速に増加させます。小さな文書でも、マルチスレッドまたは非同期操作はすぐに上昇することがあります。
アーキテクチャを変更できない場合
x64がオプションでない場合は、大規模な文書をより小さなチャンクに分割し、低解像度で処理します。 パフォーマンスと精度にトレードオフを期待してください。 32ビットプロジェクトの安定したサポートは現在調査中です。

